AI를 빡세게 통제하시나요, 아니면 그냥 맡기시나요? 실제로 어떤 방식이 더 나은 코드를 뽑아내는지 궁금합니다.

B는 최종 목표를 테스트 기준까지 포함해서 잘 정의했을 때만 작동함. A는 여전히 자기 작업에 자부심이 있는 사람들을 위한 것. B는 리뷰 피로도가 심함. 에이전트 코드를 다 리뷰하겠다고 큰소리치던 개발자들도 첫 주 지나면 다 포기함.

하나는 대략적인 형태 잡기용, 다른 하나는 세부 사항 채우기용이라 둘 다 필요함.

B는 토큰 보조금이 있을 때나 단기적으로 가능한 방식임.

짧은 리시(tight leash), 작은 PR, 자동 병합은 절대 금지, 프로덕션 코드는 항상 직접 검토함. 빠른 프로토타입이나 데모 만들 때는 느슨하게 풀어줌. 특히 기존 프로덕션 코드를 수정할 때는 조심해야 함. LLM이 죽은 코드나 중복된 부분을 남겨서 2500줄짜리 함수를 만들어버리는 경향이 있거든. 그냥 내버려 두면 공들여 설계한 아키텍처 다 망치고 5분 만에 유지보수 불가능한 상태로 만들어버림.

난 B로 시작해서 필요하면 A로 다듬는 편임. B를 할 때는 가이드라인이랑 목표를 대충 주고, 나한테 명확하게 질문을 던지거나 계획을 먼저 제시해보라고 함. 그러면 원하는 결과의 90%는 얻을 수 있고, 나머지는 구체적인 프롬프트로 미세 조정하면 됨. 그렇게 2주 주말 동안 SaaS 하나 뚝딱 만들었음. 진짜 빠르더라.

B 캠프는 에이전트한테 실패하는 테스트를 종료 조건으로 던져줄 수 있을 때 효과적임. 기계가 검증할 수 있는 기준이 없으면 AI가 지 맘대로 끝났다고 판단하는데, 그 판단은 보통 틀리거든. 테스트 기준이 명확한 신규 프로젝트라면 B가 최고임. 근데 기존 시스템이나 아키텍처 건드리는 거면 무조건 짧은 리시(tight leash)로 가야 함.

처음엔 나도 B였던 것 같은데, 지금은 모든 기능을 다 스코프(범위) 정해놓고 함.

계획 짤 때는 마음껏 하게 둠. 계획 수정하고 승인한 뒤에는 짧은 리시로 통제함. 주니어 엔지니어한테 주는 것처럼 읽기 권한은 거의 다 열어주는데(메트릭이나 깃 레포 등), 쓰기 권한은 없거나 엄격하게 제한함.

직관을 기르는 게 최고임. 시간이 지나면 아키텍처가 미해결이거나 목표가 불분명해서 주의가 필요한 부분과, 단순히 추가만 하면 되는 직관적인 부분을 구분할 수 있게 됨.

팀 관리하는 사람으로서(내가 컨트롤 프릭이고 마이크로 매니징한다는 건 알고 있음), AI도 똑같이 다룸. 모든 줄을 검토하고 작은 작업만 맡김. 긴 작업을 맡기고 싶어서 많이 시도해봤는데, 뭘 해도 결국 망쳐놓고 며칠씩 걸려 수정해야 할 쓰레기 더미만 만들어냄. 그래서 짧은 리드(short leash)가 답임.