시리즈 · AI는 어떻게 개발자들의 벽을 허물었나
2회 · AI는 어떻게 개발자들의 벽을 허물었나 2 - 공개 코드와 코드 중심 인터페이스의 힘
웹·게임·임베디드의 개발 장벽과 AI 도구가 이를 재구성하는 방식을 살펴보는 3부 연재의 두 번째 글이다. 첫 글이 장벽의 정체를 봤다면, 이번 글은 그 장벽을 AI가 넘을 때 무엇을 읽을 수 있고 무엇을 읽지 못하는지 살핀다. 결론부터 말하면 공개 코드 생태계는 AI에게 압도적으로 유리한 지형이다. 반대로 코드·변경 이력·사용 맥락이 닫혀 있거나 UI 조작 속에만 남는 플랫폼은 AI가 이해할 수 있는 표면적을 줄인다.
이 논지가 중요한 이유는 단순히 “AI가 코드를 많이 봤다”가 아니기 때문이다. 개발은 함수 한 개를 생성하는 일이 아니라, 요구사항이 코드·설정·에셋·테스트·장애 기록으로 변하는 과정을 읽는 일이다. Git과 GitHub가 상징하는 공개 협업 문화는 이 흔적을 소스, commit, issue, PR, 리뷰와 라이선스로 남긴다. Java 자체를 곧바로 오픈소스의 동의어로 부를 수는 없지만, 오늘날 OpenJDK처럼 구현과 생태계가 공개된 언어·도구는 같은 장점을 얻는다.
공개 저장소 코드가 코드 모델 학습에 실제 쓰인 사례도 명확하다. BigCode의 The Stack은 358개 언어의 허용적 라이선스 소스 코드를 모은 6.4TB 데이터셋이며, GitHub 기반 코드 모델 연구·학습을 위해 공개됐다. BigCode는 StarCoder 계열이 GitHub 데이터로 학습됐다고도 밝힌다. 다만 이것이 모든 상용 모델이 모든 GitHub 저장소를 학습했다는 증거는 아니다. OpenAI의 모델 개발 설명처럼 일부 제공자는 데이터의 큰 범주만 공개한다. 정확한 모델별 저장소 목록을 모른다고 해서 공개 코드 문화가 AI에 유리하다는 구조적 사실까지 흐려지는 것은 아니다.
공개 코드가 중요한 이유는 분명하다. 코드는 실행 가능한 예제이고, 문서는 이름을 설명하며, 이슈는 실패 조건을 남기고, PR과 리뷰는 왜 설계가 바뀌었는지 기록한다. 이 연결 자체가 개발 지식의 인프라다. AI는 모델 내부의 기억만으로 일하는 것이 아니라 검색, 저장소 읽기, 테스트, 린터, 셸, 문서와 결합할 때 더 좋은 작업 단위를 만든다.
공개 코드는 ‘학습 재료’ 이전에 검증 가능한 맥락이다
대규모 언어 모델은 대규모 텍스트와 코드에서 패턴을 학습해 다음 토큰을 예측하는 방식으로 코드를 생성한다. 공개 코드의 강점은 양만이 아니다. 같은 문제의 여러 구현, 실패한 이슈, 수정 diff, 테스트와 문서가 서로 연결돼 있어 AI가 생성한 답을 다시 검증할 발판이 생긴다. 그러나 좋은 답을 얻는 과정은 단순 생성이 아니다. 문제를 재현하고, API 계약을 찾고, 의존성을 확인하고, 테스트를 통과시키고, 라이선스와 보안 영향을 검토해야 한다.
예를 들어 낯선 저장소의 장애를 만났을 때 AI에게 필요한 것은 한 줄의 에러 메시지보다 다음과 같은 관측 가능성이다.
# 수정 전에는 프로젝트의 상태와 재현 가능한 검사부터 읽는다.
git status --short
rg -n "timeout|retry|ConnectionError" src test
npm test -- --runInBand이 세 명령은 해답을 만들지 않는다. 대신 변경 이력, 관련 코드, 현재 실패를 묶어 준다. AI가 여기에 README, 이슈, CI 로그, 타입 정의까지 함께 읽을 수 있다면 “이 함수가 있을 법하다”는 추측보다 훨씬 좁은 가설을 만들 수 있다. GitHub Code Quality처럼 코드 품질의 근거를 PR과 검사 결과에 남기는 흐름이 중요한 이유도 같다.
GitHub도 공개 코드 참조 기능에서 제안 코드 주변을 공개 저장소 인덱스와 비교해 출처를 표시하는 방식을 설명한다. GitHub Copilot code referencing은 이를 학습 데이터셋 공개가 아닌 제안 검증과 출처 확인 기능으로 다룬다. 개발자는 AI가 낸 코드를 그대로 붙이는 사람이 아니라, 그 코드가 어느 계약·라이선스·테스트를 통과했는지 확인하는 사람이어야 한다.
결국 AI가 학습할때 그저 지식을 학습하는 것을 넘어 맥락과 추론이라는 고급 단계의 학습을 위해서는 각 코드가 발전해 나가는 맥락을 가진 Git같은 공용코드 정보가 대단히 고급스러운 정보라는 뜻이 된다.
코드만으로 드러나는 제품일수록 AI가 관찰하기 쉽다
이제 UI 기반 플랫폼 이야기가 왜 필요한지 드러난다. AI는 텍스트 저장소와 도구 로그에 남은 흔적을 가장 쉽게 읽는다. 그런데 Unity·Unreal처럼 사용자가 에디터 UI로 오브젝트를 만들고, Prefab을 묶고, 에셋과 이벤트를 연결하면 개발 맥락의 일부가 코드 바깥으로 빠져나간다. 이 말은 UI가 열등하다는 뜻도, AI가 에디터를 전혀 학습할 수 없다는 뜻도 아니다. 다만 모델이 주로 코드·문서·diff를 통해 학습하거나 현재 프로젝트를 읽을 때, UI 조작과 시각적 판단만으로 남은 정보는 누락될 가능성이 더 크다는 뜻이다.
결국 이 글의 기준은 ‘모든 개발의 내용이 사람과 도구에게 얼마나 열려 있는가’다. 에디터의 씬 데이터, 에셋 참조, 자동화 API, 빌드 로그, 스크린샷 비교가 코드와 함께 남으면 UI 기반 플랫폼도 AI가 이해할 맥락을 더 많이 제공한다. 반대로 핵심 결정이 닫힌 바이너리, 사내 전용 도구, 재현할 수 없는 클릭 순서에만 있으면 AI뿐 아니라 새로 들어온 인간 개발자에게도 비싼 장벽이 된다.
웹의 HTML, CSS, JavaScript는 좋은 예다. 버튼의 구조, 레이아웃 규칙, 상태 변화가 텍스트로 표현되므로 화면을 렌더링하지 않고도 많은 의도를 추론할 수 있다. Swing이나 JavaFX처럼 버튼 생성·레이아웃·이벤트 바인딩을 코드로 묶었던 UI 방식도 같은 계열의 장점이 있었다. 물론 ‘텍스트로 표현된다’와 ‘예쁘고 접근성 있게 동작한다’는 같은 말이 아니다. 실제 브라우저, 화면 크기, 키보드 탐색, 색 대비는 여전히 실행해서 검증해야 한다.
// 선언형 UI는 의도와 상태 전이를 코드 리뷰·테스트의 대상으로 만든다.
export function SaveButton({ pending, onSave }: {
pending: boolean; onSave(): Promise<void>;
}) {
return <button disabled={pending} onClick={() => void onSave()}>
{pending ? 'Saving…' : 'Save'}
</button>;
}
게임 엔진의 에디터 중심 흐름을 ‘AI가 못 하는 영역’이라고 부르는 것은 꽤 성급한 결론이긴 하지만 더 정확한 결론은 에셋·시각적 결과·에디터 상태·실행 궤적을 함께 제공할수록 AI의 지원 품질도 높아질 가능성이 크다는 것이다. 모든 플랫폼이 코드 전용으로 바뀐다고 예언할 수는 없다. 다만 앞으로의 플랫폼 경쟁은 어떤 방식으로든 AI에게 전체 개발 맥락을 전달하는 방법, 즉 코드·선언형 데이터·UI 상태·도구 호출을 연결하는 방법을 고민하게 될 가능성이 높다.
AOSP와 MCP는 두 가지 다른 종류의 ‘학습테마’이다
안드로이드는 이 논점을 잘 보여 준다. AOSP 아키텍처 개요는 Android Open Source Project가 공개되고 수정 가능한 안드로이드 소스이며, 프레임워크·HAL·네이티브 라이브러리·커널 계층을 설명한다고 밝힌다. 개발자는 문서와 소스를 통해 OS 구조, API, 빌드와 테스트의 출발점을 얻을 수 있다. 이는 모바일 시스템을 이해하려는 사람과 AI 모두에게 매우 풍부한 공개 맥락이다.
하지만 AOSP가 곧 모든 안드로이드 폰의 완전한 설계도는 아니다. 실제 단말의 vendor 이미지, SoC·그래픽·무선 드라이버, OEM 확장, 통신사 조건은 기기마다 다르고 일부는 공개되거나 그대로 이식되지 않는다. AOSP의 VNDK 개요는 vendor가 성능·기능을 위해 라이브러리를 확장할 수 있음을 설명한다. 공개 기반이 넓다는 말은 기기별 검증이 필요 없다는 말이 아니다.
MCP는 또 다른 종류의 열림이다. Model Context Protocol은 AI 애플리케이션이 파일, 데이터베이스, 검색, 워크플로 같은 외부 시스템과 연결하는 오픈 표준이다. 즉, 모델이 더 많은 것을 ‘기억’하게 하는 기술이라기보다 필요한 자료와 도구를 명시적인 연결로 제공하는 방식이다.
{
"server": "project-docs",
"capabilities": ["read_repository", "search_docs"],
"policy": "read-only"
}이런 도구 계약은 예시일 뿐 실제 MCP 설정 형식은 구현체마다 다를 수 있다. MCP의 본질은 레거시와 AI 사이의 연결성이다. 오래된 서버의 API·데이터 모델·운영 명령·권한 경계를 도구로 노출하면, AI는 기능을 호출할 수 있을 뿐 아니라 그 기능이 무엇을 하고 어떤 맥락에서 위험한지도 더 잘 읽을 수 있다. 다시 말해 MCP는 AI가 필요한 데이터를 ‘몰래 수집’하는 장치가 아니라, 제공자가 기능과 맥락을 제한된 계약으로 제공해 탐색 장벽을 낮추는 장치다.
CLI 에이전트는 AI와 레거시의 연결 방향성을 보여준다
Google의 Gemini CLI는 터미널에서 동작하는 오픈소스 AI 에이전트로 파일 작업, 셸 명령, 웹 가져오기, MCP 지원을 제시한다. 이것을 단순한 개발자 도구로만 보면 절반만 본다. API+MCP가 레거시 서버의 기능과 맥락을 AI에 전달하는 창구라면, CLI+MCP는 데스크톱 프로그램·로컬 파일·명령줄 환경을 AI가 이해하고 조작하는 창구가 된다. 현재도 수많은 사업자들이 AI 모델을 자신들의 데스크탑 서비스에 CLI+MCP를 이용해 파일·명령·검색·도구 호출과 연결한 개발 경험을 제공하려는 이유다. Gemini Managed Agents와 원격 MCP의 논의도 이 연장선에 있다.
Microsoft의 폐쇄성은 어떻게 평가해야 하나
필자는 과거 Microsoft의 플랫폼 전략이 컴퓨팅 생태계에 큰 상호운용 비용을 남겼다고 본다. Office와 Windows가 발전시킨 생산성·개발 도구의 가치를 부정하는 말은 아니다. 하지만 Internet Explorer와 Windows 중심 기술이 웹 개발자를 특정 플랫폼에 묶었던 역사도 지워서는 안 된다. 미국 법무부가 공개한 United States v. Microsoft 법원의 사실인정은 Microsoft가 Windows 전용 브라우징 기술에 의존하도록 ISV를 유도했고, 경쟁 브라우저가 노출한 API에 개발자가 의존하지 못하게 하려 했다고 기록한다. 이는 과거의 독점적이고 폐쇠적인 MS의 문화를 증명한다.
이 비판은 ‘MSDN이 외부에 비공개였다’는 오해에서도 되풀이 된다. MSDN과 오늘의 Microsoft Learn은 읽을 수 있는 공개 문서였다. 다만 그 문서는 자연스럽게 Microsoft 플랫폼의 API·도구·배포 방식 중심으로 구성된 벤더 문서다. 공개 저장소의 코드·토론·변경 이력처럼 외부가 자유롭게 재사용하고 독립 구현을 검증할 수 있는 지식 인프라와는 성격이 다르다는 것이 그 비판의 중심이다. Microsoft가 이후 Linux·오픈소스와의 관계를 크게 바꿨다는 사실도 함께 봐야 한다. “Microsoft Loves Linux”는 2016 Ignite 세션과 현재 WSL 문서에서 실제로 확인된다. 개발자들은 이제 MS가 오픈소스에 더 호의적이고 참여적이길 기대한다.
AI 관점에서 중요한 평가는 더 단순하다. 오래된 사유 API, 폐쇄 포맷, 벤더 전용 도구, 라이선스 제약이 강할수록 학습·검색·재현·독립 검증에 쓸 수 있는 공개 맥락은 줄어든다. 그렇다고 사유 플랫폼이 무가치한 것은 아니다. 기업은 보안, 개인정보, 품질 관리, 고객 데이터 보호를 위해 일부 맥락을 닫아야 한다. 문제는 닫힌 영역을 열어야 할 때도 표준·문서·도구 계약을 제공하지 않아 사용자가 다른 플랫폼과 연결할 길까지 잃게 만드는 경우다.
C, C++, C#에서 AI가 확실히 못 짠다는 가설은 벤치마크가 필요하다
그렇다면 폐쇠적인 MS 언어플랫폼들은 다른 공개적인 언더들에비해 AI의 실력이 떨어지지 않을까 하는 의문이 자연스레 생긴다. 이 가설은 현장의 체감으로는 충분히 제기할 수 있지만, 현재 공개 근거만으로 ‘AI가 C/C++/C#을 Java·Node.js·JavaScript·Python보다 확실히 못 짠다’고 단정할 수는 없다. HumanEval-X는 C++, Java, JavaScript, Go를 포함한 다국어 평가를 만들었고, MultiPL-E는 Python 기반 코딩 벤치마크를 18개 언어로 옮겨 같은 문제를 비교할 수 있게 한다. 이런 도구가 필요한 이유 자체가 모델·버전·프롬프트·라이브러리·과제에 따라 언어별 성적이 달라지기 때문이다.
더 설득력 있는 주장은 이렇다. Windows 전용 C++·COM·드라이버, 오래된 C# 프레임워크처럼 공개 예제와 최신 테스트 환경이 적고 벤더·버전 종속이 큰 과제에서는 AI의 실패율이 높아질 가능성이 있다. 그러나 이를 사실로 만들려면 실제 업무와 닮은 과제를 같은 조건으로 측정해야 한다.
# 같은 요구사항을 언어별로 구현한 뒤, 생성·빌드·테스트를 분리해 기록한다.
for lang in python javascript java cpp csharp; do
./run-task-suite --language "$lang" --tasks ./tasks --samples 20
done| 측정 항목 | 확인할 질문 |
|---|---|
| 빌드 성공률 | 생성물이 해당 도구체인에서 바로 컴파일되는가 |
| 테스트 통과율 | 같은 기능 계약을 충족하는가 |
| 수정 횟수 | 사람의 보정이 몇 번 필요했는가 |
| 의존성 오류 | 오래된 패키지·SDK·OS 종속을 잘못 가정했는가 |
| 보안·성능 검사 | 메모리 안전, 권한, 병목을 별도로 통과하는가 |
뭐. 결국 이 가설을 검증하기에는 자료가 부족하다. 몇몇의 감에 의존한 경험으로 결론을 내기에는 너무 성급하다. 현대에 비해 열악하고 폐쇠적이었던 과거의 코드 결과물들이 현대 플랫폼과 코드들에 비해 품질이 당연히 더 떨어질 수 밖에 없지 않겠는가? 문제는 이 또한 가설이다.
결국 AI의 소화력은 마법이 아니라 관측 가능성의 결과다. 코드, 문서, 예제, 테스트, 이슈, 도구 API가 연결될수록 낯선 분야의 첫 지도가 빨리 그려진다. 학습 코드들도 중요하지만 코드의 맥락 지도가 훨씬 중요할 수도 있다는 뜻이다. 다음 글에서는 이 지도가 Windows 입력, Bluetooth, Linux 보드, 센서처럼 운영체제와 물리 세계가 만나는 곳에서 어떻게 실험으로 이어지는지 살핀다.
댓글 없음:
댓글 쓰기