코딩 에이전트 과잉 설계 — 단순함을 지키는 건 사람 몫

지난달, 홈페이지에 CORS 헤더 하나만 추가하려고 코딩 에이전트에게 요청했습니다. 돌아온 건 Origin 검증 로직에 토큰 기반 인증, IP 화이트리스트, 에러 로깅 미들웨어까지 얹어진 수백 줄짜리 PR이었어요. 전 그냥 Access-Control-Allow-Origin: * 한 줄만 원했거든요. 최근 커뮤니티에서 "AI 에이전트가 모든 걸 과잉 설계한다"는 불만이 화제가 됐는데, 제가 6개월 넘게 AI 에이전트 32마리로 파이프라인을 굴려본 결론은 이겁니다. 이건 모델이 나빠진 게 아니라, 단순함을 지킬 경계를 사람이 안 그어준 탓이에요.

왜 에이전트는 항상 더 복잡하게 만들까요?

제가 운영하는 한국어 블로그 자동발행 파이프라인엔 AI 에이전트가 32마리 있습니다. 발행팀 17마리, 개발·운영팀 5마리, 쇼츠 제작팀 5마리, 카드뉴스팀 5마리죠. 매일 3편 발행하는데 발행 전 결정론 품질 게이트가 16종, 그 뒤에 검증자 에이전트 5명이 차단권을 들고 또 심사합니다. 이 구조를 처음 보는 사람은 이렇게 묻더라고요. "이것도 과잉 설계 아니냐고요."

맞습니다, 과할 수 있어요. 하지만 실제로 잡아낸 게 있으니까 남겨뒀습니다. 지난 2개월간 게이트를 거친 글이 242건인데, 그중 69건이 차단됐어요. 섹션 간 재진술이나 검색 진입점 부족 같은 걸 자동으로 걸러낸 거죠. 없었으면 똑같은 표현을 반복하거나 검색에서 안 보이는 글로 발행됐을 겁니다. 심지어 지금 쓰고 있는 이 글도 오늘 게이트에 걸렸어요. 첫 버전에 상투적 마무리 표현을 써서 게이트 두 개가 막았거든요. 경계를 그어주는 장치가 실제로 작동한다는 걸 제가 몸소 증명한 셈이죠.

코딩 에이전트도 비슷합니다. "HTTP 헤더 추가"라는 요청만 받으면, 에이전트는 안전한 쪽으로 기울도록 훈련받은 모델이라 보안·에러 처리·로깅까지 챙기는 게 디폴트예요. 제가 "CORS 헤더 한 줄만"이라고 명시 안 하면, 에이전트 입장에선 "프로덕션 환경이면 당연히 검증 로직도 필요하지 않을까" 하고 덧붙이는 거죠. 훈련 데이터가 "좋은 코드"를 그렇게 정의했으니까요.

과잉 설계의 진짜 원인은 경계 부재입니다

작년 12월, 자동발행 파이프라인에 SEO 폐루프를 추가할 때 겪은 일입니다. 처음엔 "구글 서치 콘솔 API로 조회수 가져와서 낮은 글 찾아줘"라고만 했어요. 에이전트가 돌려준 건 순위 추적, 키워드 분석, 경쟁사 비교, 심지어 자동 리라이팅 제안까지 담긴 400줄 스크립트였습니다. 전 그냥 조회수 숫자만 원했는데요.

두 번째 시도에선 이렇게 바꿨습니다. "GSC API로 지난 7일 조회수만 JSONL로 저장. 분석·추천 기능 금지. 100줄 이내." 결과는 83줄이었고, 딱 필요한 것만 했어요. 차이는 경계를 그어줬느냐 안 그어줬느냐였습니다.

제 파이프라인에서 게이트 16종이 살아남은 이유도 같습니다. 처음엔 게이트가 8종이었는데, 실제로 돌려보니 AI-티 탐지, 내부 중복, 니치 적합성 같은 게 빠져서 품질이 들쭉날쭉했거든요. 그래서 필요한 만큼만 추가했어요. 근데 만약 에이전트한테 "품질 게이트 만들어줘"라고만 했으면 아마 30종쯤 나왔을 겁니다. "혹시 모르니까" 하면서요.

복잡함이 나쁜 건 아니지만, 맥락이 필요합니다

"그래도 안전한 게 나쁘냐"는 반론이 있을 수 있어요. 맞습니다, 안전은 중요하죠. 하지만 맥락 없는 안전 장치는 짐이에요. 제가 CORS 헤더를 로컬 테스트 환경에 추가하는데 IP 화이트리스트가 왜 필요합니까. 에이전트는 모르는 거예요, 이게 프로덕션인지 테스트인지. 그걸 알려주는 건 제 몫이죠.

"모델이 퇴화한 거 아니냐"는 의견도 봤습니다. 제 경험으론 아닙니다. 오히려 최근 모델일수록 보안·접근성·테스트 커버리지를 더 챙기는 쪽으로 학습돼 있어요. 문제는 그게 항상 필요한 게 아니라는 거죠. 프로토타입 단계에선 빠른 검증이 우선이고, 리팩토링 단계에선 기존 로직 유지가 우선인데, 에이전트는 그 구분을 못 해요.

제 파이프라인에서 검증자 에이전트 5명(eagle, bee, swan, raven, peacock)이 차단권만 갖고 승인권은 없는 이유도 비슷합니다. 승인까지 주면 "이 글 완벽하게 만들자"면서 과잉 수정이 시작되거든요. 차단만 시키니까 명백한 문제만 걸러내고, 나머지는 그대로 통과해요.

단순함을 지키려면 사람이 먼저 정의해야 합니다

코딩 에이전트에게 "과잉 설계하지 마"라고 말하는 건 소용없습니다. 대신 "이 범위 안에서만 해"라고 말해야 해요. 제가 지금 쓰는 방법은 세 가지입니다.

첫째, 금지 조건을 명시합니다. "인증 로직 추가 금지, 기존 함수 시그니처 변경 금지, 100줄 이내." 이렇게 쓰면 에이전트가 경계를 넘지 않아요. 둘째, 출력 형식을 고정합니다. "JSONL 한 줄에 날짜·조회수만, 다른 필드 금지." 형식을 정해주면 분석·추천 같은 덤은 들어갈 자리가 없죠. 셋째, 단계를 쪼갭니다. "먼저 헤더만 추가, 검증 로직은 별도 티켓." 한 번에 다 시키면 에이전트가 알아서 붙이는데, 쪼개면 각 단계가 단순해져요.

제 파이프라인도 마찬가지입니다. 게이트 16종이 많아 보이지만, 각 게이트는 하나만 체크해요. 중복 게이트는 중복만, 링크 게이트는 링크만 봅니다. 하나가 여러 개를 보기 시작하면 거기서 과잉이 시작되거든요.

자주 묻는 질문

Q. 에이전트가 제안한 추가 기능이 유용할 때도 있지 않나요? A. 있습니다. 그럴 땐 별도 티켓으로 분리하세요. 지금 당장 필요한 것과 나중에 고려할 것을 섞으면 둘 다 망가집니다.

Q. 경계를 너무 좁게 그으면 에이전트 활용도가 떨어지지 않나요? A. 오히려 반대예요. 명확한 범위 안에서 에이전트가 더 빠르고 정확하게 일합니다. 애매하게 시키면 재작업이 늘어요.

Q. 프로덕션 환경에선 보안·에러 처리가 필수 아닌가요? A. 필수 맞습니다. 다만 순서가 있어요. 먼저 핵심 기능을 단순하게 구현하고, 검증 후 방어 로직을 붙이는 게 디버깅도 쉽고 안전합니다.

Q. 게이트를 16종이나 두는 게 과잉 아닌가요? A. 처음엔 저도 그렇게 생각했는데, 실제로 돌려보니 각 게이트가 잡는 문제가 달라요. 없으면 품질이 떨어지고, 있으면 자동으로 걸러지니까 유지합니다.