사내 AI 코딩 에이전트 만들기: ACP·MCP·React

코드 완성 도구와 에이전트는 다른 물건입니다. 완성 도구는 지금 편집 중인 자리의 문맥 안에서 일합니다. 에이전트는 코드베이스 전반을 보고 추론하며, 여러 단계의 작업을 조율하고, 도구를 호출하고, 실패하면 다시 시도하고 결과를 검증합니다.

여기서 흔한 오해 하나를 원문이 짚습니다. 재시도가 정확성을 보장하지 않습니다. 에이전트에게 "안 되면 다시 해 봐" 를 허락하는 것만으로는 품질이 올라가지 않습니다. 한계 있는 실행, 정지 조건, 권한 범위, 그리고 합격 기준이 여전히 필요합니다.

왜 사내 에이전트가 필요한가

범용 어시스턴트가 모르는 것이 셋 있습니다. 사내에서 쓰는 프레임워크의 관례, 내부 API, 그리고 조직의 코딩 표준입니다. 이것을 모르는 상태로 생성된 코드는 리뷰에서 다시 쓰입니다.

사내 에이전트를 만들어 얻는 것은 네 가지입니다.

• 업무 흐름에 맞춘 개발자 경험: 쓰는 도구 안에서 불립니다
• 재사용 가능한 스킬로 포장한 도메인 지식: 한 사람의 머릿속에서 꺼내 놓습니다
• MCP 서버로 노출한 업무 도구: 린터, 생성기, 사내 조회 API
• 릴리스 수명주기 통제: 에이전트의 동작을 버전으로 관리합니다

원문의 예시는 Ext JS 현대화 작업을 돕는 /extlint 명령입니다. 마크다운으로 적은 스킬, MCP 로 노출한 린트 도구, 진단 결과 검토, 한계 있는 경로 교정 재시도, 그리고 요약으로 이루어집니다.

ACP 와 MCP: 무엇이 다른가

• ACP (Agent Client Protocol): 클라이언트와 에이전트 백엔드(클라우드·CLI·로컬) 사이의 공통 인터페이스입니다. 제공자가 바뀔 때 클라이언트를 다시 만들지 않게 해 줍니다
• MCP (Model Context Protocol): 외부 도구와 자원을 발견하고 호출하는 규약입니다

스킬과 도구는 다릅니다

스킬은 마크다운으로 적은 절차와 지침입니다. 무엇을 어떤 순서로 하라는 글입니다. MCP 도구는 실제로 실행되는 작업입니다. 둘을 섞으면 "지침은 있는데 실행이 없는" 에이전트나 "실행은 하는데 기준이 없는" 에이전트가 나옵니다.

도구 호출의 수명주기는 네 단계입니다. 요청 해석 → 도구 선택과 인자 구성 → 서버 실행 → 결과 처리입니다. 기업에서 각 단계에 붙여야 하는 것은 권한, 입력 검증, 실행 경계, 실패 처리, 관측 가능성, 그리고 사람의 승인입니다.

로컬 모델과 클라우드 모델: 인프라 결정입니다

어느 쪽을 쓸지는 취향이 아니라 비용·하드웨어·프라이버시·과제 난이도가 걸린 인프라 결정입니다. 로컬 실행은 LM Studio 나 Ollama 로 가능합니다.

로컬 추론만으로 데이터 주권이 보장되지 않습니다

원문이 분명히 적어 둔 대목입니다. 모델을 사내에서 돌려도 텔레메트리, 패키지 관리자, MCP 도구, 로깅이 여전히 데이터를 밖으로 내보낼 수 있습니다. "로컬 모델이니 안전하다" 는 결론은 나머지 경로를 점검한 뒤에야 성립합니다. 작업을 의도적으로 나눠 배치하는 하이브리드 구성이 현실적입니다.

인터페이스: VS Code Webview 와 그리드

원문의 구현은 React 기반 VS Code Webview 를 쓰고, 진단 결과는 ReExt 그리드로 봅니다. 그리고 데이터를 세 층으로 나눕니다. 사용자에게 보여 줄 출력, 운영 진단, 그리고 제한된 기술 데이터입니다. 이 구분이 없으면 내부 스택 트레이스가 사용자 화면에 나옵니다.

자가 치유 흐름: 되먹임 고리를 믿을 수 있게

도구의 출력이 다음 행동을 정하는 고리가 에이전트의 핵심입니다. 그 고리를 신뢰할 수 있게 만드는 조건이 다섯입니다.

• 재시도에 한계를 둔다 (횟수와 시간)
• 수정은 증거에 근거한다: 추측으로 고치지 않는다
• 실패했을 때 권한을 올리지 않는다
• 결과를 검증한다
• 증거가 모자라면 사람에게 명확히 넘긴다

도입 5단계

1. 반복적이고, 정의가 명확하고, 측정 가능한 작업을 하나 고른다
2. ADR(아키텍처 결정 기록)로 구조와 모델 전략을 적는다
3. 범위가 좁은 스킬과 MCP 도구를 만든다
4. VS Code 인터페이스와 관측 수단을 붙인다
5. 기준선과 비교해 평가하고, 포장해서 확대한다

평가 지표는 작업 완료율, 사람 개입 횟수, 검증 통과율, 복구 성공률, 성공당 비용, 소요 시간, 결함·회귀율, 정책 준수입니다.

정리하면

• 에이전트의 값은 생성 속도가 아니라 사내 지식을 스킬·도구로 포장한 정도에서 나옵니다.
• ACP 는 에이전트 백엔드를 바꿔 끼우는 인터페이스, MCP 는 도구를 붙이는 규약입니다.
• 재시도는 한계·증거·검증이 함께 있을 때만 품질이 됩니다.
• 로컬 모델이 곧 데이터 주권은 아닙니다: 나머지 유출 경로를 점검해야 합니다.
• 좁은 작업 하나로 시작해 지표로 확인한 뒤 넓힙니다.

미래웹이 덧붙입니다

국내에서 이 글이 가장 쓸모 있는 자리는 레거시 현대화입니다. 10년 넘게 쓴 Ext JS 애플리케이션이나 오래된 사내 프레임워크를 손볼 때, 가장 비싼 비용은 코드를 쓰는 일이 아니라 그 코드베이스의 관례를 아는 사람의 시간입니다.

그 관례를 스킬 문서로 적고 린트 도구를 MCP 로 붙이면, 한 사람만 알던 판단이 팀 전체가 쓰는 도구가 됩니다. 원문의 /extlint 예시가 정확히 그 모양입니다. 현대화 프로젝트에서 이것을 먼저 만들면 뒤따르는 작업의 속도가 달라집니다.

보안 심사 쪽에서는 위의 "로컬 모델이라고 안전한 것은 아니다" 대목을 특히 권합니다. 사내 도입 검토 문서에서 이 구분이 빠진 경우를 자주 봅니다. 승인받을 문서에는 모델의 위치만이 아니라 텔레메트리·로깅·패키지·MCP 도구의 외부 통신 여부를 항목으로 적어 두시는 것이 좋습니다.

사내 코딩 에이전트를 검토하고 계신다면

어느 작업부터 시작할지, 사내 지식을 어떤 단위로 스킬화할지, 그리고 보안 경계를 어디에 그을지가 설계의 핵심입니다. Ext JS 현대화와 AI 도입을 함께 보시는 경우 미래웹의 AI 컨설팅으로 문의해 주십시오.

이 글은 Sencha 공식 블로그 게시물 Building Custom AI Coding Agents with ACP, MCP & React (2026년 10월 1일 게시 · 10월 16일 갱신, Team Sencha)을 미래웹 주식회사가 한국어로 옮기고 해설을 덧붙인 것입니다. 원문의 저작권은 Sencha / Idera, Inc. 에 있습니다. "미래웹이 덧붙입니다" 항목은 원문에 없는 미래웹의 견해입니다. 번역 과정에서 생긴 오류가 있다면 원문을 기준으로 판단해 주십시오.