코딩 손 놓은지 2년된 사람의 바이브 코딩 모험기 2편

서론

지난 글에서 끝에 두 가지 실패를 이야기했다. 두 번째 버전이 욕심으로 인해 첫 버전에 비해 기능이 너무 커졌다는 거랑, 리뷰 루프가 끝없이 길어져서 PR 하나에 코덱스 리뷰가 18번 돌았다는 거였다. 그때 "이건 구조가 지금처럼 정립이 안 돼서 그렇다"라고 변명처럼 적어뒀는데, 그 얘기를 하려고 한다.

그 얘기를 하기 전에, 상황이 좀 바뀐 것부터 얘기를 하면... 그 사이에 AX(AI 전환) 쪽 일에 본격적으로 투입됐다. 그렇다고 원래 본업이 없어진 것도 아니라서, 둘을 동시에 쳐내야 하는 처지가 됐다. 만약 내가 계속 들여다봐야 하는 구조였으면 때려치워야 했을 거다. 그런 이유로, 이 워크플로우는 나의 최소한의 관여로 기능이 개발되도록 고안한 형태이다.

도대체 유튜브 알고리즘이 이 라이브를 어떻게 띄워준건지 모르겠습니다. https://www.youtube.com/watch?v=UyzmteyNnP8

 

먼저 도구부터. 그때 claude.md랑 MCP 조합으로 손수 짰던 규칙들을, 지금은 oh-my-claudecode(줄여서 OMC)라는 플러그인 위에서 굴린다. 클로드 코드에 얹는 오케스트레이션 레이어인데, "한 모델이 다 하는" 대신 "역할을 쪼개서 서로 견제하게" 만들어 주는 도구다. 

당연한 얘기지만, 이 omc를 나름대로 튜닝을 해서 쓰고 있는데 어디까지가 omc 가 지원하는 거고 어디까지가 내가 튜닝한 건지가 좀 헷갈리긴 합니다...

 

 

워크플로우 요약

작업 하나를 어떤 순서대로 작업하는지부터 훑고 가자.

 

지피티가 그려줬는데... 뭐 이렇게 귀엽게 만들어줬지?

deep-research 스킬로 시작한다. 뭘 만들지, 어디가 걸림돌인지 코드베이스와 자료를 먼저 훑는 단계다. 그 위에서 계획을 세우는데, 나 혼자 적어 내려가는 게 아니라 OMC의 컨센서스 플래닝을 돌린다. 여러 모델이 각자 계획을 내고, 그걸 한 번 합의·정제(refine)한 다음 스펙을 만든다. 그리고 이 스펙을 코덱스가 반증(falsify)해보고 통과해야 확정된다. 이걸 최종적으로 fable 이 확정 짓고 PLAN.md를 만든다.

확정된 PLAN.md는 TDD 용 test를 만들고, 그것 역시 마찬가지로 코덱스가 반증 후 fable 이 확정 짓고, ralph 스킬로 받아서 글자 그대로 구현한다. 완료까지 자율로 돈다. 구현이 끝나면 새 코덱스가 열려서 리뷰하고, 지적사항은 그 자리에서 코덱스가 직접 고친다. 거기까지 통과하면 마지막으로 fable이 전체를 다시 검토하는데, 문제없으면 commit 하고 push 한다.

말로 풀면 길어 보이는데, 내가 할 일은 미리 기획을 기능 단위로 쪼개서 적어놓고, 출근 전과 퇴근 후에 기존 작업이 끝났나 보고 테스트해 본 다음 문제가 없으면, 그다음 작업이 뭔지 물어보고, 그 작업의 deep-research 까지만 진행하면 된다.

 

 

기획부터 테스트 생성까지

우선 기획은 이 워크플로우를 타지 않는다. 사전에 미리 클로드나 클로드 코드를 붙잡고, '이러이러한 기능이 들어간 웹페이지가 필요한데, 목표는 무엇이고, 어떤 구조를 가져야 하고, 어떤 언어를 사용해야 한다.' 이런 걸 미리 토의해서 기획안을 만든다. 그걸 next-actions.md 같은 이름의 파일에 정리를 해달라고 하면서, 미리 작업을 나눠서 할 수 있게 기능단위로 쪼개달라고 요청을 해서 저장한다.

 

저는 기획은 무조건 읽지만 코드는 바빠서 안읽긴합니다... 출처 : https://www.youtube.com/watch?v=Kf1dYpnH-N4

 

해당 문서를 다시 한번 읽어보면서 내가 생각한 게 맞는지 상상을 하면서 읽어본다. 이 문서대로 다 완성했을 때 정말 내가 원하는 기능을 가진 프로그램이나 웹페이지가 만들어질까? 그게 맞다고 생각이 된다면 이제 인터뷰를 해야 할 시간이다.

 

omc를 설치한 다음 터미널에서 omc를 실행하여, '/deep-interview next-actions.md 파일을 읽고 다음 작업이 뭔지 확인해서 작업하자' 정도 입력하면, 이제 해당 작업 내용이 정확히 어떻게 구현되어야 하는 건지를 사람과 핑퐁 하면서 해당 작업의 스펙을 만들고, 그걸 코덱스가 검토한 다음 문제가 없을 때 작업자가 읽을 plan을 만들고, 그걸 다시 검토한 다음, 테스트를 만들고, 그걸 다시 검토해서 문제가 없으면 기획이 끝난다.

 

복잡하게 들리지만 앞서 말했듯이 사람이 할 일은 deep interview 스킬을 켜고, 질의에 응답하는 것 까지가 끝이다. 여기에서 알아서 구현으로 넘어간다

 

 

구현과 리뷰

구현은 설명할 게 없다. 계획보다 낮은 단계의 모델로 문서 그대로 구현하면 된다. 원래 sonnet을 썼는데 sonnet 5가 나오고 서브에이전트가 추가로 서브에이전트를 소환하는 버그? 같은 게 있어서 현재는 opus의 effort를 낮춰서 사용하고 있고, 코덱스의 성능이 더 좋은 시기 거나 두 llm 간 사용량 차이가 너무 크면(클로드는 주 사용량의 80% 를 썼는데 코덱스는 이제 30%를 썼다거나 하면) 코덱스를 구현자로 사용하기도 한다.

 

지금은 opus medium 이 구현자이기 때문에 코덱스를 리뷰어로 사용하고, 만약에 코덱스를 구현자로 사용하면 opus를 리뷰어로 사용해야 한다. llm 들은 읽는 거보다 생성이 사용량이 더 많이 닳기 때문에(api 요금도 마찬가지이고), 구현보다 리뷰가 훨씬 덜 사용한다. 그렇기 때문에 리뷰 결과를 보고 다시 구현자가 구현하는 것이 아니라 리뷰어가 바로 수정하도록 한 다음 blocker 가 0이 될 때까지 계속 반복한다.

 

코드 리뷰는 diff를 이용하여 기존과 달라진 내용만 리뷰하도록 해서 토큰을 아끼고, 그 대신 기존 코드와 동시에 free scan을 한번 더 돌려서 코드 간 갭을 확인하여 수정하고, 그 결과 문제가 없을 때 push를 한다.

  

 

결론

여기에 작업이 중단되었을 때에 텔레그램으로 연락이 오게 봇을 올려준 것을 마지막으로 지금의 워크플로우가 완성되었다.

 

계속 조금씩 수정하고 있어서 언제 또 뭐가 바뀔지는 모르겠는데 우선 일하면서 병행하기에는 지금 구조가 가장 적절한 것 같다. 나는 기획만 던져주고, 중간에 막히는 지점이 있을 때에 컨펌을 하고, 최종본을 보고 QA만 하면 되는 이 구조가 당분간은 최종이지 않을까?

 

만약 다른 회사에 가서 다시 코딩을 하게 된다면, 이 구조에서 이제 한 번에 한 작업만 하는 게 아니라 워크트리를 나눠서 동시에 여러 작업을 병행하는 식으로 하면 될 것 같다고 생각하고 있다. 

 

openai에서도 한 사람이 8시간 근무하면 에이전트 동작 시간이 24시간을 넘어간다는데, 이런 느낌으로 굴러가고 있는 게 아닐까? 그런 거대한 회사에서는 어떻게 사용하는지를 찾아보고 좀 더 수정해야겠다.