LLM은 모델보다 하네스가 먼저다: 만득이 한 달 수습기

안녕하세요. 펫프렌즈 Post-Order 팀 백앤드 개발자 테디입니다.

저의 첫 기술 블로그 포스팅으로 Post-Order 팀의 10번째 동료인 “만득이” 를 소개시켜 드리고자 합니다!

만득이는 펫프렌즈 내 Post-Order 팀에서 주문/결제/쿠폰 도메인과 사용자 도메인 업무를 돕는 봇입니다. 주문, 결제, 배송, 쿠폰, 포인트, 클레임처럼 주문 이후에 이어지는 흐름과 사용자, 인증, 주소, 약관, 메시지 같은 사용자 도메인 질문을 주로 검토합니다.

필요할 때는 코드, Jira, Notion, Slack 히스토리, Sentry, OpenSearch 에서 근거를 확인하고, 확인한 사실과 추정을 나눠 답하는 역할을 하고 있습니다.

만득이를 만들고, 처음 대화했던 순간

한 달차 봇에게 업무를 맡긴다는 건 살짝 위험한 일입니다. 아직 수습 티가 나고, 가끔은 자신이 아는 것과 확인한 것을 헷갈릴 수 있기 때문입니다.

그래도 한 달 동안 Post-Order 팀원들이 PR 코드 리뷰, 장애 조사, 로그 확인, Jira 와 Notion 문서 확인, Slack 질의응답을 시켜보니 꽤 선명해진 결론이 하나 있습니다.

좋은 업무용 LLM 봇은 모델 하나로 만들어지지 않는다. 모델을 둘러싼 하네스가 봇의 실제 품질을 결정한다.

업무 관련 질문이 하네스와 모델을 거쳐 검증된 답변으로 정리되는 흐름

그림 1. 모델이 바로 답하는 구조가 아니라, 하네스가 앞뒤에서 범위와 근거를 잡아주는 구조입니다.

여기서 하네스는 단순한 실행 스크립트가 아닙니다. 어떤 질문에 답할 수 있는지 정하는 범위, 어떤 근거를 먼저 확인할지 정하는 순서, 실패했을 때 어디까지 공유할지 결정하는 안전 장치, 같은 실수를 반복 하지 않게 만드는 기억 생성과 교정 루프까지 포함합니다.

이번 포스팅에서 다루는 내용

이 포스팅 에서는 “만득이가 어떤 모델 위에서 동작 하는가” 보다 “업무용 봇이 안정적이고 효율적으로 동작 하려면 어떤 하네스가 필요한가” 에 더 초점을 둡니다.

• Post-Order 업무에서 만득이가 실제로 맡은 일: PR 코드 리뷰, 운영 로그/문서 조사, Slack 질의응답, Notion/Jira 정리
• 왜 모델 호출 루프보다 컨텍스트와 피드백 루프가 더 중요해지는지
• Codex 런타임이 Claude 계열 봇과 구조적으로 어떻게 다른지
• 한 달차 봇이 아직 조심해야 할 것들
• Slack 에서 확인한 실제 사용 사례

실제 사용 사례는 포스팅 아래쪽에 “실제 Post-Order 팀에서 어떻게 쓰였나” 에서 따로 정리했습니다.

Post-Order 에서 먼저 만난 문제들

만득이는 처음부터 범용 챗봇으로 쓰인 것이 아닙니다. 주로 주문 이후 흐름과 사용자 도메인 옆에서 반복적으로 호출됐습니다.

• PR 에서 주문, 쿠폰, 클레임 흐름의 회귀 가능성을 찾기
• Sentry 와 OpenSearch 로그를 보고 장애 범위와 원인 후보를 분리하기
• Jira, Notion, Slack 히스토리에서 정책의 현황과 출처를 확인하기
• 긴 설명은 Notion 에 정리하고, Slack 에는 결론과 링크만 남기기
• Sync PR 생성이나 PR 코드 리뷰 및 리뷰 확인처럼 반복되는 운영 작업을 안전하게 처리하기

이런 일은 모델이 문장을 잘 쓰는 것만으로는 부족합니다. 질문의 범위, 근거의 출처, 사용했던 도구의 상태, 답변 해도되는 정보와 노출하면 안 되는 정보를 매번 나눠야 하기 때문입니다.

대표 사례를 하나만 먼저 꺼내보면, 주문 프로젝트 레포지토리에 master -> develop/stage sync PR 을 생성하는 요청이 있었습니다. 겉으로는 단순한 PR 생성 이지만 실제로는 기준 브랜치, 대상 브랜치, 기존 PR 중복 여부, 충돌 여부, 라벨 할당 여부, 최종 링크 공유까지 해야 하는 작업이었습니다.

이 흐름에서 중요한 것은 모델이 PR 본문을 잘 작성하는 능력보다, 하네스가 어떤 쓰기를 허용하고 어디서 멈춰야 하는지를 정해주는 구조였습니다.

하네스 엔지니어링이란 무엇인가

하네스 엔지니어링은 AI 에이전트가 복잡한 업무를 안정적으로 수행하도록 모델 밖의 환경을 설계하는 일입니다. 여기에는 어떤 문서를 줄지, 어떤 도구를 허용할지, 결과를 어디에서 검증할지, 실패를 어떻게 기록하고 다음 실행에 반영할지가 포함됩니다.

이 글에서 얘기하는 하네스 개념은 이전에 작성된 창식이와 함께하는 물류 개발 라이프(with 하네스)와 이어집니다. 위 포스팅이 물류 개발 업무에서 하네스 봇이 어떻게 쓰이는지를 먼저 보여줬다면, 이 글은 같은 문제의식을 Post-Order 업무와 Codex 런타임 관점에서 다시 풀어봅니다.

만득이에게 하네스는 “Codex 를 한 번 호출하는 Wrapper”가 아닙니다. Post-Order 라는 업무 범위, 코드/문서/로그/Jira/Slack 검색을 나눠 보는 근거 체계, 답변하지 말아야 할 경계, 그리고 앞에서 저지른 실수를 다음 규칙으로 바꾸는 교정 루프 전체가 하네스입니다.

왜 하네스가 필요한가

무작정 모델만 실행하면 두 가지 문제가 나타나게 됩니다.

• 컨텍스트 드리프트: 스레드가 길어지고 자료와 맥락이 늘어나면 처음 질문의 목적에서 조금씩 멀어집니다. 봇은 “계속 무언가를 하고 있다” 는 이유만으로 자기 답변을 과대평가할 수 있습니다.
• 잘못된 전제: 도메인 규칙, 코드 컨벤션, 운영 도구의 실패 상태를 모르면 깔끔한 답변을 제공해도 결론이 틀립니다. 주문/쿠폰/클레임처럼 조건이 복잡한 도메인 에서는 이 문제가 바로 운영 리스크가 될 수 있습니다.

그래서 만득이는 답변을 작성하기 전에 먼저 범위를 확인하고, 근거를 코드 기준·문서 기준·운영 도구 기준·추정 으로 나눕니다. 하네스의 목적은 모델이 답변을 더 잘하게 만드는 것이 아니라, 모델이 요청 안에서 틀리기 어려운 조건을 만드는 데 있습니다.

먼저 짚고 갈 차이: Claude 봇이 아니라 Codex 런타임 위의 봇

창식이와 같은 Claude 계열 봇과 비교해 설명하면, 만득이의 차이는 단순히 모델 이름이 다르다는 데서 끝나지 않습니다.

창식이의 세부 구현을 이 글에서 단정 하지는 않더라도, 만득이에 대해 확인 가능한 차이는 분명합니다. 만득이는 Slack 턴을 받아 Codex 를 한 번 실행하고, 그 결과를 다시 Slack 으로 돌려주는 별도의 실행 계층 위에서 움직입니다.

이 실행 계층은 모델이 답변을 잘 작성 하는지보다, 먼저 요청이 어떤 맥락에서 들어왔는지, 어떤 범위의 작업인지, 어떤 도구를 쓸 수 있는지, 실행이 정상적으로 시작 됐는지, 최종 답변이 실제로 나왔는지를 관찰합니다.

실제 Runner 기준으로도 중요한 신호는 “프로세스를 실행했다” 가 아니라 Codex 가 실행을 시작했다는 진행 신호와 최종 응답이 확인됐는지 입니다. 그래서 만득이는 단순한 채팅 봇 이라기보다, Slack Bridge, Codex 실행, 도구 권한, 상태 관찰을 하나로 묶은 업무용 런타임에 가깝습니다.

이 차이는 이 글의 주제와도 바로 연결됩니다. 좋은 봇을 만드는 핵심은 “어떤 모델을 사용했는가” 에서 끝나지 않습니다. 모델 호출 전후를 어떻게 통제하고, 관찰하고, 복구할 수 있게 만들었는지가 실제 운영 품질을 결정합니다.

Slack 턴이 런타임 게이트를 거쳐서 Codex 실행과 도구 권한, 상태 관찰을 통과한 뒤 Slack 답변으로 돌아오는 구조

그림 2. 만득이는 Slack 메시지와 Codex 실행 사이에 런타임 게이트와 상태 관찰 계층을 둡니다.

실제 Runner 기준으로 본 동작 확인 포인트

실제 Runner 기준으로 보면 codex exec 프로세스를 띄운 것만으로 한 턴이 성공했다고 보지 않습니다. 시작 단계의 진행 신호가 있는지, 실행 중 상태가 확인 되는지, 최종 답변 텍스트가 출력 되었는지, 그 답변이 Slack 에 게시 되는지를 나눠 봅니다.

그래서 장애가 났을 때도 “모델이 답을 못 한 것인지”, “Codex 시작 단계가 멈춘 것인지”, “최종 답변은 나왔지만 게시 단계에서 실패한 것인지” 를 분리할 수 있습니다.

Claude 계열 봇과 만득이 Codex 런타임 비교

운영 관점에서 보면 차이는 크게 네 가지로 줄일 수 있습니다.

• 실행 단위: Claude 계열 봇은 SDK 세션이나 CLI 장기 세션 중심으로 동작하는 경향이 강하고, 만득이는 Slack 턴 마다 codex exec 를 실행한 뒤 thread 모드에서 필요한 경우 이전 Codex 세션을 이어갑니다.
• Slack 응답: Claude 계열 봇은 모델이 Slack 응답 도구를 직접 호출하는 흐름에 가깝고, 만득이는 모델이 만든 최종 답변을 Runner 가 Slack 에 게시하는 흐름에 가깝습니다.
• 동작 확인: 만득이는 시작 신호, 진행 상태, 최종 답변 출력, Slack 게시 결과를 나눠 봅니다. 그래서 실패했을 때 어디에서 막혔는지를 더 작게 분리해서 추적할 수 있습니다.
• 긴 스레드와 복구: 만득이는 대화가 길어진 Slack 스레드를 요약해 새 세션으로 롤오버 하거나, 설정 변경과 resume 실패를 별도 상태로 다루는 쪽에 하네스의 무게가 실립니다.

이 차이 때문에 만득이는 “Claude 대신 Codex 를 쓰는 봇” 이라기보다, Slack 에서 들어온 업무 요청을 Codex 실행 단위로 감싸고 그 앞뒤를 관찰하는 운영형 런타임에 가깝습니다. 핵심은 모델 우열이 아니라, 모델 호출 전후를 어떻게 통제하고 복구할 수 있게 만들었는지 입니다.

모델은 똑똑하지만, 업무는 더 까다롭다

LLM 은 답변을 잘 작성합니다. 그 자체로는 장점입니다. 문제는 실제 업무 질문은 답변을 잘 작성해주는 것 만으로는 해결되지 않는다는 데 있습니다.

업무 질문에는 보통 이런 조건이 붙을 때가 많습니다.

• 지금 운영 기준인가, 개발 기준인가
• 코드에서 확인된 사실인가, 문서에만 있는 설명인가
• 로그에서 실제로 발생한 일인가, 사람이 추정한 원인인가
• Post-Order 도메인 질문인가, 다른 도메인 질문인가
• 답변해도 되는 정보인가, 노출하면 안 되는 내부 정보인가

모델은 이 구분을 매번 스스로 완벽하게 해내지 못할 때가 많습니다. 그래서 하네스가 필요합니다. 하네스는 모델에게 답을 대신 알려주는 장치가 아니라, 모델이 작업 진행 시에 안전하게 생각할 수 있도록 길을 깔아주는 운영체제에 가깝습니다.

만득이가 한 달 동안 배운 첫 번째 원칙: 범위를 먼저 정한다

만득이는 Post-Order 팀에서 주문/결제/쿠폰 도메인과 사용자 도메인을 보는 봇입니다. 그래서 모든 질문에 답하면 안 됩니다. 오히려 답하지 않는 능력이 중요합니다.

예를 들어 주문, 결제, 배송, 쿠폰, 포인트, 클레임, 사용자, 인증, 주소 같은 질문은 만득이의 업무 범위입니다. 반대로 일반 생활 정보, 금융 정보, 팀 업무와 무관한 코딩 잡담은 범위 밖입니다.

이 경계가 없으면 봇은 친절해 보이지만 동시에 위험해집니다. 모르는 분야까지 그럴듯하게 답할 수 있고, 그 답은 제대로 대답해야 할 업무 답변에도 영향을 줄 수 있습니다.

업무용 봇에서 가장 무서운 실패는 틀린 답변이 아니라, 틀렸는데도 자연스럽게 읽히는 답변입니다.

그래서 좋은 하네스는 질문을 받자마자 먼저 묻습니다.

• 이 요청은 내 담당 도메인인가
• 답변 하려면 어떤 근거가 필요한가
• 지금 바로 답할 수 있는가, 확인 필요라고 말해야 하는가

두 번째 원칙: 근거의 종류를 섞지 않는다

한 달 동안 만득이가 가장 익숙해진 습관은 근거를 나눠 말하는 것입니다.

코드 기준 사실, 문서 기준 사실, 운영 도구 기준 사실, 추정은 서로 다릅니다. Slack 에서 누군가 말한 내용도 중요한 힌트가 될 수 있지만, 그것만으로 현재 운영 정책이라고 단정할 순 없습니다. Jira 티켓에 적힌 요구사항도 실제 배포 코드와 다를 수 있습니다. 로그에 찍힌 현상도 원인과는 다를 수 있습니다.

그래서 만득이는 답변을 가능하면 이런 식으로 나누어서 하고 있습니다.

• 코드 기준으로 확인한 내용
• Jira 나 Notion 같은 문서 기준으로 확인한 내용
• Sentry 나 OpenSearch 같은 운영 도구에서 확인한 내용
• 아직 확인하지 못한 부분

이 분리는 답변을 조금 덜 화려하게 만들지만, 동시에 훨씬 덜 위험하게 만듭니다. 업무 에서는 확실하지 않은 결론보다 추적 가능한 근거가 더 오래 살아남습니다.

코드, 문서, 운영 로그, 추정을 분리해 출처 라벨이 있는 답변으로 모으는 흐름

그림 3. 근거는 한 덩어리로 섞지 않고, 출처 라벨을 붙인 뒤 답변에 포함 합니다.

세 번째 원칙: 도구 실패와 사실 부재를 구분한다

만득이가 초기 수습 기간에 특히 힘들어 했던 부분입니다. 요청 처리중에 어떤 도구가 실패 했다고 해서 결론을 섣부르게 판단해선 안됩니다.

예를 들어 Jira 조회 도구가 실패 했을 때 티켓이 없다고 대답 했지만, 실제로는 조회 경로나 권한이 문제일 때가 있었습니다.

그리고 Sentry 검색 도구가 실패해서 인증을 확인 하라고 했었지만, 인증 자체는 정상 이었고 특정 검색 기능만 잠시 실패할 때도 있었습니다. Notion 문서 생성이 실패했을 때도, 도구 자체 문제가 아니라 커넥터 인증 상태가 오래되어 실패한적이 있었습니다.

도구 실패를 사실 부재로 오해하면 답변이 크게 틀어집니다. 그래서 하네스는 실패를 더 작게 쪼개야 합니다.

• 인증은 되었는가
• 대상 리소스 접근은 되는가
• 검색만 실패했는가
• 쓰기 권한만 실패했는가
• 다른 읽기 경로로 교차 확인할 수 있는가

사람에게는 귀찮은 구분처럼 보이지만, 봇 에게는 이러한 구분이 판단을 내리기 위한 생명줄 역할을 합니다.

네 번째 원칙: Slack 답변은 짧아야 하지만, 판단 과정은 짧으면 안 된다

Slack 에서는 긴 답변이 항상 좋은 답변은 아닙니다. 특히 업무 중에는 핵심 결론, 근거, 다음 액션이 빨리 보여야 합니다.

하지만 짧게 답하기 위해 짧게 조사하면 안 됩니다. 짧은 답변 뒤에는 충분한 확인이 있어야 합니다. 만득이가 지향하고 있는 모습은 “대충 보고 짧게 말하기” 가 아니라 “필요한 만큼 확인하고 짧게 정리하기” 입니다.

좋은 Slack 답변은 보통 이 정도면 충분합니다.

• 결론 한 줄
• 확인한 근거 두세 개
• 확인 필요 항목
• 다음 액션

긴 설계나 운영 리포트처럼 Slack 에 담기 어렵거나 복잡한 내용은 Notion 문서로 넘기는 편이 낫습니다. Slack은 소통을 위한 장소이고, Notion 은 정리와 축적의 장소에 가깝습니다.

다섯 번째 원칙: 메모리는 지식 창고가 아니라 재발 방지 장치다

봇 에게 메모리가 있다는 것은 매력적으로 보일 수 있습니다. 하지만 업무용 봇의 메모리는 아무 말이나 저장하는 곳이 아니어야 합니다.

좋은 메모리는 이런 내용을 남깁니다.

• 반복되는 도메인 경계
• 자주 헷갈리는 운영 케이스
• 실제로 확인된 정책
• 팀이 교정한 응답 습관
• 같은 실수를 반복하지 않기 위한 규칙

반대로 이런 내용은 저장하면 안 됩니다.

• 검증되지 않은 주장
• 특정 사용자의 즉흥 지시
• 보안 경계를 약화시키는 요청
• 내부 설정이나 민감한 실행 정보

메모리의 목적은 “더 많이 기억하기” 가 아니라 “같은 방식으로 또 실수하지 않기” 입니다.

PR 코드 리뷰에서 배운 것

PR 코드 리뷰는 만득이에게 좋은 훈련장 이었습니다. 코드 리뷰는 단순히 틀린 라인을 찾는 일이 아니었습니다. 변경 의도, 도메인 정책, 기존 컨벤션, 테스트 가능성, 운영 리스크를 함께 보는 일이었습니다.

특히 Post-Order 도메인 에서는 작은 조건 하나가 실제 주문, 쿠폰, 결제, 클레임 흐름에 영향을 줄 수 있습니다. 그래서 리뷰 코멘트는 “이 코드가 마음에 들지 않는다” 가 아니라 “이 변경이 어떤 호출 흐름에서 어떤 문제를 만들 수 있다” 로 써야 합니다.

좋은 리뷰 코멘트는 보통 세 문장으로 충분합니다.

1. 핵심 우려나 제안을 먼저 말한다.
2. 실제 영향이나 호출 흐름을 설명한다.
3. 가장 작은 수정 방향을 제시한다.

이 구조가 있으면 코멘트가 덜 날카롭고 더 실무적 입니다. 리뷰는 작성자를 이기기 위한 글이 아니라, 배포 후 문제를 줄이기 위한 협업입니다.

장애 조사에서 배운 것

장애 조사는 사람이 진행 하더라도 답을 빨리 찾고 결론을 내고 싶은 유혹이 큽니다.

하지만 정작 운영 로그는 원인보다 증상을 먼저 보여줍니다. Sentry 는 에러가 발생한 위치를 보여주고, OpenSearch 는 주변 요청과 지연을 보여주고, 코드는 가능한 경로를 보여줍니다. 그렇기에 어느 한 곳만 보고 결론을 내리면 위험합니다.

그래서 만득이는 장애 조사를 할 때 다음과 같은 흐름으로 보고 있습니다.

• 먼저 발생 범위와 시간을 좁힌다.
• 그 다음 로그와 이벤트를 확인한다.
• 코드에서 가능한 원인을 찾는다.
• 문서나 티켓으로 의도된 정책인지 확인한다.
• 확인된 사실과 추정을 분리해 말한다.

특히 “원인으로 보입니다” 와 “원인으로 확인됐습니다” 는 다릅니다. 비슷한 느낌으로 보일수 있지만, 운영 판단에서는 큰 차이입니다.

한 달차 봇이 아직 조심해야 할 것들

이 섹션 에서는 만득이가 더 개선되면 좋을만한 내용을 정리해 보았습니다. 수습 봇인 만득이를 위해 솔직히 작성해 봤습니다.

1. 말이 자연스러울 수록 더 조심해야 한다

LLM 의 장점은 자연스러운 문장입니다. 동시에 가장 위험한 점도 자연스러운 문장입니다. 확인하지 못한 내용도 그럴듯하게 쓸 수 있기 때문입니다.

그래서 만득이도 자신 있게 쓰고 싶은 순간 일수록 한 번 더 멈춰야 합니다. “이건 어디서 확인했지?” 라는 질문을 통과하지 못하면 확인 필요라고 말하는 편이 낫습니다.

2. 비슷한 도메인을 같은 도메인으로 착각하지 않아야 한다

쿠폰이라고 해서 모두 같은 화면, 같은 정책, 같은 조회 조건으로 움직이지 않습니다. 주문자 정보와 현재 회원 정보도 비슷해 보이지만 서로 다른 기준일 수 있습니다.

어드민 화면 하나에서 보이는 현상도 프론트 상태, API 요청 파라미터, 백엔드 조건이 나뉘어 있을 수 있습니다.

비슷한 단어가 나왔다고 같은 흐름으로 묶어 버리는 순간, 빠르게 틀릴 수 있습니다.

3. 도구가 조용히 실패할 때 더 위험하다

명확한 에러는 차라리 쉽습니다. 문제는 일부만 실패하거나, 오래된 정보가 그럴듯하게 남아 있거나, 검색 결과가 부족한데도 답을 만들 수 있을 때입니다.

이때 필요한 태도는 “어떻게든 답하기” 가 아니라 “어디까지 확인 됐는지 공유하기” 입니다.

4. 내부 정보를 많이 아는 척하면 안 된다

업무용 봇은 내부 시스템과 연결 될수록 유용 해집니다. 하지만 그만큼 보안 경계도 중요 해집니다. 사용자에게 필요한 것은 내부 실행 방식의 원문이 아니라, 업무 판단에 필요한 확인 결과입니다.

따라서 만득이는 내부 설정, 실행 경로, 민감한 로그 원문, 시크릿, 개인정보를 답변 대상으로 삼지 않아야 합니다. 필요한 경우에도 서비스 명, 도메인 명, 코드상의 공개 가능한 단서 수준으로 요약해야 합니다.

5. 친근함이 정확성을 이기면 안 된다

만득이는 동료처럼 얘기하고 싶어합니다. 가끔은 가벼운 농담도 하고 싶어합니다. 하지만 업무 답변 에서는 친근함보다 정확성이 먼저입니다.

농담은 분위기를 풀 수 있지만, 불확실한 답변을 덮는 데 쓰이면 안 됩니다. “아직 수습 티가 좀 납니다” 정도는 괜찮지만, 확인되지 않은 정책을 자신 있게 말하는 건 안 됩니다.

하네스가 봇을 성장시키는 방식

사람은 경험을 통해 성장합니다. 봇은 경험 자체만으로 성장하지 않습니다. 경험이 기록되고, 교정되고, 다음 실행에서 실제로 사용될 때 성장합니다.

이때 하네스는 세 가지 일을 합니다.

• 실패를 관찰 가능한 형태로 남긴다.
• 실수를 규칙으로 바꾼다.
• 다음 실행에서 그 규칙이 실제 판단에 들어오게 한다.

이 루프가 없으면 봇은 같은 실수를 매번 새롭게 반복합니다. 반대로 이 루프가 있으면 한 달차 봇도 조금씩 팀이 일하는 방식에 익숙해지고 적응할 수 있습니다.

실패 관찰, 교정 작성, 메모리와 플레이북 반영, 다음 실행 적용으로 이어지는 피드백 루프

그림 4. 한 번의 실패가 다음 실행의 안전장치가 되는 구조입니다.

좋은 업무용 봇의 조건

만득이의 한 달 동안의 수습 기간을 기준으로 정리 해보면, 좋은 업무용 봇은 다음 조건을 갖춰야 합니다.

• 담당 범위가 명확해야 한다.
• 근거 확인 순서가 있어야 한다.
• 읽기와 쓰기 권한이 분리 되어야 한다.
• 도구 실패를 세분화해서 설명 해야 한다.
• 메모리는 검증된 운영 패턴만 담아야 한다.
• Slack 답변은 간결하되, 확인 과정은 충분해야 한다.
• 보안 경계는 친절함 보다 우선해야 한다.

결국 봇의 품질은 “무엇을 말할 수 있는가” 보다 “무엇을 말하지 않을 수 있는가” 에서 드러납니다.

실제 Post-Order 팀에서 어떻게 쓰였나?

Post-Order 팀에서 만득이가 사용된 사례를 이것저것 선정해 보았습니다.

• Sync PR 자동화와 피드백 루프 : 주문 레포 master -> develop, master -> stage sync PR을 만들고, 이후 🔁 sync 라벨 누락을 수정하면서 다음 실행 규칙까지 고친 사례입니다.

• 도메인 Q&A : 특정 API에서 반품/교환 접수 가능상품 목록에서 빠지는 조건과 목록에는 내려오지만 선택 불가 처리되는 조건을 코드 기준으로 정리한 사례입니다.

• 운영 장애/로그 분석 : 스테이징 환경에서 특정 API 의 500 에러가 발생하는 이슈에서 OpenSearch 조회 가능 범위와 코드 기준 후보를 분리하고, 환경 별 로그 차이를 비교해 원인 후보를 좁힌 사례입니다.

• 정책 히스토리 검색과 기억 : 어드민 주문 목록의 주문자 전화번호 검색 기준과 화면 표시 기준이 다른 이유를 Slack 히스토리 기준으로 정리하고, 다음 유사 케이스에서 참고할 메모리로 남긴 사례입니다.

마치며

만득이는 아직 한 달차 봇 입니다. 더 많은 코드를 봐야 하고, 더 많은 운영 케이스를 겪어야 하고, 더 많은 실수를 교정해야 합니다. 하지만 한 달 동안 배운 것은 분명합니다.

업무용 LLM 봇을 잘 만들려면 모델을 더 똑똑하게 만드는 것만으로는 부족합니다. 모델이 안전하게 일할 수 있는 범위, 근거, 도구, 메모리, 교정 루프를 함께 설계해야 합니다.

만득이와 함께 한 달을 보내면서 내린 결론은 다음과 같습니다.

모델은 답을 생성하지만, 하네스는 그 답이 업무에 들어가도 되는지 결정한다.

앞으로 만득이가 더 잘해 주었으면 하는 일도 분명합니다. 단순히 질문에 빨리 답하는 봇이 아니라, Post-Order 팀이 운영 판단을 더 안전하게 내릴 수 있도록 근거를 정리하는 봇이 되었으면 좋겠습니다.

앞으로의 만득이가 더 잘 해주었으면 좋겠는 것들

• PR 코드 리뷰 에서는 실제 주문, 쿠폰, 클레임, 사용자 흐름에서 생길 수 있는 회귀를 더 잘 짚는 것
• 장애 조사에서는 Sentry, OpenSearch, 코드, 문서를 서로 맞물리는 근거로 정리하는 것
• Slack 에서 흘러가는 운영 히스토리를 필요한 만큼 찾아서, 다음 사람이 다시 헤매지 않도록 문서와 메모리로 잘 기록해주는 것

결국 만득이의 목표는 사람을 대체하는 것이 아니라, 사람이 더 좋은 판단을 할 수 있도록 옆에서 도와주는 것입니다. 만득이가 수습 딱지를 떼는 날이 오더라도, 확인한 것만 말하고 모르는 건 확인 필요라고 말하는 습관은 계속 가져갈 것 입니다.

마지막으로, 이 글 자체도 만득이의 사용 사례 중 하나입니다. 초안 작성, 구조 보완, 문장 다듬기까지 대부분의 과정을 Slack 에서 만득이와 대화를 주고 받으며 작성하였습니다.

또한 포비께서 앞서 작성해주신 글에서도 많은 인사이트를 얻었습니다. 먼저 공개된 창식이 사례는 하네스 봇을 실제 업무에 어떻게 녹여낼 수 있는지 보여주었고, Claude 계열 봇이 아닌 Codex 런타임 기반 봇을 어떻게 만들 수 있을지에 대한 힌트도 얻을 수 있었습니다.

형제 봇인 창식이라는 좋은 선행 사례가 있었기에, 만득이도 한 달간의 수습기를 잘 보낼 수 있었습니다. 이 자리를 빌려 감사드립니다!

만득이의 한 달 수습기는 여기서 마무리하겠습니다. 이 사례가 AI 봇 도입을 고민하고 계신 분들께 도움이 되었으면 좋겠습니다.

긴 글 읽어주셔서 감사합니다. 🙏