MCP로 POC의 자료 조사와 초안 작성 줄이기

POC를 진행하다 보면 코드를 쓰기 전에 할 일이 많습니다. 요구사항을 읽고, 관련 문서와 기존 구현을 찾고, 실제 동작을 로그로 확인해야 합니다. 새로운 주제를 다룰 때는 이런 준비가 구현보다 오래 걸리는 느낌도 있었습니다.

이번에는 AI 에이전트가 필요한 자료를 직접 찾아보도록 연결했습니다. Jira와 Confluence, GitHub, Splunk를 오가며 정보를 모으고 구현 계획과 문서 초안을 만들게 했습니다. 가장 도움이 된 부분은 작업을 시작할 때 필요한 조사와 정리였습니다.

자료를 직접 읽도록 연결

이전에는 사람이 티켓과 문서를 읽고 필요한 내용을 대화창에 붙여 넣는 일이 많았습니다. 도구를 연결한 뒤에는 티켓에서 관련 문서를 찾고, 기존 코드와 로그를 확인하는 작업까지 에이전트에 맡겨 볼 수 있었습니다.

MCP 는 이런 연결에서 도구와 데이터를 제공하는 공통 방식을 정의합니다. 다만 모든 기능을 MCP로 연결한 것은 아닙니다. 일부는 기존 API의 명세와 호출 규칙을 정리해 직접 사용하게 하는 것으로도 충분했습니다.

각 도구에서 찾을 정보도 나눴습니다.

티켓만 읽었을 때는 빠지는 내용이 있었습니다. 운영 문서와 팀 위키까지 함께 참고해야 왜 그런 구현을 사용하는지 설명할 수 있었습니다. 자료를 많이 넣는 것보다 현재 작업에 필요한 자료를 골라 주는 쪽이 중요했습니다.

예를 들어 티켓의 요구사항을 읽고 관련 설계 문서를 찾은 다음, 유사한 코드와 최근 변경을 확인하도록 요청했습니다. 동작에 대한 의문이 있으면 로그도 조회하고, 그 결과를 바탕으로 구현 계획 초안을 만들게 했습니다.

사람이 먼저 모든 내용을 요약해서 전달할 때보다 초안을 검토하기까지의 준비가 줄었습니다. 다만 가져온 자료가 오래됐거나 서로 다른 버전의 설명이 섞이면 초안도 잘못된 방향으로 갈 수 있었습니다. 제안의 근거가 된 문서와 코드를 함께 확인해야 했습니다.

테스트 코드의 기본 구조를 만들거나 PR 설명에서 확인할 시나리오를 뽑는 작업도 도움이 됐습니다. 반복 코드나 익숙한 구현 방식에서는 빠르게 검토할 초안을 받을 수 있었습니다.

문서도 구현과 병행해서 작성하게 했습니다. PR 설명과 API 사용법, 아키텍처 결정 기록의 초안을 먼저 받고, 빠진 배경과 판단 이유를 보충했습니다. 구현을 마친 뒤 처음부터 설명을 쓰는 부담을 줄일 수 있었습니다.

그렇다고 생성된 테스트가 통과했다는 이유로 구현까지 맞다고 볼 수는 없었습니다. 테스트도 같은 잘못된 가정을 따라갈 수 있어, 기대 결과가 실제 업무 규칙과 맞는지 확인해야 했습니다.

조직에서 새 도구를 연결하려면 법무팀과 보안팀 검토가 필요했습니다. 원하는 도구를 한 번에 모두 붙일 수는 없어, 허용된 정보원부터 연결해 POC를 진행했습니다. 다른 도구는 심사를 이어가는 상태였습니다.

정보에 접근할 수 있어도 요약 과정에서 중요한 예외가 빠지는 문제는 남았습니다. 여러 문서를 짧게 합쳐 전달하면 읽는 속도는 빨라져도 조건과 맥락이 사라질 수 있었습니다. 중요한 결정은 요약만 보지 않고 원문으로 돌아가 확인했습니다.

요구사항의 우선순위와 구현 범위, 도메인 규칙은 사람이 결정했습니다. 에이전트가 만든 코드와 테스트가 실제 환경에 맞는지 검증하고, 문서의 주장에 근거가 있는지도 확인했습니다.

이번 POC에서는 조사와 초안 작성에 드는 수고가 줄었다고 느꼈습니다. 전체 개발 기간을 얼마나 단축했는지 수치로 비교한 실험은 아니었습니다. 자료 조사는 AI에 맡기더라도 구현 방향을 정하고 결과를 검증하는 일은 직접 해야 했습니다.