
지난 겨울 토요일 새벽 2시, 앱 아이콘 색깔 하나를 세 시간째 고치고 있었어요. 6년차 개발자가 코드도 아니고 아이콘 앞에서 멈춰있었습니다.
웃긴 건, 그 반년짜리 프로젝트에서 정작 코딩에 쓴 시간이 전체의 30%도 안 됐다는 사실입니다. 제일 자신 있던 일이 제일 작은 조각이었던 거죠. 회사 안에서는 절대 안 보이던 제 구멍들이, 혼자 다 짊어지고 나서야 하나씩 드러나더라고요.
6년차에 또 사이드 프로젝트를 시작한 이유
솔직히 회사 일이 매너리즘이었어요. 잘 굴러가는 시스템에 부품 하나 끼우는 느낌이랄까요. 0에서 1을 만들어본 지 너무 오래됐다는 갈증이 컸습니다.
그래서 안드로이드 스튜디오(Android Studio) 열고 가볍게 시작했죠. 머릿속 계산은 "MVP니까 한 달이면 되겠지"였어요. 흔히들 말하는 4~6주 통념을 저도 그대로 믿었습니다.
근데 막상 스토어에 올리기까지 6개월이 걸렸어요. 이게 제가 특별히 느려서가 아니었어요. 커뮤니티 회고들을 찾아보니 9개월간 스택을 세 번 갈아엎은 사례도 있고, "6개월"은 오히려 흔한 구간인 경우가 많았습니다.
중간에 깨달은 게 하나 있어요. 의욕으로만 굴리면 무조건 멈추거든요. 그래서 "토요일 2시간은 무조건 앉는다" 같은 주간 최소치를 정해놓고 규율로 끌고 갔어요. 동기 부여가 아니라 경계를 긋는 거였죠.
기획·설계를 혼자 지면서 드러난 1인 개발의 약점
회사에선 PO가 우선순위를 잘라주고, 디자이너가 화면을 그려주고, QA가 버그를 잡아줬어요. 그게 다 사라지니까 의사결정 피로가 어마어마했어요.
버튼 하나 위치 정하는 데 30분씩 고민하는 저를 보면서 좀 멍해졌습니다. 그제야 알았어요. 회사에서 제가 잘했던 것 중 절반은 '제 실력'이었고, 나머지 절반은 'CI/CD, 코드 리뷰어, 동료' 같은 조직 인프라였다는 걸요.
공수 예측도 계속 빗나갔어요. "이건 이틀이면 끝나지" 한 게 일주일씩 걸리고, 2~3배는 우습게 넘어가더군요. 혼자라 검토해줄 사람이 없으니 잘못된 길로 한참 가다 되돌아오는 일이 잦았습니다.
결국 초기에 그렸던 기능 12개를 5개로 줄였어요. 욕심을 못 버리면 영원히 출시 못 한다는 걸, 범위가 폭주하고 나서야 인정했습니다.

출시 직전 가장 오래 붙잡은 비개발 업무 3가지
여기서부터가 진짜였어요. 코드는 다 짰는데 출시가 안 되는 거예요. 막혀있던 게 전부 개발이 아닌 일들이었거든요.
- 앱 아이콘 제작 — 디자인 감각이 없으니 색 하나에 세 시간씩 날렸어요.
- 개인정보처리방침 작성 — 법적 문구라 함부로 쓸 수도 없더라고요.
- 스토어 스크린샷과 설명 카피 — 이게 의외로 제일 어려웠습니다.
특히 플레이 콘솔 심사에서 1차 반려를 맞았어요. 권한 사용 설명을 빠뜨렸다는 이유였죠. 코드는 멀쩡한데 서류에서 막히니까 좀 허탈하더군요.
이 비개발 업무들에만 2~3주가 추가로 들어갔습니다. 후반부 시간의 대부분을 엔지니어링이 아닌 일에 썼다는 얘기예요. 카피라이팅, 가격 고민, 문구 다듬기. 6년차 개발자가 회사 밖에서 완전한 초보가 되는 구간이었습니다.

회사 코드 습관과 1인 개발 코드 습관이 갈라진 지점
이건 좀 뼈아픈 발견이었어요. 회사에선 리뷰 통과시키려고 미리 추상화를 깔아두는 습관이 있었거든요. 인터페이스 만들고, 레이어 나누고, 확장 대비하고요.
혼자 할 땐 그게 다 독이 됐어요. 빠른 검증이 먼저인데 과하게 설계하니 진도가 안 나갔습니다. 그래서 반대로 "일단 동작하면 OK" 모드로 막 짰더니, 이번엔 3개월 뒤에 제 코드를 제가 못 알아보겠더군요.
테스트도 문서도 생략했으니 당연한 결과였어요. 회사에서 30분이면 잡던 버그를, 개인 프로젝트에선 2시간씩 헤맸습니다. 무슨 의도로 짠 코드인지 단서가 하나도 안 남아있었으니까요.
여기서 배운 건 명확합니다. 1인 개발 코드는 '3개월 뒤의 나'를 위해 써야 한다는 점이에요. 그 사람은 완전히 남이거든요. 과한 추상화는 빼되, 왜 이렇게 짰는지 한 줄 메모는 남겨야 한다고 봅니다.
반년을 돌아보며 다음 1인 개발에 다르게 할 것
가장 크게 깨진 착각은 "좋은 제품이면 알아서 퍼진다"였어요. 전혀요. 출시는 결승선이 아니라 마케팅의 출발선이더라고요.
Indie Hackers 회고에서 본 한 인디 개발자는 4년간 26개 프로젝트를 냈는데 18개가 1원도 못 벌었다고 해요. 무수익 비율이 69%인 셈입니다. 발견되고, 신뢰받고, 결제받는 일이 개발보다 훨씬 어렵다는 거죠. AI로 만드는 속도는 빨라졌지만, 그만큼 다들 쏟아내니까 주목받기 경쟁은 오히려 더 치열해졌습니다.
번아웃의 정체도 알게 됐어요. 앱의 실패가 곧 '나의 실패'로 느껴질 때 시작되더라고요. 결과와 자아 사이에 완충재가 하나도 없으니까 다운로드 수에 제 기분이 출렁였습니다.
그래서 다음엔 세 가지를 다르게 하려고 해요. 코드보다 검증을 먼저, 범위는 처음부터 절반으로, 그리고 개발만큼 마케팅 시간을 따로 떼어두는 것. 이 셋이 핵심이에요.
"빨리 잘 만들기"와 "작게 검증하고 알리기" 중에 저는 후자를 택하기로 했어요. 전자는 6년 동안 회사에서 충분히 단련된 근육이었지만, 막상 혼자 서보니 저를 멈춰 세운 건 늘 후자 쪽이었거든요. 반년을 통째로 갈아 넣고 나서야 알았습니다. 혼자 만들어보기 전엔, 내 실력 중 어디까지가 진짜 내 것이었는지 영영 모른다는 걸요. 그 답을 확인한 것만으로도 이번 6개월은 손해가 아니었어요.

'개발 일지' 카테고리의 다른 글
| 한 회사 6년차 개발자의 손익계산서 — 이직 안 한 게 손해였을까 (0) | 2026.07.13 |
|---|---|
| 6년차 개발자가 매번 검색하는 코드와 절대 안 까먹는 것들 (0) | 2026.07.12 |
| 샤워하다 해법이 떠오른다면, 당신은 퇴근에 실패한 겁니다 (0) | 2026.07.11 |
| 주니어 멘토링 1년, 가르치다 시니어 개발자가 더 배운 5가지 (0) | 2026.07.10 |
| Kotlin/Wasm 증분 컴파일로 바뀐 KMP 빌드, 6.8초의 일주일 (0) | 2026.06.18 |