1인 개발자가 반복하는 실수 5가지 — 직접 겪고 나서야 알게 된 것들
기능보다 제약이 먼저입니다. 방향이 틀리면 기능이 쌓일수록 더 돌아가야 합니다.
지금 돌아보면 부끄럽지만, 저는 프로젝트마다 비슷한 실수를 반복했습니다. 코드를 다 짜고 나서야 “이건 안 되는 거였어”를 알게 되는 경험, 1인 개발자라면 한 번쯤 겪어봤을 겁니다. 규모가 크지 않아서 회의도 없고, 검토자도 없고, 그냥 혼자 달리다가 벽에 부딪히는 방식으로요.
제가 여러 프로젝트를 거치면서 겪은 삽질 다섯 가지를 공유합니다. 개별 에피소드로 보면 “그런가 보다” 싶은데, 뒤에 나오는 메타 패턴을 보시면 사실 다 같은 실수였다는 게 보입니다.
삽질 1 — 기능 다 만들고 규제에 막힌 주식 앱
주식 포트폴리오 앱(자람)을 만들었습니다. 백엔드 API 연동, 실시간 시세 조회, 매수·매도 시뮬레이션까지 꽤 많이 구현했을 때였어요. 그런데 KIS(한국투자증권) 약관을 꼼꼼히 읽다가 한 줄이 눈에 들어왔습니다.
“핀테크사는 타인의 계좌를 대행하여 주문·조회를 수행할 수 없습니다.”
유사투자자문업 규제까지 따지면, 제가 만들려던 서비스 구조 자체가 법적으로 회색지대였습니다. 설계 전에 이 한 줄을 봤다면 방향이 완전히 달랐을 겁니다. 코드가 꽤 쌓인 시점에서 멈추는 건, 백지에서 다시 시작하는 것보다 훨씬 더 힘든 일이었습니다.
이때 배운 것: 규제·법적 제약은 기능을 만들기 전에 확인해야 합니다. 기능은 나중에 얼마든지 추가할 수 있지만, 사업 구조는 쉽게 바꾸기 어렵습니다.
삽질 2 — 미술관인데 쇼핑몰 기능부터 만든 경우
한새암 미술관 프로젝트에서는 시작부터 “어떤 기능을 만들 것인가”로 달려들었습니다. 작품 판매 기능, 결제 연동, 배송 관리… 개발자로서 꽤 구체적인 그림이 있었거든요.
그런데 실제로 작가와 이야기를 나눠보니, 원하는 게 달랐습니다.
“판매보다는 보여주는 게 중요해요.”
미술관은 갤러리였습니다. 파는 곳이 아니라 보여주는 곳. 제가 만든 쇼핑몰 기능은 처음부터 방향이 틀렸던 겁니다. 결국 강의 협업 카드도 제거하고, 연락처도 “작품 문의만”으로 좁혔습니다. 처음에 “이 서비스의 정체성이 뭔가요?”를 먼저 물었다면 삽질이 없었을 텐데요.
이때 배운 것: “기능”보다 “정체성”이 먼저입니다. 사용자(혹은 의뢰인)가 진짜 원하는 게 뭔지 확인하기 전까지는, 어떤 기능을 만들어도 방향이 틀릴 수 있습니다.
삽질 3 — 사업자 분리가 절세라는 오해
개발 수익(율소프트, 용역)과 서비스 수익(슬로우루프랩)을 분리하면 세금이 줄어들 거라고 생각했습니다. 법인 두 개면 소득이 나뉘니까요. 그래서 실제로 사업자를 분리했습니다.
그런데 종합소득세 구조를 제대로 이해하고 나니, 개인사업자를 여러 개 갖고 있어도 연말에 소득이 합산된다는 걸 알게 됐습니다. 분리 행동이 세금 구조 이해보다 먼저였던 결과였습니다.
이때 배운 것: 행동보다 구조 이해가 먼저입니다. 특히 세금·법 같은 영역은 “일단 해보고 수정”이 잘 안 됩니다. 수정 비용이 실행 비용보다 훨씬 크거든요.
삽질 4 — CLAUDE.md 규칙을 20개 넣었더니 준수율이 내려간 사건
Claude Code를 쓰면서 프로젝트 지침 파일(CLAUDE.md)에 규칙을 계속 추가했습니다. 코딩 스타일, 커밋 형식, 파일 구조, 문서화 방식… 좋은 규칙들이었지만 숫자가 20개를 넘어가자 이상한 일이 생기기 시작했습니다. 규칙이 있는데 안 지켜지는 거예요.
알고 보니 컨텍스트 희석이 실제로 발생했습니다. 규칙이 많아지면 LLM이 세션마다 관련 없는 규칙까지 로드하고, 정작 중요한 규칙의 가중치가 낮아집니다. 20개 규칙이 다 중요하면 결국 아무것도 중요하지 않은 것과 같습니다.
claude-code-4레버-방법론에서 이 문제를 더 자세히 다뤘는데, 핵심은 글로벌/프로젝트/이슈별로 분리하고 이슈 섹션은 끝나면 반드시 제거하는 것입니다.
이때 배운 것: 정체성을 흐리는 것은 기능이나 규칙 모두 마찬가지입니다. 줄이는 것도 설계의 일부입니다.
삽질 5 — 791KB 세션에서 중요한 작업을 놓친 사례
세션 하나가 791KB였습니다. 한 세션에서 여러 작업을 처리하다 보면 이런 일이 생깁니다. 나중에 소화할 때 세션 제목(첫 메시지)이 “마이위키 설계”였으니, 마이위키 설계 결과만 정리했습니다.
그런데 실제로는 그 세션 안에 product-pipeline 스킬 신설 작업도 완료돼 있었습니다. 세션 끝부분의 긴 대화 구간, 코드 없이 텍스트만 오가는 구간이 신호 밀도가 가장 높은데 거기서 놓친 거예요.
에이전트-컨텍스트-끊김-second-브레인-통합을 읽어보시면 이 문제를 어떻게 구조적으로 해결했는지 볼 수 있습니다.
이때 배운 것: 제목이 내용을 보장하지 않습니다. 큰 세션은 실제 작업 완료 마커를 직접 스캔해야 합니다.
메타 패턴 — 다섯 삽질의 공통점
정리하고 나니 다 같은 실수였습니다.
- 제약부터 — 기능보다 규제·법·사용자 의도를 먼저 확인했어야 했습니다
- 우회 ≠ 통과 — 문제를 우회하면 나중에 더 크게 돌아옵니다
- 희석 금지 — 정체성을 흐리는 것은 기능이든 규칙이든 결국 제거됩니다
- 구조 이해 먼저 — 행동보다 “왜 이렇게 하는가”가 먼저여야 합니다
- 소화할 때 범위 체크 — 제목이나 외형보다 실제 내용을 직접 확인해야 합니다
1인 개발자는 이 모든 것을 혼자 판단해야 합니다. 그래서 반복 실수가 더 쉽게 일어납니다. 팀이 있으면 누군가가 “그거 법적으로 괜찮아?”라고 물어봤을 테니까요.
다음 프로젝트를 시작하기 전에, 규제·법적 제약·핵심 사용자의 정체성부터 확인해보세요. 기능은 나중에 얼마든지 추가할 수 있지만, 방향이 틀리면 기능이 쌓일수록 더 돌아가야 합니다.
방법: Claude Code를 잘 쓰는 4가지 레버 · 심화: product-pipeline 스킬 · 심화: 에이전트 컨텍스트 끊김과 세컨드브레인 통합 · 함께 보기: 주식앱 AI 에이전트 개발 노하우 · 함께 보기: 집서버 주식앱 배포 삽질기