AI관련 정보를 요즘 받지 않았다가, 또 많은 정보를 받기 시작하면서 글을 적어본다 [LINK]
나의 습관 중 하나는 이유불문 주는 정보는 한번씩 다 본다는 것이다. 무심코 지나가다가 나에게 득이 될 수 있는 정보가 있을 수 있기 때문에 모든 정보를 허투루 보지 않는다. (이미 신뢰를 잃은 사람 제외)
위의 링크를 확인해보면, 많은 개발자가 AI 코딩 도구를 도입하며 생산성의 혁명을 꿈꾼다.
하지만 현실은 프롬프트 몇 줄에 의존하다가 코드가 꼬이고, 결국 처음부터 다시 짜는 ‘AI 부채’에 시다리는 경우가 허다하다. 진정한 고수는 도구에 휘둘리지 않는다.
최근 화제가 된 ‘바이브 코딩’은 단순한 감각이 아니라, AI를 완벽하게 통제하는 규율 있는 파이프라인을 의미한다. 본 포스팅에서는 클로드 코드를 주력으로 사용하는 찐 개발자들의 워크플로우를 분석하여, 복잡한 프로젝트에서도 무너지지 않는 실전 AI 코딩 전략을 상세히 다룬다.
1. AI 코딩 독학의 핵심, 기획과 구현의 엄격한 분리
AI 코딩에서 가장 위험한 순간은 AI가 ‘알아서’ 코드를 짜기 시작할 때이다.
이는 마치 설계도도 없이 벽돌부터 쌓는 초보 건축가와 같다. 바이브 코딩의 제1원칙은 작성된 계획을 개발자가 직접 검토하고 승인하기 전까지 AI에게 단 한 줄의 코드도 쓰게 하지 않는 것이다.
ㄱ. 지휘관과 병사의 역할 분담
AI는 지치지 않는 병사이지만, 전략적 판단력이 부족한 지휘관이다.
개발자는 아키텍처의 큰 그림을 그리는 지휘관이 되어야 하며, AI는 그 지시에 따라 정밀하게 움직이는 병사가 되어야 한다. 이 관계가 역전되어 AI가 설계를 주도하게 되면, 시스템은 순식간에 누더기 코드로 변질된다.
ㄴ. 토큰 낭비를 막는 효율적인 프로세스
코드부터 들이받는 방식은 수많은 에러 수정 과정을 거치며 불필요한 토큰을 소모한다.
하지만 리서치와 계획 단계를 선행하면 전체적인 컨텍스트를 유지하면서도 정확한 타격이 가능하다. 이는 결과적으로 비용 절감과 품질 향상이라는 두 마리 토끼를 잡는 전략이다.
2. AI 코딩 독학 1단계: 코드베이스 리서치와 컨텍스트 확보
모든 의미 있는 작업은 코드베이스를 깊이 읽는 것부터 시작한다. 클로드 코드에게 관련 부분을 철저하게 이해하라고 시키고, 발견한 내용을 반드시 별도의 파일인 research.md에 작성하게 해야 한다.
ㄱ. 채팅창 요약의 함정에서 벗어나기
보통의 사용자들은 채팅창 안에서 대충 요약된 내용으로 만족한다. 하지만 이는 휘발성 정보에 불과하다. 마크다운 파일로 기록을 남기는 것은 AI에게 ‘생각의 흔적’을 고착화시키는 행위이다.
1. 특정 폴더를 깊이 읽고 동작 방식을 파악하도록 지시했음
2. 함수 시그니처 수준이 아니라 내부 로직까지 상세히 분석하게 했음
3. 분석 결과물은 반드시research.md파일로 저장하도록 강제했음
ㄴ. ‘비싼 실패’를 예방하는 심층 분석
AI 코딩에서 가장 비싼 실패는 문법 에러가 아니다.
멀쩡하게 돌아가는 것 같지만 기존 시스템의 레이어를 무시하거나 중복된 API를 만드는 ‘구조적 오염’이 진짜 무서운 것이다. 리서치 단계는 이러한 오염을 원천 차단하는 거름망 역할을 한다.
3. AI 코딩 독학 2단계: Plan MD 작성을 통한 설계 승인
리서치가 끝났다면 이제 plan.md 파일을 만들 차례이다. 여기에는 상세 구현 계획이 담겨야 한다.
ㄱ. 상세 구현 계획서의 구성 요소
계획서에는 단순한 할 일이 아니라, 접근 방식에 대한 상세 설명, 실제 변경 사항을 보여주는 코드 스니펫, 수정될 파일 경로, 그리고 발생 가능한 트레이드 오프(Trade-off)가 포함되어야 한다.
1. 기능 구현을 위한 상세 플랜 마크다운 작성을 요청했음
2. 실제 코드베이스를 기반으로 변경 사항을 제안하도록 설정했음
3. 내장 플랫 모드 대신 프로젝트 내 실제 파일을 생성하여 연속성을 유지했음
ㄴ. 주석 달기 사이클의 마법
개발자는 생성된 plan.md 파일을 에디터에서 열고 직접 주석(메모)을 단다. “이 부분은 캐싱이 필요 없어”, “이 함수는 재시도 로직이 중복이야” 같은 피드백을 문서 안에 직접 적는 것이다.
4. AI 코딩 독학 3단계: AI 주도권을 제어하는 인터랙션
메모를 달았다면 클로드에게 다시 명령을 내린다. 이때 가장 중요한 문구는 “아직 구현하지 마“이다.
ㄱ. 확정될 때까지 코딩 금지
AI는 성격이 급한 조수와 같아서, 계획이 조금만 보강되어도 바로 코드를 짜려고 달려든다. 개발자가 “만족한다”고 말하기 전까지는 절대로 타이핑을 시작하게 해서는 안 된다.
1. 문서에 추가된 메모를 모두 반영하여 계획을 업데이트하도록 했음
2. 승인 전까지는 코드 작성을 절대 금지하는 제약 조건을 걸었음
3. 이 사이클을 최소 1회에서 수 차례 반복하여 설계를 정교화했음
ㄴ. Shared Mutable State 패턴의 활용
채팅창에서 텍스트로 대화하는 것은 한계가 있다. 문서라는 ‘공유된 상태’를 두고 이를 함께 수정해 나가는 방식은 인간과 AI 간의 협업 효율을 극대화한다. 이는 에이전트 워크플로우에서 가장 실용적인 방법론이다.
5. AI 코딩 독학 4단계: 기계적 구현과 실시간 감독
계획이 확정되었다면 이제 구현은 지루하고 반복적인 작업이 된다. 그리고 그래야만 한다. 창의적인 판단은 이미 계획 단계에서 끝났기 때문이다.
ㄱ. 표준 프롬프트를 통한 자동화
구현 단계에서는 사전에 정의된 표준 프롬프트를 사용한다. “전부 구현해라”, “작업이 끝나면 계획서에 완료 표시를 해라”, “타입 체크를 멈추지 마라” 등의 명령이 여기에 해당한다.
1. 계획 단계에서 합의된 내용을 기계적으로 찍어내게 했음
2. 구현 중 발생하는 사소한 위치 오류 등은 즉각적인 짧은 프롬프트로 교정했음
3. 프런트엔드 작업 시 스크린샷을 활용하여 시각적 피드백을 전달했음
ㄴ. 설계자에서 감독자로의 전환
코드가 작성되는 동안 개발자의 역할은 아키텍트에서 감독자로 바뀐다. AI가 계획을 충실히 따르는지, 예기치 못한 타입 에러를 내지는 않는지 감시하는 것에 집중한다.
6. AI 코딩 독학 5단계: 과감한 리셋과 범위 재설정
만약 AI가 구현 과정에서 길을 잃거나 엉뚱한 방향으로 가고 있다면 어떻게 해야 할까? 그 위에 덧방을 치는 것은 최악의 선택이다.
ㄱ. 모레성 위에 벽돌 쌓지 않기
잘못된 구현 위에 패치를 거듭하면 결국 전체 시스템이 붕괴한다. 이때는 Git의 강력한 기능을 빌려야 한다.
1. 잘못된 방향으로 흐를 시
git reset또는git revert를 수행했음
2. 범위를 다시 좁게 설정하여 계획 단계부터 재시작했음
3. 점진적 수정보다 통째로 되돌리는 것이 훨씬 빠르고 품질이 좋음을 확인했음
ㄴ. 결론: 시스템으로 통제하는 코딩의 미래
결국 성공적인 AI 코딩은 화려한 프롬프트 기술에 있지 않다. 리서치가 무지한 변경을 막고, 계획이 잘못된 설계를 막으며, 주석 달기 사이클이 인간의 의도를 주입하는 ‘시스템’에 있다. 운전대를 꽉 잡고 클로드 코드를 도구로서 부릴 때, 비로소 진정한 의미의 바이브 코딩이 완성된다.
내가 이 유투브 내용을 보고 내용을 요약하고 회고하는 의미에서 기록하는 이유는 나도 같은 상황이기 때문이다.
어떻게 정리하면 좋을까? 라고 생각만 하다가 내가 하고 싶은 이야기 담겨져서 내용을 적어보았다.
처음에는 막시켰는데, 잘 개발하다가 만들고 있는 서비스가 서서히 무너지는 것을 느끼게 되었다.
분명히 되던 기능에서 깃에 커밋하였는데, 어느순간 되지 않아서 히스토리를 찾고 롤백해도 이미 무너지고 있는 서비스에 탑을 쌓고 있어서 롤백해도 되지 않았다.
그래서, 지금 이 글을 작성하고 있는 동안 서브 에이전트에게 코드 한 줄씩 보면서 QA와 상의 하면서 코드를 고치라고 하는 중이다.