토큰 30억 태우며 성장 중인 에이전트 개발기

회사 생활을 하다 보면 누구나 한 번쯤 마주치는 귀찮은 벽이 있습니다. 바로 ‘품의서’ 작성입니다. 사내 그룹웨어(Flex)에 들어가 보면 양식만 무려 111개에 달합니다. 사전승인을 받아야 하는지, 자금집행인지, 법인카드 결제인지 계좌이체인지, 금액 구간별 결재선은 어디까지 올려야 하는지… 재무 담당자가 아닌 일반 구성원에겐 매번 헷갈리고 부담스러운 일입니다.

"이걸 Slack에서 대화 몇 마디로 상담해주고, 양식까지 알아서 대신 써주는 에이전트가 있다면 얼마나 편할까?"

그렇게 호기롭게 시작했습니다. codex부터 최신 추론 모델까지 갈아 끼워가며 30억 토큰을 넘게 태웠고, 2주 넘게 밤낮으로 코드를 깎았습니다. 결론부터 말씀드리면, 이 프로젝트는 2주가 지난 지금도 여전히 '성공' 근처에도 가지 못했습니다.

아무리 기술적으로 정교하게 만들어도, **"그냥 사람이 지난달 문서를 복제해서 날짜만 바꾸는 게 10배는 더 빠르다"**는 냉혹한 현실을 마주했기 때문입니다.

그 2주간의 치열했던 삽질과, 왜 그런 결론에 도달할 수밖에 없었는지 과정을 솔직하게 정리해 보았습니다.

 

1. 처음엔 — 야심 차게 세운 파이프라인과 'All Passed'의 함정

처음 구상은 꽤 깔끔해 보였습니다.

1. 사용자가 Slack에서 "이번 달 주차비 정산하려고 해"라고 편하게 말합니다.
2. 에이전트가 대화를 통해 빠진 정보(사전승인 여부, 금액, 지급 요청일 등)를 알아서 인터뷰하듯 모읍니다.
3. 로컬 확인 화면에서 정리된 값을 보여주고,
4. 북마클릿(Bookmarklet)을 통해 Flex의 해당 양식 페이지에 제목, 지출구분, 금액 등을 자동으로 쏙 채워줍니다.

보안과 통제 원칙도 엄격하게 세웠습니다. 돈이 오가는 일인 만큼 에이전트가 결재선을 임의로 바꾸거나 최종 [보내기] 버튼을 누르는 일은 철저히 막았습니다. 사람이 확인한 뒤에만 화면에 값을 넣게 했고, 개인정보나 원문 데이터는 어디에도 영구 저장되지 않도록 철저히 격리했습니다.

단위 테스트를 500개 넘게 돌려 모두 'PASS(exit 0)'가 떴을 때, 저는 솔직히 "이제 다 됐다"고 생각했습니다. 아키텍처는 견고했고, 설계상 빈틈은 없어 보였습니다.

그런데 막상 실제 환경에 올려 테스트를 시작하자마자, 예상치 못한 장벽들이 줄줄이 튀어나왔습니다.

 

2. 두 번째 — 민감정보와 권한이라는 넘을 수 없는 벽

가장 먼저 부딪힌 문제는 **‘보안과 민감정보’**였습니다.

자금집행 품의서에서 가장 번거롭고 오타가 나기 쉬운 핵심 항목은 무엇일까요? 바로 거래처명, 은행, 계좌번호, 예금주, 그리고 원천징수를 위한 주민등록번호 같은 정보들입니다.

하지만 이런 민감한 금융·개인정보를 Slack 대화창에 텍스트로 적게 하거나 LLM 문맥으로 보낼 수는 없습니다. 사내 보안 규정상으로도 금지되어 있고, 나중에 마스킹 처리를 한다 해도 Slack에 최초 입력되는 순간 이미 유출 위험이 발생합니다.

그렇다면 에이전트가 알아서 이전 결재 문서들을 조회해서 계좌 정보를 읽어오면 되지 않을까요? 그것 역시 불가능했습니다. 에이전트에게 전사 임직원의 결재 문서를 열람할 수 있는 마스터 권한을 줄 수는 없으니까요.

결국 에이전트는 보안 때문에 가장 중요하고 귀찮은 계좌번호와 예금주를 만질 수 없었고, **"계좌 정보와 첨부파일은 화면에서 직접 입력하세요"**라는 안내만 남겨둘 수밖에 없었습니다. 정작 사람 손이 제일 많이 가는 구간은 자동화에서 쏙 빠져버린 셈입니다.

 

3. 세 번째 — "그냥 복제해서 날짜만 바꾸면 30초인데..."

결정타는 실제 사용 시나리오에서 터졌습니다.

월별 주차비 정산이나 정기적인 용역비 지급 같은 업무는 매달 반복됩니다. 에이전트를 쓰는 흐름은 이랬습니다.

• Slack에서 봇과 34턴, 많게는 78턴씩 대화를 주고받으며 승인 여부와 날짜를 확인합니다.
• 분명 앞에서 "사전승인 받았고 9월분이야"라고 말했는데, 대화 상태가 꼬이며 지급 방식을 또 묻기도 합니다.
• 겨우 로컬 확인 링크를 열어 클릭하고, Flex 창을 띄워 북마클릿을 실행합니다.
• 양식의 서너 개 칸이 채워지면, 나머지 계좌번호와 증빙 영수증은 사람이 직접 다시 첨부합니다.

테스트를 진행하던 중 문득 멍해졌습니다. "내가 이걸 왜 슬랙에서 봇한테 구구절절 설명하고 있지?"

숙련된 구성원이 평소에 하던 방식은 전혀 달랐습니다.

1. Flex를 켠다.
2. 지난달에 결재받았던 '8월 주차비' 문서를 연다.
3. 상단의 [복제하기] 버튼을 누른다.
4. 제목의 '8월'을 '9월'로 고치고, 날짜 바꾸고, 이번 달 세금계산서 파일 하나 첨부하고 [보내기]를 누른다.

끝입니다. 30초도 채 안 걸립니다. 지난달에 이미 입력해 둔 거래처 계좌, 예금주, 결재선이 복제 한 번으로 완벽하게 그대로 살아있기 때문입니다.

우리가 2주 동안 최신 AI 모델들을 동원해 30억 토큰을 태우며 만든 정교한 대화형 에이전트가, 사람이 기존 문서 복제해서 날짜 두 개 고치는 속도를 도저히 이길 수 없었던 것입니다.

 

4. 피봇 — '작성 대행'을 접고, '초안 검토'라는 새로운 가설로

머리를 한 대 세게 맞은 기분이었습니다.

에이전트가 폼을 대신 채워주는 게 편할 거라는 생각 자체가 만드는 사람 입장의 착각이었습니다. 입력해야 할 데이터가 복잡하고 민감할수록, '대화로 대신 써주는 것'은 사용자에게 오히려 더 큰 피로를 줍니다.

그래서 2주간 붙들고 있던 '작성 대행' 기능을 과감하게 보류하기로 했습니다. 그리고 역할을 완전히 바꾸는 새로운 가설을 세워보았습니다. **대신 써주는 에이전트가 아니라, 사람이 다 쓴 문서를 제출하기 전에 훑어봐 주는 '초안 검토(리뷰어)'**로 방향을 틀어보는 것입니다.

• 작성은 사람이 하던 대로 합니다. 기존 문서를 복제하든 직접 쓰든, 사람이 가장 편하고 빠른 방식으로 후딱 작성합니다.
• 에이전트는 검토만 시도해 봅니다. 제출 직전, 혹시나 사람이 놓치기 쉬운 실수들만 짚어주는 역할입니다.
  • "지난달 문서를 복제하셨는데, 본문 날짜가 아직 지난달(8월)로 남아있어요."
  • "첨부된 세금계산서의 금액과 본문에 입력된 이체 금액이 맞지 않아요."
  • "이번 달 필수 영수증 첨부가 누락되어 있습니다."

물론, 이 '초안 검토' 방식이 성공한다는 보장은 어디에도 없습니다. 이것 역시 브라우저의 초안을 어떻게 안전하게 읽어올지, 검토 피드백이 사람에게 진짜 유용한지 등 또 다른 현실의 벽들을 하나씩 검증해 나가야 하는 출발선에 불과합니다.

 

5. 그래서 배운 것

여전히 성공한 결과물은 손에 쥐지 못했지만, 2주간의 헛발질 속에서 남은 배움은 분명합니다.

1. 인간의 가장 빠른 지름길(Happy Path)을 모르면 엉뚱한 걸 자동화합니다.
   사람들은 이미 '문서 복제'라는 가장 직관적이고 빠른 인터페이스를 쓰고 있었습니다. 그 실제 행동을 깊이 보지 않은 채 "처음부터 하나씩 빈칸을 채워주는 봇"을 만들려 했으니 당연히 더 느리고 번거로울 수밖에 없었습니다.
2. 권한과 보안 제약이 촘촘한 도메인일수록 '대행'의 가성비가 떨어집니다.
   계좌번호, 주민번호, 첨부파일, 결재 권한처럼 진짜 귀찮은 항목들을 보안 때문에 에이전트가 만질 수 없다면, 자동화의 체감 효용은 급격히 낮아집니다.
3. 테스트 코드의 '초록불'이 사용자 경험의 성공을 뜻하지 않습니다.
   수백 개의 단위 테스트를 통과하고 엄격한 보안 원칙을 지켰지만, 실제 사용자에게 돌아온 피드백은 "그냥 내가 하는 게 빠른데요?"였습니다. 기술적 정합성과 실제 유용성은 전혀 다른 문제입니다.
4. 시키는 사람이 도메인을 모르면, 에이전트와 함께 구르며 배울 수밖에 없습니다.
   가장 아프지만 값진 교훈입니다. 지시하는 사람이 업무의 본질과 제약을 명확히 모른 채 시작하면 아무리 뛰어난 모델을 붙여도 헛바퀴를 돕니다. 그런데 시키는 사람이 처음부터 모든 제약과 최적의 경로를 완벽히 알기는 불가능에 가깝습니다. 결국 에이전트와 함께 진흙탕에서 진하게 구르고, 수십억 토큰을 태워보며 벽에 부딪혀봐야 비로소 "아, 이 문제는 작성 대행이 아니라 검토의 영역이었구나"라는 본질에 도달하게 되는 것 같습니다.

\

제가 평소 좋아하는 말이 있습니다.

성공의 반대말은 '실패'가 아니라 '성장'이다.

 

이 프로젝트는 아직 성공하지 못한 채 여러번 실패해왔습니다.

하지만 30억 토큰을 태우고 실패를 온몸으로 겪어내며 저 역시 한 뼘 더 자랐다고 믿습니다.

새롭게 세운 '초안 검토'라는 가설 앞에서도 또 어떤 엉뚱한 문제로 굴러떨어질지 모르겠지만, 그래도 한 걸음 더 본질에 가까워졌다고 스스로를 위로하며 다시 도전해보려 합니다.