코드 작성에서 검토로: AI 시대에 Go가 다시 주목받는 이유

AI 코딩 도구가 수백 줄의 코드를 몇 초 만에 쏟아내면서, 소프트웨어 개발의 무게중심이 '작성'에서 '검토'로 옮겨가고 있다. 구글 개발자 블로그가 게시한 이 글은 바로 이 전환기에 Go 언어가 유독 잘 들어맞는다고 주장한다. 핵심 논지는 단순하다. 사람이 코드를 얼마나 빨리 타이핑하느냐는 더 이상 생산성의 척도가 아니며, 이제 중요한 것은 이미 생성된 코드를 읽고, 검증하고, 오래 유지보수하는 일이라는 것이다.

프로그래밍이 아니라 소프트웨어 엔지니어링

글은 프로그래밍과 소프트웨어 엔지니어링을 구분한다. 프로그래밍이 문제를 풀기 위해 코드를 짜고 실행하는 행위라면, 소프트웨어 엔지니어링은 여러 사람이 협업해 시간이 흐르며 진화하는 시스템을 설계·구현하는 일이다. 20여 년 전 롭 파이크, 로버트 그리스머, 켄 톰프슨이 Go를 만든 동기가 바로 이 팀 단위 개발이었다는 점을 저자는 강조한다. 다른 언어들이 표현 방식을 늘리며 기능을 확장하는 동안, Go는 의도적으로 단순함을 택해 팀 전체가 같은 방식으로 코드를 구조화하고 포맷하고 테스트하도록 했다는 설명이다.

AI가 팀원으로 합류하면서 이 설계 철학의 값어치가 달라졌다는 것이 글의 관점이다. AI와 사람은 의외로 비슷한 것을 필요로 한다. 외부 검증 없이 AI가 코드를 반복적으로 리팩터링하면 첫 시도는 95% 맞더라도 이후 패스마다 오류가 누적되고 컨텍스트 윈도가 오염되어 정확도는 떨어지고 토큰 비용은 오른다. 사람이 손으로 반복 수정할 때 겪는 열화와 크게 다르지 않다.

언어가 아니라 플랫폼

Go의 차별점으로 저자가 첫손에 꼽는 것은 Go가 단일 언어가 아니라 플랫폼이라는 사실이다. 표준 툴체인만으로 포매터, 테스트 프레임워크, 의존성 관리, 보안 도구를 기본 제공하고, 방대한 표준 라이브러리가 복잡한 외부 프레임워크의 필요성을 줄인다. 대다수 개발자가 동일한 핵심 도구를 쓰기 때문에 생태계 전체가 균일하게 움직이고, 그 결과 프로젝트 간 코드가 비슷해져 사람과 AI 모두 더 빨리 이해할 수 있다. 저자는 이 구조적 획일성이 LLM 학습 데이터의 표준화로도 이어진다고 본다.

읽기 우선 철학도 같은 맥락에 놓인다. 개발자는 코드를 타이핑하는 시간보다 읽는 시간이 훨씬 길다는 인식에서 Go는 영리함보다 단순함을 택했다. 한 가지 논리를 여러 방식으로 표현할 수 있는 언어에서 AI는 뒤죽박죽 뒤섞인 스타일의 코드를 만들어내고, 리뷰어는 의도를 해독하느라 지친다. gofmt로 단일 포맷을 강제하고 복잡한 추상화를 의도적으로 제한함으로써, 시니어가 짰든 주니어가 짰든 LLM이 짰든 코드가 똑같아 보이게 만든다. 문법이 예측 가능하면 환각으로 만들어진 API 호출이나 논리 결함, 보안 취약점을 더 빨리 잡아낼 수 있다는 것이다.

컴파일러라는 안전망과 공급망

신뢰성 측면에서 저자는 정적 타입 시스템을 자동화된 안전망으로 제시한다. 파이썬 같은 동적 타입 언어에서는 환각성 오류가 기본 문법 검사를 통과해 운영 환경에서야 터지지만, Go에서는 존재하지 않는 메서드를 쓰거나 잘못된 타입을 넘기면 컴파일 자체가 실패한다. 게다가 Go의 컴파일 속도가 Java, C#, Rust보다 빠르기 때문에, 에이전트가 스스로 타입·문법 오류를 고치는 자기 교정 루프를 효율적으로 돌릴 수 있다는 점을 강조한다.

공급망 보안도 비중 있게 다룬다. LLM은 학습 데이터에 기대어 오래되거나 관리되지 않는, 심지어 악성인 서드파티 의존성을 제안하곤 하는데, Go의 풍부한 표준 라이브러리가 외부 의존성 대신 공식 패키지로 자연스럽게 유도한다. 외부 모듈이 필요할 때는 체크섬 데이터베이스와 모듈 미러가 모든 모듈의 무결성을 기록해 중간자 공격과 조용한 변조를 막고, govulncheck가 취약한 심벌을 호출하는 코드를 짚어 잡음이 적고 실행 가능한 경고를 준다. 여기에 기본 테스트 프레임워크와 네이티브 퍼즈 테스트가 지속적 검증의 표준 샌드박스 역할을 한다.

실무자가 새겨둘 지점

유지보수 관점에서 저자가 내세우는 카드는 호환성 약속이다. Go 1.0용으로 15년 전에 쓴 코드가 최신 툴체인에서 수정 없이 컴파일되며, Go 2.0은 없을 것이라는 약속 아래 코드는 깨지지 않는다. 단일 정적 바이너리와 크로스 컴파일은 스크립트를 실행하고 마이크로서비스를 띄우는 AI 에이전트에게 특히 유리하고, gopls와 모더나이저 개념이 도입된 새 go fix는 대규모 코드베이스의 현대화를 자동화한다.

다만 이 글이 구글 Go 팀 쪽에서 낸 옹호성 게시물이라는 점은 감안해서 읽을 필요가 있다. 95% 정확도 같은 수치의 출처나 측정 방식은 제시되지 않고, 다른 언어와의 정량 비교도 서술적 주장에 머문다. 그럼에도 'AI가 만든 코드를 사람이 검증하는 병목'이라는 문제 정의 자체는 언어 선택과 무관하게 유효하다. 강한 타입, 통일된 포맷, 재현 가능한 빌드, 공급망 무결성 도구가 AI 협업 환경에서 왜 값어치가 커지는지는 Go를 쓰지 않는 팀에게도 곱씹어볼 만한 기준이다.