2026년 4월 · GoCodeLab · 개발자 멘탈

0→1은 재밌는데 1→100이 안 되는 이유

앱 만들 때 새벽 3시까지 코딩한 적이 있는데 출시 후 업데이트를 3달째 미루고 있다면, 본인 얘기다. 그리고 본인 얘기다.

본인은 작년에 사이드 프로젝트 하나를 17일 만에 만들었다. 첫 9일은 잠을 거의 안 잤다. 새벽 4시에 자고 8시에 일어나서 또 코딩을 했다. 카페에 노트북을 들고 가서 점심을 거르고 코딩을 했다. 재밌었기 때문이다. 누가 시킨 것도 아니고 돈이 들어오는 것도 아니었는데 본인은 그 17일이 그 해에 가장 살아있는 시간이었다고 지금도 기억한다.

그 앱을 출시한 게 2주 뒤다. 그리고 한 달 뒤부터 업데이트를 안 했다. 사용자 피드백 메일이 왔는데 답장을 6일째 미뤘다. 버그 리포트 하나가 GitHub Issues에 떠 있는데 반 년째 안 닫혀 있다. 본인은 그 앱을 방치하고 있다. 만들 때 그렇게 신났던 사람이 맞나 싶을 정도로.

이 사이클이 본인에게만 있는 게 아니라는 걸 알고 나서 본인은 좀 안심했다. 그리고 왜 이렇게 되는지가 궁금해졌다. 본인이 게으른 거라는 결론으로는 설명이 부족했다. 그 17일 동안 본인은 누구보다 부지런했기 때문이다.

플로우 — 도전과 기술이 맞물리는 좁은 구간

Csikszentmihalyi라는 헝가리계 미국 심리학자가 1990년에 Flow: The Psychology of Optimal Experience라는 책을 냈다. 사람이 일에 완전히 몰입해서 시간 감각이 사라지는 상태를 플로우(flow)라고 부른 사람이 이 사람이다. 본인도 새벽 3시까지 코딩하다가 시계 보고 벌써? 했던 그 상태가 정확히 플로우다.

Csikszentmihalyi가 그린 유명한 그림이 하나 있다. 가로축은 기술 수준, 세로축은 도전 난이도다. 기술이 너무 높고 도전이 너무 낮으면 지루함이 온다. 도전이 너무 높고 기술이 부족하면 불안이 온다. 두 축이 균형 있게 같이 올라가는 좁은 대각선 띠 안에서만 플로우가 발생한다. 이 띠를 플로우 채널이라고 부른다.

여기서 중요한 건, 플로우 채널은 고정된 자리가 아니다라는 점이다. 본인이 코딩을 잘하게 될수록 같은 작업은 도전이 아니라 지루함이 된다. 그래서 플로우를 유지하려면 기술이 늘어난 만큼 도전도 같이 올려야 한다. 이걸 안 올리면 같은 일이 갑자기 재미없어진다. 본인이 그 17일을 그렇게 신나게 보낼 수 있었던 이유는, 그 시기의 본인 기술 수준에 처음 만드는 앱이라는 도전 난이도가 정확히 맞았기 때문이다.

1→100 구간이 플로우 채널 바깥인 이유

문제는 출시 이후다. 출시 이후의 작업은 도전 난이도가 갑자기 떨어진다.

새 기능을 만드는 게 아니라, 이미 만든 기능의 버그를 고치는 일이다. 새로운 디자인을 짜는 게 아니라, 사용자가 왼쪽 버튼이 안 보여요라고 한 걸 5픽셀 옮기는 일이다. 새 화면을 짜는 게 아니라, iOS 18 호환성 패치를 하는 일이다. 이 작업들은 본인의 기술 수준에서 보면 너무 쉬운 작업이다. 그래서 플로우 채널 바깥의 지루함 영역으로 떨어진다. 지루함이라는 감정은 의지력으로 못 이긴다. 본인이 해야 한다고 아무리 자기 자신을 다그쳐도, 뇌가 그 작업에 잘 안 붙는다.

게다가 1→100 구간은 보상의 구조도 달라진다. 만들 때는 오늘 만든 것이 곧바로 손에 잡혔다. 어제 없던 화면이 오늘 생겼다. 그 자체가 도파민이었다. 출시 이후엔 오늘 한 일이 어제 있던 걸 그대로 유지하는 일이다. 사용자 입장에선 잘 돌아가는 게 디폴트고, 잘 돌아가게 만드는 본인의 노동은 안 보인다. 보이지 않는 노동에는 피드백이 안 온다. 피드백이 안 오면 플로우의 핵심 조건 하나가 빠진다. Csikszentmihalyi가 플로우의 8가지 조건을 정리했는데, 그 중 하나가 즉각적인 피드백이다. 출시 이후의 일은 그 조건을 거의 다 못 충족한다.

자기결정이론 — 내재 동기가 외재 보상으로 대체될 때

여기서 두 번째 이론이 등장한다. Deci와 Ryan이라는 두 심리학자가 2000년에 Self-Determination Theory(SDT)를 정리했다. 동기를 내재 동기와 외재 동기로 나누고, 어떤 조건에서 사람이 어떤 일을 지속하는지를 다룬 이론이다.

내재 동기는 그 일 자체가 재밌어서 하는 동기다. 본인이 17일 동안 코딩한 이유가 이거다. 외재 동기는 그 일을 하면 뭐가 따라오니까 하는 동기다. 출시 이후엔 다운로드 수, 매출, 별점, 트위터 반응이 본인의 동기 자리를 차지한다.

SDT에서 가장 흥미로운 결론 중 하나가 과정당화 효과(overjustification effect)다. 원래 재미있어서 하던 일에 외부 보상이 붙으면, 보상이 사라졌을 때 그 일에 대한 흥미가 원래 수준보다 더 떨어진다. 보상이 들어오는 동안 뇌가 이건 보상 때문에 하는 일이라고 재분류해버리기 때문이다. 그 다음부터는 보상이 멈추면 일도 멈춘다.

본인이 출시 직후에 다운로드 수에 매달렸던 게 정확히 이 함정이다. 만드는 것 자체가 재밌어서 코딩하던 본인이, 출시 후엔 다운로드 수가 올라야 코딩하는 본인이 됐다. 다운로드 수가 안 오르자 본인은 코딩할 이유를 잃었다. 17일 동안 본인을 새벽 3시까지 깨워뒀던 그 동기는, 출시 후 2주 만에 다운로드 100명이라는 외부 지표로 대체됐고, 그 지표가 기대만큼 안 오르자 통째로 꺼졌다.

SDT는 내재 동기를 유지하기 위한 세 가지 조건도 제시한다. 자율성(autonomy), 유능감(competence), 관계성(relatedness). 자율성은 본인이 정한 방식으로 한다는 감각, 유능감은 점점 잘하고 있다는 감각, 관계성은 누군가와 연결되어 있다는 감각이다. 만들 때는 셋 다 충족된다. 본인이 정한 일정으로 본인이 정한 기능을 만들고, 매일 새 코드를 쓰면서 유능감을 느끼고, 빌드 인 퍼블릭으로 누군가와 연결된 느낌을 받는다. 출시 이후엔 셋이 다 약해진다. 사용자 피드백이 일정을 흔들고(자율성↓), 같은 일을 반복하면서 유능감을 못 느끼고(유능감↓), 사용자가 늘어도 그 사람들이 본인을 알아주는 게 아니라 앱을 알아주기 때문에 관계성도 약하다.

ojin 사례 — 출시 직후 신남, 2주 후 귀찮음, 한 달 후 방치

본인의 패턴을 솔직하게 적으면 이렇다.

출시일에 본인은 트위터에 출시 글을 올린다. 좋아요가 박힌다. 다운로드 수가 첫날에 80명 정도 찍힌다. 본인은 그날 밤 신나서 다음 기능을 기획한다. 캘린더에 주간 업데이트를 매주 수요일로 적어놓는다.

첫 주 업데이트는 한다. 신나서. 두 번째 주 업데이트는 미룬다. 한 번 미루기 시작하면 지난 주에 못 한 것과 이번 주에 할 것이 합쳐져서 도전 난이도가 한 번에 두 배로 뛴다. 두 배가 된 도전을 보면 일단 안 한다. 그렇게 3주가 지나면 원래 만들고 싶었던 것과 지금까지 안 한 것의 격차가 너무 커져서 본인은 그 앱을 덮는다. 그 다음에 본인은 새 프로젝트를 시작한다. 새 프로젝트는 도전 난이도와 본인 기술이 다시 맞물리는 0→1 구간이기 때문이다. 본인은 또 17일 동안 새벽 3시까지 코딩한다. 그 다음에 또 출시한다. 또 방치한다. 이게 본인의 사이클이다.

유지보수도 플로우가 가능한가 — 작은 도전 재설계

해결책을 거창하게 제시하긴 어렵다. 본인도 아직 이 사이클을 못 깼다. 다만 Csikszentmihalyi와 SDT를 이해하고 나서 본인이 시도하는 가벼운 재설계 두 가지가 있다.

첫째, 유지보수 작업에 도전 난이도를 인위적으로 더한다. 같은 버그를 고치더라도 30분 안에라는 시간 제약을 건다. 단순 패치 PR을 코드 리팩토링과 같이라는 약간의 추가 도전과 묶는다. 도전 난이도가 본인 기술 수준 근처로 다시 올라오면 그 작업은 지루함 영역에서 플로우 채널 쪽으로 조금 이동한다. 이게 완벽하진 않지만, 해야 한다고 자신을 다그치는 것보단 효과가 있었다.

둘째, 외부 보상 지표를 안 본다. 다운로드 수, 매출, 별점을 출시 후 첫 한 달 동안만 보고 그 다음엔 대시보드를 끈다. 외부 지표가 본인의 내재 동기를 잡아먹는 걸 막기 위해서다. 대신 오늘 본인이 어떤 코드를 썼는지를 본인 노트에 적는다. 만드는 행위 자체로 다시 동기를 회복하려는 시도다.

본인은 이 두 가지로 사이클이 다 풀렸다고는 못 말한다. 다만 본인의 게으름이 아니라 플로우 채널의 구조와 내재 동기의 대체라는 두 가지 메커니즘이 작동하고 있다는 걸 알고 나서, 본인은 자책을 좀 덜 하게 됐다. 1→100을 못 가는 건 본인이 잘못된 게 아니라, 1→100 구간이 원래 0→1 구간만큼 재밌게 설계되어 있지 않은 것이다. 그 차이를 메우는 건 다른 종류의 일이고, 의지력으로 메우는 일이 아니라 환경을 다시 짜는 일에 가깝다.

오늘도 GitHub Issues에 닫히지 않은 이슈 하나가 떠 있다. 본인은 오늘 그걸 30분 타이머를 걸고 열어볼 생각이다. 그게 본인이 지금까지 찾은, 자책 안 하는 가장 가벼운 시작이다.

이 글은 2026년 4월 기준이다. 인용한 연구는 시간이 지나도 변하지 않지만, 본인의 해석은 더 나은 데이터로 바뀔 수 있다.