ANCHORMIND직원 한 명이 퇴사하면, 회사 업무가 마비되지는 않는가
예외 주문은 어떻게 처리하는지, 거래처와 어떤 약속을 했는지, 지난 장애를 왜 그 방법으로 해결했는지. 이런 지식은 대개 문서가 아니라 사람에게 남는다. 그 사람이 자리를 옮기거나 퇴사하면 절차서는 그대로 남아도 업무의 맥락은 함께 사라진다.
새로 들어온 사람은 반대편에서 같은 문제를 겪는다. 누구에게 물어야 할지, 어디에서 찾아야 할지 모르는 첫날이 길어지고, 바쁜 선배를 기다리는 시간이 쌓인다. 매뉴얼에는 무엇을 하라고 적혀 있지만 왜 그렇게 결정했는지, 어떤 시도가 실패했는지는 빠져 있다.
AnchorMind Enterprise Solutions는 이 공백을 겨냥한다. 목표는 한 문장으로 요약된다. 24시간 곁에 있는, 우리 회사의 업무에 정통한 노련한 사수. 흩어진 사내 지식과 업무 중에 내린 판단·해결 과정을 하나의 기억으로 연결하고, 함께 일하며 남긴 경험을 다음 사람과 다음 업무의 자산으로 만든다.
문서 검색과 사수는 무엇이 다른가
사내 문서 검색은 이미 적힌 것을 찾아 준다. 사수는 그보다 한 걸음 더 나간다. 질문을 받으면 관련 절차와 함께 지난번에 무엇이 통했고 무엇이 실패했는지, 그때 왜 그 선택을 했는지를 같이 알려 준다.
AnchorMind는 이 차이를 기억의 단위로 해결한다. 사실만 저장하지 않고 의사결정, 오류, 해결 절차와 경험의 맥락을 각각 기억 파편으로 남긴다. 그리고 질문이 들어오면 관련 문서·코드와 함께 이 파편들을 찾아 답변의 근거로 쓴다. 정리하면 세 문장이다.
- 지식이 모인다. 문서, 코드, 데이터, 운영 기록을 권한 범위 안에서 연결한다.
- 경험이 남는다. 업무 중 확인한 판단의 이유, 실패한 시도, 해결 과정과 결과를 기록한다.
- 다음 업무에 쓰인다. 기록한 경험을 다음 질문과 과제에서 다시 찾아 쓰는 흐름을 시스템으로 만든다.
담당자가 바뀌어도 경험은 조직에 남는다
사람에게만 남은 경험은 담당자 교체와 함께 끊긴다. 조직에 기록하고 검토한 경험은 교체 이후에도 이어진다. 차이는 시간이 흐를수록 커진다. 업무에서 얻은 판단·실패·해결 경험을 꾸준히 기록하고 갱신하면, 다음 담당자가 활용할 수 있는 노하우가 조직 안에 쌓이기 때문이다.
예를 들어 처음 결제 장애를 맡은 신입이 "우리 팀은 이 문제를 어떻게 해결했나요?"라고 묻는다고 하자. 시스템은 권한 범위 안에서 결제 정책과 관련 코드, 과거 장애 기록을 함께 찾는다. 당시의 원인과 시도, 해결 방법과 그 방법을 선택한 이유를 연결해 보여 주고, 현재 정책과 다른 기록은 따로 표시한다. 신입은 지난 해결 경험과 판단 근거를 바탕으로 첫 점검을 시작하고, 최신 상황과 출처는 담당자가 확인한다.
현재 기능과 맞춤 구축
현재 AnchorMind가 제공하는 것은 경험을 축적하고 다시 꺼내 쓰는 기억 시스템이다. 기억 파편 저장과 관련 기억 검색, 신뢰 검토와 충돌 정리, 검색 추적과 재현으로 어떤 기억이 답변에 쓰였는지 확인할 수 있다. 기억 반출입과 MCP 연결로 이미 쓰고 있는 업무 도구에서 바로 활용한다.
여기에 고객 환경에 맞춘 커넥터를 더한다. 아래 항목은 소스 접근 권한, 커넥터 제공 여부와 인수 조건을 프로젝트별로 합의하는 구축 후보다.
- Data MCP (PostgreSQL, MySQL): 테이블·열 허용목록, 사용자별 권한, 시간·행 수 제한을 적용한 읽기 전용 자연어 데이터 분석.
- Code MCP (GitLab, GitHub): 코드와 변경 이력에 관련 의사결정과 유사 장애를 연결한다. 이전 담당자가 무엇을 왜 바꿨는지, 지난번 어떤 해결이 통했는지 확인한다.
- Operations MCP (EKS, CloudWatch): 진단용 읽기 권한으로 로그와 메트릭을 분석한다. 운영 변경은 별도 승인 경로를 거친다.
- Knowledge MCP (문서, 파일): 사내 문서와 기록된 노하우를 함께 찾아 답한다. 업무 절차와 판단 근거, 출처를 연결하고 담당자가 최신성을 검토한다.
모델은 외부 API와 자체 구축 중에서 고른다
조직의 경험은 민감한 정보와 맞닿아 있다. 그래서 아키텍처는 고객이 통제하는 환경을 경계로 그린다. 기억 허브와 키 정책, 신뢰 검토, 소스 권한과 도구 호출 제한, 전송 정책과 선택적 마스킹이 모두 이 경계 안에 있다.
추론을 맡을 모델은 두 가지 선택지를 열어 둔다. 하나는 승인된 외부 LLM API다. 이 경우 허용된 본문만 전송 정책을 거쳐 경계를 넘고, 외부 모델의 보관·학습 조건은 공급자, 상품과 계약별로 확인한다. 다른 하나는 로컬 추론, 곧 자체 구축 LLM이다. 모델 추론까지 고객 환경 안에서 처리하므로 데이터가 외부로 나가지 않아야 하는 업무에 맞는다. 두 방식은 업무별로 섞어 쓸 수도 있다.
온보딩 제로를 지향하되, 성과는 측정으로 확인한다
온보딩 제로는 지향점이다. 실제 성과는 같은 업무 과제를 두고 도입 전후를 비교해 확인한다. 신입의 첫 독립 업무 완료 시간, 과제 정확도, 반복 질문과 사수의 설명 부담이 기본 지표다. 장애 대응이라면 원인 식별 시간, 제안 정확도, 승인 후 복구 시간을 구분해서 본다.
비용도 같은 원칙으로 계산한다. 3년 TCO는 초기 구축비, 36개월의 월 운영비, 변경·교육·종료 및 이관 비용의 합이다. 제안서에는 워크로드 가정, 가격 기준일, 환율, 세금과 지원 범위를 적고, 고정된 절감률이나 성과를 보장하지 않는다.
인수 조건이 명확한 파일럿부터
도입은 세 단계로 진행한다.
1. 범위 정의와 파일럿: 선정한 소스와 공통 기준 과제로 시작한다. 4주 파일럿은 목표 일정이며 데이터 접근과 보안 검토 준비에 따라 산정한다. 2. 보안 강화와 확장: 권한·문서 ACL, 고객별 마스킹과 운영 절차를 검증한다. 조직 SSO와 부서 RBAC는 별도 확장 범위다. 3. 확산과 지속 관리: 검증한 소스와 부서부터 넓히고, 업무에서 얻은 판단과 해결 경험을 계속 기록한다. 최신성·충돌·삭제 정책을 운영해 다음 직원과 다음 과제가 쓸 노하우를 쌓는다.
우리 회사의 사수를 함께 설계하려면
시작점은 거창하지 않다. 신입이 자주 묻는 질문과 선배에게만 남아 있는 노하우를 알려 주면, 사내 지식과 경험을 연결할 시스템과 기록 방식, 도입 범위를 함께 검토한다. 상담 신청과 구축 아키텍처 백서는 Enterprise Solutions 페이지에서 확인할 수 있다.