비개발 조직의 AI 에이전트 도입기 - Blockchain Ops

들어가며

가상자산 거래소의 블록체인 운영(Blockchain Operation, 이하 "옵스") 업무에는 화려한 순간이 별로 없습니다. 출금지갑 잔고를 점검하고, 미집금(고객 입금 주소에서 회사 지갑으로 자산이 모이지 않은) 케이스가 없는지 확인하고, 콜드월렛 비율을 살피고, 잔고를 대사합니다. 하나하나는 자잘한 일이지만, 이 중 무엇 하나라도 누락되면 그대로 사고로 이어질 수 있는 업무들입니다.

여기에 옵스 업무의 난이도를 높이는 두 가지 조건이 있습니다. 규제 환경의 변화에 신속하게 대응해야 하고, 하나의 업무를 수행하는 데에도 DB부터 지갑 시스템, 모니터링 도구까지 여러 도구를 통합적으로 사용해야 한다는 점입니다.

저희 블록체인 옵스팀은 개발 조직이 아닙니다. 하지만 이 문제들을 풀기 위해 AI 에이전트 워크플로우를 팀의 업무 방식 자체에 도입했고, 지금은 여러 업무 영역에서 에이전트를 운영하며 직접 애플리케이션을 만들어 업무를 내재화하는 단계까지 왔습니다. 이 글에서는 그 과정에서의 설계 고민과 중간 성과, 그리고 아직 남아 있는 한계를 공유합니다.

왜 옵스 업무에 AI 에이전트인가

도입을 결정하기 전에, 저희 업무의 특성을 먼저 정리해 보았습니다. 돌아보면 이 특성들은 그대로 AI 에이전트가 가치를 만들어내기 좋은 조건이기도 했습니다.

정리하면 옵스 업무의 본질은 컨텍스트 통합, 반복의 정확성, 여러 도구의 오케스트레이션입니다. AI 에이전트가 자연스럽게 가치를 만드는 영역이고, 그래서 외부에 맡기는 대신 옵스팀이 직접 만들고 운영하는 모델을 택했습니다.

어떻게 만들고 운영하고 있나

1. 레이어드 에이전트 구조 — 업무와 도구의 분리

가장 먼저 한 결정은 업무 시나리오와 도구 노하우를 분리하는 것이었습니다. 도구별 사용 지침을 한 번 잘 정리해 두면, 모든 업무 에이전트가 이를 재사용할 수 있는 구조입니다.

업무 레이어의 에이전트는 실제 옵스 업무 단위로 만들어지며, 각각 세 가지 요소로 구성됩니다.

1. 업무 지침 — 전체 처리 절차, 판단 기준, 주의사항
2. 쓰는 도구 — 해당 업무에 필요한 MCP 서버·외부 API와 업무별 주의사항
3. 단계별 실행 스크립트 — 조회 → 계산 → 리포트 → 의사결정 보조로 이어지는 단계를 Python 스크립트로 구체화

현재는 세 가지 카테고리로 운영 중입니다.

• operation-advisor — 출금지갑 보충, 집금 모니터링, 콜드월렛 비율, 집금 스케줄, 멀티체인 브릿지 판단, 입출금 중단/재개, 거래지원(상장) 자산 뉴스 모니터링, 최소 출금 수량 기준 관리, 출금 한도 관리 등 일상 운영 어드바이저 역할을 합니다. 에이전트들의 점검 결과는 매일 사내 메신저 채널로 전송되고, 팀은 그 결과를 기준으로 하루의 오퍼레이션 필요 여부를 판단합니다.
• oncall-helper — 출금 지연, 잔고 대사 불일치가 발생했을 때 적시 대응을 보조합니다.
• report-helper — 일일 잔고 대사 보고, 월별 비용 정산, 자산 분리보관 현황, 정기 업무현황자료 등 정기 보고를 생성합니다.

스킬 레이어의 에이전트들이 다루는 MCP 서버 자체는 대부분 이미 외부에 존재합니다. 저희가 한 일은 MCP 서버를 그대로 쓰는 것이 아니라, 옵스팀 업무 맥락에 맞춰 사용 지침을 구체화한 것입니다. 예를 들어 DB 조회 스킬에는 옵스팀이 자주 쓰는 스키마와 테이블, 시스템 간 매핑이 끊긴 컬럼의 히스토리, 비즈니스 용어 매핑이 담겨 있고, 커스터디·지갑 조회 스킬에는 옵스 관점의 지갑 구조와 자주 조회하는 트랜잭션 패턴이 정리되어 있습니다. 같은 MCP 서버라도 옵스팀 손에 들어왔을 때 바로 쓸 수 있는 형태가 되는 이유입니다.

2. 에이전트보다 먼저 — 사전 인프라

에이전트가 실제 업무에서 작동하려면 그 이전에 충족되어야 할 인프라가 있습니다. 도입 초기에 이 부분부터 점검·구축했습니다.

3. PR과 리뷰로 에이전트를 함께 길러내기

에이전트를 사용하다가 "이 케이스에서는 이렇게 동작했으면 좋겠다" 싶은 것이 생기면, 누구든 PR을 올리고 리뷰를 거쳐 에이전트 정의에 반영합니다. 개발자에게는 익숙한 흐름이지만, 비개발 조직에서 이 방식이 정착되자 에이전트의 동작 변화가 버전 관리되는 자산으로 누적되기 시작했습니다. "어떻게 일하는지"를 글로 남기는 습관이 생기면서, 운영 노하우가 개인의 머릿속에서 팀의 문서로 이동했습니다.

4. 라우팅 표 기반 실행

에이전트가 늘어나면서 새로운 문제가 생겼습니다. 같은 프롬프트인데 실행할 때마다 다르게 행동하는 것입니다. 담당자의 프롬프트 스킬에 따라 결과가 달라진다면, 그것은 표준화가 아니라 결국 개인기에 기대는 일입니다.

이를 해결하기 위해 라우팅 표를 도입했습니다.

• CLAUDE.md에 프롬프트 의도 → 담당 에이전트 매핑을 라우팅 표로 명확히 정의합니다.
• 자주 반복하는 작업은 하나의 트리거 프롬프트로 묶었습니다. 예를 들어 "모니터링 돌려줘" 한 마디면 출금지갑·집금·콜드 비율·브릿지 4개 에이전트가 병렬로 실행됩니다.

또 하나의 원칙은 역할 분담입니다. LLM은 전체 업무 프로세스를 총괄하고 예외 상황을 기록·대응하는 역할을 맡되, 데이터 수집·전처리·계산은 결정적(deterministic)인 Python 스크립트가 수행합니다. 즉 어느 에이전트로 갈지는 라우팅 표로, 그 에이전트가 실행하는 것은 결정적 스크립트로 고정합니다. 에이전트의 행동을 사람의 프롬프트 스킬에 맡기지 않는 것입니다.

무엇이 달라졌나

업무 효율화 — "자잘한 업무를 빠짐없이, 정확하게"

옵스 업무는 단건의 임팩트는 작지만 누락이 곧 사고로 이어집니다. 에이전트 도입 이후 다음 변화가 관찰됩니다.

• 누락 방지 — 일일 점검 항목들이 표준 플레이북으로 정의되어, 담당자가 바뀌어도 동일한 절차가 보장됩니다.
• 판단 근거의 일관성 — 출금지갑 보충량, 콜드 비율, 집금 임계, 출금 한도 등 판단 기준이 코드와 문서로 명문화되어, "왜 이 결정을 했는가"를 언제든 재현할 수 있습니다.
• 온보딩 가속 — 새로 합류한 팀원이 도구별 노하우를 스킬 에이전트를 통해 즉시 활용합니다. 사수의 입에 의존하던 지식이 문서로 이동했습니다.
• 크로스체크 비용 감소 — 매번 수동으로 하던 대조 작업이, 의심 항목에 한해 자동으로 수행됩니다.

규제 대응 — 요구사항 변경에 에이전트로 대응

잔고 대사 일일보고는 주말과 휴일을 포함해 매일 수행해야 하는, 번거롭지만 중요도가 높은 업무입니다. 일일 잔고 대사 에이전트를 도입하면서 이 업무를 원활히 수행할 수 있게 되었습니다.

데이터웨어하우스, 커스터디·지갑 API, 스프레드시트, 전자결재 시스템까지를 하나의 에이전트가 돌아다니며 일일 대사를 end-to-end로 처리합니다. 대사 결과의 미매칭 항목은 자동 분류되고, 조건을 충족하면 후속 조치 등록까지 에이전트가 직접 수행합니다. 사람은 결과 검증과 전자결재 승인이라는, 내부통제 관점에서 반드시 쥐고 있어야 하는 단계만 수행합니다.

규제 요구사항의 변경에도 별도의 시스템 개발 일정 없이 에이전트로 대응할 수 있었습니다.

온콜 대응 가속

온콜 알림이 울리면 이제 온콜 보조 에이전트가 DB, 지갑·커스터디 시스템, 알림 시스템, 내부 위키 등 여러 시스템을 한 번에 모아 조사합니다.

• 잔고 대사 불일치 원인 파악 — 시퀀스별 잔고 변화를 자동 추적하고, 원인 유형을 자동 분류합니다.
• 출금 지연 확인 — 출금 지연 알림이 발생하면 처리 상태와 원인을 즉시 확인해, 에스컬레이션 여부 판단을 지원합니다.

여러 시스템의 탭을 오가며 맥락을 모으던 시간이, 종합된 조사 결과를 검토하고 판단하는 시간으로 바뀌었습니다.

비개발 조직의 R&D 역량화

착오전송 복구에 필요한 개발이나 외부 감사 시 사용할 지갑 잔고 모니터링 도구처럼, 이전에는 개발팀에 요청해서 만들어야 했던 것들을 이제는 자체적으로 해결할 수 있는 범위에서 직접 개발해 사용하고 있습니다.

도구가 손에 잡히기 시작하자 "기술적으로 어렵다"는 이유로 미뤄 두었던 업무가 가능해졌고, 개발과 비개발이라는 업무 구분에 구애받지 않고 일하는 흐름이 자리 잡고 있습니다.

협업·문화적 효과

• 비개발자도 개발자와 동일한 협업 방식으로 업무를 진행하게 되었고, 특정 업무가 자연스럽게 주담당·부담당 체제로 나뉘며 팀 운영이 안정화되었습니다.
• 메모리·플레이북·로그 파일을 통해, 과거에는 사람의 머릿속에만 있던 노하우가 휘발되지 않는 팀의 자산으로 누적됩니다.
• 팀원마다 다르던 작업 방식과 판단 기준이 공용 에이전트와 공용 컨텍스트를 통해 하나의 표준으로 수렴하면서, 누가 담당해도 동일한 절차와 품질이 보장되고 업무 결과의 편차가 줄었습니다.

한계, 그리고 다음 단계

물론 아직 풀지 못한 과제들이 있습니다. 솔직하게 정리해 봅니다.

마치며 — 반복의 정확성에서 조직의 R&D 역량으로

이번 도입을 한 문장으로 요약하면 이렇습니다.

반복의 정확성에서 출발해, 조직의 R&D 역량으로.

반복업무의 누락 최소화, 규제 변경에 대한 신속한 대응, 온콜 원인 파악의 가속을 실제 운영에서 확인했고, 나아가 비개발 조직이 직접 도구를 만들어 업무를 내재화하는 단계까지 왔습니다.

AI 에이전트 도입을 고민하는 비개발 조직이 있다면, 저희 경험에서 세 가지를 말씀드리고 싶습니다. 첫째, 자기 팀 업무의 특성을 다시 한번 깊이 들여다보세요. 에이전트가 어디에서 가치를 만들 수 있는지는 업무의 본질에서 나옵니다. 둘째, 인프라와 공용 컨텍스트를 팀 차원에서 함께 준비하세요. 셋째, 도구 노하우를 업무와 분리해 재사용 가능한 레이어로 만들고, 에이전트의 품질을 사람의 프롬프트 스킬에 맡기기보다 라우팅 표와 결정적 스크립트로 고정하세요.

저희 팀에게 AI 에이전트는 단순한 업무 보조 도구가 아니라, 팀이 일하는 방식과 성장하는 방식을 바꾼 기반이 되었습니다.