LLM 시대의 엔지니어링
(x.com/yairwein)- LLM 시대에 제품과 개발 조직을 어떻게 만들 것인가에 대한 Reindeer에서의 1년 반의 고민을 정리한 글로, 휴먼 컨텍스트(human context)가 가장 희소한 자원이라는 인식에서 모든 통찰이 출발
- 콘텐츠 생산량은 폭발적으로 증가했지만 인간의 소비 속도는 그대로이며, 그 격차가 새로운 병목 — slop이 slop을 먹이는(slop feeds slop) 악순환을 차단해야 함
- 모델링·API 설계 같은 구조적 결정은 여전히 인간의 영역이며, LLM이 만들어내는 산출물에 대해 "no"라고 말할 사람이 필요
- 코드 리뷰만으로 LLM을 이길 수 없으므로 린터·LLM 저지(LLM judges)·소규모 PR 같은 자동·규율 기반 방어층 구축 필요
- 개발자의 핵심 역량은 깊은 기술 지식이 아니라 컨텍스트 스위칭과 자신의 컨텍스트 윈도우 크기, 적응한 개발자는 초생산적이 되지만 적응하지 못한 개발자는 팀에 마이너스(net negative)
휴먼 컨텍스트는 희소 자원
- 25년간 업계에서 변하지 않은 사실 — 가장 비싼 자원은 휴먼 컨텍스트, 사람도 LLM처럼 제한된 컨텍스트 윈도우와 어텐션 마스크를 가짐
- 지금 일어난 변화는 사방에서 LLM slop이 쏟아진다는 것 — 생산 속도와 인간 소비 속도의 비율이 새로운 병목
- 문제는 slop이 slop을 먹임
- LLM이 부풀린 코드 주석, 장황한 PR 설명, 결과 대신 히스토리를 늘어놓는 문서 생성
- 다음 LLM이 이를 읽고 컨텍스트가 노이즈로 채워진 채 같은 방식으로 이어감
- 조직 내 텍스트 콘텐츠는 압축적이어야 하며, 코드와 그 동작에서 명확하지 않은 것만 담아야 함
인간을 대체할 수 없는 영역
- 모델링은 인간의 일
- CUJ(Critical User Journey)를 API 흐름으로 옮기고, 컴포넌트가 무엇인지, 각각의 관심사와 경계가 어디인지 결정하는 작업
- LLM이 코드를 빠르게 뱉어내므로 나쁜 모델링도 빠르게 확산, 사후에 고칠 수 없는 뒤틀린 의존성을 만듦
- 실행 비용이 싸질수록 최종 가치에서 구조에 대한 인간 결정의 비중이 커짐
- 모델링은 실제 조직의 진실이며, 한 곳에 접근 가능하게 살아 있어야 함
- API 정의에는 엄격한 인간 규율 필요
- LLM은 특정 태스크에 편한 필드를 자꾸 추가하는 경향, 그런 필드 하나하나가 API를 영구히 더럽힘
- API는 공개 계약(public contract)이지 스크래치 패드가 아님 — "no"라고 말할 인간 필요
Slop에 대한 대규모 방어
- 인간 코드 리뷰로 LLM을 이길 수 없음 — 확장성이 없어 결국 다들 눈 감고 승인하는 상태로 귀결
- Reindeer는 자동 강제 레이어로 수렴
- 린터(Linters): 서비스 간 금지된 의존성, 아키텍처 경계 같은 절대적 논리 규칙
- LLM 저지(LLM judges): 코드화하기 어렵지만 모델이 검사할 수 있는 것들, 예: 암묵적 계약
- 단, API를 건드리거나 모델링 변경이 일어날 때는 실제 인간 리뷰 필수
- 일상 수준의 규칙은 "서로에게 slop을 던지지 말 것"
- 작은 PR, 필요하면 스택드(stacked) PR
- 2,000줄짜리 slop PR을 던지고 싶은 유혹과 리뷰어가 눈 감고 승인할 가능성에 맞서야 함
- PR은 주의(attention)의 기본 단위 — 사람의 컨텍스트 윈도우를 넘으면 승인은 받지만 읽히지는 않음
Padded rooms — LLM을 풀어놓을 영역
- 위 구조를 갖추면 LLM이 자유롭게 뛸 수 있는 영역, "padded rooms"(완충실) 을 식별 가능
- 모델링에 영향 없고 장기 의존성 없는 영역
- slop이 발생해도 쉽게 교체 가능하고 코드베이스 전체로 퍼지지 않음
- 회사 코드의 대부분일 수 있지만 하중을 지지(load bearing) 하지 않음
- 고객 커스터마이제이션의 해답도 여기에 있음
- 커스터마이제이션은 100% padded rooms 안에 살아야 함
- 코어로 새는 순간 코어가 갈라지고 신규 고객마다 리스크 발생
- padded rooms은 아키텍처에서 대가를 치르지 않고도 고객에게 빠르게 "yes"라고 말할 수 있게 해주는 인프라
기술 부채의 경제적 역전
- 하중 영역과 padded 영역의 분리는 기술 부채와의 관계도 바꿈
- 과거: 개발 도중 모델링 문제를 발견하면 미래의 자신에게 미룸, 재작성 비용이 높아 큰 작업 중에는 부채를 삼킴
- 현재: 재작성 비용이 거의 0에 수렴
- 진짜 투자는 타이핑이 아니라 모델링에 있었음
- 버리고, 모델링을 고치고, 다시 쓰는 것은 저렴
- 미루면 매우 비싸짐 — 잘못된 코드를 지나가는 모든 LLM이 그것을 채택, slop이 slop을 먹임, 즉시 고치지 않은 모델링 실수는 짧은 시간 안에 몇 배 더 복잡한 부채가 됨
이 시대의 PM
- PM 역할이 변화 — 모델링 담당자와 긴밀하게 협업하여 CUJ가 API와 컴포넌트로 옮겨지는 과정에서 깨지지 않도록 보장
- PM과 모델러가 동기화되지 않으면
- 기술적으로는 작동하지만 CUJ를 만족시키지 못하는 제품, 또는
- 깔끔한 CUJ지만 합리적으로 만들 수 없는 결과물
- Reindeer에서는 PM이 별도 레포에서 직접 MVP를 구축
- 이 코드는 절대 프로덕션에 닿지 않는다는 전제
- LLM과 함께 빠르게 움직이며 고객에게 보여줄 수 있는 자유 확보
- 성공하거나 고객을 만나야 하는 것은 정식 모델링·개발 프로세스를 통과
- 코어에 투자하기 전에 빠르게 데모를 세우고 고객 검증 가능 — 아이디어 테스트의 속도와 제품에 들어가는 것에 대한 외과적 엄격함의 균형
루프에서 자유롭게 해주는 인프라
- 에이전트를 손으로 잡아주는 것과 여러 태스크를 병렬로 돌리고 자러 가는 것의 차이는 좋은 보상 함수(reward function)
- 없으면 LLM은 돌아오지 못하는 여행을 떠남
- 있으면 자기가 언제 가깝고 언제 먼지를 스스로 판단
- 개발에서 좋은 보상 함수는 좋은 테스트로 번역됨
- 플랫폼에 대한 E2E 테스트 포함
- 아무것도 테스트하지 않는 mock에 의존하는 나쁜 습관에서 LLM을 떼어냄
- LLM 기반 출력에 대한 Evals
- 깨끗한 컨텍스트의 LLM 저지가 자동 리뷰 루프 수행 — 코드를 쓴 에이전트가 빠진 동일한 환각에 저지가 빠지지 않도록
- 조직 차원에서 이 인프라는 공유가 필요
- Reindeer에는 카테고리로 나뉜 중앙 skill marketplace 레포, 내부 스킬을 모두 포함
- Claude Code, Codex 모든 하니스에서 자동 지원되고, 본인처럼 깊이 unhinged한 사람을 위해 pi.dev도 지원
- 신규 개발자는 즉시 모든 조직 스킬을 받음(온보딩과 셋업을 수행하는 스킬 포함)
미래의 개발자
- 이 시대 개발자의 결정적 역량은 깊은 지식이 아니라 컨텍스트 스위칭과 본인의 컨텍스트 윈도우/어텐션 마스크 크기
- 큰 컨텍스트를 유지하고, 포커스를 잃지 않고 태스크 사이를 이동하며, 여러 에이전트를 병렬로 관리하는 사람이 승리
- 뾰족한 기술 깊이는 LLM이 채워주므로 덜 중요해짐
- 추가 역량은 모델링 능력, 시스템 아키텍처에 대한 좋은 이해, 설계 단계에서 무엇을 경계해야 하는지에 대한 감각
- 새 세상이 개발자를 둘로 가르는 이유
- 적응한 사람은 초생산적(super-productive) 이 됨
- 적응하지 못한 사람은 중립이 아니라 팀에 순 마이너스(net negative)
- LLM은 곱셈자(multiplier) — 다룰 줄 아는 사람에게는 생산성, 다루지 못하는 사람에게는 고속의 손상
- 보상 측면에서 두 번째 유형 개발자의 급여는 0이 됨 — 일이 없을 것
- 훨씬 적은 인원으로 훨씬 많은 일을 할 수 있지만 성장은 매우 어려움, 매우 선택적이어야 함
토큰 비용에 대해
- 반복되는 질문: 토큰 비용이 5~10배 뛰면 어떻게 되는가
- 시간이 지나면 이 우려는 비현실적
- AI에는 가속화된 무어의 법칙, 달러당 품질이 계속 상승
- 충분히 많은 오픈 모델이 존재해 카르텔 형성 불가
- 토큰이 싼 이유 — Claudex가 갑자기 비합리적으로 비싸지면 모두 어떤 neocloud의 Qwen으로 옮겨갈 것이기 때문