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

MVP를 6개월 다듬는 진짜 이유

"이번 버전만 고치면 출시할 수 있어."

이 말을 3달째 반복하고 있다면, 솔직히 말하자. 출시 안 할 거다. 적어도 이 상태로는 안 한다. 본인은 그 사실을 이미 안다. 다만 인정하기 싫어서 또 onboarding 화면을 다시 그리고 있을 뿐이다. 나도 그랬다. 그래서 이 글을 쓴다.

인디 개발자가 출시를 못 하는 이유는 코드가 부족해서가 아니다. 시장이 안 보여서도 아니다. 두 단어로 정리된다. 매몰 비용과 완벽주의. 이 둘은 사이좋게 손잡고 본인을 6개월씩 잡아두는 중이다.

매몰 비용 오류 — 이미 쓴 시간이 미래를 망친다

1985년 Arkes와 Blumer가 단순한 실험을 했다. 영화관 시즌권을 무작위로 다른 가격에 팔았다. 한 그룹은 정가 100달러. 다른 그룹은 할인 50달러. 같은 영화, 같은 좌석, 같은 영화관. 그런데 100달러를 낸 사람들이 영화관에 더 자주 갔다. 영화가 재미없어도 갔다. "이미 100달러 썼으니까 안 가면 손해"라는 마음 때문이다.

이게 매몰 비용 오류(sunk cost fallacy)다. 핵심은 한 줄이다. 이미 쓴 비용은 미래 결정에서 빼야 합리적이다. 회수가 안 되니까. 그런데 인간 뇌는 그렇게 못 한다. 이미 쓴 게 아까워서, 손해 위에 손해를 더 얹는 길로 들어선다.

문제는 매몰 비용이 돈만이 아니라는 거다. 시간, 노력, 자존심, 새벽에 짠 코드 1만 줄. 전부 같은 회로를 점화한다. 인디 개발자는 그래서 위험하다. 본인은 6개월짜리 시즌권을 끊은 셈이다. 1,000시간을 부었다. 그 시간이 아까워서 출시 못 한다. 다듬는다. 다듬으면 시간이 더 쌓인다. 더 못 버린다. 더 다듬는다. 이게 6개월짜리 루프의 정체다.

여기서 뼈아픈 부분 하나. 다듬는 행동은 매몰 비용을 줄이는 게 아니다. 늘리는 거다. 본인은 "투자 회수 중"이라고 느낀다. 실제로는 정반대다. 다듬는 한 시간이 매몰 비용 한 시간을 더 얹는다. 그러니까 출시는 매일 더 무서워진다. 어제보다 오늘 더 못 낸다. 이게 6주 차에는 안 보였다가 6개월 차에 갑자기 보인다.

완벽주의는 매몰 비용의 가면이다

여기서 완벽주의가 끼어든다. 완벽주의는 보통 "기준이 높아서"라고 설명된다. 멋있게 들린다. 그런데 Adderholdt-Elliott이 1987년 Perfectionism: What's Bad About Being Too Good?에서 정리한 분류는 좀 다르다. 완벽주의에는 두 종류가 있다. 정상적 완벽주의와 신경증적 완벽주의. 정상적 완벽주의자는 기준에 도달하면 만족한다. 신경증적 완벽주의자는 기준이 도달할 때마다 한 발 더 도망간다. 만족점이 영원히 한 발 앞에 있다.

인디가 출시 직전 UI를 갈아엎는 건 정상적 완벽주의가 아니다. 신경증적 완벽주의다. 그리고 이게 핵심인데, 신경증적 완벽주의는 이미 쓴 시간을 정당화하는 방식으로 작동한다. "이만큼 만들었으면 적어도 이 정도는 돼야지." 이 문장이 머리에서 자동 재생된다. 이게 매몰 비용 회로가 쓰는 명함이다.

즉 완벽주의는 매몰 비용이 쓰는 가면이다. 둘은 같은 회로의 두 이름이다. 본인이 "이건 완벽주의 때문이야"라고 자위하는 동안, 회로는 "이건 매몰 비용 때문이야"라고 비웃고 있다.

솔직히 말하면, 내 사례

한 번은 출시 일주일 전에 UI를 통째로 갈아엎은 적 있다. 정확히는 "갈아엎어야 할 것 같은 느낌"이 들었고, 그 느낌을 따랐다. 폰트 시스템부터 다시 짰다. 컬러 토큰을 새로 정의했다. 화면 12개를 다 다시 그렸다. 그 작업이 3개월 걸렸다. 출시는 그만큼 미뤄졌다.

그 3개월 동안 사용자는 0명이었다. 그건 확실하다. 갈아엎은 UI가 객관적으로 더 나았는가? 지금 돌이켜 보면 잘 모르겠다. 다만 그때 머릿속에서 자동 재생되던 문장은 정확히 이거였다. "이만큼 했는데 이 수준으로 출시하기엔 아깝다." 시간이 아까운 게 아니었다. 시간이 이미 들어가서 아까웠다. 영화관 시즌권 100달러랑 똑같다.

더 솔직히 말하면, 그보다 전에 묻은 사이드 프로젝트도 있다. 버전 0.1을 만들어 놓고 출시는 못 하고 기능만 계속 추가한 앱. 처음엔 "한 가지만 더 넣고 출시"였다. 한 달 뒤엔 "두 가지만 더". 세 달째에 onboarding을 다시 만들었다. 다섯 달째에는 코드베이스가 무거워서 새 기능 추가가 느려졌다. 결국 출시 안 했다. 정확히 말하면 못 한 게 아니라 안 했다. 그 시점엔 출시할 수 있었다. 다만 "이 정도로는 안 되지"라는 자아의 목소리가 더 컸다. 그 앱은 지금 폴더 어딘가에서 자고 있다. 사용자 0명짜리 무덤이다.

3개월 뒤에 출시한 다른 앱이 일주일 전 버전보다 사용자한테 더 의미 있었는가. 솔직히 모르겠다. 다만 본인 마음은 그 3개월로 평온해졌다. 매몰 비용은 사용자가 아니라 본인의 자아를 위한 비용이다. 그게 진짜 무서운 부분이다. 자아가 비싸지면 사용자가 멀어진다.

탈출 프레임 — '지금 출시 안 하면 더 손해'

매몰 비용 회로를 끊는 건 의지의 문제가 아니다. 프레임의 문제다. 본인은 보통 이렇게 묻는다. "지금 버리면 6개월이 손해 아닌가?" 잘못된 질문이다. 6개월은 이미 지나갔다. 회수 안 된다. 그 6개월은 어떤 결정을 내려도 안 돌아온다.

질문을 이렇게 바꾼다. "지금 출시 안 하면 다음 6개월도 잃는다." 이게 진짜 손해다. 매몰 비용은 과거에 묻혔지만, 출시 안 함은 미래를 매일 갉아먹는다. 매일 사용자 0명, 매일 피드백 0개, 매일 본인 자신감 -1. 6개월 더 다듬어 봐야 다음 6개월도 0이다. 그동안 시장은 움직이고 경쟁자는 출시하고 본인 의욕은 마른다.

회로를 강제로 끊는 한 줄짜리 질문이 있다. 다듬고 싶어질 때마다 본인한테 묻는다. "지금 이 코드를 누가 1주일 전에 본인한테 줬다면, 본인은 거기에 3개월을 더 쓰겠는가?" 답이 "아니다"라면, 지금 다듬고 있는 3개월도 안 써야 한다. 이미 들어간 시간은 결정에서 빼야 한다. Arkes & Blumer가 40년 전에 한 말이다. 한 줄로 회로가 끊긴다.

그리고 한 가지 더. 출시는 종료가 아니라 입구다. v1.0은 v1.1로 가는 문이다. 출시 후에 폰트 바꿔도 된다. 화면 갈아엎어도 된다. 다만 그땐 사용자 데이터를 가지고 한다. 출시 전 갈아엎기는 본인 머릿속 데이터로 한다. 둘은 완전히 다른 작업이다. 머릿속 데이터는 매몰 비용 회로에 오염돼 있다. 사용자 데이터는 안 그렇다.

못생긴 v1이 없으면 v2도 없다

매몰 비용은 본인의 자아를 위한 보험이고, 사용자 피드백은 앱을 위한 보험이다. 둘 중 어느 쪽에 시간을 쓸지는 본인이 정한다.

본인이 6개월 차에 출시 못 하고 있다면, 코드가 부족한 게 아니다. 이미 너무 많이 부었기 때문이다. 그게 출시를 막는 진짜 이유다. 인정하기 싫지만 그렇다. 나도 그랬다.

오늘 할 일 하나. 출시일을 캘린더에 박는다. D+14든 D+30이든. 그날 기능이 부족해도 올린다. 못생긴 v1을 낸다. 그래야 v2가 나온다. 못생긴 v1이 없으면 v2도 없다. 6개월 더 다듬은 v1보다, 못생긴 채로 1주일 만에 받은 사용자 욕 10개가 앱을 더 빨리 좋게 만든다.

이번 버전만 고치면 출시할 수 있다는 그 말. 3달째 반복하고 있다면, 그 말 자체가 매몰 비용이 보내는 신호다. 그 신호가 켜지는 순간이 출시할 순간이다.

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