AI 코딩 도구 제대로 쓰는 법: 실리콘밸리 개발자의 인간-기계 격리 워크플로우 4단계 전략

9개월 동안 Claude를 사용해서 깨달은 한 가지: 계획을 승인하기 전까지는 AI에게 한 줄의 코드도 작성하게 하지 마세요

당신도 그렇나요? 새로운 AI 프로그래밍 도구를 받자마자 바로 던져버리는군요: “뱀 게임을 만들어줘” 또는 “이 페이지에 검색 기능을 추가해줘”.

그러면 어떻게 될까요? 코드는 실행되는 것처럼 보이지만, 프로젝트에 들어가면 버그 천지입니다. 캐싱 레이어는 무시되고, ORM 규칙은 깨지며, 심지어 어딘가에서 이미 존재하는 기능을 다시 만들고 있습니다.

이건 AI가 바보가 아니라, 당신이 게으른 겁니다. 대형 언어 모델 보조 프로그래밍에서 대부분의 사람들은 치명적인 실수를 합니다: “생각”과 “실행”을 혼동하는 것입니다.

실리콘밸리의 거물 Boris Tane은 9개월 동안 Claude Code를 고강도로 사용한 후, 당신의 인식을 뒤집을 만한 “인간-기계 격리 워크플로우”를 정리했습니다.

이 방법의 핵심은 한 문장입니다: 당신이 검토하고 계획을 승인하기 전까지는 AI에게 한 줄의 코드도 작성하게 하지 마세요.

AI의 손을 통제만 한다면, 그 효율은 당신을 놀라게 할 겁니다.

아래 Research → Plan → Annotate → Implement 워크플로우는 전문을 꼼꼼히 읽어보길 권합니다.

첫 번째 단계: Research (읽는 것만 아닌, 깊은 심문)

코드베이스를 AI에 던져주면 당신의 시스템을 이해할 것이라고 순진하게 생각하지 마세요. AI의 기억력은 제한되어 있으며, 그저 “얕게 맛보기만 하는” 인턴과 같습니다.

Boris의 방법은 아주 “광적”입니다: 그는 AI에게 깊은 독서를 강요하며, 읽은 내용을 반드시 지속적인 research.md 파일에 작성하게 합니다.

주의하세요, 채팅창에서 말로 보고하는 것이 아니라, 문서를 작성하는 것입니다.

여기 핵심이 있습니다: 그는 프롬프트에 이 단어들을 미친 듯이 쌓아 올립니다: “deeply” (깊이), “in great details” (아주 상세하게), “intricacies” (복잡한 세부 사항들).

이건 단순한 수사가 아니라, AI에 전시 명령입니다. 이 단어들이 없으면 AI는 함수 서명만 읽고도 “이해했어”라고 말할 수 있습니다. 이 단어들이 있으면 소스 코드를 진짜로 씹어 먹을 겁니다.

왜 이렇게 해야 할까요?

AI 보조 프로그래밍에서 가장 비싼 대가는 문법 오류가 아니라, 맥락에서 벗어난 “올바른” 구현입니다.

기존 캐싱 전략을 무시하는 함수는 실행에 오류가 없지만, 데이터베이스를 망가뜨릴 수 있습니다. Research 단계는 이런 위협을 싹에서 제거하기 위한 것입니다.

두 번째 단계: Plan (내장 모드를 버리고, 직접 제어하세요)

Claude Code는 Plan Mode가 내장되어 있나요? 미안하지만, 그건 초보자를 위한 겁니다.

진짜 고수는 AI에게 상세한 plan.md를 생성하게 요구합니다. 이 파일에는 반드시 다음이 포함되어야 합니다:

• 방법론 설명
• 실제 코드 조각
• 수정할 파일 경로
• 절충과 고려사항 (Trade-offs)

왜 굳이 .md 파일을 써야 할까요?

이건 지속적인 산물입니다. 편집기에서 자유롭게 수정, 삭제, 주석 작성을 할 수 있으며, 좁은 채팅창에서 AI와 다툴 필요가 없습니다.

여기 독자 비결이 하나 있습니다:

오픈소스 프로젝트에서 비슷한 기능을 본 적이 있다면, 코드를 AI에 던져주세요: “다른 사람들이 정렬 가능한 ID를 만드는 방식이야, 이걸 참고해서 계획을 작성해줘.”

기억하세요: 구체적인 참조 구현이 있으면 AI의 지능이 두 배로 높아집니다.

세 번째 단계: Annotate (이건 영혼! 반드시 1-6회 반복)

이 워크플로우에서 가장 핵심적이며, 대부분의 사람이 가장 부족한 부분입니다.

AI가 작성한 plan.md를 받았으면, 급하게 코드를 작성하게 하지 마세요. 당신은 이 문서에 미친 듯이 주석을 작성해야 합니다.

프로세스는 다음과 같습니다:

AI가 계획 작성 → 문서에 인라인 주석 작성 → AI가 주석에 따라 문서 업데이트 → 1~6회 반복

당신의 주석은 다음과 같을 수 있습니다:

• 두 단어: “not optional” (매개변수 속성 수정)
• 한 문장: “remove this section” (이 로직은 필요 없음)
• 코드 조각: 원하는 데이터 구조를 직접 붙여넣기
• 아키텍처 수정: “visibility 필드는 item이 아니라 list에 있어야 해, schema를 리팩터링”

이 단계에서 당신은 방지 명령을 추가해야 합니다:

“don’t implement yet” (아직 코드를 작성하지 마세요!)

이 문장이 없으면, AI가 “이해했다”고 생각하면 흥분해서 코드 작성을 하러 달려가고, 쓰레기를 만들어낼 겁니다.

Markdown 문서는 인간과 AI 사이의 “공유 상태”입니다. 당신은 아키텍트, AI는 타이피스트입니다. 이 반복을 통해 일반적인 쓰레기 방안을 완벽하게 당신의 시스템에 맞는 커스텀 방안으로 다듬을 수 있습니다.

네 번째 단계: Implement (AI를 무자비한 타이핑 기계로 만드세요)

plan.md에 만족하면, 이제 당신은 뇌를 끄고 AI를 최대 속도로 돌릴 수 있습니다.

Boris는 표준화된 실행 프롬프트를 사용합니다. 스크린샷을 찍어 저장하는 걸 추천합니다:

implement it all. mark completed in plan. do not stop until all phases done. no any/unknown types. continuously run typecheck.

각 문장은 피와 눈물의 경험입니다:

• “implement it all”: 가려서 고르지 말고, 모든 작업을 완료하세요.
• “mark it as completed”: 문서로 진행 상황을 추적하세요, 말만 하지 마세요.
• “do not stop”: 함수 하나만 완료하고 멈춰서 자축하지 마세요, 한 번에 끝까지 하세요.
• “no any/unknown types”: any/unknown 유형 사용을 금지합니다, 이건 최저선입니다!
• “continuously run typecheck”: 코드를 작성하는 동안 타입 검사를 계속 실행하세요, 끝까지 기다리면 붉은 선이 가득합니다.

이 단계에서 설계 결정은 이미 모두 완료되었습니다. 구현 과정은 기계적이고 지루해야 합니다.

프로그래밍이 당신을 스릴 있게 만든다면, 계획이 엉망이라는 겁니다.

마지막: 누가 운전석에 앉나요?

많은 사람들의 AI 프로그래밍은 결국 “AI의 뒤를 닦아주는 것”이 되어버립니다. 원인은 너무 일찍 권한을 위임했기 때문입니다.

Boris의 논리는 아주 명확합니다:

Research → Plan → Annotate, 이 세 단계는 “뇌를 만드는 것”; 마지막 Implement만이 “손을 움직이는 것”입니다.

실행 과정에서 AI가 튀면, 수정하려고 하지 마세요.

바로 Revert(되돌리기), 범위를 축소, 다시 시작하세요. 잘못된 방향에서 수정을 계속하면 쓰레기산만 얻게 됩니다.

기억하세요, 가장 강력한 AI가 있어도, 운전석에서 핸들을 잡고 있는 건 언제나 당신이어야 합니다.

AI가 이렇게 강력하다면, 왜 AI가 잘하는 “실행”만 맡기고, 당신의 소중한 뇌력을 “설계”에 남겨두지 않을까요?

이 글을 당신의 프로그래머 친구들에게 전달해서, 그들의 모발을 구해주세요.