Written by jay
on 

LLM을 정식 개발인프라로 편입시키려면

2026년 첫 회사 올핸즈 미팅에서 발표할 기회가 있어서 최근에 가지고 있는 AI를 이용한 자동코딩에 대한 생각을 공유했다. LLM을 단순한 코드 생산 도구가 아니라 프로덕트 개발 인프라의 한 부분으로 도입해야 한다는 메시지였다.

Andrej Karpathy가 남긴 트윗 중 인상 깊었던 말이 있다. 2025년 12월을 기점으로 자신의 코딩 비율이 매뉴얼 코딩 8 : 자동 코딩 2 에서 매뉴얼 2 : 자동 8 로 뒤집혔다는 이야기였다. 20년 이상 프로그래밍을 한 사람도 자존심을 조금 상하면서까지 자동 코딩을 이미 대세로 받아들이고 있다는 말이다. 나 역시 이제는 Claude Code 없이 코딩을 하는 것을 굉장히 피곤해하는 상황까지 왔다.

부끄럽게도 우리 회사는 Claude Code를 이용하여 코드를 많이 “생산”해내지만 그 생산해낸 코드를 만들어내는 방식은 전사적으로 표준화되지 않았다. 따라서 팀원 개개인마다 사용 역량의 차이뿐 아니라 그때그때 random seed에 따라 코드의 스타일과 동작이 달라지고 있다. 아직은 사람이 리뷰를 하고 또 팀원 개개인이 나름의 스킬, 에이전트 등을 활용하고 있어서 겉으로는 큰 파편화가 드러나지 않는다. 하지만 이런 시스템의 한계로 인해 아직은 LLM 자체가 코드를 내뱉는 머신 정도의 지위로 활용되고 있다.

LLM의 비결정론적인 특성이 예측 가능하지 않은 코드를 생산하기 때문에 많은 사람들이 skill이니 agent니 하는 것들을 만들어서 활용하고 있는 상황이다. 근데 생각해보면 기존 프로그래머도 비결정론적이다. 소프트웨어가 공학의 영역에 완전히 들어가지 못하는 이유 중 하나가 프로그래머의 작업방식이 제멋대로고 강제할 수 없기 때문이라는 의견도 있다. 그래서 여러가지 코딩 스탠다드나 방법론들을 배우고 팀에서 권장하는 것을 보면 LLM에게만 결정론적 동작을 기대하는 것은 과한 요구일 수 있다.

사람 프로그래머의 비결정성은 오랫동안 코딩 컨벤션, 리뷰, 프로세스로 흡수해 왔다. LLM 역시 같은 방식으로 다뤄야 한다면, 개인의 요령이 아니라 시스템 차원의 표준화가 필요해진다.

1년 전쯤 LLM으로 코딩을 할 수 있겠다는 사실을 보고 나도 vibe coding을 몇번 해봤다가 vanilla 상태의 환경은 너무 간단한 수정조차 못하고 문제를 못찾고 헤매고 있는 것을 경험 한 후에는 한동안 자동코딩을 등한시했다. 그 기저에는 여전히 “나는 코드를 쓸 수 있고, 멍청한 모델이 뽑아내는 것 보다 내가 하는게 더 빠르다”는 생각이 강했다. 하지만 Karpathy의 말처럼 어느 시점을 지나며 이 생각은 깨졌다. 모델은 멍청하지 않고, 나보다 훨씬 빠르다.

지나가다 본 글인데 이제는 LLM을 이용해 자동코딩을 하는 것에 대한 부정적인 견해를 부정적으로 보고 멀리해야하는 것 아닌가는 의견도 있다. AI hype에 열광하는 것도 문제지만 반대로 AI가 쓸모없다고 지나치게 부정적이면 안된다는 것이고 정말 공감하는 바이다. 이제는 LLM을 나보다 코딩을 잘하는 존재(굉장히 쓰기 꺼려지는 단어다)로 인식하고 이를 기존 프로덕트 개발 파이프라인에 “진지하게” 편입시키는 방식을 고민해보려 한다.

팀에서 LLM을 결정론적이고 예측 가능한 팀원으로 취급할 수 있게 하려면 결국엔 agent, skill들의 전사 표준화가 필요해질것 같고 이 부분에 대한 탐색을 꽤 진지하게 시간을 들여야 할 것이다. 그래서 LLM을 단순히 코드 생성 기계가 아니라 실제 프로덕트 개발 파이프라인에서 인지부하를 줄일 수 있는 역할들을 믿고 맡기게끔 적용해야한다.

현재의 “AI”에 대한 사람들의 관심이나 시장의 기대는 상당한 버블이 끼어있는건 맞다. 하지만 AI, 정확히는 LLM을 이용한 자동코딩은 전혀 hype이 아니라 실재하는 practice로 자리잡은지가 한참 되었고 아마도 de facto standard로 자리잡을 것이다. 그 과정에서 LLM을 진짜 팀원처럼 활용하려면 표준화된 agent와 skill을 갖추는 것이 필요하다. agent와 skill도 너무나 많은 것들이 쏟아지고 있어서 팀에서 잘 자체개발하거나 옥석가리기가 필수적이다.

앞으로의 AX 과제는 LLM을 더 잘 쓰는 사람이 되는 것이 아니라, LLM이 안정적으로 일할 수 있는 팀의 구조를 만드는 것일 것이다.