Shipping at Inference-Speed

Shipping at Inference-Speed

Poooling·2026년 1월 6일·2

AI 에이전트 시대, 코드를 직접 타이핑하는 것은 이제 회사에 손해입니다. '코더'가 아닌 '아키텍트'로서 추론 속도로 배포하는 새로운 개발 패러다임을 받아들여야 합니다.

제목

"코드 한 줄 한 줄 읽고 계신가요? 죄송하지만 당신의 커리어는 3년 뒤에 끝납니다."

솔직히 고백하자면, 불과 반년 전까지만 해도 저는 AI가 짜준 코드를 100% 신뢰하지 않았습니다. 스타트업에서 산전수전 겪으며 야생형 개발자로 살아온 8년, 제 손끝에서 나오는 '장인 정신'이 곧 실력이라 믿었거든요. 대기업으로 이직한 후 체계적인 코드 리뷰 문화를 접하면서 그 믿음은 더 공고해지는 듯했습니다. 하지만 최근 몇 달간, 그 믿음이 얼마나 안일했는지 뼈저리게 느끼고 있습니다.

우리는 지금 '추론 속도(Inference-Speed)'로 배포하는 시대에 살고 있습니다.

예전에는 코드를 작성하는 시간이 병목이었습니다. 하지만 이제 병목은 오직 '모델의 추론 시간'과 제가 '깊게 생각하는 시간' 뿐입니다. 지난 5월까지만 해도 프롬프트 한 번에 돌아가는 코드가 나오면 "오, 신기하네" 정도였죠. 지금은 그게 당연한 '기본값(Default)'이 되었습니다.

제가 겪은 가장 충격적인 변화는 '코드를 읽는 방식'이 달라졌다는 점입니다. 예전엔 PR(Pull Request)이 올라오면 변수명 하나, 로직 한 줄을 현미경 보듯 뜯어봤습니다. 그런데 GPT-5 수준의 모델들이 등장하고, 에이전트(Agent)들이 고도화되면서 저는 더 이상 코드를 정독하지 않게 되었습니다. 스트림(Stream)으로 쏟아지는 코드를 훑어보며 전체적인 구조와 컴포넌트 위치만 파악하면 그걸로 충분하더군요.

마치 수작업으로 도자기를 빚던 장인에서, 거대 자동화 공장의 공장장으로 보직이 변경된 기분이었습니다. 처음엔 "내가 이 코드를 완벽히 장악하지 못했다"는 불안감이 엄습했습니다. 하지만 에이전트가 제가 며칠 걸려 짤 리팩토링을 단 몇 분 만에, 그것도 의존성까지 완벽하게 맞춰 해결해 올 때 인정할 수밖에 없었습니다. 제가 직접 타이핑하는 건 이제 '회사에 손해'라는 사실을요.

실제로 저는 최근 'Oracle'이라는 CLI 도구를 만들었습니다. 에이전트가 작업하다 막히면 멈추지 않고, 스스로 문서를 뒤지고 필요한 정보를 쿼리해서 루프를 닫게 만드는 도구입니다. 예전 같으면 제가 중간에 개입해서 구글링하고 문서를 떠먹여 줬겠지만, 이제는 모델에게 "Oracle한테 물어봐"라고만 하면 됩니다.

심지어 제가 거의 다룰 줄 모르는 언어인 Zig로, 제 사이드 프로젝트인 터미널 멀티플렉서(VibeTunnel)의 핵심 모듈을 포팅하는 데 걸린 시간은 단 5시간이었습니다. 두어 문장의 프롬프트를 던졌을 뿐인데, 에이전트는 수차례 압축(compaction) 과정을 거쳐 완벽하게 작동하는 결과물을 내놓았습니다. 제가 직접 했다면 문법 공부하고 디버깅하느라 몇 주는 족히 걸렸을 일입니다.

물론, 여전히 두려움은 있습니다. Xcode 없이 iOS 앱을 빌드하고, Go와 TypeScript를 자유자재로 오가는 에이전트를 보며 "나의 전문성은 어디에 있는가?"라는 질문을 매일 던집니다. 하지만 역설적으로, 기술의 장벽이 무너지면서 우리가 집중해야 할 곳은 명확해졌습니다.

이제 우리는 '코더(Coder)'가 아니라 '아키텍트(Architect)'이자 '디렉터(Director)'가 되어야 합니다. 어떤 언어를 쓰느냐, 어떤 문법을 아느냐는 중요하지 않습니다. 중요한 건 "무엇을 만들 것인가", 그리고 "이 시스템을 어떻게 연결할 것인가"를 결정하는 능력입니다.

후배님들, 그리고 동료 개발자 여러분. 단순히 문법을 익히고 라이브러리 사용법을 외우는 데 시간을 쏟지 마십시오. 대신, 에이전트라는 유능한 부하 직원을 어떻게 부릴지, 그들에게 어떤 맥락(Context)을 주어야 최고의 결과물을 낼 수 있을지 고민하십시오.

변화는 이미 시작된 게 아니라, 이미 우리를 앞질러 가고 있습니다. 흐름에 올라타지 않으면, 우리는 결국 그저 '옛날 방식'을 고집하는, 유지보수 비용이 비싼 개발자로 남게 될 것입니다. 함께 살아남읍시다. 그리고 더 빠르게, 더 많이 만들어냅시다.

Poooling
PooolingAuthor

Poooling님의 다른 글

댓글 0

첫 번째 댓글을 남겨보세요!