LLM 시대의 엔지니어링 — 휴먼 컨텍스트가 가장 희소한 자원이다

LLM 시대의 엔지니어링 — 휴먼 컨텍스트가 핵심 자원이다

LLM 시대의 엔지니어링 — 휴먼 컨텍스트가 가장적 자원이다

LLM 시대에 제품과 개발 조직을 어떻게 만들 것인가에 대한 고민이 깊어지고 있다. 최근/Reindeer에서 1년 반 동안 정리한 내용이 화제를 모으고 있다. 핵심은일개 — 휴먼 컨텍스트가 가장 희소한 자원이라는 인식이다.

---

슬롭이 슬롭을 먹는 악순환

25년간 업계에서 변하지 않은 사실이 있다. 가장 비싼 자원은 언제나 휴먼 컨텍스트다. 사람도 LLM처럼 제한된 컨텍스트 윈도우와 어텐션 마스크를 가진다. 지금 일어난 변화는 사방에서 LLM 슬롭이 쏟아진다는 것이다.

문제는 생산 속도와 인간 소비 속도의 비율이 새로운 병목이 됐다는 점이다. 콘텐츠 생산량은 폭발적으로 증가했지만 인간의 소비 속도는 그대로다. 그 격차가 _slop이 slop을 먹이는_ 악순환을 만들어낸다.

LLM이 부풀린 코드 주석, 장황한 PR 설명, 결과 대신 히스토리를 늘어놓는 문서를 생성하면, 다음 LLM이 이를 읽고 컨텍스트가 노이즈로 채워진 채 같은 방식으로 이어간다. 조직 내 텍스트 콘텐츠는 압축적이어야 하며, 코드와 그 동작에서 명확하지 않은 것만 담아야 한다.

---

모델링은 인간의 영역

CUJ(Critical User Journey)를 API 흐름으로 옮기고, 컴포넌트가 무엇인지, 각각의 관심사와 경계가 어디인지 결정하는 작업은 여전히 인간의 영역이다. LLM이 코드를 빠르게 뱉어내므로 나쁜 모델링도 빠르게 확산되고, 사후에 고칠 수 없는 뒤틀린 의존성을 만들어낸다.

실행 비용이 싸질수록 최종 가치에서 구조에 대한 인간 결정의 비중이 더 커진다. 모델링은 실제 조직의 진실이며, 한 곳에 접근 가능하게 살아 있어야 한다.

API 정의에는 엄격한 인간 규율이 필요하다. LLM은 특정 태스크에 편한 필드를 자꾸 추가하는 경향이 있다. 그런 필드 하나하나가 API를 영구히 더럽힌다. API는 공개 계약이지 스크래치 패드가 아니다 — "no"라고 말할 인간이 필요하다.

---

슬롭에 대한 대규모 방어

인간 코드 리뷰만으로 LLM을 이길 수 없다. 확장성이 없기 때문이다. 결국 다들 눈 감고 승인하는 상태로 귀결된다. Reindeer는 자동 강제 레이어로 수렴했다:

• 린터(Linters): 서비스 간 금지된 의존성, 아키텍처 경계 같은 절대적 논리 규칙

• LLM 저지(LLM judges): 코드화하기 어렵지만 모델이 검사할 수 있는 것들 — 예: 암묵적 계약

단, API를 건드리거나 모델링 변경이 일어나는 때는 실제 인간 리뷰가 필수다. 일상 수준의 규칙은 간단하다 — _서로에게 슬롭을 던지지 말 것_.

작은 PR, 필요하면 스택드(stacked) PR을 사용해야 한다. 2,000줄짜리 슬롭 PR을 던지고 싶은 유혹과 리뷰어가 눈 감고 승인할 가능성에 맞서야 한다. PR은 주의의 기본 단위다. 사람의 컨텍스트 윈도우를 넘으면 승인은 받지만 읽히지는 않는다.

---

패디드 룸 — LLM을 풀어놓을 영역

위 구조를 갖추면 LLM이 자유롭게 뛸 수 있는 영역, "_padded rooms_"를 식별할 수 있다. 모델링에 영향 없고 장기 의존성 없는 영역이다. 슬롭이 발생해도 쉽게 교체 가능하고 코드베이스 전체로 퍼지지 않는다. 회사 코드의 대부분일 수 있지만 하중을 지지하지 않는다.

고객 커스터마이제이션의 해답도 여기에 있다. 커스터마이제이션은 100% padded rooms 안에 있어야 한다. 코어로 새는 순간 코어가 갈라지고 신규 고객마다 리스크가 발생한다. padded rooms은 아키텍처에서 대가를 치르지 않고도 고객에게 빠르게 "yes"라고 말할 수 있게 해주는 인프라다.

---

기술 부채의 경제적 역전

과거에는 개발 도중 모델링 문제를 발견하면 미래의 자신에게 미루었다. 재작성 비용이 높아 큰 작업 중에는 부채를 삼켰다. 그러나 지금은 다르다. 재작성 비용이 거의 0에 수렴했다.

진짜 투자는 타이핑이 아니라 모델링에 있었다. 버리고, 모델링을 고치고, 다시 쓰는 것은 저렴하다. 반면 미루면 매우 비싸진다. 잘못된 코드를 지나가는 모든 LLM이 그것을 채택하고, 슬롭이 슬롭을 먹이며, 즉시 고치지 않은 모델링 실수는 짧은 시간 안에 몇 배 더 복잡한 부채가 된다.

---

이 시대의 PM

PM 역할이 변화하고 있다. 모델링 담당자와 긴밀하게 협업하여 CUJ가 API와 컴포넌트로 옮겨지는 과정에서 깨지지 않도록 보장해야 한다. PM과 모델러가 동기화되지 않으면 두 가지 결과가가능출한다:

1. 기술적으로는 작동하지만 CUJ를 만족시키지 못하는 제품

2. 깔끔한 CUJ지만 합리적으로 만들 수 없는 결과물

Reindeer에서는 PM이 별도 레포에서 직접 MVP를 구축한다. 이 코드는 절대 프로덕션에 닿지 않는다는 전제다. LLM과 함께 빠르게 움직이며 고객에게 보여줄 수 있는 자유를 확보한다. 성공하거나 고객을 만나야 하는 것은 정식 모델링·개발 프로세스를 통과한다. 코어에 투자하기 전에 빠르게 데모를 세우고 고객 검증이 가능하다 — 아이디어 테스트의 속도와 제품에 들어가는 것에 대한 외과적 엄격함의 균형이다.

좋은 보상 함수 없으면 LLM은 돌아오지 못하는 여행을 떠난다. 있으면 자기가 언제 가깝고 언제 먼지를 스스로 판단한다. 개발에서 좋은 보상 함수는 좋은 테스트로 번역된다. 플랫폼에 대한 E2E 테스트를 포함해서, 아무것도 테스트하지 않는 mock에 의존하는 나쁜 습관에서 LLM을 떼어내야 한다.

---

LLM 기반 출력에 대한 Evals

깨끗한 컨텍스트의 LLM 저지가 자동 리뷰 루프를 수행한다. 코드를 쓴 에이전트가 빠진 동일한 환각에 저지가 빠지지 않도록 조직 차원에서 이 인프라를 공유해야 한다. Reindeer에는 카테고리로 나뉜 중앙 skill marketplace 레포가 있다. 내부 스킬을 모두 포함하며, Claude Code, Codex 모든 하니스에서 자동 지원된다. 신규 개발자는 즉시 모든 조직 스킬을 받는다 — 온보딩과 셋업을 수행하는 스킬 포함이다.

---

미래의 개발자

이 시대 개발자의 결정적 역량은 깊은 지식이 아니라 컨텍스트 스위칭과 본인의 컨텍스트 윈도우/어텐션 마스크 크기다. 큰 컨텍스트를 유지하고, 포커스를 잃지 않고 태스크 사이를 이동하며, 여러 에이전트를 병렬로 관리하는 사람이 승리한다. 뾰족한 기술 깊이는 LLM이 채워주므로 덜 중요해진다.

추가 역량은 모델링 능력, 시스템 아키텍처에 대한 좋은 이해, 설계 단계에서 무엇을 경계해야 하는지에 대한 감각이다.

새 세상이 개발자를 둘로 가른다. 적응한 사람은 초생산적(super-productive)이 되고, 적응하지 못한 사람은 중립이 아니라 팀에 순 마이너스(net negative)가 된다. LLM은 곱셈자다 — 다룰 줄 아는 사람에게는 생산성을, 다루지 못하는 사람에게는 고속의 손상을 제공한다.

보상 측면에서 두 번째 유형 개발자의 급여는 0이 될 것이다. 일이 없을 것이라는 뜻이다. 훨씬 적은 인원으로 훨씬 많은 일을 할 수 있지만 성장은 매우 어려우며, 매우 선택적이어야 한다.

---

토큰 비용에 대한 답변

토큰 비용이 5~10배 뛰면 어떻게 될까라는 질문이 반복된다. 시간이 지나면 이 우려는 비현실적이다. AI에는 가속화된 무어의 법칙이 적용되며, 달러당 품질이 계속 상승한다. 충분히 많은 오픈 모델이 존재해 카르텔 형성이 불가능하다. 토큰이 싼 이유 — Claudex가 갑자기 비합리적으로 비싸지면 모두 어떤 neocloud의 Qwen으로 옮겨갈 것이기 때문이다.

---

핵심 정리

1. 휴먼 컨텍스트가 가장 희소한 자원 — 모든 판단의 출발점

2. 슬롭의 악순환을 차단해야 한다 — 자동 방어층(린터, LLM 저지) 구축

3. 모델링은 인간의 영역 — "no"라고 말할 사람 필요

4. 패디드 룸 식별 — LLM이 자유롭게 뛸 수 있는 영역을 아키텍처적으로 분리

5. 기술 부채 경제 역전 — 재작성 비용은 0, 미루는 비용만이 비싸다

6. 적응한 개발자 vs 아닌 개발자 — 생산성 극대화 또는 팀에 마이너스

LLM 시대의 엔지니어링은 결국 휴먼 컨텍스트를 지키는 Arbeit다. 기술의 속도와 인간의용량 사이의 격차를 인식하고, 그 격차를 줄이는 방향으로 시스템을 설계하는 것이 핵심이다.

---

📚 출처

• LLM 시대의 엔지니어링 - GeekNews

• 원본: x.com/yairwein (Reindeer Engineering Blog)

---

📚 출처

• https://news.hada.io/topic?id=30060