1인 스타트업 실행 (2): 에이전트와 함께 제품 만들기#

아이디어를 골랐다면 이제 만들 차례입니다. 이 장은 코딩 에이전트와 함께 혼자서 제품을 만드는 과정을 다룹니다. 어떤 언어나 프레임워크를 쓸지가 아니라, 에이전트가 코드를 쓰는 시대에 사람이 어디에 서야 하는지, 무엇을 남기고 무엇을 검토해야 하는지, 그리고 무엇을 직접 만들지 말아야 하는지에 대한 이야기입니다. 필자가 회사에서 개발 프로세스를 다시 짜면서 겪은 논쟁과, 개인 프로젝트에서 내린 결정들이 바탕입니다.

만드는 비용이 내려가면 병목은 다른 곳으로 옮겨 갑니다#

코딩 에이전트가 들어오면 가장 먼저 체감하는 것은 “코드가 빨리 나온다"는 사실입니다. 그런데 몇 주 지나면 다른 사실을 발견합니다. 코드가 빨리 나오는 만큼 검토해야 할 것이 빨리 쌓인다는 것입니다. 에이전트가 만드는 변경량은 사람이 한 줄씩 읽는 속도를 쉽게 넘어섭니다. 1인 스타트업에서는 그 사람이 창업자 한 명입니다.

그래서 에이전트 시대의 제품 개발은 “어떻게 더 빨리 만들까"가 아니라 “무엇을 검토하고 무엇을 자동으로 보장할 것인가” 의 문제가 됩니다. 이 장의 모든 내용은 이 한 문장에서 나옵니다.

실행 가능한 초안과 프로덕션의 경계#

회사에서 겪은 사례 하나로 시작하겠습니다. 기획자가 코딩 에이전트로 프론트엔드 프로젝트에서 직접 화면 변경과 기능 추가를 시도할 수 있게 되었습니다. 별도 브랜치에서 리뉴얼 방향을 직접 구현했고, 기존 API를 쓸 수 있는 부분은 실제 동작까지, API 변경이 필요한 부분은 가짜 데이터로 화면을 구성했습니다. 매우 강력한 방식입니다. 기획서를 쓰는 데서 멈추지 않고 실제로 움직이는 화면을 만들 수 있으니까요.

하지만 동시에 문제가 생겼습니다. 내부 모듈 재사용, 기존 구조와의 정합성, API 경계, 상태 관리 같은 개발적 고려가 반영되지 않았고, 코드 변경량은 사람이 정상적으로 리뷰하기 어려운 수준으로 커졌습니다. 그리고 더 근본적인 문제가 있었습니다. 코드는 의도를 보존하지 않습니다. 화면은 “무엇이 바뀌었는가"를 보여 주지만, “왜 그렇게 바뀌었는가”, “어떤 대안이 있었는가”, “무엇을 포기했는가”, “정상 동작의 기준이 무엇인가"는 화면만으로 알 수 없습니다. 에이전트가 변경된 코드를 보고 작성한 설명 문서는 원래 의도라기보다 이미 만들어진 결과를 그럴듯하게 해석한 사후 설명이 되기 쉽습니다. 개발자는 의도를 전달받는 것이 아니라 diff를 보며 의도를 역추론해야 했습니다. 협업이라기보다 고고학에 가까웠습니다.

혼자 일하는 1인 스타트업이라면 이 문제가 없을까요? 오히려 더 교묘하게 나타납니다. 기획자와 개발자가 같은 사람이니 의도 전달 문제는 없어 보이지만, 3주 뒤의 나는 다른 사람입니다. 에이전트에게 “이렇게 바꿔 줘"라고 말하고 결과를 받아 넘긴 변경이 수십 개 쌓이면, 어느 결정이 확정이고 어느 것이 임시인지, 왜 그 구조를 택했는지 본인도 기억하지 못합니다. 에이전트는 기억하지 못하고(세션이 끝나면 잊습니다), 코드에는 적혀 있지 않습니다.

그래서 필자가 세운 첫 번째 원칙은 에이전트의 산출물을 “실행 가능한 초안"으로 본다는 것입니다. 초안은 빠르게 만들어 의도를 검증하는 데 쓰고, 그것을 프로덕션 품질로 승격시키는 경로를 따로 둡니다. 그 경로에는 최소한 다음 단계가 있습니다.

1. 제품 의도 검토: 이 변경이 어떤 사용자 흐름을 바꾸는가
2. 설계 정합성 검토: 기존 구조, 모듈, 디자인 시스템과 맞는가
3. API 및 데이터 계약 정리: 어떤 API가 필요하고 기존과 무엇이 달라지는가
4. 가짜 데이터 제거 계획: 임시 데이터가 어디에 남아 있는가
5. 하네스 검증: 타입, 테스트, 계약 검사, 시각 회귀, 스테이징
6. 배포 및 롤백 계획

혼자일 때 이 단계들은 회의가 아니라 체크리스트입니다. 에이전트에게 “구현해 줘” 대신 “구현하기 전에 이 변경이 바꾸는 사용자 흐름, 필요한 API 변경, 임시 데이터 위치, 확정된 결정과 미정인 부분을 먼저 정리해 줘"라고 요청하면, 초안과 함께 의도 문서가 남습니다. 그 문서가 3주 뒤의 나에게 보내는 기획서입니다.

리뷰는 사라지지 않고 바뀝니다#

에이전트 기반 개발에서 중요한 질문은 “리뷰를 할 것인가 말 것인가"가 아니라 “무엇을 리뷰할 것인가” 입니다. 사람이 모든 diff를 읽는 방식은 오래 가지 못합니다. 리뷰는 코드 중심에서 의도, 계약, 위험, 하네스 결과 중심으로 이동해야 합니다. 사람이 검토해야 할 것은 이런 것들입니다.

• 이 기능이 어떤 사용자 흐름을 바꾸는가
• 어떤 API가 필요하고 기존 API와 무엇이 달라지는가
• 어떤 데이터 상태와 테이블에 영향을 주는가
• 인증, 권한, 과금에 영향이 있는가
• 임시 데이터가 어디에 남아 있는가
• 실패했을 때 롤백 가능한가
• 테스트, 타입 검사, 종단간 테스트, 시각 회귀가 무엇을 보증하는가

반대편 의견도 있습니다. 하네스를 더 믿고 일단 반영한 뒤 잘못된 부분을 개선하자는 것입니다. 사람이 모든 코드를 이해하고 승인해야 한다는 전제가 곧 병목이 된다는 점에서 이 의견에는 분명한 진실이 있습니다. 하지만 전제가 있습니다. 하네스는 명시된 것만 검증합니다. 테스트는 정답을 스스로 만들지 못합니다. 무엇이 정상 동작인지, 어떤 데이터 상태가 깨지면 안 되는지는 누군가 먼저 정의해야 합니다. 이 정의가 약한 상태에서 “일단 반영 후 개선"으로 가면, 하네스가 강화되는 것이 아니라 잘못된 동작을 정상으로 고정하는 테스트가 생깁니다.

그래서 과도기의 원칙은 이렇습니다.

• 큰 변경을 사용자 흐름, 페이지, API 단위로 쪼갭니다. 쪼개는 비용이 너무 크면 차라리 작은 단위로 다시 구현합니다.
• 에이전트의 변경에는 의도, 우선순위, 예외 케이스, 성공 기준을 함께 남깁니다.
• 임시 데이터는 명시적으로 목록화하고 실제 구현 과제로 전환합니다.
• 리뷰는 전체 코드 검열이 아니라 시스템 계약과 위험 지점 검토로 재정의합니다.
• 사람이 리뷰하던 판단 기준을 점진적으로 테스트, 스킬, 문서, 계약으로 옮깁니다. 이것이 과도기의 핵심 작업입니다. 오늘 사람이 본 것을 내일은 하네스가 보게 만드는 일입니다.

“일단 반영하고 나중에 대응하자"는 기본 원칙이 되어서는 안 됩니다. 그 방식은 속도를 높이는 것이 아니라 검토 비용과 장애 비용을 운영 환경 뒤로 미루는 것이고, 한 번에 너무 많은 변경이 들어가면 문제가 생겼을 때 어디서부터 잘못됐는지 파악하기도 어려워집니다. 실험은 자유롭게 하되, 운영 반영은 작고 명확한 단위로 관리합니다.

디자인은 능력이 아니라 기본값의 문제입니다#

코딩 에이전트에게 화면 디자인을 맡기면 웬만큼 괜찮은 결과물이 나옵니다. 그런데 어디서 본 듯 비슷비슷하고 디테일이 어설픕니다. 이 현상은 에이전트의 능력 부족 때문이 아닙니다. LLM은 방향 지시가 없으면 가장 확률 높은 답을 냅니다. “괜찮은 버튼"의 최빈값은 특정 폰트, 보라색 그라데이션, 카드 그리드, 흰 배경입니다. 모든 AI 생성 디자인이 닮아 보이는 이유입니다. “더 예쁘게 해 줘” 같은 모호한 요청은 모호한 평균값을 다시 불러올 뿐입니다.

해결책은 능력을 더하는 것이 아니라 모델이 기본값에서 의도적으로 멀어지도록 조종하는 것입니다. 필자가 디자인 도구들을 조사하고 시안을 직접 뽑아 비교한 끝에 정리한 구조는 세 계층입니다.

생성기(스킬)는 방향을 만들어 내지만 상태가 없어서 매번 조금씩 다른 결과를 냅니다. “우리가 이걸로 결정했다"는 사실을 기억하지 못합니다. 그래서 채택한 방향을 디자인 문서에 적어 두고, 에이전트가 항상 읽는 지침 파일에서 그 문서를 참조하게 합니다. 생성기는 아트 디렉터이고, 디자인 문서는 그 디렉터가 서명한 브랜드 가이드라인입니다. 5번째, 20번째 페이지에서도 같은 제품처럼 보이게 하는 유일한 통일 지점입니다.

마지막 계층이 가장 자주 빠집니다. 도구가 설치되어 있는 것과 그 도구가 루프에 물려 있는 것은 다릅니다. 브라우저 MCP가 설정되어 있어도 “화면을 만든 뒤 스크린샷을 찍어 자기 결과를 보고 디자인 문서 기준으로 고쳐라"는 지침이 없으면 에이전트는 눈을 감고 만듭니다. 이 책의 다이어그램도 같은 방식으로 만들었습니다. 에이전트가 SVG를 쓰고, 로컬 서버에 띄워 스크린샷을 찍어 확인하고, 깨진 곳을 고치는 루프를 돌렸습니다.

직접 만들지 말아야 할 것#

1인 스타트업이 가장 빠지기 쉬운 유혹은 “핵심이 중요하니 전부 직접 만들어야 한다"는 생각입니다. AI 에이전트가 들어간 제품을 만들 때 특히 그렇습니다. 필자가 AI 에이전트 기반 웹서비스를 구상하면서 부딪힌 질문이 있습니다. “이 서비스의 에이전트가 정말 일을 하게 만들려면, 코딩 능력을 어디서 가져와야 할까?”

처음에는 모델 API를 붙이고, 파일 편집 기능을 만들고, 셸 명령을 실행하고, 테스트를 돌리면 되지 않을까 생각하기 쉽습니다. 하지만 조금만 깊게 들어가면 저장소 체크아웃, 파일 읽기 / 수정, 명령 실행, 테스트와 빌드, diff와 PR 준비, 비밀값 주입, 네트워크 제한, 시간과 비용 제한, 실패 후 재시도와 로그 수집까지 들어 있습니다. “코딩을 잘하는 에이전트"는 똑똑한 모델 하나로 생기지 않습니다. 실행 환경, 도구, 승인 구조, 격리, 관측 가능성이 함께 있어야 쓸 만해집니다.

필자의 결론은 코딩 능력 자체를 바닥부터 구현하는 접근은 1인 개발자에게 대체로 비합리적이라는 것입니다. 이미 나와 있는 코딩 에이전트 런타임(앞 장에서 본 CLI형, 서비스형 에이전트들)을 실행 엔진으로 두고, 제품은 그 위의 운영 계층을 가져가는 편이 현실적입니다.

이 구도에서 첫 유즈케이스는 좁아야 합니다. 저장소를 연결하고, 이슈 하나를 고르고, 격리된 환경에서 수정하고, 테스트 결과와 diff를 보여 주고, 사용자가 승인하면 PR을 만드는 흐름 하나만 잘 작동해도 충분히 강한 출발점입니다. 그 위에 리뷰어 에이전트, 비용 정책, 장기 메모리를 차례로 올리면 됩니다. 인프라도 처음부터 거창할 필요가 없습니다. 작업마다 독립 컨테이너를 띄우는 가장 단순한 구성으로 시작하고, 동시 작업이 많아지면 그때 더 정교한 스케줄링을 검토합니다. 전제는 상태와 로그와 산출물을 컨테이너 밖에 두고, 운영 계층이 실행 환경의 세부를 많이 모르게 설계하는 것입니다.

혼자 만드는 사람을 위한 체크리스트#

이 장을 체크리스트로 압축하면 아래와 같습니다. 필자는 새 프로젝트를 시작할 때 이 순서로 하네스를 세웁니다.

1. 지침 파일부터: 프로젝트 규칙, 구조 문서, 디자인 문서를 저장소에 두고 에이전트가 항상 읽게 합니다. (3장, 4장)
2. 끝을 먼저 정의: 기능마다 “정상 동작의 기준"을 테스트나 체크리스트로 적습니다. 에이전트는 그 기준을 통과할 때까지 돌립니다.
3. 초안과 프로덕션을 구분: 에이전트의 산출물은 초안입니다. 승격 경로(의도 검토 → 계약 정리 → 하네스 검증 → 스테이징 → 배포)를 체크리스트로 둡니다.
4. 의도를 남기기: 구현 전에 사용자 흐름, API 변경, 임시 데이터, 확정 / 미정 사항을 에이전트에게 정리하게 합니다.
5. 작게 쪼개기: 한 번에 검토할 수 없는 변경은 만들지 않습니다.
6. 리뷰 대상을 바꾸기: 코드 한 줄이 아니라 계약과 위험 지점을 봅니다. 사람이 본 것은 다음 날 하네스로 옮깁니다.
7. 디자인은 문서로 동결: 생성기로 방향을 잡고, 디자인 문서로 고정하고, 스크린샷 루프로 검증합니다.
8. 루프는 가져다 쓰기: 코딩 에이전트 루프, 샌드박스, 실행 환경은 직접 만들지 않습니다. 제품은 운영 계층을 소유합니다.

다음 장에서는 이렇게 만든 제품 안에 AI 기능을 넣을 때의 선택, 즉 비용 구조, 캐싱, 모델 배치, 그리고 내 제품을 사용자의 에이전트 안으로 들여보내는 방법을 다룹니다.