작업 방식 (Method)

Spec-First Solo Build (기준 문서 먼저, 혼자 끝까지)

코드를 직접 짜지 않고도, 기준을 세우고 AI를 지휘해 제품을 출시까지 끌고 가는 법

Spec-First Solo Build 작업 방식 요약

이 페이지는 제가 실제로 지켜 온 작업 규칙을 하나의 방법으로 정리한 것입니다. 홍보 문구가 아니라 매 프로젝트에서 반복해 온 절차입니다. 아래 템플릿은 공개용 뼈대입니다. 프로젝트별 실제 지시 발췌는 각 케이스스터디의 "AI 지휘 과정"에서 볼 수 있습니다.

(01)

프레임워크: 7단계로 0에서 출시까지

Fig. ai-workflow-01

기획부터 출시까지 — 지시·확인·수정 루프

01아이디어문제 정의

02기획·기준화면·구조·“이렇게 동작해야 함”을 문서로

03AI에 지시목표·기준·제약을 한 단계씩

04실행·확인직접 플레이·빌드·로그로 대조

05출시보안·데이터 점검 후 스토어·웹

어긋나면 원인을 짚어 수정 지시 · 반복

코드를 직접 쓰지 않고, 기준을 정한 뒤 AI에게 순서대로 지시하고 직접 돌려 보며 고칩니다. 3↔4는 기준을 통과할 때까지 반복합니다.

01
문서로 규칙·설계를 먼저 세운다
코드를 직접 읽지 않으므로 품질의 1차 방어선은 '규칙 문서'입니다. 프로젝트마다 규칙 문서에 일하는 방식·금지사항·검증 기준을 못박고, 매 세션 시작에 그걸 읽히고 "현재 단계 말해"로 동기화합니다.
02
디자인/UI·데이터를 먼저 다 뽑고 개발에 착수한다
병행하면 꼬이므로 화면·데이터를 선(先)확정합니다. (예: 디자인 도구로 전 화면을 뽑은 뒤 코드로 연결)
03
작게 나눠 지시하고, 본인이 실행·스크린샷으로 확인한다
"다 됐다"는 말이 아니라 폰·시뮬레이터로 직접 돌려 **본인 눈으로** 확인합니다.
04
점수가 아니라 기준·벤치마크를 말로 준다
완성도를 수치가 아니라 레퍼런스(대기업 앱)와 톤으로 지시하고 구현은 위임합니다.
05
틀린 걸 잡아내고 방향을 바꾼다
그럴듯한 성공을 의심하고("하드코딩 아니지?"), 막히면 즉시 되는 수단으로 전환합니다(가짜 금지·실용 피벗).
06
AI의 자기보고를 믿지 않고 증거로 검증한다
"기억"이 아니라 실제 코드·결과물·다른 입력으로 재확인시킵니다.
07
인수인계 문서로 맥락을 유지하고, 여러 AI를 조직처럼 운영한다
계정·컨텍스트가 바뀌어도 맥락이 끊기지 않게 문서로 남기고, 멀티세션은 한 세션을 PM으로 세워 운영합니다.

Spec-First Solo Build — 규칙과 기준을 먼저 문서로 정하고, AI에게 지시·확인·교정을 반복해 출시까지 끌고 갑니다.

3~6단계는 한 번 흐르고 끝나는 게 아니라 지시 → 확인 → 교정으로 반복합니다.

(02)

원칙

01
추측하지 않는다
한 번 고쳐서 안 되면, 두 번째 시도 전에 공식 문서·동일 사례를 반드시 검색합니다.
02
만들기 전에 보여준다
새 화면·구조는 목업이나 설계를 먼저 보고 확인한 뒤 진행합니다.
03
바꾸기 전에 영향을 말한다
수정 전에 부작용·연쇄 이슈를 먼저 설명하고, 승인 후에만 바꿉니다.
04
끝까지 흐르는지 확인한다
필드·파라미터를 더하면 정의만이 아니라 모든 호출부를 찾아 고치고, 제출 전 생성된 코드를 다시 읽어 값이 끝까지 흐르는지 봅니다.
05
틀리면 안 되는 건 기준을 문서로
보안·급여처럼 실수가 치명적인 영역은 코드보다 설계 문서가 먼저입니다.
06
실패에서 원칙을 만든다
한 번의 손실·사고에서 재발을 막는 작업 규칙을 하나 건집니다. (예: "변경 전 승인" 원칙은 초기 트레이딩 봇 실패에서 나왔습니다.)
07
문서와 코드를 어긋나지 않게 한다
릴리스마다 문서의 수치를 실제 코드와 대조합니다. AI가 쓴 문서는 실제와 달라지기 쉬워, 대조를 습관으로 둡니다.

(03)

프롬프트 템플릿 (뼈대)

제가 반복해서 쓰는 지시의 뼈대만 공개합니다. 실제로 효과를 낸 세부 조건·순서·검증 기준은 면접·협업 시 공유합니다. 프로젝트별 실제 지시 발췌(1~2문장)는 각 프로젝트 케이스스터디의 'AI 지휘 과정'에서 볼 수 있습니다.

A. 아이디어 평가 — 임의 점수 없이 실제 사례 근거로

문제 재정의 → 유사 사례 검색 → 성공·실패 패턴 비교
→ 사례 근거 스코어카드 → 아이디어 도출 → 요약(상위 + 리스크 + 다음 액션)
[각 단계의 기준·개수·판정 규칙은 비공개]

B. 기능 구현 지시

[목표] …   [기준] 이렇게 동작 / 이건 금지   [제약] 스택·정책(문서 확인 후)   [확인] 내가 점검할 것

C. 버그 수정 지시

[증상] …   [먼저] 원인부터 검색·가설   [수정 전] 영향 설명 → 승인 후 변경

(04)

내가 오류를 잡는 방식

01
증상을 사실로 설명한다
AI에 "무엇이·언제·어떤 화면에서" 생겼는지 재현 가능한 사실로 전달합니다.
02
원인부터, 추측 없이
공식 문서·동일 사례를 먼저 찾아 원인 가설을 세웁니다.
03
첫 수정이 빗나가면 멈춘다
두 번째 시도 전에 반드시 다시 검색합니다 — 같은 추측을 반복하지 않습니다.
04
값이 끝까지 흐르는지 확인한다
고친 뒤 모든 호출부와 생성된 코드를 다시 읽어 확인합니다.
05
재발을 막는 기준으로 남긴다
같은 실수가 안 나도록 작업 원칙이나 설계 기준으로 적어 둡니다.

실제 디버깅 사례(증상→지시→실패→해결)는 각 프로젝트 케이스스터디의 "이렇게 고쳤다"에서 볼 수 있습니다.

(05)

실수 → 교훈

Mistake
트레이딩 봇 과신 → 손실
✓ Lesson
바꾸기 전에 영향을 먼저 설명받고 승인한다(지금도 모든 프로젝트에 적용).
Mistake
AttenNFC: AI 생성 코드가 기준 미달
(급여 변수 9종 중 5종만, API 불일치, GPS 하드코딩).
✓ Lesson
AI 결과를 기준과 대조해 검증하고, 어긋나면 "재작성"을 지시한다. 재작성 후 `flutter analyze` 이슈 0을 직접 확인.
Mistake
MECHOOSE: 초기 화면 구조가 한 파일에 몰림
✓ Lesson
분리 기준은 처음에 세워야 나중 수정 비용이 싸다.

(06)

숫자로 본 작업량 (근사치)

claude.ai 대화 149개 · 사용자 지시 약 9,002개 (2026-02~10, 약 8.5개월) — 개인·비포폴 대화까지 포함한 전체 활동 기준.
출시·배포 단계까지 간 제품 다섯 (THE HOUSE·MECHOOSE·Momento·Money Navigation·MemoHub), 그중 라이브 운영 둘(MECHOOSE·MemoHub).
한 대화 최다 지시: THE HOUSE 696개.

수치는 기록 기반 근사치입니다(대화의 프로젝트 분류는 제목·키워드 휴리스틱이라 추정값).

(07) Honest

Honest Review

개발자가 만들었다면? 강점 · 동등 · 다음 단계

강점동등다음 단계 (보완 중)

THE HOUSE
강점3동등4보완 중5
↗ 테스트·자동화 — 자동 테스트·CI 아직 없음
개선 계획 → 구매·세이브 테스트+CI, 모듈 분리, 비공개 Git, 공개 출시 전 서버 측 구매 확인
MECHOOSE
강점3동등4보완 중4
↗ 테스트·자동화 — 테스트·CI·린트·타입검사 아직 없음
개선 계획 → 결제부터 테스트+CI, 백엔드 도메인별 분리, 주문·결제 정식 테이블 이전, 오류 알림 도입
Momento
강점3동등4보완 중5
↗ 테스트·자동화 — 매칭 엔진만 테스트 있음
개선 계획 → 운영 스키마 저장소 고정, 핵심 흐름 테스트+CI, 서버 측 구매 확인, Android 완성도
AttenNFC
강점2동등3보완 중4
↗ 기능 완성도 — 설계 대비 구현 약 10~15%
개선 계획 → 서버 확인 포함 출근 1회 왕복을 끝까지 연결 → 테스트·CI·번역·라벨을 화면마다
AI 동영상 스트리밍 플랫폼
강점4동등3보완 중3
↗ 테스트·버전 관리 — 테스트·git 없음
개선 계획 → 비공개 Git·결제 테스트부터 → CI·모니터링·백업·롤백