AI Agent, 이제 '부탁'이 아니라 '환경 설계'로 길들여야 할 때

AI 에이전트가 날이 갈수록 똑똑해진다고 하지만, 실제 현장에선 아직 갈 길이 멀다는 이야기가 많다. 특히나 프롬프트 엔지니어링만으로는 에이전트를 완벽히 제어하기 어렵다는 경험담이 여기저기서 들려온다. 결국 AI 에이전트를 제대로 쓰려면, 단순히 프롬프트 몇 줄 잘 쓰는 것을 넘어 시스템적 접근이 필요하다는 쪽으로 논의가 옮겨가는 모양새다.

프롬프트는 ‘부탁’일 뿐, 에이전트는 ‘환경’으로 길들여야

요즘IT에 올라온 하네스 엔지니어링으로 AI 에이전트를 길들여봤습니다 글이 딱 이 지점을 짚어준다. 필자는 AI 에이전트를 실제 프로젝트에 적용하면서 ‘프롬프트’가 아니라 ‘워크플로우’를 설계해야 한다는 인사이트를 얻었다고 한다. 아무리 프롬프트에 ‘절대 하지 마라’고 굵은 글씨로 써놔도 에이전트는 가끔 그냥 해버린다는 것. 마치 AI 두뇌가 ‘부탁’은 듣는 둥 마는 둥 하다가, 아예 못 할 환경을 만들어줘야 말을 듣는다는 이야기처럼 들린다.

이런 맥락에서 ‘하네스 엔지니어링’이라는 개념이 등장한다. 에이전트의 행동을 제약하고 유도하는 ‘환경’ 자체를 설계하는 방식이다. 예를 들어, 에이전트가 외부 도구를 사용할 때 특정 API만 호출하도록 제한하거나, 특정 단계에서만 특정 정보를 제공하는 식이다. 이는 에이전트가 ‘자유 의지’로 이상한 짓을 할 여지를 줄이고, 정해진 프로토콜 안에서만 움직이게 하는 데 효과적이다.

Claude Code 유출에서 본 에이전트 구조의 본질

지난 3월 Anthropic의 AI 코딩 도구인 Claude Code에서 소스맵 파일이 유출되는 사고가 있었다. 그런데 클로드 코드 소스 유출에서 배우는 에이전트 구조 글을 보면, 이 유출된 내부 구조가 오히려 에이전트 완성도의 본질을 보여준다고 분석한다. 핵심은 에이전트가 단순히 똑똑한 모델을 붙이는 것을 넘어, 얼마나 정교한 워크플로우와 도구 활용 메커니즘을 갖추고 있느냐에 달렸다는 점이다.

Claude Code의 구조를 보면, 여러 에이전트가 각자의 역할을 수행하고, 이들이 정해진 순서와 규칙에 따라 상호작용하며 복잡한 코딩 작업을 처리한다. 즉, 모델 자체의 지능도 중요하지만, 그 지능을 효과적으로 발휘하게 하는 ‘시스템 설계’가 훨씬 중요하다는 의미다. 이는 마치 오케스트라의 개별 연주자들도 중요하지만, 지휘자와 악보, 그리고 무대 동선이 완벽해야 좋은 연주가 나오는 것과 비슷하다.

개발자 커뮤니티의 공감: AI는 5배 생산성 향상이 아니다

이런 맥락에서 Reddit r/ExperiencedDevs 커뮤니티에서 Managers decided AI is worth 5x speedup; how do I explain to them how it really works?라는 글이 큰 공감을 얻었다. 매니저들은 AI가 5배 생산성 향상을 가져올 것이라고 믿지만, 실제 개발자들은 AI가 생성한 ‘슬롭 코드’를 검토하고 수정하는 데 더 많은 시간을 쓴다는 이야기다.

또 다른 글 How to deal with juniors shipping AI slop code?에서는 주니어 개발자들이 AI가 만든 엉성한 코드를 PR(Pull Request)로 올리고, 왜 그렇게 만들었는지 물으면 제대로 된 설명을 못 한다는 고충이 공유된다. AI의 도움을 권장하지만, 검토에 드는 시간과 노력이 만만치 않다는 토로다.

결국 AI 에이전트가 실제 업무에 유의미한 가치를 창출하려면, 단순히 모델을 던져주는 것이 아니라, Show GN: Geas - AI Agent가 실수하지 않도록 엄격한 업무 프로토콜을 지키게 하기 같은 시도처럼, 에이전트가 실수하지 않도록 엄격한 업무 프로토콜과 제약 조건을 설계하는 것이 필수다. 프롬프트는 시작일 뿐, 에이전트의 행동을 예측 가능하게 만드는 ‘환경 설계’가 다음 단계인 셈이다.