누구나 빵을 굽는 시대 (개발이야기임)

예전에 《따끈따끈 베이커리》를 보다 한 장면에 한참 멈춰 있던 적이 있습니다. 일본 제빵사들이 프랑스에 도착하자 누군가 묻습니다. "빵 만들 줄 아나?" 제빵사들은 당연하다는 듯 "그렇다"고 답합니다. 일본에서 빵을 만들 줄 안다는 건 아무나 가진 능력이 아니니까요. 빵집을 차린 전문 제빵사쯤은 되어야 하는 일입니다. 그런데 돌아온 반응이 뜻밖이었습니다. "여기선 다들 빵 정도는 만들 줄 아는데." 프랑스에서는 집집마다 빵을 굽습니다.

같은 "빵 만들 줄 안다"는 말이, 일본에서는 자격이 되고 프랑스에서는 자랑이 되지 않습니다. 빵을 구울 줄 아는 사람이 드무냐 흔하냐의 차이일 뿐인데 말입니다.

요즘 개발을 보면 그 프랑스가 자꾸 떠오릅니다. 코드를 배운 적 없는 기획자가 LLM으로 내부 대시보드를 만들고, 디자이너가 자기 포트폴리오 사이트를 직접 짭니다. 예전 같으면 개발자에게 부탁하거나 솔루션을 결제했을 일입니다. 그래서 한동안은 마음이 복잡했는데, 지금은 이게 개발자에게 꼭 나쁜 소식만은 아니라고 생각하는 편입니다. 다만 조건이 하나 붙는 것 같습니다.

누구나 요리하는 시대

집에서는 누구나 밥을 짓습니다. 그래도 음식점이 사라지지는 않았습니다. 살아남은 건 집에서 해 먹는 것보다 나은 집들이었습니다.

개발도 비슷한 모양이 되어가는 듯합니다. 1인 SaaS라는 말이 유행하지만, 제가 본 상당수는 팔려고 만든 게 아니었습니다. 자기가 쓰려고 만든 것이었습니다. 간단한 사내 도구, 알림 봇, 데이터 정리 스크립트 같은 것들 말입니다. 내가 쓸 거라서 운영도 크게 신경 쓸 일이 없습니다. SLA를 맞출 필요도, CS를 받을 필요도, 결제를 붙일 필요도 없으니까요. 만들고, 내가 쓰고, 안 맞으면 고치면 그만입니다.

이런 일이 늘면서 굳이 사 먹을 이유가 줄어듭니다. 저도 예전 같으면 월 구독을 했을 작은 도구들을, 요즘은 그냥 만들어 쓰는 편입니다.

"이정도면 충분하다"의 함정

LLM이 만든 결과물은 완벽하지 않다고들 합니다. 대략 8할쯤 채운다고요. 그런데 신기하게도 8할이면 사람들이 잘 씁니다. "이정도면 충분하지" 하면서요.

여기서 이런 결론으로 빠지기 쉽습니다. "그럼 8할짜리를 빠르게 만들어 팔면 되겠네." 그런데 막상 보면 그 8할은 잘 팔리지 않는 듯합니다. 사는 쪽도 똑같이 만들 수 있기 때문입니다. LLM은 나만 쓰는 도구가 아니라 누구나 쓰니까요. 내가 요구사항을 잘 정리해 8할을 뽑아낸다면, 잠재 고객도 똑같이 뽑아냅니다. 요구사항을 깔끔하게 정리하는 능력은 이제 차별점이 되기 어려운 것 같습니다. 그건 말하자면 집밥입니다.

그런데 여기서 갈립니다

우울한 이야기 같지만, 데이터를 보면 결이 조금 다릅니다. 같은 AI 도구를 쥐었는데 결과가 사람마다 크게 갈린다는 점입니다.

한 조사에서는 10년 차 이상 시니어 개발자들이 AI로 생산성이 80% 넘게 올랐다고 답한 반면, 주니어에게서는 의미 있는 향상이 거의 나타나지 않았다고 합니다. 도입 자체는 이미 끝난 싸움이고, 남은 건 품질 싸움이라는 이야기가 그래서 나오는 듯합니다.

제 작업 방식을 돌아봐도 비슷합니다. 저는 기획이나 정형화된 API 코드는 요구사항만 던지고 맡기는 편입니다. 데이터가 흔한 영역이라 대체로 잘 나오니까요. 반면 까다로운 인프라 문제나 제가 만드는 오픈소스에서는, 원인을 직접 짚고 가능한 해결 후보까지 좁혀서 줍니다. 같은 도구를 쓰지만 어디서 손을 떼고 어디서 방향을 잡을지가 결과를 가르는 것 같습니다. AI가 개발자를 평평하게 대체한다기보다, 방향을 아는 사람에게서 더 많은 걸 끌어낸다는 쪽에 가깝지 않나 싶습니다.

집에서는 못 내는 맛

음식점이 살아남는 건 집에서 못 내는 맛이 있을 때입니다. 막연하게 들릴 테니 제가 직접 만진 것으로 이야기해보겠습니다.

플랫폼에에 모바일 페이지 전환을 붙인 적이 있습니다. 화면이 바뀔 때 네이티브 앱처럼 미끄러지는 그 움직임입니다. 이건 "전환을 부드럽게 해줘"라고 아무리 깔끔하게 요청해도 8할짜리로는 잘 나오지 않았습니다. 직접 부딪힌 것만 적어도 이렇습니다. 이전 페이지를 언제 언마운트할지, 그 타이밍을 usePathname 변화에 어떻게 맞출지, 스프링 물리로 감속 곡선을 어떻게 줄지, 그 애니메이션을 VSync에 맞춰 프레임 드랍 없이 흘릴지. 요구사항을 정리해서가 아니라 깎아내면서 나오는 디테일이었습니다.

그래서 저는 이 부분을 아예 라이브러리로 떼어냈습니다. 직접 구현하기엔 비용이 큰 영역이라, 그 비용을 대신 치러주는 도구를 만든 셈입니다. 제가 느끼기에 핵심은 이겁니다. 직접 만들기엔 비싼 디테일이라야 "사서 쓰는 게 낫다"가 성립합니다. 그 비용의 크기가 곧 해자인 듯합니다. 그리고 그 디테일을 낼 수 있느냐는 결국 개발 실력의 문제입니다. AI 시대에 실력이 덜 중요해진 게 아니라, 오히려 값이 더 또렷하게 매겨지기 시작한 것 같습니다.

그럼, LLM이 곧 그 맛까지 내지 않을까

당연한 반문이 떠오릅니다. "지금이야 8할이지만, 조금만 더 좋아지면 그 비싼 디테일까지 LLM이 해주는 거 아닌가." 솔직히 저도 한동안 이게 가장 두려웠습니다. 그런데 모델이 어떻게 학습하는지를 들여다보니, 그 걱정이 생각만큼 단순하지는 않았습니다.

AI가 잘하는 건 데이터가 흔한 영역입니다

LLM은 결국 학습 데이터로 배웁니다. 그리고 여러 연구가 비슷하게 말하는 건, 데이터에 자주 등장한 것일수록 잘한다는 점입니다.

Kandpal 등의 2023년 연구(ICML)는, 모델이 어떤 사실을 맞히는 정확도가 사전학습에서 그 사실과 관련된 문서가 몇 번 등장했는지와 거의 로그-선형으로 비례한다는 걸 보였습니다. 웹에 흔한 지식은 잘 맞히고, 드문 지식은 못 맞힌다는 이야기입니다. Razeghi 등의 2022년 연구는 한발 더 나아갑니다. 단순 암기뿐 아니라 수치 추론조차, 그 숫자가 학습 데이터에 자주 나왔을수록 더 잘 풀었다고 합니다. 우리가 '추론'이라 부르던 것의 일부도 빈도에 끌려간다는 뜻으로 읽혔습니다.

제 경험과도 크게 다르지 않습니다. CRUD나 흔한 패턴의 프론트 코드는 LLM이 곧잘 짭니다. 자료가 널려 있으니까요. 반면 니치한 도메인, 새로 나온 라이브러리, 남들이 잘 가지 않은 최적화 구간으로 가면 눈에 띄게 약해집니다. 제 오픈소스에서 원인을 직접 짚어줘야 했던 것도, 돌이켜보면 그 영역이 데이터가 얇은 곳이었기 때문인 듯합니다. 그리고 시장에서 팔리는 가치는 정확히 그쪽, 흔하지 않고 코드로 잘 적히지 않는 판단 쪽으로 옮겨가는 것 같습니다.

게다가 재료가 줄고 있습니다

"그럼 데이터를 더 부으면 되지 않나" 싶지만, 여기서 두 번째 벽을 만나는 듯합니다. Epoch AI의 추정에 따르면 모델이 학습할 수 있는 공개 웹의 양질 텍스트는 2026~2028년 사이 고갈에 가까워진다고 합니다. 최근 프런티어 모델의 병목이 연산이 아니라 데이터의 양과 질이었다는 분석도 여럿 보입니다.

흔한 재료는 거의 다 쓴 셈입니다. 남은 건 글로 잘 적히지 않는 영역입니다. 흥미로운 건, 생산성이 올라 만족 기준이 높아질수록 제가 만드는 게 새 라이브러리나 새 방법론 쪽으로 옮겨간다는 점입니다. comwit의 전환 라이브러리도 그렇게 나왔습니다. 그건 아직 학습 데이터에 없는, 모델이 미처 먹지 못한 자리인 것 같습니다.

그래도 "안심하라"는 말은 아닙니다

정직하게 덧붙이고 싶습니다. 이게 영구적인 안전지대는 아닙니다. RAG, 하네스 엔지니어링, 스킬 등이 드문 영역을 조금씩 메워 갑니다. 그러니 한계는 사라진다기보다 위로 밀려 올라가는 듯합니다. 올해 비싼 디테일이 내년엔 기본기가 될 수도 있습니다.

제가 말하려는 건 "LLM이 여기까지는 못 온다"가 아닙니다. 여기까지 오는 데에는 구조적인 시차가 있고, 지금이 그 시차를 우위로 바꿔둘 수 있는 시기라는 쪽에 가깝습니다. 걱정하며 멈춰 있어도 그 시기는 똑같이 닫힙니다. 그렇다면 그동안 데이터가 얇은 영역에서 실력을 쌓아두는 편이 낫지 않을까 싶습니다.

페인킬러로는 부족해진 것 같습니다

스타트업에는 "비타민 말고 페인킬러를 만들어라"는 격언이 있습니다. 아픈 곳을 없애주면 사람들이 돈을 낸다는 뜻이었습니다. 그런데 이제는 그 페인킬러조차 각자 직접 만드는 듯합니다. 가벼운 불편 정도는 사용자가 LLM으로 스스로 해소해버립니다. "당신의 문제를 해결해 드립니다"만으로는 더 이상 지갑이 잘 열리지 않는 것 같습니다.

그렇다고 개발자가 할 일이 줄어든 건 아닙니다. 합격선이 8할 위로 올라갔다는 건, 그 위를 만들 수 있는 사람의 값이 올라갔다는 뜻이기도 합니다. 요구사항만 그럭저럭 정리하면 통하던 시기는 지나간 듯합니다. 대신 집밥보다 나은 한 접시를 낼 수 있는 사람에게는 오히려 기회가 더 커진 것 같습니다.

그래서 개발자는 어디에 서 있나

누구나 집밥을 해먹습니다. 그렇다고 요리사가 사라지진 않습니다.

정리하면 이렇습니다. LLM은 데이터가 흔한 영역, 즉 8할을 빠르게 채웁니다. 그건 이제 누구나 만드는 집밥입니다. 반면 데이터가 얇은 영역, 직접 깎아야 나오는 디테일과 코드로 잘 적히지 않는 판단은 한동안 사람의 몫으로 남는 것 같습니다. 데이터의 한계와 그 한계가 채워지는 시차가 우리에게 시간을 벌어주는 셈입니다.

그래서 두려워하기보다 그 시차를 쓰는 쪽이 맞다고 생각합니다. 제가 실제로 신경 쓰는 것도 돌아보면 세 가지로 정리됩니다. 어디까지 맡기고 어디서 방향을 잡을지 판단하는 일, 나온 결과물을 제대로 검토하는 일, 그리고 모델이 아직 먹지 못한 자리에 라이브러리든 방법론이든 제 자산을 쌓아두는 일입니다.

결국 스스로에게 같은 질문을 하게 됩니다. 지금 내가 만드는 건 남들이 직접 8할의 퀄리티로 만들 수 있는 것인가, 아니면 직접 만들기엔 비싼 것인가. 그리고 나는 그 비싼 쪽을 만들 수 있는 사람인가.

개발을 할줄 안다는 사실 하나로 개발자가 되는 시대는 끝난거 같습니다. 반면 요리를 할 수 있음에도 음식을 사먹습니다. 남이 나의 능력을 돈주고 쓰고 싶을정도로 실력을 올려야 한다는 것. 그리고 LLM이 따라오지 못한, 그리고 따라가기엔 기술이 아닌 구조적으로 시간이 걸린다는 점.