AI 코딩 논쟁, 결론보다 중요한 실전 점검 5가지

반응형

AI 개발 도구를 둘러싼 ‘RAG는 끝났다’, ‘Skills가 MCP를 대체했다’ 같은 단정적인 문장이 빠르게 퍼지고 있습니다. GitHub Blog는 2026년 9월 18일 글에서 이런 주장을 실제 개발 업무의 조건으로 다시 나눠 보자고 제안했습니다.

핵심은 유행하는 결론을 고르는 것이 아니라, 코드 위험도와 필요한 맥락에 맞춰 사람의 판단을 남기는 것입니다.

3줄 핵심 요약

• AI가 만든 코드는 위험도에 따라 검토 깊이를 달리해야 합니다.
• RAG·MCP·Skills는 경쟁 관계가 아니라 서로 다른 역할을 나눠 가질 수 있습니다.
• 도구 선택보다 직접 시험하고 결과를 기록하는 개발 습관이 중요합니다.

AI가 만든 코드, 전부 같은 강도로 볼 필요는 없다

GitHub는 생성된 코드의 책임이 여전히 개발자에게 있다고 설명합니다. 다만 운영 인증 로직을 바꾸는 작업과 간단한 CSS 실험은 실패 비용이 다릅니다.

변경 범위를 먼저 읽고 의존성과 예외 상황을 파악한 뒤, 오류 처리·권한·데이터 접근·성능·접근성·테스트처럼 위험이 큰 부분을 우선 검토하는 방식이 현실적입니다. 기준은 ‘모든 줄을 똑같이 읽었는가’가 아니라 결과를 설명하고 책임질 수 있는가입니다.

RAG, MCP, Skills는 역할이 다르다

원문은 MCP를 도구와 데이터에 연결하는 표준 인터페이스로, Skills를 팀의 절차와 전문 지식을 묶은 맥락으로 설명합니다. RAG는 문서·지원 이력·코드베이스처럼 모델 밖에 있는 관련 정보를 찾아 답변을 뒷받침합니다.

따라서 MCP가 연결을 제공하고 Skills가 사용 방법을 설명하며 RAG가 필요한 근거를 찾는 조합도 가능합니다. 하나의 기술이 다른 기술을 ‘죽였다’고 보기보다 어떤 문제를 해결하는지 구분해야 합니다.

채용과 생산성의 기준도 도구 이름보다 판단력이다

GitHub는 모든 개발자가 같은 AI 도구와 워크플로를 써야 한다고 말하지 않습니다. 중요한 질문은 언제 AI를 쓰고 언제 직접 작업하는지, 생성 코드의 품질과 보안을 어떻게 확인하는지, 도구가 바뀌면 프로세스를 어떻게 조정하는지 설명할 수 있는가입니다.

AI를 전적으로 의존하거나 무조건 거부하는 태도보다, 신뢰 범위와 사람이 개입하는 지점을 명확히 말하는 편이 실무에 가깝습니다.

오늘 바로 적용할 5분 점검표

첫째, 변경이 운영·인증·결제·권한 영역인지 표시합니다. 둘째, 생성 전에 기존 구현과 의존성을 읽습니다.

셋째, 생성 후 오류 처리와 권한 검사를 먼저 확인합니다. 넷째, 필요한 경우 MCP·Skills·RAG 중 부족한 맥락을 채울 수단을 선택합니다.

다섯째, 작은 테스트를 실행하고 결과와 남은 위험을 기록합니다. 이 절차는 특정 제품을 추천하는 것이 아니라 도구가 바뀌어도 재사용할 수 있는 검토 습관입니다.

사용자와 업계에 미치는 영향

개발자는 새로운 AI 용어의 승패를 따라가기보다 자신의 코드베이스에서 위험이 어디에 있는지 설명하는 능력을 키울 수 있습니다. 팀은 AI 사용 여부만 묻기보다 검토 기준, 테스트 결과, 사람이 승인하는 경계를 문서화하는 편이 유지보수성과 온보딩에 도움이 됩니다.

확인할 점

이 글은 GitHub Blog의 공식 글을 요약·해석한 내용입니다. GitHub의 관점과 사례가 포함된 글이므로 일반적인 개발 원칙으로 확장할 때는 조직의 보안 정책과 규제 요건을 별도로 확인해야 합니다.

특정 도구의 지원 범위나 기능은 이후 변경될 수 있습니다.

출처

• GitHub Blog

728x90