세일즈 에이전트 만들다 AI 팀 복구한 경험

소개

저는 세일즈 전담 인력이 부족한 소규모 B2B 기업을 위한 세일즈 파이프라인을 만들고 있습니다.

잠재고객 발굴 → 기업 조사 → 연락처 탐색 → 아웃바운드 메시지 작성까지 AI가 수행하고, 사용자는 최종 추천 고객과 메시지를 보고 발송 여부를 결정하는 방식입니다.

이 업무를 여러 AI가 나눠서 하면 좋겠다고 생각해 자비스 터미널(CYS Terminal)에 팀을 구성했습니다.

그런데 사용하면서 예상하지 못한 문제가 생겼습니다. 컴퓨터를 껐다가 다시 켤 때마다 대화 잠금이나 복원 문제가 반복됐습니다.

오늘도 세일즈 파이프라인 작업을 이어가려고 자비스를 열었지만, 결국 상당 시간을 AI 팀이 다시 일할 수 있게 복구하는 데 사용했습니다.

이번 글은 개발 성공기보다는, 이 시행착오를 통해 내 업무에 어떤 도구가 필요한지 판단하게 된 경험 을 공유하는 글입니다.

진행 방법

1. 재시작 후 팀이 작동하지 않는 원인을 확인했습니다

사용한 도구는 맥 환경의 CYS Terminal과 Codex CLI입니다. ChatGPT에 화면을 공유하며 상황을 해석하고, 자비스의 실행 가능한 패널에 진단과 복구를 요청했습니다.

처음에는 다음과 같은 안내가 나왔습니다.

This conversation is open in another app

재시도 키를 눌러도 해결되지 않았습니다. 확인 결과, Master와 Reviewer가 같은 대화를 열려고 하는 중복 연결이 발견됐습니다. 일부 대화에는 여러 역할의 복원 기록도 섞여 있었습니다.

화면의 패널 이름이 Master라고 해서, 실제로 Master의 대화가 연결돼 있는 것은 아니었습니다.

제가 전달한 진단 요청 중 하나는 다음과 같습니다.

123456789101112131415재시작할 때 Master·CSO·Reviewer에 대화 중복 잠금이 반복된다.
현재 여러 패널에 같은 Reviewer 지침과 ACK 기록이 보인다.

전체 작업 이력은 읽지 말고, 시작·복원 설정만 조회해줘.

1. 각 패널의 등록 역할, 복원 대상 session ID,
   실제 실행 명령을 대조해 표로 보여줘.
2. 같은 session ID를 여러 패널이 사용하는지 확인해줘.
3. 잠긴 대화를 현재 점유한 프로세스를 확인할 수 있다면
   PID와 확인 근거를 보고해줘.
4. Worker의 -32603 오류는 별도 문제로 구분해줘.

설정 수정, 프로세스 종료, fork, 노드 생성, 재시작은 하지 마.
조회 실패는 한 번만 보고하고 반복 시도하지 마.
마지막에 확인된 원인과 최소 수정안을 짧게 제시해줘.

2. 대화를 분리하고 일부 팀원을 복구했습니다

기존 프로젝트와 대화 기록을 보존하면서 역할별 대화를 식별했습니다. 원래 Master 대화는 확정하기 어려워 새 독립 대화를 만들고, 파일로 작업 내용을 인계하는 방향으로 진행했습니다.

그런데 대화를 분리한 뒤에도 문제가 끝나지 않았습니다.

• 역할은 등록됐지만 Codex 종류 정보가 비어 있는 패널
• 기존 Worker와 새 Worker의 역할 주소 불일치
• 입력창을 감지하지 못해 전달이 보류되는 메시지
• 복구된 패널에 뒤늦게 도착하는 과거 경보

한 가지 오류를 고치면 끝나는 상황이 아니라, 대화·역할·입력 감지·메시지 전달을 각각 확인해야 하는 상황이었습니다.

3. “메시지를 보냈다”와 “실제로 받았다”를 구분했습니다

메시지 전송 결과가 QUEUED라고 나오면 처음에는 전달이 된 줄 알았습니다. 하지만 실제로는 대기열에 들어갔다는 뜻이었습니다.

상대 패널에 메시지가 나타났는지, 회신이 생성됐는지, 그 회신이 Master에게 도착했는지를 따로 확인해야 했습니다.

입력창 감지를 위해 패널 크기를 조정하는 과정에서는 화면 표시까지 어긋났습니다. 일부 메시지는 전달됐지만 전체 팀의 통신이 안정적으로 복구됐는지는 끝까지 확인하지 못했습니다.

결국 추가 복구를 중단하고 작업 내용을 기록했습니다.

오늘 복구 과정에서는 세일즈 파이프라인의 신규 조사·구현·시험을 진행하지 못했습니다.

결과와 배운 점

1. 제 작업에는 자비스의 운영 복잡도가 더 크게 느껴졌습니다

오늘의 결과는 일부 패널과 메시지 전달을 복구한 것이었습니다. 팀 전체가 정상적으로 일할 준비를 마쳤다고 보기는 어려웠습니다.

반면 시간과 토큰은 계속 사용됐습니다. 제가 만들고 싶은 것은 세일즈 파이프라인인데, 실제로는 AI 팀의 대화와 역할, 통신 상태를 관리하고 있었습니다.

이 경험을 통해 내린 결론은 다음과 같습니다.

현재 제가 만들려는 세일즈 파이프라인에는 자비스 터미널보다 Codex 중심의 구성이 더 맞겠다는 것입니다.

자비스 자체의 성능을 일반적으로 평가한 결론은 아닙니다. 제 작업에서 필요한 기능과, 그 기능을 얻기 위해 감수해야 하는 운영 부담을 비교한 판단입니다.

2. 스터디장이 설명해 준 차이를 경험으로 이해했습니다

예전에 스터디장님이 Codex 내부 서브에이전트와 자비스를 활용한 멀티에이전트 팀의 차이 를 설명해 주셨습니다.

당시 이해한 핵심은, 작업을 나눠 맡기고 결과를 받는 것과 각 에이전트가 자기 맥락을 유지하면서 계속 협업하는 것은 다르다는 점이었습니다.

처음에는 여러 AI가 역할을 나누는 모습에 집중했습니다. 이번에는 제게 정말 필요한 것이 무엇인지 생각하게 됐습니다.

제가 현재 구현하려는 조사 → 구현 → 검수 흐름은, 우선 Codex에서 작업을 나누고 필요한 때 서브에이전트를 활용하는 방식으로도 접근할 수 있겠다고 판단했습니다.

여러 독립 CLI와 모델을 상시 팀으로 운영해야 할 필요는 아직 크지 않았습니다.

3. 앞으로 도구를 고를 때 확인할 기준이 생겼습니다

앞으로 업무 자동화나 간단한 에이전트를 개발할 때는 가장 단순한 구성으로 실제 결과물을 먼저 만들고, 부족한 부분이 확인될 때 도구를 추가 하려고 합니다.

4. 다음에는 세일즈 파이프라인 자체에 집중하려고 합니다

기존에 만든 코드와 조사 자료, 요구사항은 보존하고 Codex 중심으로 개발을 이어갈 계획입니다.

우선 잠재고객을 찾고, 근거를 조사하고, 연락 초안을 만드는 흐름 하나를 실제로 작동시키겠습니다. 그 과정에서 병렬 작업이나 독립 검수가 필요하면 역할을 추가하려고 합니다.

이번에는 기대했던 기능 개발을 끝내지는 못했습니다. 그래도 “멀티에이전트를 쓸 것인가?”보다 “이 업무에 어느 정도의 팀 운영 구조가 필요한가?”를 먼저 판단해야 한다 는 기준은 얻었습니다.

도움 받은 글

• 스터디장님의 Codex 내부 서브에이전트와 자비스 활용 멀티에이전트 비교 설명
• 나만의 팀 하네스 — 통합 실습 가이드
• ChatGPT와 함께 진행한 오류 화면 해석 및 복구 지시 정리

출처

• 원문: https://www.gpters.org/nocode/post/seiljeu-eijeonteureul-mandeuldaga-ai-tim-bogguman-haessseubnida----nae-dB5v7ukxuhWQlvg (2026-10-22 · 움취움움취)