직접 구축해야 할까요?

지금 이 순간, 어디에서나 일어나고 있는 이야기입니다. 한 주니어 엔지니어가 오후 한나절 만에 결제 시스템을 출시합니다. Stripe, Postgres, Redis, 작업 큐(job queue), 웹훅 핸들러(webhook handler). 하루가 끝나기도 전에 이 모든 것이 완성되었습니다.

2019년이었다면 이는 분기 단위의 업무였습니다. 엔지니어 세 명, 벤더 비교 테스트(vendor bake-off), 그리고 Kafka가 정말 필요한지에 대해 논쟁하는 위키(wiki) 페이지가 필요했죠.

오후에 만든 버전은 데모에서는 잘 작동했습니다. 하지만 2주 후, 새벽 2시에 누군가에게 호출(paging)을 보내게 되었습니다.

어떤 일이 일어났는지 설명하겠습니다. 주니어 엔지니어는 Claude Code를 열고 앱에 대해 설명했습니다. Claude는 결제를 위해 Stripe를, 주문을 위해 Postgres를, 세션을 위해 Redis를, 백그라운드 작업을 위해 BullMQ를, 그리고 웹훅을 전파(fan out)하기 위해 SQS 큐를 연결했습니다. 모든 조각이 연결되었습니다. 결제 버튼은 작동했고, 영수증도 도착했습니다. 데모는 깔끔했습니다.

그 후 실제 트래픽이 유입되었습니다. 영수증 이메일이 결제와 동일한 동기식 경로(synchronous path)로 발송되었는데, 이메일 제공업체의 서비스가 느려진 오후가 되자 결제 요청들이 이메일 전송을 기다리며 대기(hang)하다가 타임아웃(timeout)이 발생했습니다. 사용자들은 로딩 스피너를 보다가 포기하고 다시 '구매'를 눌렀습니다. 그중 일부는 이중 결제가 되었습니다. 이 중 어떤 것도 데모에서는 나타나지 않았습니다. 모든 것이 프로덕션(production) 환경에서 나타났습니다.

코드가 문제는 아니었습니다. 코드는 훌륭했습니다. Claude는 지저분한 코드를 작성하지 않습니다. 문제는 각 도구가 수행하는 작업에 적합한 기본 단위(primitive)인지, 혹은 도구 5개가 정말 필요한지 아무도 묻지 않았다는 점입니다.

여기에 변화가 있으며, 이것이 핵심입니다. 2019년의 병목 현상(bottleneck)은 구축하는 것이었습니다. 결제 프로세서를 연결할 수 있는가? 큐를 실행할 수 있는가? 업무는 조립(assembly)에 있었습니다.

2026년에는 조립이 무료입니다. Claude가 한 세션 만에 해냅니다. 병목 현상은 상류(upstream)로 이동하여, 기술적인 정답이 없는 질문으로 옮겨갔습니다. '이것이 과연 존재해야 하는가? 만약 존재해야 한다면, 그것은 실제로 무엇으로 구성되어야 하는가?'

도구(Tools)는 설계의 단위가 아닙니다. 당신이 지금까지 사용해 온 모든 시스템의 밑바닥에는 일곱 가지의 기본 요소(Primitives)가 있습니다. Stripe는 외부 서비스(External Service)입니다. Redis는 키-값 저장소(Key-Value Store)입니다. SQS는 큐(Queue)입니다. 작업 실행기(Job runner)는 워커(Worker)입니다. 도구의 이름을 부를 때, 당신은 브랜드를 부르는 것입니다. 기본 요소의 이름을 부를 때, 당신은 결정(Decision)을 내리는 것입니다: 누가 기다릴 것인가, 무엇이 실패할 것인가, 그리고 언제 실행될 것인가를 말입니다.

이것이 바로 AI 네이티브 패턴(AI-native patterns)이 보기보다 그리 새롭지 않은 이유이기도 합니다. LLM은 Stripe가 차지하는 것과 동일한 위치인 외부 서비스(External Service)로서 당신의 아키텍처(Architecture)에 등장합니다. 모든 팀이 앞다투어 구축하려는 RAG는 임베딩(Embeddings)을 보유한 벡터 데이터베이스(Vector Database), 소스 문서를 보유한 파일 저장소(File Store), 그리고 이들을 모델에 연결하는 서비스(Service)입니다. 2년 전에는 흔치 않았던 구성이지만, 이미 당신이 알고 있는 세 가지 기본 요소입니다. 이름은 새로워졌을지 모르나, 형태는 그렇지 않습니다.

액세스 패턴(Access pattern)에 잘못된 기본 요소를 선택한다면, 더 많은 도구를 추가한다고 해서 구원받을 수 없습니다. 그것은 더 많은 배선(Wiring) 아래에 실수를 파묻을 뿐입니다.

2026년에 가장 흔히 발생하는 잘못된 행보는 가장 쉬운 길을 택하는 것입니다. 구축 비용이 들지 않을 때, 모든 본능은 새로운 것을 찾으라고 말합니다. 캐시(Cache)가 필요한가요? Redis를 추가하세요. 검색(Search)이 필요한가요? 벡터 데이터베이스를 추가하세요. 큐(Queue)가 필요한가요? SQS를 추가하세요. 각 추가 사항은 컴파일이 되고 데모(Demo)가 가능하기 때문에 마치 진전처럼 느껴집니다.

시니어 엔지니어의 행보는 그 반대입니다. 무언가를 추가하기 전에, 시니어 엔지니어는 한 가지 질문을 던집니다: '일곱 가지 중 내가 이미 사용 중인 것이 있는가, 그리고 그중 하나가 이미 이것을 커버할 수 있는가?' 대부분의 경우 하나는 가능합니다. 주니어 엔지니어는 결국 다섯 개의 도구를 갖게 됩니다. 시니어 엔지니어는 이미 가지고 있던 두 개의 기본 요소로 동일한 작업을 완수하며, 실패할 수 있는 가동 부품(Moving parts)이 절반뿐인 시스템을 갖게 됩니다.

절제(Restraint)가 희소한 기술이 되었습니다. 구축하는 것이 어렵기 때문이 아닙니다. 이제는 구축하는 것이 너무나 쉬워졌기에, 당신과 무분별하고 취약한 시스템 사이를 가로막는 유일한 장애물은 '다음 것을 추가하지 않겠다'는 절제력뿐이기 때문입니다.

Course 1에서 저는 정확히 7개의 프리미티브 (primitives)를 가르칩니다. 이 고정된 개수는 제가 사과해야 할 제한 사항이 아닙니다. 그것이 바로 핵심입니다. 메뉴가 짧을 때, 당신은 매 순간 신중하게 선택할 수밖에 없습니다. 새로운 도구 뒤에 잘못된 결정을 숨길 수 없습니다. 왜냐하면 손을 뻗어 잡을 새로운 도구가 없기 때문입니다. 7개가 전부입니다. 당신은 그것들을 조합 (compose) 합니다.

AI는 엔지니어를 쓸모없게 만들지 않았습니다. AI는 조립 (assembly)을 무료로 만들었고, 모든 가치를 판단 (judgment)으로 옮겨 놓았습니다. 더 많은 것을 연결한다고 해서 이기는 것이 아닙니다. 당신이 이미 무엇을 가지고 있는지 아는 것으로 승리하는 것입니다.

추신: 가장 어려운 부분은 더 이상 도구들을 서로 연결하는 것이 아닙니다. 각 작업에 실제로 어떤 프리미티브 (primitive)가 필요한지 선택하는 것입니다. 저는 바로 그 목적을 위해 사용하는 의사결정 프레임워크 (decision framework)를 다음과 같이 작성했습니다: systemthinkinglab.ai/learn/building-blocks/decision-framework/