LLM 시대의 개발 조직, 사람의 컨텍스트가 병목이에요

LLM 시대의 개발 조직, 사람의 컨텍스트가 병목이에요

AI 뉴스 썸네일

LLM이 코드를 더 빨리 쓰게 만들면서 개발 조직의 병목도 달라졌어요. 이제 문제는 입력 속도가 아니라 사람이 이해하고 거절하고 구조를 잡을 수 있는 시간이에요.

핵심 요약

구분	핵심	왜 볼 만한가요
개발 조직	사람의 컨텍스트가 가장 비싼 자원이라는 관점이 나왔어요	산출물이 많아질수록 리뷰와 의사결정의 한계가 더 빨리 드러나요
설계	모델링과 API 경계는 사람이 직접 잡아야 해요	LLM이 만든 작은 편의 필드 하나가 장기 계약을 망칠 수 있어요
운영 방식	린터, LLM 저지, 작은 PR 같은 방어층이 필요해요	사람이 모든 코드를 읽는 방식은 규모가 커질수록 버티기 어려워요
제품 실험	PM이 별도 저장소에서 MVP를 빠르게 만들고 검증하는 방식이 제안됐어요	실험 속도와 코어 제품의 안정성을 분리할 수 있어요

1. LLM 시대의 개발 조직은 사람의 컨텍스트를 아껴야 해요

Reindeer의 Yair Weinberger는 1년 반 동안 LLM 시대의 제품 개발 방식을 고민하며, 가장 희소한 자원은 여전히 사람의 컨텍스트라고 말해요. LLM 덕분에 코드, 문서, PR 설명은 훨씬 빨리 만들어져요. 하지만 사람이 읽고 판단하는 속도는 그대로예요. 그래서 조직 안에는 읽히지 않는 설명, 불필요하게 긴 주석, 결과보다 과정을 늘어놓는 문서가 쌓이기 쉬워요. 1

이 글에서 특히 날카로운 지점은 "slop이 slop을 먹인다"라는 표현이에요. LLM이 장황한 내용을 만들고, 다음 LLM이 그 내용을 다시 읽으면 컨텍스트가 더 흐려져요. 한 번 흐려진 문맥은 다시 코드와 문서로 번져요. 그래서 조직 안의 텍스트는 더 짧고 정확해야 해요. 코드만 봐도 알 수 있는 설명은 덜어내고, 코드만으로는 드러나지 않는 결정만 남겨야 해요. 2

모델링과 API는 여전히 사람의 일이에요

글의 중심은 단순히 "AI 코딩을 잘 쓰자"가 아니에요. 제품의 핵심 사용자 흐름을 API와 컴포넌트 경계로 옮기는 일은 사람이 해야 한다는 주장에 가까워요. LLM은 코드를 빨리 만들지만, 나쁜 구조도 빨리 퍼뜨려요. 잘못 잡힌 의존성은 나중에 고치기 어렵고, 여러 에이전트가 그 위에서 계속 코드를 만들면 부채가 짧은 시간 안에 커져요.

API 설계도 같은 문제를 안고 있어요. LLM은 특정 작업에 편한 필드를 쉽게 추가해요. 지금 당장은 빨라 보여도, API는 한 번 공개되면 계약이 돼요. 임시 편의가 계약에 들어가면 제품은 그 값을 계속 끌고 가야 해요. 그래서 API나 데이터 모델이 바뀌는 순간에는 사람이 "아니요"라고 말할 수 있어야 해요.

코드 리뷰만으로는 부족해요

사람이 모든 LLM 산출물을 끝까지 읽고 막는 방식은 오래가기 어려워요. 코드 생산량이 늘어나면 리뷰어는 결국 큰 PR을 대충 승인하게 돼요. 그래서 글은 자동 강제 장치를 먼저 세우라고 말해요. 금지된 서비스 의존성이나 아키텍처 경계처럼 명확한 규칙은 린터가 잡고, 코드로 쓰기 어려운 암묵적 계약은 LLM 저지가 살펴보는 식이에요.

다만 모델링 변경이나 API 변경은 자동 검사만으로 넘기면 안 돼요. 이 부분은 실제 사람이 리뷰해야 해요. 일상적인 작업에서는 작은 PR을 유지하고, 필요하면 스택드 PR로 나누는 규율이 중요해요. PR은 코드 묶음이 아니라 사람의 주의를 쓰는 단위예요. 사람이 한 번에 읽을 수 있는 범위를 넘기면, 승인은 받아도 제대로 읽히지 않아요.

LLM을 풀어놓을 방도 따로 필요해요

흥미로운 개념은 "padded rooms"예요. 제품의 핵심 모델링에 영향을 주지 않고, 장기 의존성을 만들지 않는 영역을 따로 두자는 뜻이에요. 이 공간에서는 LLM이 비교적 자유롭게 코드를 만들 수 있어요. 잘못 만들어도 쉽게 갈아엎을 수 있고, 코어 코드베이스로 오염이 번지지 않기 때문이에요.

고객별 커스터마이징도 이 공간 안에 머물러야 해요. 커스터마이징이 코어 제품으로 새어 들어가면 고객이 늘어날수록 구조가 갈라져요. 반대로 완충 공간이 잘 잡혀 있으면 고객 요청에는 빠르게 "네"라고 답하면서도, 핵심 아키텍처는 덜 흔들 수 있어요.

PM의 역할도 더 가까워져요

이 글은 PM 역할의 변화도 짚어요. PM은 사용자 흐름이 API와 컴포넌트로 옮겨지는 과정에서 모델링 담당자와 더 붙어 있어야 해요. 사용자 흐름은 좋아 보이지만 만들기 어려운 구조가 될 수도 있고, 기술적으로 깔끔하지만 사용자의 실제 여정을 놓칠 수도 있어요. 두 문제가 서로 다른 문제가 아니라 같은 결정의 양면이라는 설명이 설득력 있어요.

Reindeer에서는 PM이 별도 저장소에서 직접 MVP를 만든다고 해요. 이 코드는 운영 제품에 들어가지 않는다는 전제가 붙어요. 덕분에 고객에게 빠르게 보여 주고, 반응이 있는 아이디어만 정식 모델링과 개발 과정을 거쳐요. 실험의 속도와 제품 코어의 안전성을 분리하는 방식이에요.

개발자에게 필요한 능력도 바뀌고 있어요

글의 결론은 꽤 직설적이에요. LLM 시대의 개발자는 깊은 기술 지식만으로 평가되기 어렵고, 큰 문맥을 잡고 여러 작업을 오가며 에이전트를 관리하는 능력이 더 중요해진다는 관점이에요. 여기에 시스템 구조를 보는 눈과 설계 단계에서 위험을 알아차리는 감각이 붙어야 해요.

이 주장은 다소 강하게 들릴 수 있어요. 그래도 현장에서 이미 체감되는 부분이 있어요. LLM은 좋은 판단을 가진 사람에게는 배율 장치가 되지만, 나쁜 구조를 그대로 밀어붙이는 사람에게도 같은 속도를 줘요. 그래서 조직은 "누가 더 많은 코드를 만들었나"보다 "누가 더 읽기 쉬운 맥락과 안전한 경계를 남겼나"를 더 봐야 해요.

왜 중요한가요

AI 코딩 도구 이야기는 보통 생산성 수치로 흘러가요. 하지만 이 글은 생산성이 늘어난 뒤의 조직 운영 문제를 봐요. 사람이 읽을 수 있는 양은 그대로인데 산출물만 늘어나면, 개발팀은 더 빨라지는 대신 더 흐려질 수 있어요.

그래서 앞으로의 개발 조직은 두 가지를 같이 해야 해요. LLM이 마음껏 달릴 수 있는 안전한 영역을 만들고, 제품의 핵심 구조에는 더 엄격한 사람의 판단을 남겨야 해요. 속도를 얻으려면 아무 곳에나 AI를 붙이는 것보다, 어디까지 자동화하고 어디서 멈출지 먼저 정해야 해요. 2

참고 자료

1. LLM 시대의 엔지니어링 — GeekNews
2. LLM Oriented Engineering — Yair Weinberger