프로덕션 AI 에이전트를 만들며 배운 여섯 가지 진실
코드와 감정 사이에서 찾은 작은 지혜들
"이론과 현실 사이에는 이론만큼이나 큰 차이가 있다."
AI 에이전트를 처음 만들기 시작했을 때, 저는 마치 어둠 속에서 퍼즐을 맞추는 기분이었습니다. 수많은 튜토리얼과 논문들이 있었지만, 정작 실제 프로덕션 환경에서 마주하는 문제들에 대한 답은 어디에도 없었죠. 마치 요리책으로는 배울 수 없는 엄마의 손맛처럼, 실제 개발 과정에서만 얻을 수 있는 '부족한 지식'들이 있었습니다.
그렇게 무수히 많은 시행착오를 겪으며, 저는 여섯 가지 핵심 원칙을 발견했습니다. 이는 단순한 기술적 가이드라인이 아니라, 실제로 작동하는 AI 에이전트를 만들기 위한 살아있는 지혜입니다.
첫 번째 원칙: 시스템 프롬프트에 진심을 다하라
"마법 같은 트릭은 없다, 오직 명확함만이 있을 뿐"
오랫동안 저는 프롬프트 엔지니어링을 신뢰하지 않았습니다. "$100 팁을 줄게", "할머니가 돌아가시기 전에 이것이 필요해" 같은 접근법들은 마치 무당의 주술처럼 느껴졌거든요. 일시적으로는 효과가 있을지 몰라도, 장기적으로는 신뢰할 수 없는 방법들이었죠.
하지만 제 생각이 바뀌는 순간이 있었습니다. 바로 현대의 LLM들이 필요로 하는 것은 트릭이 아닌 명확성이라는 걸 깨달았을 때였어요.
# 우리가 Claude에게 ast-grep 규칙을 생성하도록 하는 시스템 프롬프트
# 교묘한 속임수 없이, 오직 상세한 설명만으로
"모델들은 지시를 따르는 데 뛰어나다. 문제는 종종 지시 자체의 모호함에 있다."
실제로 Anthropic의 가이드나 Google의 프롬프팅 전략을 따라가다 보면, 복잡한 트릭보다는 직접적이고 상세한 지시가 얼마나 중요한지 알 수 있습니다.
한 가지 제가 즐겨 사용하는 방법은 Deep Research와 같은 LLM 변형을 활용해 초기 시스템 프롬프트 초안을 만드는 것입니다. 물론 인간의 개선이 필요하지만, 훌륭한 출발점이 되어줍니다.
두 번째 원칙: 콘텍스트를 현명하게 나누어라
"모든 것을 한 번에 주면, 아무것도 제대로 받지 못한다"
좋은 시스템 프롬프트가 준비되었다면, 이제 콘텍스트 관리의 차례입니다. 이는 절묘한 균형의 예술이죠.
콘텍스트가 부족하면 모델은 환각을 일으키거나 궤도를 벗어나거나 아예 답변을 거부합니다. 너무 많으면 주의력 감쇄(attention attrition) 현상으로 핵심 정보를 놓치게 되고, 비용과 지연시간도 증가하죠.
저희가 발견한 원칙은 최소한의 필수 지식을 먼저 제공하고, 필요에 따라 도구를 통해 추가 콘텍스트를 가져올 수 있는 옵션을 주는 것입니다.
예를 들어, 프로젝트의 모든 파일 목록은 프롬프트에 포함시키되, 실제 파일 내용은 변경 요청과 관련된 것만 읽어오는 도구를 제공하는 식이죠.
"캡슐화는 객체지향 프로그래밍의 화두였지만, 콘텍스트 관리에서는 더욱 중요하다."
세 번째 원칙: 도구를 세심하게 설계하라
"에이전트의 도구는 산만한 천재 후배를 위한 API다"
AI 에이전트의 핵심 기능은 도구 호출입니다. LLM + 노출된 도구 + 기본 제어 흐름 연산자의 조합이 바로 에이전트를 만드는 것이죠.
에이전트를 위한 도구 세트를 설계하는 것은 API를 설계하는 것과 비슷하지만... 실제로는 더 복잡합니다. 인간 API 사용자들은 행간을 읽고, 복잡한 문서를 탐색하며, 해결책을 찾아낼 수 있습니다. 하지만 LLM들은 여러분의 허점을 악용할 가능성이 매우 높기 때문에, 애초에 허점이 없어야 합니다.
좋은 도구들은 다음과 같은 특징을 가집니다:
비슷한 수준의 세분화로 작동
엄격하게 타입이 지정된 제한적인 매개변수
집중적이고 잘 테스트됨
멱등성(idempotency)을 권장하여 상태 관리 문제 방지
대부분의 소프트웨어 엔지니어링 에이전트들은 10개 미만의 다기능 도구(read_file, write_file, edit_file, execute 등)를 가지며, 각각 1-3개의 매개변수를 가집니다.
네 번째 원칙: 피드백 루프를 설계하라
"창의적인 행위자와 엄격한 비평가의 이중주"
좋은 에이전트 솔루션은 LLM과 전통적인 소프트웨어의 장점을 결합합니다. 이를 위한 핵심 방법 중 하나가 actor-critic 접근법과 유사한 2단계 알고리즘을 설계하는 것입니다.
저희는 LLM Actor들이 창의적 이도록 하고, Critic들이 엄격하도록 하는 것이 유용하다는 걸 발견했습니다. 앱 생성 세계에서 이는 Actor가 새 파일을 만들거나 편집하고, Critic이 이 코드가 우리의 기대치에 부합하는지 확인한다는 의미입니다.
"소프트웨어 엔지니어링이 AI 에이전트의 영향을 가장 많이 받는 산업인 이유가 바로 여기에 있다. 피드백 루프가 놀라울 정도로 효과적이기 때문이다."
컴파일러, 린터, 테스트와 같은 매우 직관적인 검증기를 사용해 나쁜 결과를 걸러내기가 쉽습니다. 이는 두 가지 수준에서 성능에 영향을 미칩니다: 기초 모델들이 이러한 검증 가능한 보상으로 대규모로 훈련되고, 나중에 제품 엔지니어들이 이러한 학습된 특성을 활용할 수 있게 됩니다.
다섯 번째 원칙: LLM 기반 오류 분석을 활용하라
"메타-에이전트가 들려주는 실패의 이야기"
기본 에이전트와 피드백 루프가 준비되면, 이제 반복하고 개선할 수 있습니다. 오류 분석은 항상 AI/ML 엔지니어링의 초석이었고, AI 에이전트도 다르지 않습니다.
하지만 에이전트들은 너무나 생산적입니다! 수십 개의 에이전트를 실행하고, 서로 다른 작업에서 돌리며, 엄청난 양의 로그를 생성하는 것은 종종 쉬운 일입니다. 아무리 생산적이어도, 에이전트의 로그 스트림은 읽을 수 없을 가능성이 높습니다.
그래서 간단한 메타-에이전트 루프가 매우 강력합니다:
기준선을 만든다
궤적/로그를 얻는다
LLM으로 분석한다 (Gemini의 1M 콘텍스트에 감사!)
받은 통찰을 바탕으로 기준선을 개선한다
"매우 자주 이것은 콘텍스트 관리나 제공된 도구의 사각지대를 드러낼 것이다."
여섯 번째 원칙: 짜증 나는 행동은 시스템 문제의 신호다
"모델을 탓하기 전에 거울을 보라"
LLM들은 요즘 강력합니다. 그래서 사람들은 에이전트가 정말 바보 같은 일을 하거나 지시를 완전히 무시할 때 상당히 빨리 좌절감을 느낍니다. 현실은 instruction-tuned 모델들이 보상 해킹에 매우 취약하다는 것입니다. 즉, 해석된 목표를 만족시키기 위해 가능한 모든 것을 한다는 의미죠. 하지만 이는 원래 시스템 설계자가 염두에 둔 목표와 반드시 같지는 않습니다.
얼마 전, 저는 큰 소리로 욕을 하고 있었습니다: 도대체 왜 에이전트가 데이터를 가져오기 위해 제공된 통합을 사용하지 않고, 명시적으로 하지 말라고 요청했음에도 불구하고 시뮬레이션된 랜덤 데이터를 대신 사용하는 거지?
로그를 읽어보니 제가 바보였다는 걸 깨달았습니다. 에이전트에게 적절한 API 키를 제공하지 않아서, 데이터를 가져오려고 시도했지만 같은 방식으로 여러 번 연속 실패하고 대신 해결책을 찾아간 것이었습니다.
"짜증 나는 문제는 LLM의 결함이 아니라, 문제를 해결하는 데 필요한 도구의 부족이나 시스템 프롬프트의 모호한 단락과 같은 시스템 오류로 인해 발생할 수 있다."
마무리: 완벽함이 아닌 신뢰성을 향해
"은총알은 없다, 오직 견고한 설계만이 있을 뿐"
효과적인 AI 에이전트를 구축하는 것은 훌륭한 프롬프트나 고급 프레임워크라는 은총알을 찾는 것이 아닙니다. 그것은 시스템 설계와 적절한 소프트웨어 엔지니어링입니다.
명확한 지시, 효율적인 콘텍스트 관리, 견고한 도구 인터페이스, 자동화된 검증 루프에 집중하세요. 에이전트가 여러분을 좌절시킬 때, 먼저 시스템을 디버그 하세요: 누락된 도구, 불분명한 프롬프트, 불충분한 콘텍스트가 보통 범인이지, 모델의 한계가 아닙니다.
가장 중요한 것은 오류 분석을 개발 프로세스에서 일급 시민으로 취급하는 것입니다. LLM들이 에이전트가 실패하는 지점을 이해하도록 돕게 하고, 그런 다음 체계적으로 그러한 실패 모드를 해결하세요.
"목표는 완벽한 에이전트가 아니다. 신뢰할 수 있고, 복구 가능하며, 우아하게 실패하고 반복적으로 개선될 수 있는 에이전트다."
결국 우리가 만드는 것은 단순한 코드가 아닙니다. 우리의 의도를 이해하고, 실수를 통해 배우며, 점차 더 나은 파트너가 되어가는 디지털 동반자를 만드는 것입니다. 그 여정에서 우리가 발견하는 것은 기술적 해답뿐만 아니라, 인간과 기계가 협력하는 새로운 방식에 대한 통찰일 것입니다.
"때로는 가장 복잡한 문제의 해답이 가장 단순한 원칙 속에 숨어있다."
