AI 코딩 도구가 보편화되면서 '바이브 코딩(Vibe Coding)'이라는 용어가 유행하고 있습니다. 하지만 현업의 복잡한 비즈니스 로직을 다루는 시니어 엔지니어 입장에서 볼 때, 단순히 느낌에 의존하는 코딩은 비결정적인 시행착오(Non-deterministic trial and error)를 반복하는 가장 빠른 지름길일 뿐입니다.

프로젝트가 조금만 복잡해져도 AI의 결과물이 무너지는 이유는 모델의 성능 탓이 아닙니다. 엔지니어가 AI를 제어하는 규율 있는 파이프라인(Disciplined Pipeline)이 없기 때문입니다. 실리콘밸리의 숙련된 개발자들이 클로드(Claude)를 활용해 아키텍처의 정합성을 유지하며 생산성을 극대화하는 실전 워크플로우를 공개합니다.

1. 핵심 원칙: 기획과 코딩의 엄격한 분리

AI 코딩에서 발생하는 '가장 비싼 실패'는 문법 오류나 단순 버그가 아닙니다. 진짜 무서운 실패는 주변 시스템을 야금야금 망가뜨리는 구현입니다. 기존 레이어를 무시한 함수 선언, ORM 관리를 고려하지 않은 마이그레이션, 혹은 이미 존재하는 로직을 중복으로 만드는 행위들입니다.

이를 방지하기 위한 제1원칙은 명확합니다. 작성된 계획을 개발자가 직접 검토하고 승인하기 전까지, 클로드에게 단 한 줄의 코드도 쓰게 해서는 안 됩니다.

"기획과 코딩의 분리, 이게 제가 아는 가장 중요한 단 한 가지예요."

코드를 먼저 작성하는 것은 아키텍처에 대한 주도권을 AI에게 넘겨주는 행위입니다. 기획을 선행함으로써 우리는 불필요한 토큰 소모를 줄이고, 시스템의 결정론적 무결성(Architectural Integrity)을 확보할 수 있습니다.

2. 첫 번째 단계: 'Deep Read'를 통한 리서치 문서화

모든 유의미한 작업은 코드베이스에 대한 깊은 이해에서 시작됩니다. 클로드에게 단순히 코드를 요약하라고 시키는 것은 위험합니다. 채팅창의 요약은 일시적이며, AI는 종종 파일 몇 개만 훑고 이해한 척 '환각(Hallucination)'을 일으키기 때문입니다.

대신 research.md라는 물리적 파일을 생성하게 하십시오. AI는 구조화된 보고서를 작성해야 할 때 훨씬 적게 환각을 일으킵니다. "입력(Input)이 강력해야 출력(Output)도 강력하다"는 원리를 이용하는 것입니다.

[리서치 단계 프롬프트 예시]

이 폴더를 깊이 읽고 어떻게 동작하는지 깊이 이해하고 모든 세부 사항을 파악해라.
끝나면 리서치의 상세 보고서를 작성해라. 
알림 시스템을 '매우 상세히' 연구하고, 발견한 모든 기술적 세부 사항을 담은 research.md를 작성해라.

여기서 깊이, 매우 상세히와 같은 단어는 클로드의 어텐션을 강제하는 중요한 파라미터 역할을 합니다.

3. 두 번째 단계: 'Shared Mutable State'로서의 플랜(Plan) 관리

클로드 코드의 내장 '플랜 모드' 대신 별도의 plan.md 파일을 사용하는 이유는 명확합니다. 이는 인간과 AI가 동일한 문서(State)를 함께 수정해 나가는 'Shared Mutable State(공유 가변 상태)' 패턴의 구현입니다.

• 연속성: 노트북 세션이 끊기거나 채팅 히스토리가 밀려나도, plan.md는 프로젝트 산출물로 영구히 남습니다.
• 직접 편집: AI가 제안한 계획 중 마음에 들지 않는 부분을 에디터에서 즉시 수정할 수 있습니다.
• 컨텍스트 유지: 클로드의 '오토 컨팩션(Auto-compaction)' 기능이 작동하더라도, 물리적 파일인 MD 문서는 압축되지 않고 원본 그대로의 맥락을 유지합니다.

[플랜 단계 프롬프트 예시]

ETF 리밸런싱을 구현하는 상세 plan.md를 작성해라. 
목록 조회 시 '오프셋 페이징' 대신 '인풋 기반 페이징'을 지원해야 함. 
변경 사항을 제안하기 전에 반드시 소스 파일을 다시 읽고 실제 코드베이스를 기반으로 계획을 세워라.

4. 세 번째 단계: 주도권을 놓지 않는 '인라인 메모' 피드백 루프

플랜 문서가 나오면 이제 엔지니어가 '설계자(Architect)'로서 개입할 차례입니다. 문서 내부에 직접 주석을 달아 클로드에게 피드백을 줍니다. 이는 단순한 채팅보다 훨씬 정교한 인간 주도 루핑 방법론입니다.

• 아키텍처 교정: "이건 PUT이 아니라 PATCH여야 해."
• 기술 부채 및 중복 방지: "부모 클래스가 재시도를 처리하니까 이 로직은 중복이야. 제거하고 그냥 실패하게 둬."
• 도메인 지식 주입: "비저빌리티 필드는 개별 아이템이 아니라 리스트 자체에 있어야 해. 스키마를 재구조화해."
• 접근 방식 거부: "이 부분은 캐싱이 필요 없어. 복잡도만 높이니 제거해."

메모를 남긴 후에는 반드시 다음과 같이 지시하십시오. "메모를 모두 반영해서 문서를 업데이트해. 하지만 '아직 구현하지 마'." 이 문구는 클로드가 계획이 충분하다고 독단적으로 판단하여 코딩을 시작하는 것을 막는 핵심 안전장치입니다.

5. 네 번째 단계: 구현은 기계적인 공정일 뿐이다

계획이 확정되었다면 구현은 지루할 정도로 기계적이어야 합니다. 모든 창의적인 결정과 아키텍처 검토는 이미 이전 단계에서 끝났기 때문입니다. 이 단계에서 엔지니어는 '설계자'에서 '감독자'로 역할을 전환합니다.

저는 리서치부터 구현까지 **'하나의 긴 세션(One Long Session)'**을 유지하는 것을 권장합니다. 클로드가 세션 내내 리서치와 계획을 반복하며 쌓아온 맥락이 구현의 정확도를 극대화하기 때문입니다.

[표준 구현 프롬프트]

• "계획대로 전부 구현해라. 단계를 완료할 때마다 계획 문서에 완료 표시를 해라."
• "작업이 끝날 때까지 멈추지 마라. Unknown 타입을 쓰지 말고 지속적으로 타입 체크를 실행해라."
• 팁: 디자인 수정 시에는 구구절절 설명하기보다 스크린샷 한 장을 첨부하는 것이 훨씬 결정론적인 결과를 만듭니다.

6. 마지막 생존 전략: 모래성 위에 집 짓지 않기 (Git Reset)

AI와 협업하다 보면 로직이 꼬여 비결정적인 오류가 반복되는 지점이 반드시 옵니다. 이때 부분적인 패치로 상황을 모면하려 하지 마십시오. 그것은 잘못 설계된 모래성 위에 벽돌을 계속 쌓는 행위입니다.

가장 효율적인 해결책은 깃(Git)을 리셋하거나 되돌린(Revert) 후, **범위를 더 좁게 재설정(Narrowing Scope)**하여 다시 시작하는 것입니다. "전부 되돌려. 이제 목록 뷰를 심플하게 만드는 것 외엔 아무것도 하지 마"라고 명령하는 결단력이 더 견고한 소프트웨어를 만듭니다.

결론: AI 코딩의 본질은 '무엇을 쓸지' 확정하는 것

결국 승패는 마법 같은 프롬프트가 아니라 '생각하는 것'과 '타이핑하는 것'을 분리하는 엄격한 프로토콜에 달려 있습니다. 리서치는 무지한 변경을 막고, 계획은 잘못된 설계를 방지하며, 주석 달기 사이클은 개발자의 전문적 판단을 시스템에 주입합니다.

AI에게 운전대를 완전히 맡기지 마십시오. 당신은 설계도를 그리는 아키텍트가 되어야 하며, 클로드는 그 설계도를 한 치의 오차 없이 실행하는 최고의 조수가 되어야 합니다.

당신은 지금 클로드에게 운전대를 맡기고 계신가요, 아니면 당신의 설계도를 실행할 완벽한 조수로 부리고 계신가요?