라이브 리포트: 이 정도 속도라면 이론을 세울 게 아니라 제거해야 합니다

4월 15일부터 4월 30일까지. 2주간. 혼자서. 그리고 AI와 함께.

이것은 회고가 아닌 라이브 리포트 (Live report)입니다.

이 시리즈의 이전 포스트들은 형태 (shape)에 관한 것이었습니다: 계약, 패턴, 그리고 혼자서 구축해 온 24년의 세월 말입니다. 이번 포스트는 그 형태에 AI가 추가되고 속도가 변할 때 어떤 일이 일어나는지에 관한 것입니다.

저는 여전히 그 과정 속에 있는 상태에서 이 글을 쓰고 있습니다. 형태는 유지되었습니다. 하지만 속도는 유지되지 않았습니다.

내가 구축한 것

2주. 1명. 미화하지 않은 담백한 목록은 다음과 같습니다:

API 게이트웨이 (API gateway): Zuplo를 사용하여 5개의 서비스를 하나의 공개 API 뒤로 통합
커스텀 도메인 (Custom domains): 프로덕션용 gw.ldxhub.io, 개발자 포털용 gw.portal.ldxhub.io
개발자 포털 (DevPortal): API 레퍼런스 자동 생성, 소개, 서비스별 가이드, 가격 책정, MCP 설정, "어디서든 사용 가능" 포함
인증 (Auth): Google OAuth, GitHub OAuth, 이메일을 포함한 Auth0 — 가입부터 첫 호출까지 약 30초 소요
무료 티어 (Free tier): 월 25,000 크레딧, 신용카드 불필요
결제 (Billing): 통합 크레딧 시스템, 크레딧당 $0.0001, 4가지 플랜 (Free, Starter $15, Standard $50, Pro $150), 초과 사용량은 동일한 요율로 청구
Stripe 연동: 유료 플랜 구독 및 초과 사용량 정산을 위해 연결됨
비동기 미터링 파이프라인 (Async metering pipeline): 작업이 완료된 후 ( 202 Accepted 이후 몇 분 또는 그 이상 경과 후) 크레딧 소비를 실행하는 별도의 경로, 게이트웨이의 결제 API로 배치 처리됨
5개 서비스 배포: StructFlow, RefineLoop, RenderOCR, CastDoc, ExtractDoc
4개 채널 통합: n8n 노드 (마켓플레이스에서 검증됨), Dify 플러그인 (검증됨, 다국어 지원), Claude Desktop과 같은 AI 어시스턴트를 위한 MCP, 그리고 직접 API
마케팅 페이지: 기업 랜딩 페이지 (LP) (ldxlab.io/ldxhub 및 서비스별 페이지)에 4개의 제품 페이지를 구축했으며, 각 페이지는 개발자 포털로 연결됨
8개의 예정된 아티클: 디자인 철학을 다루는 dev.to 및 Zenn의 아티클. 이 글은 다섯 번째 아티클입니다.

이것은 표면적인 내용입니다. 그 어떤 것도 화려하지 않습니다. 이 모든 것들은 반드시 완료되어야 했습니다.

형태는 유지되었다

이전 포스트들에서 보여준 형태는 변하지 않았습니다.

작업(Jobs)이 들어옵니다. API가 작업을 보유합니다. API는 재시도(retries)가 필요한 모든 것을 재시도합니다. API는 보고할 실제 결과가 있을 때 보고합니다. 2003년 음악 플랫폼과 2006년부터 2014년까지의 e-book 플랫폼을 구동했던 것과 동일한 형태가, 이제는 구조화된 추출(structured-extraction) 서비스와 다른 네 개의 서비스를 감싸고 있습니다.

변한 것은 그 내부의 속도였습니다.

무엇이 빨라졌고, 무엇이 변하지 않았는가

빨라진 것:

API 설계 반복 (API design iteration) — 모든 인터페이스는 자리를 잡기 전까지 세 번 또는 네 번의 형태를 거쳤습니다.
4개 국어(영어, 일본어, 중국어, 포르투갈어) 문서화 — 마켓플레이스 플러그인(marketplace plugins)에서 요구했고, 순차적으로 진행할 시간이 없었기 때문입니다.
예외 케이스(Edge-case)의 언어화 — "만약 입력값에 inputs와 file_id가 모두 누락되면 어떻게 되나요?"와 같은 질문에 대해, 질문이 나온 바로 그 시간 안에 서면으로 답변이 이루어졌습니다.
마켓플레이스 플러그인 온보딩 (n8n, Dify) — 제출, 검토, 버전 업데이트 (version bumps).
마이그레이션 (Migrations), 픽스처 (fixtures), 건전성 검사 (sanity checks)

변하지 않은 것:

과금 구조 (billing structure)에 대한 결정
통합 경계(integration boundary)를 어디에 설정할 것인가 (어떤 엔진을 사용할지, 어떤 접면(surfaces)을 사용할지)
무엇을 출시하고 무엇을 건너뛸 것인가
무엇을 레거시 내부 API (legacy internal API)에 남겨두고 무엇을 공개 서비스 (public service)로 만들 것인가

AI는 판단력을 대체하지 않았습니다. AI는 타이핑의 대부분을 대체했습니다.

(대부분 말입니다. 공개 서비스를 레거시 내부 API와 연결하는 래퍼(wrappers)들은 제가 직접 타이핑했습니다. 그것들은 작고 지루했으며, 이 일을 24년 동안 해오며 제 머릿속에 그려온 바로 그 형태였습니다. 설명하는 것보다 타이핑하는 것이 더 빨랐습니다.)

무엇이 가장 어려웠는가

제가 거의 포기할 뻔했던 부분은 비동기 작업 (async jobs)에 대한 크레딧 미터링 (credit metering)이었습니다.

대부분의 API 게이트웨이는 요청(request) 단위로 미터링을 합니다. 이는 쉽습니다. 제가 필요했던 것은 작업이 완료되었을 때 미터링을 하는 것이었습니다. 이는 요청이 202 Accepted를 반환한 후 몇 분(또는 그보다 훨씬 더 긴 시간)이 지난 시점입니다.

저는 두 개의 게이트웨이 (gateway)를 평가했습니다. 서류상으로는 둘 다 비동기 리포팅 (async reporting)이 가능했습니다. 첫 번째 것은 끝까지 테스트해 보았습니다. API도 있었고 문서도 있었지만, UI와 운영 동작 (operational behavior)이 무시하기 어려울 정도로 거칠었습니다. 저는 두 번째 것을 원했습니다. 그래서 다시 돌아갔습니다.

두 번째 게이트웨이가 제가 정착하고 싶은 곳이었습니다. 하지만 막상 도착했을 때, 제가 필요로 하는 비동기 미터링 (async metering)이 실제로 가능한지 확신할 수 없었습니다. 정확히 그 부분에 대한 문서가 부실했습니다. 고객 지원 봇 (support bot)을 이용해 보았지만, 봇도 알지 못했습니다. 그러자 사람이 개입했고, 그 사람은 작업 완료 (job-completion) 측면에서 미터링 이벤트 (metering events)를 배치 (batched) 방식으로 어떻게 발생시키는지 안내해 주었습니다.

성공했습니다.

이번 빌드 과정에서 상대방이 확인해 줄 때까지 가능 여부를 알 수 없었던 유일한 부분이 바로 이것입니다. 저는 이 점을 기억하고 싶습니다. 24년 동안 혼자 빌드해 왔지만, 이 특정한 미지의 영역을 통과하는 가장 빠른 방법은 혼자 알아내는 것이 아니라, 질문을 던지고 상대방이 제대로 답변해 주는 것이었습니다.

(Stripe와 관련해서도 작은 실수가 있었습니다. 게이트웨이의 빌링 플로우 (billing flow)를 작동시키려면 Stripe 측에서 무언가를 설정해야 한다고 가정했습니다. 저는 그 '무언가'를 찾느라 한참을 시간을 보냈습니다. 하지만 그런 것은 없었습니다. 게이트웨이가 엔드 투 엔드 (end-to-end)로 처리했고, Stripe는 그저 전달받은 것을 받았을 뿐입니다. 때때로 "이것을 어떻게 통합(integrate)하나요?"라는 질문에 대한 답은 "이미 하셨습니다"일 때가 있습니다.)

결정의 양 (The decision volume)

이 부분이 저를 놀라게 했습니다.

출력량이 극적으로 증가했습니다. 그건 예상했던 바입니다. 제가 예상하지 못한 것은 결정 (decisions)과 분기 (branches)의 양이 그와 함께 배로 늘어났다는 점입니다. 각각의 결정은 개별적으로 종결되어야 하며, 이를 피할 방법은 없습니다. 각 결정을 종결하는 속도 또한 빨라졌기에, 그 중 어느 것도 병목 현상 (bottleneck)이 되지 않았습니다.

하지만 피로감의 종류가 다릅니다.

저는 24년 동안 혼자서 무언가를 만들어 왔습니다. 피로가 어떤 느낌인지 잘 압니다. 하지만 이것은 다른 종류의 것입니다. 속도가 모든 것—질문, 답변, 작은 수정 사항들—을 아무것도 안착할 시간이 없는 창(window) 안으로 압축해 버립니다. 당신은 결코 어떤 단계(phase)에 머물지 못합니다. 당신은 항상 이음새(seam)에 서 있습니다.

24년 동안 혼자 일하며 예상하지 못했던 점이 하나 있습니다. 예전에는 브랜치(branch)를 놓치는 것에 대해 걱정하지 않았습니다. 결정의 양이 항상 한 사람의 머리가 담을 수 있는 범위 내에 있었기 때문입니다. 하지만 이제 출력량이 배가되면서 새로운 두려움이 생겼습니다. 다른 다섯 가지 일을 마무리하는 동안, 고려했어야 할 무언가가 빠져나갔을지도 모른다는 두려움입니다. 경로는 계속 움직이고 인접한 브랜치들은 계속 넓어지며, 저는 확정(commit)하기 전에 그 모든 것을 보고 싶어 합니다. 이전에는 존재하지 않았던 두려움입니다. 마비될 정도는 아니지만, 분명히 존재합니다.

이에 대해 어떻게 해야 할지에 대한 명확한 답은 가지고 있지 않습니다. 하지만 이것이 중요해 보이고, 제가 읽어온 AI 도구(AI-tooling) 관련 기사들에는 다뤄지지 않았기에 보고합니다.

이론이 아닌 제거

제가 계속 유지하고 싶은 부분은 이 대목입니다.

이 정도 속도에서는 이론을 세우지 않습니다. 제거합니다.

모든 옵션을 모델링하거나, 회의에서 트레이드오프(tradeoffs)를 따져보거나, 발표 자료(deck)를 만들 시간이 없습니다. 당신은 어떤 것을 한 시간 동안 손에 쥐고, 그것이 다음 요소와 접촉했을 때 살아남는지 확인한 뒤, 유지하거나 제거합니다. 살아남는 것은 당신이 논쟁할 시간조차 없었던 것들입니다.

이것은 생산성에 대한 주장이 아닙니다. 하나의 묘사입니다.

마찰(friction)이 충분히 낮아질 때—타이핑이 더 이상 속도 제한 요소(rate-limiter)가 아닐 때—의사결정이 내려지는 방식이 바뀝니다. 결정은 어떤 것이 무엇을 가능하게 할 것인가가 아니라, 어떤 것이 무엇을 지원하지 못하는가, 즉 제거를 통해 내려집니다. 부정적인 사례(negative case)가 긍정적인 사례(positive case)보다 더 크게 들립니다. 당신은 "이것을 추가하면 어떨까?"라고 묻는 것을 멈추고, "이것 때문에 나중에 무엇을 제거하기가 더 어려워질까?"라고 묻기 시작합니다.

이것이 일반화될 수 있는지는 모르겠습니다. 다만 지난 2주 동안 제게 일어난 일은 이러했습니다.

결론

속도는 미덕이 아닙니다. 그것은 단지 마찰 (friction)이 사라졌을 때 발생하는 현상일 뿐입니다. 24년이 지난 지금, 제게 남은 마찰은 대부분 타이핑 (typing)이었습니다.

저는 타이핑을 제거했습니다. 형태는 이미 존재하고 있었습니다.

피로감 또한 이 리포트의 일부입니다.

Claude (Opus)로 제작되었습니다.

Resources

LDX hub 개발자 포털: gw.portal.ldxhub.io
n8n 통합: npm의 n8n-nodes-ldxhub
Dify 플러그인: Dify Marketplace의 LDX hub on Dify Marketplace
MCP 엔드포인트 (endpoint): gw.ldxhub.io/mcp

이 시리즈의 이전 글들: