에이전트형 AI를 밀어붙이는 이유는 무엇인가? 모델이 간단한 지시도 제대로 따르지 못하는데

• AI 코딩 모델이 단일 명령조차 신뢰성 있게 수행하지 못하는 현실에서, 백그라운드에서 자율적으로 작동하는 에이전틱 코딩에 대한 과도한 기대가 형성되고 있음
• 작성자는 100줄 규모의 Golang 함수를 참조 코드로 제공했음에도 GPT-5와 Gemini Pro 모두 일부 로직을 누락하거나 업데이트를 빠뜨리는 문제를 경험
• 에이전틱 시스템이 50개 파일과 다수 함수를 자율적으로 처리하는 것은 현재 기술 수준에서 비현실적이며, 오히려 디버깅에 더 많은 시간이 소요될 위험이 있음
• 커뮤니티 응답은 체계적인 프롬프팅, 문서화, 단계별 검증을 통해 제한적으로 성공적인 활용이 가능하다는 의견과, 에이전틱은 아직 실용적이지 않다는 회의적 의견으로 양분됨
• 현재 LLM은 지능이 아닌 지식 기반 시스템이므로, 개발자가 직접 맥락을 제공하고 단계별로 검증하는 "도구적 활용"이 현실적인 접근법임

원글 작성자의 문제 제기

• 단순 명령 실패 사례: 100줄의 Golang 함수를 참조로 제공하고 다른 함수를 같은 구조로 업데이트하도록 요청했으나, GPT-5와 Gemini Pro 모두 일부 로직을 누락하거나 업데이트를 빠뜨림
• 에이전틱 코딩의 비현실성: 단일 함수도 제대로 처리하지 못하는 상황에서 50개 파일에 걸쳐 다수의 함수를 자율적으로 수정하는 에이전틱 방식은 더 많은 문제를 야기할 것으로 우려
• 6000줄 파일 업데이트 질문: Stripe 버전 업데이트처럼 6000줄 규모의 파일을 안전하게 수정하는 방법에 대해 커뮤니티 의견 요청

긍정적 활용 사례 및 방법론

체계적 문서화 및 인덱싱 접근

• Markdown 참조 파일 활용: .md 파일에 레퍼런스를 저장하고 AI가 이를 읽도록 지시하면 일관성과 정확도가 향상됨
  • 예시 프롬프트: "첨부된 goLang_Update_reference.md 파일을 참조하여 update 함수의 핵심 포인트를 요약하고, 이를 기반으로 소프트웨어 업데이트 초안 작성"
• 로컬 인덱스 구축: 대규모 파일(6000줄 이상)의 경우 1000줄 단위로 스캔하여 함수명과 라인 참조를 포함한 인덱스 생성
  • 프론트엔드 작업 시 fr.index.md 등 특정 영역만 분리한 인덱스 활용

에이전트 관리 및 작업 구조화

• 에이전트 전문화: 설계(architect), 코드 탐색(codeseeker), 코더(coder) 등 역할별 에이전트를 구성하고 각각에 맞는 .md 규칙 파일 제공
• 수직 슬라이스 접근: 10만 토큰 이하로 완성 가능한 작은 기능 단위로 작업을 분할
  • 10만 토큰을 초과하면 에이전트의 오작동 가능성이 급증함
• 작업 문서화 강제: docs/TASKS.md, docs/WORKLOG.md, docs/DECISIONS.md 업데이트를 필수화하여 작업 연속성 확보

Plan Mode 및 Ask Mode 활용

• Plan Mode: 프로젝트 전체를 검토하고 요청에 따라 계획을 수립한 뒤 단계별로 진행
• Ask Mode: 코드베이스 쿼리, 아이디어 탐색, 옵션 검토 등에 활용하며 Google/StackOverflow 대체 도구로 유용

단위 테스트 선행 접근

• 테스트 기반 개발: 함수 작성 전 단위 테스트를 먼저 작성하고, AI가 테스트를 통과하는 코드를 반복 생성하도록 함
  • 기능적으로 올바른 코드를 얻을 확률이 크게 증가하며, 이후 최적화 및 정리 작업만 필요

회의적 의견 및 한계 인식

에이전틱의 현실적 한계

• 감독 없는 작업은 자살 행위: 현재 기술 수준에서 티켓을 할당하고 백그라운드에서 자율적으로 작업하도록 두는 것은 실패 확률이 높음
• 거짓말 가능성: 모델은 성공보다 환각(hallucination)을 생성할 가능성이 더 높으며, 최악의 경우 기존 코드를 파괴할 수 있음
• Planning Mode의 중복성: 기본 모델에게 상세한 계획을 요청하는 것으로도 충분하며, Planning Mode는 실질적으로 새로운 기능을 제공하지 않음

LLM의 본질적 제약

• 추론이 아닌 예측: 모델은 결과를 검증하지 않고 다음 단어를 예측하는 방식으로 작동하므로, grounding, memory, feedback이 개선되기 전까지 신뢰성은 계속 불안정할 것
• 지능 없는 지식 기반: LLM은 지능이 없는 고도화된 지식 베이스이며, 개발자가 직접 지능(BYOI: Bring Your Own Intelligence)과 맥락을 제공해야 함
• 메모리 부족: 모델은 진정한 메모리가 없고 context와 context cache에만 의존하므로, 새 채팅을 시작할 때마다 맥락이 초기화됨

언어 및 데이터 편향

• Golang의 상대적 불리함: Golang은 Python이나 JavaScript에 비해 공개 코드베이스가 적어 모델이 학습한 패턴과 관례가 부족함
  • 이는 일관성 있는 편집이나 변환 결과를 얻기 어렵게 만드는 구조적 요인

성공적 활용을 위한 실용적 가이드

프롬프팅 및 맥락 제공

• 명확하고 상세한 지시: 문법과 구두점을 정확히 사용하며, 모호한 표현 대신 명시적 지시 제공
• 모든 관련 파일 명시적 참조: 에이전트가 사용해야 할 파일을 모두 명시하지 않으면 스파게티 코드 발생 확률이 증가
• 규칙 파일 설정: 워크스페이스 전체 규칙과 프로젝트별 규칙 파일을 설정하여 일관된 코드 생성 유도
• @Docs 활용: 에이전트에게 필요한 핵심 지식을 제공하기 위해 문서 참조 기능 활용 (일부 버전에서 작동 불안정)

작업 범위 및 검증

• 작은 단위로 분할: 한 번에 처리할 수 있는 최소 단위로 작업을 나누고, 각 단계를 검증한 후 다음 단계로 진행
• 실시간 검토: 생성되는 모든 코드를 실시간으로 검토하고, 즉시 수정 요청하여 스파게티 코드 방지
• 백업 및 버전 관리: 각 단계마다 백업을 생성하고 GitHub 등 버전 관리 시스템 활용
• 테스트 실행: pytest --testmon -q로 영향받는 테스트를 증분 실행하고, 완료 전 전체 테스트 실행

모듈화 및 코드 구조

• 6000줄 파일 분할: 단일 파일에 6000줄은 비모듈적이며 맥락 제공에 불리하므로, 500줄 규모의 12개 파일로 분할하는 것이 효과적
• 수직 슬라이스 선호: 끝에서 끝까지 실행 가능한 작은 기능 단위로 개발

모델 선택 및 비용 관리

• Claude Sonnet 4.5 우선 고려: GPT나 Gemini에 비해 일관성과 정확도가 높아 추가 비용 대비 가치가 있음
• 토큰 소비 주의: 대규모 계획은 많은 토큰을 소모하므로, 실제 실행 시 작은 단계로 나누어 진행하는 것이 비용 효율적

특수 사용 사례

일회성 스크립트 생성

• 분석 스크립트: 하루에 수백 개의 일회성 데이터 분석 스크립트를 작성해야 하는 경우, 정확도가 50%라도 수동 작성 대비 1000배 빠르게 생성 및 실행 가능
• 결과 검증 가능성: 결과를 직접 검증할 수 있으므로 정확도가 낮아도 실용적

처음부터 앱 구축

• 멀티 에이전트 구조: 대규모 앱을 처음부터 구축할 때 감독 에이전트가 다른 에이전트의 작업을 검토하며 일관성 유지
  • import 이름, 변수명 일관성, 코드 중복 방지 등에 효과적
• 비용 대비 효율성: 여전히 복잡한 수정 및 리팩토링이 필요하여 단계별 접근이 장기적으로 더 저렴

커뮤니티 의견 요약

긍정적 경험 (3~5배 생산성 향상)

• Next.js 웹사이트: 제로에서 완전 작동하는 배포 가능한 웹사이트를 몇 분 만에 구축
• 복잡한 기능 구현: 채팅 앱에 threads 기능을 3~4분 만에 구현 (예상 3일 작업량)
• 체계적 접근 시: 명확한 규칙, 충분한 맥락, 단계별 검증을 조합하면 일관된 성공 가능

부정적 경험 (현재는 비실용적)

• 스파게티 코드 양산: 광범위한 목표를 주면 문서 업데이트 누락, 잔여 파일 미삭제 등 문제 발생
• 의미적 오류: 기술적으로는 작동하지만 코드 위치가 부적절하거나 기존 함수를 재구현하는 등 구조적 문제
• 5분 이상 추적 실패: 5분 이상 실행되는 긴 추적은 대부분 쓸모없는 결과 생성