2026년 MCP와 AI-Assisted Coding에 대한 나의 예측
Source: Dev.to
번역을 진행하려면 전체 텍스트를 제공해 주시겠어요?
코드 블록, URL 및 마크다운 형식은 그대로 유지하면서 본문만 한국어로 번역해 드리겠습니다.
Introduction
나는 AI에 대한 예측이 종종 금방 구식이 된다는 것을 충분히 인식하고 이 글을 씁니다.
6개월 안에 AI가 엔지니어를 대체할 것이라고 자신 있게 선언하고, 아무 일도 일어나지 않으면 조용히 일정을 미루는 CEO들처럼 들리고 싶지 않습니다. 대신, 이것은 개인적인 사고 실험입니다.
나는 아직 AI‑보조 코딩을 하는 것이 금기시되던 시절부터 실험해 왔습니다. 2021년 GitHub에서 일하면서 GitHub Copilot을 통해 개발자들에게 잘 작성된 프롬프트의 가치를 이해시키는 일을 했습니다. 나는 ChatGPT, Claude 및 기타 많은 도구들을 일찍이 사용한 사용자였으며, 프롬프트가 하나의 학문 분야가 되기 훨씬 전이었습니다.
오늘날 나는 goose(http://block.github.io/goose)의 Developer Advocate이며, 이 프로젝트는 **Model Context Protocol (MCP)**의 레퍼런스 구현이자 최초의 MCP 클라이언트 중 하나입니다. 나는 매일 여러 MCP 서버를 사용해 실제 문제를 해결합니다.
이 모든 경험 덕분에 앞으로 일어날 가능성에 대해 어느 정도 감을 잡을 수 있었습니다.
그래서 2026년에 대한 몇 가지 예측을 해보았습니다. 주로 내 비전 능력을 갈고닦기 위한 목적입니다. 이 예측 중 어떤 것이 실현될까요? 1년 뒤에 수정하게 될까요? 확인해 봅시다.
이것은 개인적인 의견이며, 내가 근무하는 회사나 내가 참여하고 있는 프로젝트를 대변하는 것이 아닙니다.
Prediction 1: AI 코드 리뷰가 해결됩니다
2026년 말까지, 우리는 AI 기반 코드 리뷰를 완전히 정복하게 될 것이라고 믿습니다.
현재 소프트웨어 개발—특히 오픈 소스—에서 가장 큰 병목 현상 중 하나는 리뷰 용량입니다. 사람들은 AI 덕분에 그 어느 때보다 빠르게 코드를 생성하지만, 그 속도는 하류 단계에 압력을 가합니다. 유지보수자, 기술 리드, 그리고 엔지니어링 매니저는 이제 더 많은 풀 리퀘스트, 더 많은 diff, 그리고 검증해야 할 영역이 늘어난 상황에 직면해 있습니다.
우리는 이미 AI 기반 코드 리뷰 도구들을 보고 있지만, 아직 완벽히 맞아떨어지는 제품은 없습니다. 이들 도구는 종종 잡음이 많고, 지나치게 경직되었으며, 실제 개발자 워크플로와 단절된 느낌을 주어 채택이 고르지 못합니다.
최근 Aiden Bai가 AI 코드 리뷰 도구인 CodeRabbit이 어떻게 개선될 수 있는지에 대해 사려 깊고 건설적인 피드백을 공개했습니다. CodeRabbit의 대응을 둘러싼 논란을 넘어, 그의 트윗이 받은 관심은 중요한 신호를 보여줍니다: 개발자들은 더 나은 솔루션을 적극적으로 기대하고 있습니다.
2026년까지는 기존 제품이 의미 있게 수준을 높이거나, 새로운 기업이 이 분야에 진입해 문제를 제대로 해결할 것으로 기대합니다. 이는 해당 영역에서 가장 시급한 문제 중 하나이며, 업계가 이를 우선적으로 해결할 것이라고 생각합니다.
AI 코드 리뷰 분야의 최신 동향을 놓치고 싶지 않다면 Nnenna Ndukwe 를 팔로우하는 것을 추천합니다.
예측 2: MCP 앱이 기본이 된다
나는 MCP Apps가 사람들이 AI 에이전트와 상호작용하는 핵심적인 방식이 될 것이라고 생각한다.
MCP Apps는 **MCP‑UI**의 후속 제품으로, 에이전트가 텍스트만으로 응답할 필요 없이 호스트 환경 안에 직접 인터랙티브 인터페이스를 렌더링할 수 있음을 처음 보여주었다—예를 들어 임베디드 웹 UI, 버튼, 토글, 선택지 등이다. 사용자는 설명 대신 상호작용을 통해 의도를 표현한다.
이 패턴이 확산되면서 인터랙티브 인터페이스가 프로토콜 자체에서 일류 지원을 받아야 한다는 것이 명확해졌다. MCP Apps는 그 흐름을 이어받아 현재 MCP 표준에 통합되고 있다.
이는 개발자 편의성을 넘어 중요한 의미를 가진다. 수년간 기업들은 임베디드 챗봇으로 사용자를 앱 안에 머무르게 하여 “스틱iness”를 높이고 매출을 올리려 했지만, 그 접근 방식은 완전히 성공하지 못했다. 한편, 사용자 행동은 변했다: 이제 사람들은 엔지니어가 아니더라도 웹사이트를 탐색하기보다 직접 ChatGPT 같은 AI 도구에 질문을 한다.
MCP Apps는 모델을 뒤집는다. 사용자를 당신의 앱으로 끌어들이는 것이 아니라, 당신의 앱이 사용자의 AI 환경 안에서 만나게 된다.
우리는 이미 초기 채택 사례를 보고 있다:
- OpenAI는 ChatGPT Apps SDK를 통해 이 방향으로 나아가고 있다.
- goose는 초기부터 MCP‑UI를 도입했으며(YouTube short), 곧 완전한 MCP Apps 지원을 출시할 예정이다.
- 다른 플랫폼들도 유사한 움직임을 보이고 있다.
MCP Apps에 대해 더 알고 싶다면 이 블로그 포스트를 확인해 보라.
Source: …
Prediction 3: Agents Become Portable Across Platforms
나는 에이전트가 사용자가 일하는 어디서든 따라다닐 것이라고 생각한다.
오늘날 MCP 서버는 에이전트를 도구와 시스템에 연결할 수 있게 해 주며, 나는 이를 많이 활용한다. 하지만 여전히 마찰이 있다. 많은 사용자가 특정 에이전트에 애착을 갖고 지속적인 재구성 없이도 다양한 환경에서 사용할 수 있기를 원한다.
이때 Agent Client Protocol (ACP) 가 흥미롭게 다가온다. ACP는 에이전트가 특정 플러그인이나 확장에 강하게 결합되지 않고, 프로토콜을 지원하는 어떤 편집기나 환경에서도 실행될 수 있게 해 준다.
우리는 goose와 함께 이 문제를 직접 겪었다. VS Code 확장 프로그램을 유지보수하는 것이 어려웠다: goose는 계속 진화했지만, 확장 프로그램은 뒤처졌고, 사용자는 오류에 부딪혔다. ACP가 그 역학을 바꾸었다. 에이전트를 플러그인에 강하게 결합하는 대신, 편집기가 클라이언트가 된다.
- Zed Industries 가 이 모델을 도입했다. Zed 편집기 안에서 goose를 사용해 보니 경험이 눈에 띄게 부드러웠다.
- JetBrains 의 편집기들도 이 프로토콜을 채택했다.
ACP는 MCP보다 덜 주목받는 편이다. 어느 정도는 눈에 띄지 않기 때문이고, 약어가 다른 에이전트 관련 프로토콜과 겹치기 때문이기도 하다. 그럼에도 그 영향력은 실제적이다.
앞으로의 전망: 이것이 편집기에만 국한될 것이라고는 생각하지 않는다. 시간이 지나면서 에이전트의 이식성이 디자인 도구, 브라우저, 기타 플랫폼까지 확장될 수 있다. 나는 goose, Codex, 혹은 Claude Code를 Figma와 같은 도구에 직접 가져와 매번 통합을 다시 만들 필요 없이 사용할 수 있을 것이라고 상상한다. 이 부분은 다소 추측적이지만, 방향성은 충분히 타당해 보인다.
예측 4: DIY 에이전트 구성은 한계에 부딪힌다
이것은 말하기에 더 위험하게 느껴진다
(원본 텍스트가 여기서 끊겼으며, 예측이 완전하지 않습니다.)
AI 에이전트 구성에 대한 성찰
“We eventually move away from heavy context engineering and excessive configuration.”
현재 우리는 모델의 한계를 보완하기 위해 여러 층의 구조를 추가하고 있습니다:
- Rules files
- Memory files
- Sub‑agents
- Reusable skills
- System‑prompt overrides
- Toggles and switches
이 모든 요소가 에이전트가 보다 신뢰성 있게 동작하도록 돕고, 특히 대규모 코드베이스, 레거시 시스템, 고영향 코드 변경의 경우에는 필수적입니다.
왜 기대되는가
엔지니어 입장에서 내 설정을 구성하는 과정은 참여감이 있습니다. 에이전트가 어떻게 사고하고 응답할지를 직접 shaping 하는 것이 즐겁습니다. AI를 블랙박스로 취급하기보다 행동을 미세 조정하는 데서 만족감을 얻습니다.
반대 입장
매주 새로운 “베스트 프랙티스”가 등장합니다. 또 다른 규칙. 또 다른 설정이 사용자에게 채택 압박을 줍니다. 어느 순간, 그 오버헤드가 이점을 초과할 수 있습니다. 빌드를 하는 대신, 빌드 행위 자체를 설정하는 데 더 많은 시간을 쓰게 되는 것이죠.
이미 개발자들이 탈피하고 있는 모습을 보고 있습니다. 초기 경험이 좋지 않아 AI를 거부하는 사람도 있고, 과정이 지치게 느껴져 거부하는 사람도 있습니다. 그들은 단지 코드를 쓰고 싶어 합니다.
쿠버네티스와의 유사점
쿠버네티스가 널리 채택되면서 엄청난 힘을 제공했지만, 동시에 개발자들을 관리하기엔 너무 복잡한 인프라에 노출시켰습니다. 해결책은 모든 개발자를 쿠버네티스 전문가로 만들려는 것이 아니라, 플랫폼 팀, DevOps 역할, 그리고 그 복잡성을 흡수하는 추상화를 도입하는 것이었습니다.
앞으로 예상되는 두 가지 경로
- Tooling이 개선되어 대부분의 설정이 배경으로 사라지는 시점이 온다.
- 기업이 AI 활성화 역할을 공식화한다.
- 이미 초기 형태가 보이고 있습니다: 내부 AI 챔피언 및 활성화 그룹(내 매니저 Angie Jones가 이끌고 있음) 등이 팀이 에이전트를 안전하고 효과적으로 사용할 수 있도록 돕고 있습니다.
나의 바람
균형을 원합니다. 설정과 깊이를 즐기지만, 모든 레포가 시작조차 복잡한 설정을 요구한다면 생산성은 확장되지 않을 것이라고 생각합니다.
2026년 예측
- 마찰 감소: 구성은 대부분 자동화되거나 직관적인 UI/UX 뒤에 숨겨집니다.
- AI 활성화 팀: 전담 역할(AI 챔피언, 플랫폼 엔지니어)이 대규모 조직에서 표준이 됩니다.
- 표준화된 베스트 프랙티스 번들: 재사용 가능하고 검증된 구성을 최소한의 노력으로 레포에 바로 넣을 수 있습니다.
- 채택 증가: “피로” 요인이 감소함에 따라 포기하는 개발자가 줄어듭니다.
“1년 후에 다시 검토해서 어떤 것이 지속되는지 확인합시다.”
당신의 예측은 무엇인가요?
- 구성 가능성과 사용성 사이의 균형이 어떻게 진화할 것이라고 보십니까?
- 위에 제시된 두 가지 경로에 동의하십니까, 아니면 다른 방향을 상상하십니까?
여러분의 의견을 기다리겠습니다!