AI 에이전트를 마이크로매니징하면 오히려 더 멍청해지는 이유

오늘날 최신 GitHub 레포지토리에서 아무 system_prompt.txt 파일이나 열어보세요. 무엇이 보이나요? 대개는 불안감에 휩싸여 빽빽하게 적어둔 텍스트의 벽일 겁니다. "절대 X를 하지 마시오. 반드시 정확히 3개의 글머리 기호로 출력하시오. 이 라이브러리는 절대 사용하지 마시오."

개발자들은 인류 역사상 가장 진보된 추론 엔진을 마치 깨지기 쉬운 정규식 스크립트처럼 다루고 있습니다.

역사적으로 보면 이런 강박적인 태도는 완전히 이해가 갑니다. 불과 1~2년 전만 해도 초기 LLM들은 주제를 벗어나지 않게 하려면 엄청난 밀착 관리가 필요했으니까요. 하지만 시대가 변했습니다. 최신 모델들은 놀라울 정도로 똑똑해졌지만, 우리는 여전히 1980년대 전자레인지를 프로그래밍하듯 프롬프트를 작성하고 있습니다. 지능을 하드코딩하려고 애쓰고 있는 셈이죠.

최근 Vercel에서 이 주장을 증명하는 흥미로운 일이 있었습니다. 그들의 엔지니어링 팀은 v0 제품을 어떻게 개선했는지에 대한 분석 과정을 공개했는데, 직관에 어긋나는 결정을 상세히 설명했습니다. 바로 에이전트 도구의 80%를 제거했다는 것입니다.

결과는 어땠을까요? 시스템은 망가지지 않았습니다. 오히려 훨씬 더 좋아졌죠. 과도하게 규정된 도구와 엄격한 가드레일을 걷어냄으로써, 그들은 혼란을 줄이고 모델이 가장 잘하는 일, 즉 '문제를 추론하는 일'을 하도록 내버려 두었습니다. 마찰을 줄이니 더 나은 코드가 나온 것입니다.

지금 AI를 활용해 무언가를 만들고 있는 모든 분들에게 여기 중요한 교훈이 있습니다. 엄격한 규칙이 아닌, 원칙을 제시하세요.

LLM에게 단계별로 무엇을 해야 할지 정확히 지시하면, 모델은 제한된 어텐션(연산량)을 품질이 아닌 '지시사항 준수'에 낭비하게 됩니다. 여러분이 하드코딩한 방식보다 더 우아한 해결책을 찾기 위해 방대한 학습 데이터를 활용할 수 있는 능력을 빼앗아버리는 셈입니다.

그 차이를 이해하기 위해, 대부분의 개발자가 에이전트 프롬프트를 작성하는 방식과 실제로 어떻게 작성해야 하는지를 비교해 보겠습니다.

나쁜 예시 (엄격한 규칙):

"사용자 데이터를 가져오는 Python 함수를 작성해. 반드시 requests 라이브러리를 사용해야 해. try/except 블록으로 에러를 처리해야 해. 정확히 'name', 'email', 'status' 키를 가진 딕셔너리를 반환해야 해. async는 사용하지 마. 모든 줄에 주석을 달아."

좋은 예시 (원칙과 목표):

"사용자 데이터를 가져오는 안정적인 Python 함수를 작성해 줘. 최신의 표준 라이브러리를 선호해. 코드는 프로덕션 환경에 적합해야 하며, 이는 네트워크 장애와 엣지 케이스를 안전하게 처리해야 함을 의미해. 복잡하고 기발한 코드보다는 가독성과 깔끔한 아키텍처를 우선시해 줘. 다운스트림 시스템은 표준 사용자 프로필(name, email, status)을 기대하고 있어."

차이가 느껴지시나요? 첫 번째 예시는 AI를 믿을 수 없는 주니어 개발자 취급합니다. 두 번째 예시는 목표와 맥락을 이해하는 시니어 엔지니어처럼 대우하죠. 좋은 결과물이 어떤 모습인지, 그리고 왜 그런지 알려준 다음, 한 걸음 물러서서 어떻게 할지는 AI가 스스로 찾아내도록 맡기는 것입니다.

물론, 이 규칙에도 한 가지 중요한 예외가 있습니다.

에이전트가 다른 에이전트와 통신할 때, 혹은 업스트림 에이전트가 엄격한 다운스트림 데이터베이스 파서로 데이터를 전달할 때는 절대적인 엄격함이 필요합니다. 기계 간의 핸드오프(handoff)에는 정확하고 타협 없는 JSON 스키마가 필수적이니까요. 하지만 추론, 생성, 문제 해결을 위한 것이라면? 통제를 조금 내려놓으세요.

오늘 당장 여러분의 코딩 어시스턴트를 업그레이드하고 싶다면, 아래 블록을 그대로 복사해서 claude.md, memory.md 또는 에이전트의 핵심 시스템 프롬프트에 붙여넣어 보세요.

## Prompt Writing Philosophy
When writing LLM prompts (system prompts, skill specs, subagent prompts): **give principles, not rigid rules.**
- Tell the LLM what good output looks like and why — let it figure out how
- Avoid prescribing exact fields, counts, or formats unless the output is a machine-consumed intermediate
- Exception: structured handoffs between agents can be rigid because downstream agents need consistent field names

기계를 마이크로매니징하려는 시도를 멈추세요. 최신 LLM을 믿어보세요. 우리가 그들을 어린아이 취급하지 않을 때, 그들은 훨씬 더 빠르고, 똑똑하며, 무한히 더 유능해집니다.