지루한 언어가 AI 코딩에 강한 이유
LLM 시대의 언어 선택은 표현력 경쟁이 아니라 검색 가능성, 관습, 오류 표면의 문제다. 지루한 생태계는 모델에게 더 적은 선택지를 주기 때문에 더 안정적인 결과를 만든다.
AI 뉴스를 놓치지 마세요
매주 핵심 AI 소식을 이메일로 받아보세요.
왜 지루함이 장점이 됐나
Jacob Young은 Use boring languages with LLMs에서 LLM 코딩 에이전트가 Go나 Rails처럼 관습이 강하고 선택지가 적은 생태계에서 더 안정적으로 작동한다고 주장한다. 글의 공개 메타데이터는 2026년 4월 20일 게시로 표시되며, 설명은 "Go처럼 응집된 생태계가 JavaScript나 Python처럼 파편화된 생태계보다 코딩 에이전트에 유리한 이유"를 다룬다.
이 주장은 단순한 언어 취향 논쟁이 아니다. LLM은 훈련 데이터에서 본 패턴을 바탕으로 다음 행동을 고른다. 같은 웹 서버를 만들 때 Go 표준 라이브러리, Rails 규약, Django 구조처럼 대표 경로가 뚜렷하면 모델이 흔들릴 여지가 줄어든다. 반대로 JavaScript 백엔드는 프레임워크, 번들러, 런타임, 패키지 매니저, 폴더 구조가 너무 많다. AgentHub의 Tailwind를 떠나는 글이 AI 코딩에 중요한 이유와 같은 결론이다. 구조가 모델의 품질을 만든다.
LLM은 자유보다 관습을 좋아한다
사람 개발자에게 선택지는 창의성일 수 있다. 모델에게 선택지는 확률 분산이다. Go는 gofmt와 표준 도구 체계가 강하고, Rails는 Convention over Configuration을 오래 밀어 왔다. 이런 생태계에서는 파일 이름, 테스트 위치, 에러 처리 방식, 라우팅 규칙이 예측 가능하다. 에이전트가 저장소를 읽고 수정할 때 "이 프로젝트만의 이상한 관습"을 추론하는 비용이 줄어든다.
반대로 C와 C++은 훈련 데이터에 좋은 예제와 위험한 예제가 함께 많다. 메모리 관리, 빌드 시스템, 플랫폼 차이가 크다. Python은 쉬워 보이지만 패키징, 가상환경, 타입 힌트, 데이터 과학 스택이 섞이면 에이전트가 실행 환경부터 헤맨다. JavaScript는 빠른 생태계 변화가 장점이지만, 오래된 답변과 최신 관습이 충돌하기 쉽다.
| 생태계 특성 | 사람에게 주는 의미 | LLM에게 주는 의미 | 결과 |
|---|---|---|---|
| 강한 포매터 | 취향 논쟁 감소 | 출력 형식 예측 가능 | 리뷰 노이즈 감소 |
| 표준 라이브러리 | 외부 의존성 감소 | 선택지 축소 | 보안과 유지보수 안정 |
| 단일 프레임워크 관습 | 빠른 온보딩 | 파일 위치 추론 쉬움 | 에이전트 탐색 비용 감소 |
| 파편화된 도구 | 유연성 증가 | 오래된 패턴 혼입 | 실행 실패와 재시도 증가 |
언어 선택은 비용 선택이다
LLM 코딩에서 비용은 토큰만이 아니다. 실패한 패치, 잘못 고른 라이브러리, 실행되지 않는 테스트, 리뷰어가 되돌리는 시간도 비용이다. Constraint Decay, 코딩 에이전트의 구조 망각 문제는 에이전트가 긴 백엔드 작업에서 기존 제약을 잊는 문제를 다뤘다. 언어와 프레임워크의 관습이 강할수록 이런 망각을 견제하는 외부 구조가 생긴다.
이는 새 프로젝트를 시작하는 팀에게 직접적인 신호다. "AI가 코드를 잘 짜니까 어떤 스택이든 괜찮다"는 판단은 위험하다. 오히려 AI를 많이 쓸수록 지루한 스택이 유리할 수 있다. OCaml이 우주에서 증명한 안전한 시스템 언어에서 본 것처럼 타입과 형식 검증이 강한 언어도 에이전트에게 명확한 경계를 준다. 좋은 타입 오류는 모델에게 다음 수정 방향을 알려주는 피드백이다.
한국 개발팀의 스택 결정
한국의 많은 팀은 채용시장, 외주 생태계, 레거시 연동 때문에 Java, Spring, Python, JavaScript를 쓴다. 이 스택들이 나쁘다는 뜻은 아니다. 다만 AI 코딩 에이전트를 적극 쓸 계획이라면 프로젝트 템플릿, 린터, 테스트 명령, 폴더 규약을 더 강하게 고정해야 한다. Google의 Java Style Guide나 TypeScript ESLint 같은 도구가 단순 스타일 문서가 아니라 에이전트 제어면이 된다.
실무 팁은 간단하다. 새 서비스를 만들 때는 "모델이 검색하면 가장 많이 본 구조"에 가깝게 시작한다. 커스텀 아키텍처는 진짜 필요할 때만 만든다. 에이전트 프롬프트에는 언어보다 저장소 규칙, 금지 의존성, 테스트 명령을 먼저 넣는다. 그리고 생성된 코드가 관습을 벗어났을 때 리뷰어가 직접 고치기보다 규칙으로 되돌아오게 해야 한다.
자주 묻는 질문
Q1: 지루한 언어만 써야 하나요?
A: 아니다. 다만 AI 코딩을 많이 쓸수록 관습과 도구가 강한 생태계가 운영상 유리해진다.
Q2: JavaScript나 Python은 AI 코딩에 부적합한가요?
A: 부적합하진 않다. 대신 프레임워크, 패키지 매니저, 포매터, 타입 규칙을 명확히 고정해야 한다.
Q3: Go가 항상 정답인가요?
A: 아니다. Go는 선택지가 적어 에이전트에 유리한 면이 있지만, 도메인 요구와 팀 역량이 먼저다.
Q4: 기존 레거시 프로젝트는 어떻게 하나요?
A: 전체 재작성보다 규칙 문서, 테스트 스크립트, 금지 패턴, 예시 PR을 정리해 에이전트 입력으로 제공하는 편이 현실적이다.
Q5: 개발자에게 주는 가장 큰 교훈은 무엇인가요?
A: 모델 성능만 기다리지 말고 코드베이스를 예측 가능하게 만들어야 한다. 예측 가능한 구조가 에이전트 성능을 끌어올린다.
관련 토픽 더 보기
📰 원본 출처
jry.io이 기사는 AI 기술을 활용하여 작성되었으며, 원본 뉴스 소스를 기반으로 분석 및 해설을 추가한 콘텐츠입니다. 정확한 정보 전달을 위해 노력하고 있으나, 원본 기사를 함께 확인하시기를 권장합니다.