MCP와 Agentic Workflow로 POC 기간 단축이 가능할까?

POC는 원래 빠르게 가설을 검증하기 위한 작업이지만, 실제로 해보면 생각보다 많은 시간이 소모된다. 요구사항을 다시 읽고, 관련 문서를 찾고, 기존 코드를 훑고, 로그를 확인하고, 구현 계획을 정리하는 과정이 반복된다. 특히 새로운 아이디어를 검증하는 초기 단계에서는 코드를 쓰는 시간보다 컨텍스트를 모으는 시간이 더 길게 느껴질 때가 많다.

이번 POC에서는 이 과정을 AI로 얼마나 줄일 수 있는지 실험해봤다. 핵심은 MCP(Model Context Protocol)와 Agentic Workflow였다. AI가 단순히 질문에 답하는 수준이 아니라, 직접 Jira를 읽고, Confluence 문서를 찾고, GitHub 코드를 검색하고, Splunk 로그를 조회하면서 필요한 재료를 먼저 모으게 했다.

결론부터 말하면, AI가 POC를 대신 만들어주지는 않았다. 하지만 컨텍스트를 찾고 초안을 만드는 속도는 확실히 빨라졌다. 사람은 여전히 중요한 판단과 검증을 맡아야 했지만, 적어도 “무엇부터 확인해야 하지?”라는 초기 마찰은 많이 줄일 수 있었다.

왜 MCP와 Agentic Workflow를 같이 봐야 했나

기존의 AI 도구는 대부분 대화창 안에 복사해 넣은 정보만 다룬다. 그래서 실제 업무에서는 늘 같은 병목이 생긴다. 티켓 내용을 복사해 붙여넣고, 문서 링크를 또 붙여넣고, 관련 코드 조각도 다시 붙여넣어야 한다. AI가 아무리 똑똑해도, 필요한 정보를 직접 읽지 못하면 계속 수동 컨텍스트 공급자가 필요하다.

MCP는 그 부분을 줄여준다. AI 에이전트가 외부 도구와 데이터 소스에 직접 접근할 수 있게 해주기 때문이다. 여기에 Agentic Workflow를 결합하면, 사용자가 “이 티켓을 보고 구현 계획을 세워줘”라고 말했을 때 에이전트가 스스로 필요한 정보원을 따라가며 작업을 진행할 수 있다.

물론 MCP만이 유일한 방법은 아니다. 실제로 일부 기능은 MCP 없이도 기존 API를 직접 호출하는 방식으로 충분히 활용할 수 있었다. API 명세를 기준으로 AI에게 별도 스킬이나 호출 규칙을 만들어주면, 에이전트가 그 API를 직접 호출해 작업을 수행하게 할 수도 있다. 다만 MCP를 사용하면 이런 외부 기능을 에이전트 입장에서 tools 형태로 더 일관되게 정의하고 사용할 수 있다는 장점이 있었다. 즉 핵심은 “반드시 MCP여야 한다”보다, AI가 필요한 정보원과 작업 도구를 얼마나 자연스럽게 다룰 수 있게 만드느냐에 더 가까웠다.

내가 기대했던 것도 바로 이것이었다.

사람이 컨텍스트를 복사해서 붙여넣는 시간을 줄일 것
초기 조사와 초안 작성을 자동화할 것
엔지니어는 구현 판단과 검증에 더 집중할 것

짧은 검증 주기에서 어떻게 나눴나

이번 POC는 비교적 짧은 검증 주기 안에서 세 단계로 나눠 진행했다.

단계	목표
Discovery	문제 정의, 데이터 소스 확인, 가능한 자동화 범위 파악
Prototype	실제로 작동하는 흐름 구현
Validation	현실 시나리오로 검증하고 한계 정리

이 구조는 하나의 예시다. 핵심은 꼭 6주여야 한다는 게 아니라, 짧은 주기 안에서 조사 → 작동하는 흐름 → 현실 검증을 분리해보는 데 있다. AI가 개입하는 프로젝트는 쉽게 “이것도 붙여보자, 저것도 자동화하자”로 커지기 쉽다. 처음부터 짧은 검증 주기를 전제로 두어야 정말 필요한 흐름이 무엇인지 더 선명하게 보였다.

AI가 직접 접근하게 한 도구들

이번 POC에서 AI 에이전트가 연결된 주요 정보원은 네 가지가 중심이었고, 여기에 사내 플랫폼과 문서 도구도 일부 함께 붙어 있었다.

Jira: 요구사항과 작업 배경 확인
Confluence: 설계 문서와 운영 문서 확인
GitHub: 기존 구현과 변경 이력 탐색
Splunk: 실제 동작 로그와 장애 흔적 확인

실제로는 이 네 가지 외에도 사내 플랫폼 문서, 운영 가이드, 팀 위키처럼 업무 맥락을 설명하는 자료가 더 있었다. 기술 구현만 보는 것이 아니라, 조직이 어떤 흐름으로 일하는지까지 같이 읽을 수 있어야 에이전트의 초안 품질이 눈에 띄게 좋아졌다.

이 네 가지가 연결되자, 초기 조사 단계가 달라졌다. 예전에는 사람이 먼저 티켓을 읽고 관련 문서를 찾은 뒤 “여기까지 읽었으니 이제 정리해줘”라고 AI에게 넘겼다. 이번에는 반대로 AI가 먼저 자료를 훑고, 사람이 그 결과를 검토하는 방식으로 바뀌었다.

물론 더 많은 도구를 한꺼번에 붙여보고 싶은 욕심은 있었다. 하지만 실제 조직 환경에서는 MCP를 새로 붙이는 일 자체가 자유롭지 않았다. 새로운 도구를 연결하려면 법무팀과 보안팀 심사를 통과해야 했고, 그 과정은 생각보다 오래 걸렸다. 그래서 이번 POC에서는 현재 허용된 정보원만 먼저 연결해 테스트했고, 나머지 도구들은 계속 심사와 검토를 진행하는 상태였다.

특히 도움이 됐던 건 이런 흐름이었다.

Jira 티켓에서 문제 정의를 읽는다.
관련 Confluence 문서를 찾는다.
GitHub에서 유사 구현과 최근 PR을 확인한다.
Splunk에서 실제 로그 패턴을 본다.
그 결과를 바탕으로 구현 계획 초안을 만든다.

이 과정 자체는 인간 엔지니어도 할 수 있다. 다만 여러 도구를 오가며 맥락을 유지하는 비용이 크다. 에이전트가 이 순서를 먼저 수행하면, 사람은 더 빨리 “이 초안이 맞는가”를 판단할 수 있었다.

실제로 빨라진 부분

가장 빨라진 것은 코드 작성 자체보다도, 작업 시작 전의 준비 과정이었다.

예를 들면 이런 작업들이다.

요구사항 요약 초안 만들기
관련 문서와 이전 구현 찾기
비슷한 PR이나 코드 패턴 정리하기
테스트 케이스 초안 만들기
ADR이나 PR 설명 문서 초안 쓰기

특히 문서화는 체감 차이가 컸다. 예전에는 구현 후에 “이제 설명 문서도 써야지” 하며 맥락을 다시 끌어올려야 했다. 이번에는 구현과 병행해서 AI가 초안을 계속 만들어주도록 했고, 사람은 그 문장을 다듬고 빠진 맥락을 보충하는 역할에 집중했다.

무엇보다 더 많은 컨텍스트를 직접 읽게 되니, 코드 작성이나 제안도 훨씬 더 사실에 가까워졌다. 단순한 코드 생성 모델처럼 일반적인 패턴만 내놓는 것이 아니라, 실제 티켓 맥락과 기존 코드, 운영 문서, 도메인 배경을 함께 참고한 상태에서 제안을 하게 되니 결과물의 완성도도 눈에 띄게 올라갔다.

코드 생성은 어디까지 유용했나

코드 생성도 분명 도움은 됐다. 반복적인 보일러플레이트, 테스트 코드 뼈대, 익숙한 패턴의 CRUD 흐름에서는 꽤 생산적이었다. 특히 테스트 코드는 생각보다 잘 만들었다. “이 함수 테스트를 먼저 만들어줘”, “이 PR 설명을 바탕으로 테스트 시나리오를 뽑아줘” 같은 요청은 잘 먹혔고, 사람이 놓치기 쉬운 기본 케이스를 빠르게 채워주는 데 유용했다.

하지만 여기서 중요한 한계도 분명했다.

문법적으로 맞는 코드와 도메인적으로 맞는 코드는 다르다.
내부 API나 최근 변경 사항은 AI가 놓치기 쉽다.
비즈니스 규칙이 복잡할수록 사람이 직접 검증해야 한다.

즉 AI가 만든 코드는 “바로 배포 가능한 정답”이 아니라, 검토 가능한 초안에 더 가까웠다. 이 점을 받아들이고 나니 기대치도 더 현실적으로 조정됐다.

사람이 끝까지 맡아야 했던 영역

이번 POC를 하며 가장 확실히 느낀 건, 사람이 해야 하는 일은 여전히 많다는 점이었다. 다만 그 일이 이전보다 더 “판단 중심”이 되었다.

끝까지 사람이 맡아야 했던 건 주로 이런 것들이었다.

요구사항 해석의 우선순위 결정
비즈니스 규칙의 참/거짓 판단
AI가 가져온 문맥 중 무엇을 믿을지 선택
실제 운영 환경과 맞는지 검증
결과물을 조직 안에서 설명 가능한 형태로 정리

특히 “이 구현이 맞는가”보다 “이 구현이 우리 도메인에서 정말 필요한가”는 AI보다 사람이 훨씬 잘했다. POC 단계에서는 이 차이가 더 크게 드러났다.

한계도 분명했다

AI-assisted POC가 만능은 아니었다. 이번 실험에서 드러난 한계는 비교적 선명했다.

최신 내부 변경 사항은 맥락이 부족하면 놓치기 쉽다.
잘못된 문서를 먼저 읽으면 그 방향으로 자신 있게 틀릴 수 있다.
프롬프트가 모호하면 결과물도 쉽게 모호해진다.
정보원 접근이 가능해도, 어떤 순서로 읽을지는 여전히 설계가 필요하다.
컨텍스트가 길어질수록 요약 과정에서 중요한 디테일이 빠지거나 왜곡될 수 있다.
여러 문서를 짧게 요약해 이어 붙이면 맥락은 빨라지지만, 원문이 가진 뉘앙스와 예외 조건은 쉽게 사라진다.
결국 휴먼 체크가 없으면 그럴듯하지만 잘못된 방향으로 결과가 굳어질 수 있다.

이 때문에 POC에서 중요한 건 “AI를 얼마나 많이 썼는가”보다 “어떤 작업을 AI에게 맡기고 어떤 판단은 사람에게 남겼는가”였다.

이번 POC에서 얻은 기준

이번 실험을 지나며, AI가 특히 잘하는 일과 사람이 계속 맡아야 하는 일을 조금 더 명확히 나눌 수 있게 됐다.

AI에게 맡기기 좋은 일:

여러 도구를 오가며 자료를 먼저 수집하기
초안, 체크리스트, 테스트 뼈대 만들기
반복적인 코드 패턴 생성하기
문서 구조화와 요약 초안 만들기

사람이 맡아야 하는 일:

요구사항의 진짜 의미 해석하기
도메인 규칙 검증하기
구현 우선순위와 스코프 결정하기
최종 결과물 책임지기

이 기준이 생기고 나서야 AI-assisted POC가 조금 덜 과장되고, 조금 더 실용적인 방식으로 보이기 시작했다.

마무리

이번 POC의 핵심 성과는 AI가 개발을 대체했다는 데 있지 않았다. 오히려 반대에 가까웠다. 사람이 해야 할 일을 더 명확하게 드러내고, 그 앞단의 반복적인 조사와 초안 작성 시간을 줄여줬다는 점이 더 중요했다.

MCP와 Agentic Workflow는 “AI가 더 똑똑해졌다”는 이야기보다, “AI가 더 많은 컨텍스트에 접근할 수 있게 됐다”는 쪽에 가깝다. 그리고 그 변화는 POC처럼 빠른 검증이 중요한 작업에서 꽤 큰 차이를 만든다.

지금 다시 보면 이 실험의 진짜 가치는 자동화의 범위를 확인한 데 있다. AI는 좋은 조수였지만, 좋은 조수를 잘 쓰는 방법 역시 결국 사람이 설계해야 했다.