솔직한 생각: 어떤 코딩 모델을 쓰느냐보다 엔지니어링 프로세스가 더 중요함
Hot take: The engineering process matters more than which coding model you're using
핵심 요약
모델 자체의 성능보다 체계적인 문서화와 검토 프로세스를 갖춘 엔지니어링 방식이 결과물에 더 큰 영향을 미친다는 의견입니다.
- 엔지니어링 프로세스 — 모델 선택보다 체계적인 워크플로우와 문서화가 결과물 품질을 결정함
- AI 네이티브 조직 — AI 시스템에 최적화된 새로운 개발 조직과 프로세스 설계가 필요함
- 시각적 설계 분리 — UI 코딩 전 이미지로 시각적 레퍼런스를 먼저 확정하는 방식이 효과적임
- 모델별 관리 방식 — 각 모델의 특성에 맞춰 관리자의 역할과 업무 지시 방식을 조정해야 함
이걸 올릴까 말까 고민 좀 했는데, 그냥 에라 모르겠다 싶어서 질러본다.
Opus, Sol 5.6/6.1, Astra 같은 모델들 써서 꽤 규모 있는 소프트웨어 프로젝트 몇 개 돌려봤는데, 솔직히 결과물 차이가 그렇게 큰지 잘 모르겠더라. 다들 일은 대충 비슷하게 처리하고, 또 다들 하나씩 꼭 빼먹는다. 코드 리뷰 한두 번 돌리고 나면 결국 다 비슷비슷한 수준으로 수렴함.
근데 이게 내가 쓰는 방식 때문인 것 같기도 해. 그냥 프롬프트 하나 던져주고 알아서 하라고 비는 게 아니거든. 큰 프로젝트 할 때는 시스템 인스트럭션만 1만~2만 토큰씩 때려 박고, 아키텍처, 요구사항, 코딩 표준, 테스트, 설계 결정 사항 같은 거 수백 페이지짜리 문서로 뒷받침해 둠.
문서 철저히 따르고, 업데이트 제때 하고, 지가 짠 코드 스스로 검토하게끔 규칙도 빡세게 걸어놨어. 에이전트들한테 아키텍처, 보안, 코드 퀄리티, 누락된 요구사항 같은 거 각자 다른 관점에서 리뷰하게 역할도 나눠줬고. 뭐 하나 놓치면 리뷰에서 바로 잡아서 수정하고, 다음엔 똑같은 실수 안 하게 문서나 인스트럭션 보강하는 식으로 굴리는 중임.
처음에 세팅하는 게 좀 빡세긴 한데, 일단 틀만 잡아놓으면 개별 코딩 작업이 아니라 프로젝트 통째로 맡겨버릴 수 있어서 편하더라.
내가 몇 년 동안 엔지니어링이랑 데이터 사이언스 팀 관리해 봤는데, 에이전트 다루는 것도 딱 그 방식이랑 똑같아. 우선순위 정하고, 요구사항 정의하고, 업무 할당하고, 결과물 리뷰하고, 전체 시스템 잘 돌아가는지 확인하는 거지. 실제 팀 운영할 때랑 똑같이, 얘네가 내놓은 결과물도 내가 직접 리뷰하고 토론하면서 개선안 제시해야 함.
이제 코딩 자체는 내 업무에서 차지하는 비중이 꽤 작아졌어. 솔직히 말해서, 결과물의 일관성이나 퀄리티는 내가 예전에 전통적인 개발 프로세스로 일할 때보다 오히려 더 나은 것 같음. 개발자들 비하하려는 게 아니라, 그냥 일을 조직하는 방식 자체가 완전히 다르다는 거지.
물론 모델마다 속도, 비용, 컨텍스트 처리 능력, 그리고 한 번에 제대로 해내는 확률 같은 건 분명 차이가 있어. 그건 나도 인정함. 근데 우리가 어떤 모델이 코드를 제일 잘 짜는지 비교하는 데 너무 시간 낭비하는 거 아닌가 싶어. 정작 중요한 건 그 모델들을 중심으로 어떻게 엔지니어링 프로세스를 구축할지 고민하는 건데 말이야. 최소한 나한테는 문서화, 워크플로우, 리뷰 프로세스만 탄탄하게 갖춰져 있으면, 모델 바꿔도 결과물 차이가 그렇게 크지 않더라고. 속도 차이 빼고는 말이지.
혹시 나처럼 규모 크고 장기적인 프로젝트 돌리는 사람들 중에 이런 단계까지 온 사람 있나? 아니면 체계적인 워크플로우랑 리뷰 프로세스를 갖춰도 여전히 모델 간의 큰 차이를 느끼고 있는지 궁금하네.

