모델보다 잘하는 게 하나는 있어야 한다
핵심 요약
코드를 쓰는 비용이 한 달에 백 달러가 된 지금, 엔지니어의 가치는 “대체 인력 대비 얼마나 더 하는가”로 다시 계산돼요.
- 어려운 분야로 도망가는 건 답이 아니에요: 모델이 못 하는 일의 목록은 계속 짧아지고 있어요. 지금 어렵다는 이유로 고른 영역은 오래 버티지 못해요.
- 모델은 몰라서, 또 겁이 많아서 실수해요: 이미 있는 모듈을 두고 처음부터 다시 짜고, 있으나 마나 한 검사를 삼중으로 넣어요. 시스템을 아는 사람만 이걸 잡아내요.
- 글쓰기는 의외로 오래 갈 기술이에요: 채점할 수가 없으니 학습시키기도 어렵고, 연구소들은 그동안 글솜씨 대신 능력에만 매달려 왔거든요.
• • •
대체 인력 대비 가치
2025년에 저는 소프트웨어 엔지니어를 “대체 인력 대비 가치”T1로 평가해야 한다고 썼어요. 회사에 얼마를 벌어다 줬느냐가 아니라, 같은 자리에 평범한 엔지니어가 앉았을 때와 비교해서 얼마나 더 벌어다 줬느냐로요. 저는 엔지니어가 이력서에 “X달러를 번 제품을 만들었다”고 쓰는 걸 볼 때마다 어쩐지 좀 우스웠어요. 사실 그냥 자기 앞에 떨어진 지라 티켓을 처리한 것뿐인데 말이죠.
지금은 대체 인력 대비 가치가 훨씬 더 중요해졌어요. 2010년대엔 대체 인력 수준의 엔지니어도 괜찮았어요. 승진시킬 정도는 아니어도 월급을 줄 만은 했죠. 코드를 쓰는 데 드는 고정 비용이 높았으니까요. 그런데 지금은 그 비용이 한 달에 백 달러예요. 지금 당신이 하는 일 중에, 그 자리에 GPT-5.6 Sol이나 Claude Opus 5를 앉혀 놨다면 못 했을 일은 뭔가요? 회사가 왜 당신에게 백 배, 천 배의 비용을 더 치러야 하죠?
무서운 질문이에요. 하지만 LLM은 사실 코드를 못 쓴다느니 다 사기라느니 하면서 눈을 감아 봐야, 손해 보는 건 자기 자신이에요. LLM이 쓴 코드가 워낙 형편없어서 그걸 쓴 회사들이 내년쯤 줄줄이 무너질 거라는 기대도 마찬가지고요. 2027년 어느 아침에 눈을 떠 보니 AI 열풍은 끝나 있고 다들 손으로 코드를 짜고 있더라, 그런 일은 일어나지 않아요. 중장기적으로 모델보다 자기가 더 잘할 수 있는 게 뭔지, 진지하게 생각해 볼 때예요.
모델을 앞서는 건 움직이는 과녁을 맞히는 일이에요. 2026년 초만 해도 “큰 코드베이스에 제대로 동작하는 변경을 넣기”는 모델이 못 하는 일 쪽에 있었지만, 지금은 아니에요. 그래서 저는 더 깊은 전문성이 필요한 “빡센 엔지니어링” 영역으로 물러나는 전략이 통할 거라고 보지 않아요. 단기적으로는 몰라도, 영원히는 아니에요. LLM이 리만 가설의 더 나은 하한을 찾아낼 수 있다면, 머지않아1 견고한 고성능 커널 드라이버든 GPU 셰이더든 뭐든 짜낼 수 있게 될 거예요.
그보다는 모델이 그동안 좀처럼 나아지지 않은 일, 그리고 원리상 나아지기 어려운 일을 보는 편이 쓸모 있다고 생각해요. 가장 좋은 예가 두 가지 있어요.
- 코드베이스에 대한 깊은 친숙함
- 기술적 커뮤니케이션
• • •
깊은 친숙함
프런티어 LLM은 무엇을 틀릴까요? 어떤 종류의 코딩 실수를 할까요? 코딩 에이전트가 대놓고 환각을 일으키거나 오프바이원 같은 단순 논리 오류를 내는 걸 본 지가 꽤 됐어요. 요즘 모델이 하는 실수는 무지에서 오는 쪽에 가까워요.
- 가져다 쓰면 되는 모듈이 코드베이스에 이미 있는데, 그걸 모르고 같은 로직을 처음부터 다시 짜요.
- 이 기능은 원래 시스템 X에 들어간다는 걸 몰라서, 엉뚱한 시스템을 고쳐 놔요.
- 회사에서 굳어진 관행과 어긋나는 코딩 스타일로 써 놔요.
또 어떤 실수는 과민함에서 와요.
- 설정에서 한 번 정해지고 두 번 다시 바뀌지 않는 값인데, 이론상 틀릴 수도 있다며 검사를 삼중으로 넣어요.
- 10밀리초 지난 데이터도 절대 안 된다고 넘겨짚고는, 늘 최신 상태를 지키려고 복잡하고 쓸데없는 시스템을 설계해요.
- 그냥 에러를 내고 죽는 게 맞는 코드(가령 CLI 도구나 알아서 재시작되는 k8s 서비스)에 폴백이며 “우아한” 성능 저하를 붙여요.
이 실수들의 공통점은 뭘까요? 시스템에 대한 맥락이 전혀 없는 똑똑한 엔지니어가 할 법한 실수예요. 문제를 풀 만큼 유능하긴 한데, “그래요, 코드 삼천 줄 더 안 짜도 된다면 이 정도 위험은 감수합시다”라고 자신 있게 말할 만큼 오래 이곳에 있지는 않았던 거죠. 누군가 연속 학습이나 정말로 거대한 컨텍스트 윈도라는 숙제를 풀어내기 전까지는, 이건 AI 에이전트가 일하는 방식에 원래 딸려 오는 한계예요. 이 실수들을 잡아낼 수 있다면 당신은 진짜 가치를 만들고 있는 거예요.
이 실수들을 잡는 유일한 방법은 코드베이스에, 그리고 시스템 전반에 익숙해지는 거예요. 이 이야기는 제 글 「직접 일하지 않는 소프트웨어는 설계할 수 없다」 에서 훨씬 자세히 다뤘어요. 그런데 여기엔 심리적인 요소도 있어요. 에이전트에게 자신 있게 반대할 수 있어야 해요.
AI 에이전트는 꽤 설득력 있게 말해요. 위에서 말한 실수 어딘가에 “박혀서” 특정 위험을 감수하지 않으려 들 때가 자주 있어요. 그럴 땐 몇 번이고 다시 그 경우를 커버하는 코드를 슬쩍 밀어 넣거나, 그 경우가 왜 중요한지 그럴듯한 논변을 써 내려가죠. 여기서 당신이 값어치를 하려면 “이거 별로예요. X랑 Y는 아예 필요 없다고 보는데요, Z를 훨씬 단순하게 하면 안 되나요?”라고 말할 수 있어야 해요. 용기가 필요한 일이에요.
AI 에이전트끼리 서로의 결과물을 리뷰하게 맡겨 두는 걸로는 안 돼요. 같은 모델을 쓰면 똑같은 가정과 똑같은 실수를 어김없이 반복해요. 다른 모델을 써도 무지와 과민이라는 같은 종류의 실수에 빠지기 쉬워요. 구조적인 이유가 같으니까요. 오히려 AI끼리 돌리는 리뷰 루프가 이런 문제를 더 자주 놓쳐요. 요즘 AI는 무슨 일이 있어도 트집 몇 개는 찾아내도록 강화학습돼 있거든요. 비평가 AI와 작업자 AI를 서로 부딪히게 두면, 과민한 코드 1만 줄이 나오기 딱 좋아요.
• • •
기술적 커뮤니케이션
AI 위에 가치를 얹을 수 있는 또 하나의 영역은 커뮤니케이션이에요. 새 모델일수록 코딩은 잘하는데, 역설적이게도 글은 점점 못 써요. GPT-3.5와 GPT-4에서는 이따금 사람이 쓴 것 같은 문장이 나왔어요. GPT-4o가 요즘 슬롭T2 특유의 말투를 퍼뜨렸고, 최근 Anthropic 모델들은 “클로드어”를 구사해요. 반쯤 바로크풍이면서 반쯤 잘려 있는, 아무도 반기지 않는 화법이죠. 예외가 없진 않았어요. GPT-4.5는 괜찮았고 o3는 제법 마음에 들었지만2, 대체로 LLM은 이걸 잘 못해요. 이유는 두 가지예요.
첫째, 좋은 글은 검증 가능한 영역이 아니에요. 수학이나 코딩을 잘하게 만들고 싶다면 문제를 만들어서 자동으로 채점하면 돼요. 좋은 글은 채점할 수 없어요. 초기 OpenAI의 RLHF 시도처럼 사람에게 채점을 맡기면, 평범한 사람이 한 단락씩 읽었을 때 그럴듯해 보이는 글이 나와요. “문장마다 수사 기법을 삼백 개씩 쑤셔 넣는” 문체는 여기서 나온 거예요. 원리만 따지면 취향 좋은 사람들을 골라 앉혀도 되겠죠. 하지만 그게 실제로 안 되는 데는 뻔한 이유가 몇 가지3 있어요.
둘째, 연구소들은 커뮤니케이션 대신 능력에만 외곬으로 매달려 왔어요. 새로운 과학적 지평을 열거나 소프트웨어 엔지니어를 대체할 모델을 학습시키는 중이라면, 커뮤니케이션 능력쯤은 내줄 수 있죠. 사실 어쩌다 이렇게 됐는지도 꽤 정확히 짚어낼 수 있어요. 모델 내부의 추론 토큰을 보면, 단어 선택이 기이하고 문법이 이상하게 잘려 있어요.
RESOLUTION: charge the current-leg’s OWN saved-prefix occupancy EAGERLY: when leg i saves e*1..e*t: ALSO commit their occupancy AT LEG i
이걸 제대로 된 영어로 옮기면, 아마 이런 클로드어 비슷한 문장이 나올 거예요.
Charge the current-leg’s saved-prefix occupancy on a clean, eager path: when leg i saves e*1..e*t, commit the occupancy at leg i.
일부 LLM의 문체가 유독 낯설게 느껴지는 이유는, 우리가 읽는 게 사실은 번역문이기 때문이 아닐까 싶어요. 모델 안의 사고 사슬은 문제 해결 능력을 좇는 사이 거의 알아볼 수 없을 지경이 됐고, 우리 눈에 닿는 문장은 그걸 반쯤 직역한 결과라는 거죠. 클로드어를 좋은 영어로 옮기는 건 놀랄 만큼 어려워요. 원문의 뒤엉키고 압축된 언어를 따라가야 할 뿐 아니라, 모델이 풀고 있는 문제를 이해할 기술적 역량까지 있어야 하니까요.
그래서 기술적 커뮤니케이션은 의외로 오래 버틸 기술일지도 몰라요. 피터 왓츠의 소설 『블라인드사이트』 의 세계는 인지 능력을 증강한 인간들로 가득해요. 주인공의 직업은 “종합가”예요. 이 천재들은 약어와 몸짓으로 말하는데, 종합가는 그들과 나머지 사람들 사이에서 번역층 노릇을 해요. 왓츠의 발상은 이래요. 커뮤니케이션 능력은 지능과 대체로 무관하고, 심지어 음의 상관관계일 수도 있다는 거죠. “천재들의 나라”에도, 그들의 통찰을 모두에게 옮겨줄 평범하게 똑똑한 사람들이 여전히 잔뜩 필요할지도 몰라요.
사람에게 무언가를 전하려는 거라면, 사람이 직접 쓴 글에는 큰 이점이 있어요. 우리 중 상당수가 AI 블라인드가 되어 가고 있거든요. AI가 만든 내용을 마주치는 순간 읽기를 멈추는 반사 신경이 생기는 거예요. 번쩍이는 옥외 광고판이나 웹사이트 사이드바 광고를 자동으로 무시하게 되는 것과 비슷하죠. AI가 쓴 기술 전략 문서를 돌린다면, 동료 대부분은 한 단어 한 단어 억지로 눈을 붙들어 가며 읽어야 할 거예요.
• • •
마치며
무엇을 하든 고기 프록시는 되지 마세요. 요청을 AI 에이전트에 그대로 복사해 넣고 그 출력을 자기 결과물로 제출하는 사람 말이에요. 그건 잘라 달라고 손을 드는 것과 같아요. 정의상 스스로는 아무 가치도 더하지 않았으니까요. 여러 에이전트를 엮은 교묘한 시스템, 이른바 “소프트웨어 공장”을 갖췄더라도 여전히 위태로워요. 그 시스템의 특징이 기업용 AI 도구에 흡수되는 순간(그리고 그렇게 될 거예요) 당신은 없어도 되는 사람이 돼요.
자신의 전문성을 지렛대 삼아, 모델이 못 하는 일을 해낼 방법을 찾아야 해요. AI를 아예 쓰지 않는 편이 고기 프록시보다는 나아요. 적어도 몇몇 부분은 모델보다 잘할 테니까요. 하지만 AI가 어디까지 할 수 있는지 파악하고, 그 빈틈을 메울 자리를 잡는 편이 훨씬 나아요. 지금 빈틈은 크게 두 군데예요. 시스템의 기술적 세부를 꿰는 능력, 그리고 그 세부를 명료하고 설득력 있게 쓰는 능력이에요.
주석
- ”LLM은 지금도 그런 거 하잖아요!”라는 생각이 든다면, 난이도 높은 소프트웨어 엔지니어링의 예시 중 각자 선호하는 것으로 바꿔서 읽으세요. ↩
- 다만 이건 “4o처럼 말하지 않아서 다행이다”에 가까운 반응이었을 거예요. ↩
- 좋은 취향을 정의하기가 어렵고, AI 연구소 연구자들이 애초에 좋은 취향을 가졌다는 보장도 없고, 예시를 두고 아무도 합의하지 못할 테고, 사용자 대부분은 그 결과를 좋아하지 않을 수도 있고, 필요한 데이터 양을 만들어낼 만큼 사람을 모을 수도 없고, 등등. ↩
역자 주
참고: 이 글은 Sean Goedecke가 자신의 블로그에 게시한 아티클을 번역한 것입니다.
원문: You have to beat the models at something - Sean Goedecke
생성: Claude (Anthropic)