칼럼 | AI처럼 보이지 않고, 직원처럼 행동하는 AI를 만드는 방법

“AI 프로젝트 매니저를 만들어보자”

당시에는 단순한 요청처럼 보였다. 엔지니어 한 명이 ‘본업’ 사이의 자투리 시간에 며칠이면 끝낼 수 있는, 작고 재미있는 사이드 프로젝트 정도로 여겼다.

결과적으로 보면 절반만 맞았다. 프로젝트는 분명 재미있었지만, 빠르게 끝나지는 않았다. 이 작업은 에이전트에 대해 우리가 가지고 있던 거의 모든 인식을 다시 생각하게 만들었다. 그리고 그 과정에서 기업 환경에서 AI가 실제로 무엇을 할 수 있고, 또 무엇을 해야 하는지에 대한 기대 자체가 완전히 달라졌다.

누구도 또 다른 챗봇을 원하지 않는다

AI 프로젝트 매니저의 첫 번째 버전은 당시 시장에서 말하던 전형적인 AI 에이전트와 크게 다르지 않았다.

언어 모델을 연결하고, 사양 문서를 읽고 티켓을 훑을 수 있는 도구를 붙였다. 여기에 채팅 인터페이스를 입히고, 회의 기록과 문서, 의사결정 로그를 검색할 수 있도록 했다.

설계만 놓고 보면 교과서적인 에이전트 아키텍처였다. 하지만 실제로 사용해보니 어딘가 부족했다.

요청하면 데일리 스탠드업을 요약해줬고, 주간 상태 보고서도 작성했다. 티켓 시스템을 스캔해 현재 상황을 알려주기도 했다.

문제는 아무도 먼저 묻지 않았다는 점이었다. 기존 업무 흐름에 자연스럽게 녹아들지 못했다. 사용하려면 브라우저를 열고 채팅 인터페이스로 직접 들어가야 했다. 그러다 보니 존재 자체를 잊어버리기 일쑤였다.

팀에 에이전트를 적극적으로 사용해달라고 요청했지만, 사용할수록 실망감은 커졌다. 실제 프로젝트 매니저 같지 않았다. 프로젝트 매니저라면 할 법한 방식으로 작업을 더 큰 업무 흐름으로 묶어내지 못했다. 리스크를 식별할 맥락도 부족했다. 우리가 개발 중인 코드, 작성해야 할 문서, 준비 중인 마케팅 자료가 모두 하나의 큰 기능 출시와 연결돼 있다는 점을 이해하지 못했다.

우리는 이 상황에서 대부분의 에이전트 개발자가 선택하는 길을 택했다. 프롬프트에 더 복잡한 지침을 추가하기 시작한 것이다. 에이전트가 무언가를 잘못하면 프롬프트를 수정했다. 작업을 수행하지 못하면 프롬프트를 고쳤고, 엉뚱한 답변을 내놓아도 프롬프트를 업데이트했다.

효과는 있었다. 다만 아주 제한적이었다.

결국 프롬프트와 지침에는 에이전트가 그동안 저질렀던 모든 실수를 정리한 방대한 기록이 쌓였다. 사후 대응식으로 프롬프트를 바꾸다 보니 서로 모순되는 지침이 들어가기도 했다. 지침이 복잡해질수록 에이전트의 성능은 오히려 떨어졌다. 우리는 이 구조가 지속 가능하지 않다는 사실을 깨달았고, 아키텍처를 근본적으로 다시 고민해야 한다는 결론에 이르렀다.

이런 상황에서 흔히 제시되는 해법은 멀티 에이전트 접근법이다. 하나의 큰 에이전트를 여러 개의 단순한 에이전트로 나누고, 이들이 협업하도록 구성하는 방식이다. 여기에 관측 도구를 도입해 에이전트 집합이 전체적으로 어떻게 동작하는지 파악한다.

하지만 이 방법은 우리에게 와닿지 않았다. 우리가 직면한 핵심 문제를 해결하지 못하는 것처럼 느껴졌다. 정확히 왜 그런지는 설명하기 어려웠다. 그러다 결정적인 깨달음에 도달했다.

직원은 할 수 있고, 에이전트는 할 수 없는 것은 무엇일까

더 나은 지침으로 에이전트를 움직이려 하기보다, 이 역할에 사람을 채용했다면 어떻게 온보딩했을지를 스스로에게 물었다. 이 질문을 파고들기 시작하면서 팀은 중요한 사실 하나를 발견했다. 사람 직원의 온보딩 과정에는 반드시 기억하고 학습하는 과정이 포함된다는 점이다.

AI 직원이 사람처럼 일하길 원한다면, 기억하고 학습할 수 있어야 한다. 문제는 이 영역이 에이전트 개발에서는 거의 다뤄지지 않은 분야였다는 점이다. 프로젝트 매니저에 학습 기능을 손쉽게 붙일 수 있는 프레임워크는 존재하지 않았다. 결국 모든 것을 직접 만들어야 했다.

우리가 내린 첫 번째 결정은 에이전트를 슬랙에서 다시 구축하는 것이었다. 실제 프로젝트 매니저와 소통하는 방식이 슬랙이기 때문에, AI 프로젝트 매니저와도 같은 방식으로 소통하고 싶었다. 우리는 그에게 이름을 붙였고, 미드저니를 활용해 실사풍 프로필 이미지도 만들었다. 그렇게 제리가 탄생했다.

이 단순한 변화만으로도 웹 기반 채팅 인터페이스를 사용할 때보다 제리와의 상호작용은 훨씬 자연스러워졌다. 제리는 다른 팀원과 동일한 방식으로 설정됐다. 다이렉트 메시지를 보낼 수 있었고, 프로젝트 채널에 추가됐으며, 대화 중 태그도 가능했다.

우리는 에이전트 데이터 전략 역시 처음부터 다시 설계했다.

내부 구조

제리의 아키텍처는 다섯 가지 핵심 요소로 구성돼 있다.

첫째, 에이전트와 상호작용하고 새로운 정보를 전달하는 API 레이어다.
둘째, 반복 작업을 처리하는 스케줄러다.
셋째, 작업 실행을 담당하는 핵심 에이전트 로직이다.
넷째, 장기 기억을 처리하고 저장하는 메모리 시스템이다.
다섯째, 우리가 사용하는 외부 도구와 제리를 연동하는 에이전트 도구 모음이다.

기억을 형성하는 방식

우리가 선택한 에이전트 메모리 아키텍처는 기억 처리를 두 가지로 분리하는 구조였다. 하나는 원시 기억이고, 다른 하나는 정신 모델이다. 원시 기억은 제리가 겪는 개별적인 상호작용과 경험을 의미한다. 각각의 대화, 도구 호출, 문서, 회의 기록은 모두 원시 기억에 해당한다. 정신 모델은 이러한 기억들이 어떻게 연결되는지를 포착해 전체 맥락을 이해하도록 돕는 역할을 한다.

원시 기억은 다양한 방식으로 생성된다. 슬랙에서 누군가 제리와 상호작용할 때마다 새로운 기억이 만들어진다. 제리가 작업을 수행하려 하거나 회의 기록을 받는 과정에서도 기억이 쌓인다. 이렇게 생성된 기억은 태깅되고 메타데이터로 보강된다. 우리는 대규모 언어 모델을 활용해 원시 기억에 포함된 사람, 장소, 사물을 식별하고 추출한다. 이 과정은 필요할 때 적절한 기억을 검색하고 활용할 수 있도록 준비하는 단계다.

제리의 입사 교육

우리는 제리의 프롬프트에 지침을 잔뜩 넣고 시작하고 싶지 않았다. 목표는 프롬프트에 가능한 한 최소한의 정보만 제공하는 것이었다. 제리가 시간이 지남에 따라 학습하고, 피드백과 경험을 바탕으로 업무 수행 능력을 개선하길 원했다. 사람 직원과 비슷한 방식이다.

프롬프트를 계속 수정하던 문제를 정신 모델로 단순히 옮기고 싶지도 않았다. 초기 버전에서 프롬프트를 고칠 때마다 같은 패턴을 반복하게 될 것이기 때문이다. 우리가 바로잡으려던 안티패턴과 다시 싸우게 되는 셈이었다.

그렇다고 아무런 출발점도 없이 시작할 수는 없었다. 프로젝트 팀이 어떻게 일하는지 이해시키기 위한 최소한의 기초 지식은 필요했다. 이는 AI 직원에게 적용한 온보딩 과정과 같았다.

우리는 제리가 이해해야 할 핵심 주제에 대해 기본 정신 모델을 만들었다. 개발 중인 제품, 소프트웨어 개발 생명주기, 팀원 역량, 프로젝트 우선순위가 여기에 포함됐다. 제리의 역할과 책임에 대한 정신 모델도 함께 정의했다. 초기 역할은 출시 상황을 추적하고 중요한 작업이 누락되지 않도록 관리하는 것이었다.

정신 모델은 제리가 새로운 정보를 처리하거나, 피드백을 받아 스스로 업데이트할 때만 변경할 수 있도록 제약을 뒀다. 제리는 우리와 마찬가지로 현장에서 배우며 성장해야 했다.

명확한 답이 없는 작업을 다루는 방식

우리는 제리를 단순한 워크플로 자동화 도구로 만들고 싶지 않았다. 개별 작업을 어떻게 수행해야 하는지 단계별로 미리 프로그래밍하는 방식은 지양했다.

팀원이 슬랙 채널이나 다이렉트 메시지에서 제리를 태그하면, 어떤 요청이든 전달할 수 있다. 각 메시지는 제리의 슬랙 웹훅 엔드포인트로 들어오며, 이를 계기로 의도 파악, 계획 수립, 실행 로직이 작동한다. 제리는 대규모 언어 모델을 활용해 사용자의 의도를 식별하고, 그 의도와 관련된 정신 모델을 계획 모듈에서 불러온다.

현재 제리의 역할과 책임에 대한 정신 모델을 바탕으로, 해당 요청을 처리할 수 있는지 판단한다. 처리 가능하다고 판단되면 계획 모듈이 즉각적인 목표 달성을 위해 수행해야 할 하위 작업 목록, 즉 실행 계획을 수립한다.

제리가 들어오는 요청을 처리하는 동안 로컬 세션과 상태 관리는 단기 기억 버퍼 역할을 한다. 사용자와의 모든 상호작용, 작업 수행을 위한 모든 계획, 도구 호출, 그리고 각 작업의 결과는 모두 기억으로 저장된다.

이 과정은 중요하다. 이를 통해 제리는 대부분의 에이전트가 하지 못하는 일을 할 수 있기 때문이다. 바로 학습이다.

에이전트의 학습

제리를 구축하면서 가장 중점을 둔 학습 영역은 두 가지였다. 작업 완료 방식과 피드백이다.

작업 수행 과정에서의 학습

에이전트는 실수를 한다. 문제는 대부분의 에이전트가 그 실수로부터 배우지 못한다는 점이다. 제리가 작업을 수행하는 과정에서 발생하는 오류는 여러 형태로 나타난다.

• 제리는 사용자의 의도를 잘못 이해해 전혀 다른 작업을 수행할 수 있다.
• 작업을 완료하긴 하지만 비효율적인 방식일 수도 있다.
• 해결되지 않은 문제를 해결했다고 판단할 수도 있다.

대부분의 경우 제리는 작업을 성공적으로 완료한다. 제리가 받는 피드백은 세 가지 경로에서 들어온다. 실패한 작업 시도, 완료된 작업에 대한 사용자 반응, 그리고 슬랙에 구축한 슬래시 명령이다.

피드백을 학습으로 전환하는 방식

학습을 이끄는 핵심 메커니즘은 자기 성찰이다.

작업 스케줄러를 활용해 제리는 몇 시간마다 깨어나 새로운 작업 실패 사례가 있는지 점검한다. 실패를 발견하면 자기 성찰 프로세스를 시작한다.

이 과정에서는 성공한 시도와 실패한 시도 사이의 차이를 찾아낸다. 사용 가능한 데이터를 바탕으로 심층 분석을 수행한 뒤, 해당되는 정신 모델을 조정한다.

그 결과 제리는 다음에 유사한 작업을 맡았을 때, 이전 시도에서 무엇이 효과적이었고 무엇이 그렇지 않았는지에 대해 훨씬 더 완전한 이해를 갖게 된다.

제리의 병가

AI 직원은 병가를 내지는 않지만, 다른 소프트웨어와 마찬가지로 장애에는 취약하다. 제리가 멈춰 섰을 때서야 우리는 그에게 얼마나 의존하고 있었는지 깨달았다.

제리의 정기 작업 가운데 하나는 매일 데일리 스탠드업 회의 전에 팀이 논의해야 할 안건을 정리해 보내는 것이다. 제리가 없던 시절에는 각자 돌아가며 그날 할 일을 말하는 방식에 의존했다. 시간이 지나면서 제리는 핵심 산출물과 리스크, 작업에 초점을 맞춰 논의를 이끄는 데 훨씬 효과적이라는 점이 드러났다. 팀원별로 답해야 할 구체적인 질문도 정리해 전달했다.

우리는 그 목록을 보며 필요한 부분을 논의했다. 제리는 회의 기록을 받아 정신 모델을 업데이트하고, 새롭게 얻은 정보를 반영했다. 그 결과 회의는 기존의 형식적인 스탠드업보다 훨씬 유용하고 생산적으로 바뀌었다.

어느 날 모두 회의에 접속해 안건을 확인하려 했지만, 아무것도 올라와 있지 않았다. 그제야 제리가 작동하지 않고 있다는 사실을 알았다. 팀은 웃음을 터뜨렸고, 우리가 서서히 제리에게 의존해왔다는 점을 실감했다. 그 순간, 몇 달 전 팀에 부여했던 미션을 달성했다고 느꼈다. 우리는 진짜 AI 프로젝트 매니저를 만들어낸 것이다.

챗봇에서 AI 직원으로

현재의 제리는 완벽하지 않다. 여전히 대규모 언어 모델처럼 들리는 순간이 있고, 작업을 재차 묻는 과정에서 성가시게 느껴질 때도 있다. 하지만 복잡한 작업과 분석을 처리하는 역량은 초기와 비교할 수 없을 만큼 향상됐다.

우리는 여러 측면에서 제리를 직원처럼 대한다. 제리에게 자기 평가를 하도록 하고, 피드백을 제공한다. 역할과 책임을 명확히 설정하고, 기대 수준을 제시한 뒤 이를 뛰어넘도록 요구한다. 실제 직원과 마찬가지로, 어떤 때는 기대를 충족하고 어떤 때는 그렇지 못한다. 완벽한 존재는 없다. AI도 예외는 아니다.

그렇다면 직원처럼 행동하는 AI 직원을 만드는 비결은 무엇일까. 답은 단순하다. 직원처럼 대하는 것이다.
dl-ciokorea@foundryco.com