인공지능

AI 기반 소프트웨어 개발에 관한 RAG, MCP, Skills 논의가 알려 주는 것은 무엇인가?

GitHub Blog의 게시글은 AI를 활용한 소프트웨어 개발에 관한 다섯 가지 흔한 가정을 분석하며, 생성된 코드 검토, 정보 검색, MCP, Skills가 서로 경쟁하는 대체재가 아니라 서로 다른 역할을 수행하는 도구임을 강조한다. 결론적으로 인간의 판단과 코드 유지보수성이 여전히 핵심 요소로 남는다.

2026-09-18
4 분 읽기
1 조회수
فريق تحرير certi.news
AI 기반 소프트웨어 개발에 관한 RAG, MCP, Skills 논의가 알려 주는 것은 무엇인가?

GitHub Blog의 한 게시글은 소프트웨어 개발에서 AI를 사용하는 것과 관련된 다섯 가지 널리 퍼진 가정을 논의한다. 그중에는 생성된 코드는 읽을 필요가 없다는 주장, RAG가 끝났다는 주장, Skills가 Model Context Protocol(MCP)을 없앴다는 주장이 포함된다. 저자는 이러한 문구의 가치는 축약된 형태 그대로의 진위가 아니라, 실제 업무에 적용할 때 그 조건과 한계를 세분화하는 데 있다고 본다.

코드에 대한 책임은 모델로 이전되지 않는다

이 글이 제시하는 기본 원칙은 개발자가 결과를 설명하고 그에 대한 책임을 질 수 있는 지점까지 코드를 검토해야 한다는 것이다. 그렇다고 모든 줄을 똑같은 깊이로 검사해야 한다는 뜻은 아니다. 운영 중인 인증 시스템의 변경은 간단한 CSS 실험과는 다른 방식으로 검토할 가치가 있다.

검토는 에이전트가 코드를 작성하기 전부터 시작될 수 있다. 현재 구현을 이해하고, 의존성과 경계 사례를 파악하며, 계획을 세우는 과정이 그 예다. 다른 경우에는 생성된 코드의 오류 처리, 권한, 데이터 접근, 성능, 사용성, 테스트를 직접 면밀히 검토해야 한다. 이 글에 따르면 AI는 노력의 위치를 바꾸지만, 작업 자체를 없애지는 않는다.

가장 중요한 역량은 올바른 판단이다

이 게시글은 기업이 AI를 전혀 사용하지 않는 사람을 채용하지 않을 것이라는 생각을 거부한다. 그러나 점점 더 많은 업무 팀이 지원자에게 이러한 도구를 어떻게 사용하는지 묻고 있다는 점은 인정한다. 이 관점에서 가장 강한 신호는 도구 자체에 대한 열정이 아니라, 개발자가 언제 도구를 사용하고 언제 수작업으로 처리하는지, 도구의 결과물을 어떻게 검토하는지, 속도와 품질, 보안, 유지보수성 사이의 균형을 어떻게 맞추는지를 설명할 수 있는 능력이다.

AI를 피하는 태도는 AI 제품을 만들거나 AI에 크게 의존하는 회사에서는 장애물이 될 수 있다. 그러나 AI에 전적으로 의존하는 것이 더 나은 해결책은 아니다. 필요한 것은 인간을 과정에 계속 참여시키고, 개발자가 무엇을 신뢰하며 무엇을 신뢰하지 않는지 명확히 설명할 수 있도록 하는 것이다.

MCP, Skills, RAG는 서로 보완적인 역할을 한다

이 글은 세 도구를 구분해 제시한다. MCP는 에이전트가 도구와 데이터에 접근하고 이를 호출할 수 있는 표준화된 방법을 제공하는 반면, Skills는 팀의 업무 방식, 프로젝트 수정 규칙 또는 사용되는 관례에 관한 정리된 지식을 제공한다. Skills는 대개 Markdown 형식으로 작성되므로 사람이 읽을 수 있다는 점도 그 유용성의 일부다.

RAG, 즉 검색 증강 생성은 문서, 지원 기록, 제품 세부 정보, 내부 지식, 코드베이스의 맥락 등 모델의 학습 데이터 외부에 있는 관련 정보를 시스템으로 가져온다. 우수한 검색은 모델이 답변에 더 가까운 맥락에서 작업을 시작하도록 돕고, 검색 범위와 불완전한 응답을 제시할 가능성을 줄인다.

따라서 저자는 Skills가 MCP를 없앴다거나 RAG가 끝났다고 보지 않는다. 에이전트는 MCP를 사용해 도구에 접근하고, Skill을 따라 프로젝트에 특화된 지침을 적용하며, 검색을 활용해 이를 뒷받침하는 맥락을 가져올 수 있다. 이러한 구성 요소들 사이의 대립은 이들이 하나의 업무 흐름 안에서 통합될 수 있는 방식을 간과한다.

새로운 시험대에 오른 유지보수성

이 게시글은 특정 코드베이스에 대해 모델을 학습시켜야 한다는 필요성이 반드시 코드가 나쁘다는 뜻이라는 생각도 논의한다. 맞춤형 학습에는 정당한 이유가 있지만, 모델이 코드베이스를 이해하지 못하는 상황은 새로운 동료 역시 마주하게 될 문제를 드러낼 수 있다.

명확한 구조, 일관된 명명, 읽기 쉬운 테스트, 유용한 추상화, 최신 문서는 에이전트와 사람 모두가 코드를 더 쉽게 이해하도록 만든다. 여기서 편집상의 해석은 AI 도구가 팀을 소프트웨어 엔지니어링 관행에서 면제해 주지 않는다는 것이다. 오히려 유지보수성의 결함을 더 뚜렷하게 드러낼 수 있다.

논의에서 실험으로

이 글은 모든 의견을 반대 의견으로 대체하기보다 의견을 실제로 시험해 보라고 권하며 마무리한다. 사례로는 기여자가 프로젝트를 개선해 pollen이라는 크레딧을 얻을 수 있는 Pollinations AI 프로젝트와, 새를 듣고 마이크, Raspberry Pi, 3D 프린팅 부품, 생성된 이미지를 사용해 새들의 방문을 변화하는 패널로 바꾸는 전자 잉크 화면을 기록한 Avian Visitors 프로젝트를 소개한다.

이 프로젝트들이 AI에 관한 모든 논쟁을 해결하는 것은 아니지만, 증거를 만들어 내고 상충 관계를 드러낸다. 한편 이 자료의 기본적인 한계는 특정 업무 흐름의 우월성을 입증하는 비교 측정 결과가 아니라 일반적인 지침 체계와 사례를 제시한다는 점이다. 따라서 그 권고는 최종 규칙이 아니라 실무를 시험하기 위한 출발점으로 다뤄야 한다.

뉴스 출처
GitHub Blog
원문 보기 ↗
ف
작성자

فريق تحرير certi.news

같은 카테고리

추천 기사

모든 뉴스 보기