요즘 AI 코딩 도구를 쓰다 보면 이런 유혹이 들죠. '모델이 이렇게 똑똑한데 그냥 통째로 맡겨버릴까?' 실제로 Fable급 최신 모델들은 큰 기능 하나를 처음부터 끝까지 혼자 구현해내는 모습을 보여주거든요. 그런데 최근 한 개발자가 정반대의 주장을 들고 나왔어요. 최신 모델에게서 최고의 결과를 뽑아내는 비결은 자율성을 더 주는 게 아니라, 오히려 '목줄을 짧게 잡는 것'이라는 겁니다. 오늘은 이 '짧은 목줄(short leash)' 방식이 뭔지, 왜 효과가 있는지 찬찬히 풀어볼게요.
'짧은 목줄'이 뭐냐면
강아지 산책에 비유하면 딱이에요. 목줄을 길게 풀어주면 강아지는 신나게 뛰어다니지만, 어디로 튈지 모르고 사고가 나도 한참 뒤에야 알게 되죠. 반대로 목줄을 짧게 잡으면 방향을 수시로 잡아줄 수 있어요. AI 코딩도 마찬가지라는 거예요. '이 기능 전체를 구현해줘'라고 던져놓고 30분 뒤에 결과를 받는 대신, 작업을 아주 잘게 쪼개서 하나씩 시키고, 그때마다 결과를 확인하고 다음 지시를 내리는 방식이에요. AI를 오토파일럿처럼 쓰는 게 아니라, 옆자리에 앉은 페어 프로그래밍 파트너처럼 쓰는 거죠.
왜 길게 풀어주면 산으로 갈까
핵심은 '오류의 복리 효과'예요. 이게 뭐냐면, AI가 작업 초반에 잘못된 가정을 하나 하면 그 위에 쌓이는 모든 코드가 그 가정을 전제로 만들어진다는 거예요. 10단계짜리 작업에서 각 단계 성공률이 95%라고 해도, 10단계를 연속으로 전부 맞출 확률은 60% 수준까지 떨어지거든요. 게다가 틀린 코드가 대놓고 틀린 게 아니라 '그럴듯하게' 틀렸다는 게 진짜 문제예요. 컴파일도 되고 테스트도 얼추 통과하는데, 설계 의도와 미묘하게 어긋난 코드요. 이런 게 3천 줄짜리 PR로 돌아오면 리뷰하는 비용이 직접 짜는 비용보다 커져버려요. '차라리 내가 짜고 만다'는 말이 나오는 이유죠.
그래서 실제로 어떻게 하냐면
방법 자체는 생각보다 소박해요. 첫째, 작업을 15~30분 안에 끝날 크기로 쪼갭니다. 둘째, 코드를 짜기 전에 먼저 계획을 세우게 하고, 그 계획을 사람이 읽고 승인해요. 방향이 틀렸으면 코드가 한 줄도 나오기 전에 잡는 거죠. 셋째, 한 번에 하나의 변경만 시키고, 각 단계가 끝날 때마다 테스트를 돌리고 커밋합니다. diff가 작으니까 리뷰가 실제로 가능해지고, 문제가 생겨도 어느 지점에서 어긋났는지 바로 보여요. 넷째, 이상한 낌새가 보이면 대화를 이어가며 수습하려 하지 말고, 그 지점으로 되돌아가서 새로 시작해요. 오염된 컨텍스트 위에서 땜질하는 것보다 깨끗하게 다시 시작하는 게 결과적으로 더 빠르거든요.
업계 흐름에서 보면
재미있는 건 업계가 지금 정확히 반대 방향으로도 달리고 있다는 거예요. AI 회사들은 에이전트가 더 오래, 더 자율적으로 일하게 만드는 데 투자하고 있고, '몇 시간짜리 작업을 혼자 해냈다'가 모델 발표의 단골 자랑거리가 됐잖아요. 한쪽에서는 자율성을 늘리고, 다른 한쪽에서는 '그래도 사람 검문소를 촘촘히 두는 쪽이 결과물이 낫더라'는 실전 경험담이 나오는 상황인 거죠. 스펙 주도 개발이나 계획 승인 워크플로 같은 도구가 계속 나오는 것도 같은 맥락이에요. 모델이 아무리 좋아져도 '의도를 정확히 전달하고 어긋남을 빨리 발견하는 문제'는 사라지지 않는다는 얘기예요.
한국 개발자에게는
팀에 AI 도구를 도입했다가 '리뷰 지옥'을 겪어본 분이라면 바로 공감하실 거예요. 이 방식은 당장 내일부터 적용할 수 있어요. AI에게 시킬 작업을 티켓 쪼개듯 잘게 나누고, 계획을 먼저 받아보고, 커밋 단위를 작게 유지하는 것. 사실 이건 좋은 개발 습관 그 자체라서, 주니어 개발자가 AI와 협업하는 감각을 익히는 훈련으로도 아주 좋아요. 도구 없이 습관만으로 시작할 수 있다는 점도 매력이고요.
정리하면, AI 코딩의 생산성은 모델 성능만이 아니라 '검증 주기를 얼마나 짧게 가져가느냐'에서 나온다는 이야기예요. 여러분은 AI에게 얼마나 긴 목줄을 주고 계신가요? 통째로 맡겨서 성공한 경험, 혹은 크게 데인 경험이 있다면 댓글로 나눠주세요.
🔗 출처: Hacker News