바이브코딩을 한동안 굴려보며 내린 결론은 의외로 단순하다. "가장 똑똑한 모델 하나에 전부 맡기는 것"이 최선이 아니라는 점이다. 자료정리, 환경 관리, 기획 검토, 실제 개발은 요구하는 역량이 제각기 다르다. 한 도구에 몰아주면 어딘가에서 반드시 균열이 생긴다.
그래서 단계별로 가장 잘 맞는 도구를 따로 붙이는 분업 구조로 옮겨갔다. 아래는 지극히 개인적인 셋팅이며 작업 성격에 따라 얼마든지 달라질 수 있음을 전제한다.
(1) 자료정리에는 옵시디언을 쓴다.
핵심은 모든 노트가 마크다운(md) 파일로 저장된다는 점이다. md는 결국 순수 텍스트이기 때문에 AI가 읽고 쓰기에 최적이고, 폴더 단위로 맥락을 통째로 전달하기에도 유리하다. 흥미롭게도 해외 IT 크리에이터들 사이에서도 개인용 SaaS를 직접 개발하기보다 옵시디언에 지식을 누적하는 방식이 늘고 있다. 무게중심이 '도구 제작'에서 '지식 축적'으로 이동하는 흐름이다.
(2) 에이전트 환경은 마이크로소프트가 에이전트 특화로 내놓은 패키지 매니저 APM으로 관리한다.
MCP 설정과 보안 같은 기본 환경을 .yml 파일 하나로 다룬다는 점이 강점이다. 흩어진 설정은 기기를 바꾸거나 협업할 때마다 처음부터 다시 맞춰야 하지만, yml 한 장이면 환경 자체를 복제하듯 옮길 수 있어 재현성이 크게 올라간다.
(3) 기획 검토에는 Opus 4.8을 둔다.
기획의 주체는 어디까지나 사람이어야 한다. 다만 내가 원한 것은 대리 기획이 아니라, 내가 놓친 지점을 한 번 더 짚고 피드백해주는 역할이었다. 직전 버전인 4.7에서 크게 실망해 지금도 Pro 등급으로만 유지하고 있지만, 기획 문서를 정리하고 빈틈을 메우는 용도로는 충분한 몫을 한다.
(4) 실제 개발은 GPT-5.5가 맡는다. 속도도 빠르지만 진가는 수정 단계에서 드러난다.
코드를 고칠 때 전체 맥락을 다시 읽고, 자체 검증을 거쳐 동일한 문제가 재발하지 않도록 막아준다.
단순히 코드를 출력하는 모델이 아니라 '일 잘하는 동료 개발자'에 가깝다.
정리하면 정리는 옵시디언, 환경은 APM, 기획 점검은 Opus 4.8, 개발은 GPT-5.5다. 물론 이 조합은 '오늘까지의' 최적해일 뿐이다.
도구는 빠르게 바뀌고, 중요한 것은 특정 제품의 이름이 아니라 '단계마다 가장 잘 맞는 손을 붙인다'는 원칙 그 자체다.
){kind=small}
){kind=small}
){kind=small}
){kind=small}