LLM 지향 엔지니어링 — Yair Weinberger (Reindeer)
LLM 지향 엔지니어링 — Yair Weinberger (Reindeer)
개요
- 출처: X 아티클, 2026.05.28
- 저자: Yair Weinberger — 이스라엘 테크 기업가, reindeer.ai 운영자, 25년 업계 경력
- 주제: LLM 시대에 제품과 개발 조직을 어떻게 구축할 것인가 (1년 반 Reindeer 경험)
- 분류: 소프트웨어 공학, 조직 설계, AI 시대의 개발 방법론
내용 분석
1. 인간 컨텍스트는 희소 자원
25년 업계 경험에서 결론: 인간 컨텍스트가 가장 비싼 자원. 사람은 제한된 컨텍스트 윈도우와 주의 마스크를 가짐 — LLM과 구조적으로 동일함.
문제: 콘텐츠 생산량은 폭발적으로 증가했지만, 인간 소비량은 변함없음. 생산량 대비 처리 가능량의 비율이 새로운 병목.
더 심각한 문제: slop가 slop을 먹음. LLM이 생성하는 부풀린 코드 주석, 장황한 PR 설명, 결과 대신 역사를 기록한 문서 — 처음에는 해lessly 보이지만, 다음 LLM이 이를 읽고 컨텍스트가 노이즈로 채워지며 같은 정신으로 계속 생성. 조직 내 텍스트는 간결해야 하며, 코드에서 명확한 것은 문서화하지 말 것.
2. 아직 인간이 대체할 수 없는 영역
모델링은 인간 작업. CUJ(사용자 시나리오)를 API 흐름으로 번역하고, 컴포넌트를 결정하며, 각 컴포넌트의 관심사와 경계를 정의하는 것은 인간이 해야 함.
위험: LLM이 코드를 빠르게 생성하므로, 나쁜 모델링도 빠르게 전파되어 사후 수정 불가능한 비틀린 의존성을 생성. 실행이 càng 싸질수록, 구조에 대한 인간 결정이 최종 가치에서 차지하는 비중이 커짐. 모델링은 조직의 실제 진실이며, 한 곳에서 접근 가능하게 유지해야 함.
API 정의는 엄격한 인간 감독 필요. LLM은 특정 작업에 편리한 필드를 추가하려 함. API는 공개 계약이지 메모장이 아님. "아니오"라고 말할 인간이 필요.
3. 규모 단위의 Slope 방어 전략
인간 코드 리뷰로 LLM을 이길 수 없음. 비현실적. 사람이 산더미 같은 코드를 검토하면 눈감고 승인하게 됨.
Reindeer의 3층 자동 강제:
- 린터: 절대적 논리 규칙. 서비스 간 금지 의존성, 아키텍처 경계 등 코드로 규정 가능한 것
- LLM judge: 코드로 규정하기 어렵지만 모델이 점검 가능한 것. 암묵적 계약 등
- API 또는 모델링 변경 시: 실제 인간 리뷰 필수
일상 규칙: slop을 서로에게 던지지 말 것. 작은 PR, 필요시 스택드. 2,000줄 slop PR을 던지고 싶은 유혹이 크고 리뷰어가 눈감고 승인할 수 있음. PR은 주의의 기본 단위. 사람의 컨텍스트 윈도우를 초과하면 읽지 않고 승인됨.
4. 쿠션 방 (Padded Rooms)
LLM을 자유롭게 풀어놓아도 되는 영역 식별. 모델링에 영향 없고 장기 의존성 생성하지 않는 곳. 여기서는 slop에 관대해도 됨 — 쉽게 교체 가능하고 코드베이스로 퍼지지 않음.
회사 코드의 대부분이 여기에 속할 수 있으나, 하중을 지지하지 않음.
고객 커스터마이징의 답: 100% 쿠션 방 안에 있어야 함. 커스터마이징이 코어로 누수하는 순간 코어가 분할되고 새 고객마다 위험이 됨. 쿠션 방이 고객에게 빠르게 "예"라고 말할 수 있게 하는 인프라. 아키텍처 대가를 치르지 않음.
5. 기술 부채: 경제적 역전
하중 지지 vs 쿠션 방의 구분이 기술 부채 관계를 바꿈.
과거: 개발 중 모델링 문제 발견 → 나중에 고침. 리작성 비용이 높으므로 큰 작업 중에는 기술 부채를 삼킴.
현재: 리작성 비용이 0에 수렴. 실제 투자물은 모델링이고 타이핑이 아님. 버리고 모델링을 고치고 리작성하는 것이 싸고, 나중에 고치려는 것이 비쌈. 잘못된 코드를 지나가는 LLM이 채택하고 slop이 slop을 먹으므로, 모델링 실수가 즉시 수정되지 않으면 짧은 시간 안에 수배 더 복잡한 부채가 됨.
6. 이 시대의 PM
PM 역할 변화. 모델링 담당자와 긴밀히 협력하여 CUJ가 API와 컴포넌트로 번역되면서 깨지지 않게 보장. PM과 모델러가 동기화되지 않으면: 기술적으로는 작동하지만 CUJ를 충족하지 않는 제품, 또는 건전하게 구축할 수 없는 깔끔한 CUJ가 나옴. 같은 결정의 양면.
Reindeer의 방식: PM이 별도 레포에서 직접 MVP 구축. 이 코드가 프로덕션에 절대 가지 않는다는 전제. LLM으로 빠르게 움직이고 고객에게 보여줌. 성공한 것이나 고객이 필요로 하는 것이 모델링과 개발의 정해진 과정을 통과. 아이디어 테스트 속도와 코어에 들어가는 것에 대한 수술적 접근을 균형 있게 유지.
7. 루프에서 해방하는 인프라
에이전트를 손잡이로 안내하는 것과 여러 작업을 병렬로 실행하고 자는 것의 차이 = 좋은 보상 함수. 없으면 LLM은 돌아오지 않는 여행을 떠남. 있으면 스스로 가까이 있는지 멀리 있는지 알음.
개발에서 좋은 보상 함수 = 좋은 테스트. 플랫폼의 E2E 포함. LLM이 아무것도 테스트하지 않는 mock에 대한 나쁜 습관 끊기. LLM 기반 출력에 대한 eval. 깨끗한 컨텍스트에서 LLM judge의 자동 리뷰 루프 — 코드를 작성한 에이전트가 mắc한 환각으로 judge도 떨어지지 않게 방지.
조직 수준: 공유 필요. Reindeer는 중앙 스킬 마켓플레이스 레포 보유. 카테고리별 내부 스킬 모두 포함. 모든 harness에서 자동 지원: Claude Code, Codex, pi.dev 등. 새 개발자는 즉시 조직 스킬 전부를 얻음 — 온보딩 및 설정 스킬 포함.
8. 미래의 개발자
핵심 역량: 컨텍스트 전환 능력과 자신의 컨텍스트 윈도우 크기(주의 마스크). 큰 컨텍스트를 유지하고, 작업 간 이동 시 집중력을 잃지 않고, 여러 에이전트를 병렬로 관리하는 사람이 승리. 포인트 기술 심도는 덜 중요해짐 — LLM이 채움.
추가 역량: 모델링 능력, 시스템 아키텍처 이해, 설계 단계에서 주의할 것.
개발자 이분법: 적응자는 초생산적. 비적응자는 중립이 아니라 순음수가 아님. LLM은 승수. 아는 사람에게는 생산성, 모르는 사람에게는 고속으로 인한 피해. "두 번째 유형의 개발자 급여는 0원. 일 자체가 없음".
소수로 더 많은 일을 할 수 있으나, 성장은 매우 어려움. 매우 선택적이어야 함.
9. 토큰 비용에 대하여
"토큰 비용이 5~10배 뛰면 어떻게 되나"라는 질문은 비현실적. AI의 가속형 무어의 법칙 존재. 달러당 품질은 계속 상승. 오픈 모델이 충분하여 카르텔 형성 불가.
새로운 시각
"slop feeds slop"의 재귀적 붕괴 기존 기술 부채 = 코드 품질 저하. LLM 시대 기술 부채 = 정보 엔트로피 증가. LLM이 slop을 읽고 slop을 생성하면 조직 내 정보 품질이 기하급수적으로 저하. 코드 문제보다 근본적 — 조직의 집단 지능 퇴화.
쿠션 방 = 모노리쓰 vs 마이크로서비스의 재해석 핵심: "어디에 LLM을 풀어놓을 것인가"가 아니라 "어디에 인간 감독을 집중할 것인가". 하중 지지 코어는 작고 인간 통제, 나머지는 LLM 자유 생성. 모노리쓰의 단순성과 마이크로서비스의 유연성 동시 확보.
"기술 부채의 경제적 역전" "나중에 고친다"가 과거에는 합리적(리작성 비용 높음). 현재는 리작성 비용 0에 수렴하므로 "나중에 고친다"가 더 비쌈. 개발자 마인드셋 근본 전환 — "지금 바로 고쳐야 한다"가 경제적 합리성.
개발자 이분법의 냉혹함 적응자 vs 비적응자 = 단순 생산성 차이가 아닌 존재론적 차이. 비적응자가 "중립"이 아닌 "순음수가 아님" — slop을 조직에 주입하는 원천.
미래 영향
개발 조직:
- 작은 PR 문화 = 생존 전략
- API 설계에 인간 감독比以往任何时候更重要
- PM 역할: "요구사항 작성" → "모델링 검증 + MVP 직접 구축"
자녀 교육:
- 컨텍스트 전환 능력, 시스템 모델링 사고, 다중 에이전트 관리 능력
- 포인트 기술보다 아키텍처 이해 중요
- "slop 식별 능력" = 새로운 리터러시
의료 AI 연결:
- 진단 지원(코어) = 인간 감독, 보고서 생성(쿠션 방) = LLM 자동화
- 의료 문서 slop 문제: LLM이 slop을 읽고 slop을 생성하면 의료 기록 품질 저하
관련 링크
키워드
#LLM_엔지니어링 #소프트웨어공학 #조직설계 #AI시대개발 #slop_문제 #쿠션방 #기술부채 #모델링 #개발자이분법