몇 주 전, 저는 2년 동안 쌓아온 작업물을 삭제했습니다.

저와 고객들을 위해 매일 실행되는 34개의 자동화 프로세스들 말입니다. WhatsApp AI 봇, Facebook 및 웹 양식을 통한 리드 캡처 (lead capture), PDF 보고서 생성, 캘린더 예약, CRM 동기화, 알림 기능까지. 이 모든 것들은 동일한 방식으로 구축되었습니다. 시각적 캔버스 위에 박스를 하나씩 드래그 앤 드롭하는 방식이었죠.

저는 그 전부를 삭제하고 코드로 다시 작성했습니다.

이 글은 "노코드는 나쁘다"라는 내용의 글이 아닙니다. 제가 사용했던 시각적 플랫폼(n8n)은 진정으로 훌륭한 오픈 소스(open-source)이며, 지난 몇 년간 빠른 배포를 가능하게 해주었습니다. 하지만 시스템이 커지면서, 저는 무언가를 구축하는 대신 도구와 싸우기 시작했습니다. 그래서 제 사례에서 왜 코드 우선(code-first) 방식이 승리했는지, 그 결과로 나온 수치들, 그리고 무엇보다 중요한—과장된 광고에는 관심이 없기에—개선되지 않은 부분들에 대해 이야기해보고자 합니다.

"코드 우선" 방식이 실제로 변화시킨 것들

유행어를 제외한 전/후 비교는 다음과 같습니다.

유지보수 (Maintenance). 이전에는 변경 사항이 생길 때마다 브라우저를 열고, 다이어그램 안에서 적절한 노드(node)를 찾아 드래그해야 했습니다. 이제 모든 변경 사항은 코드 한 줄과 git 커밋(git commit)입니다. 전체 이력, 실제 차이점(diffs), 코드 리뷰, 그리고 무언가 고장 났을 때 즉각적인 롤백(rollback)이 가능합니다.

구축 (Building). 이전에는 새로운 자동화가 생길 때마다 캔버스 위에서 처음부터 조립해야 했습니다. 이제 저는 타입이 지정된(typed) 재사용 가능한 모듈을 구성합니다. 더 빠르고, 전체 시스템에 걸쳐 일관성을 유지합니다.

제어 (Control). 로직은 명시적으로 작성된 저의 것입니다. 박스 뒤에 숨겨진 마법도, 예상치 못한 상황도 없습니다.

종속성 없음 (No lock-in). 이는 개방형 형식의 표준 코드입니다. 특정 플랫폼의 JSON 스키마(JSON schema)에 얽매이지 않고 어디에서나 실행됩니다.

저는 DBOS를 기반으로 구축했습니다. 이는 일반적인 TypeScript로 작성된 워크플로우를 실행하며, Postgres를 백엔드로 사용하고, 내장된 내구적 실행(durable execution) 기능을 갖춘 프레임워크입니다. 이에 대한 자세한 내용은 아래에서 다루겠습니다.

수치들

여전히 저를 미소 짓게 만드는 핵심 수치는 다음과 같습니다:

메모리: 약 1.4GB에서 약 150MB로 감소. 대략 10배 차이.

동일한 34개의 자동화, 동일한 작업량임에도 점유율은 10분의 1로 줄었습니다. 유휴 상태(idle)에서 새로운 스택은 약 48MB를 차지합니다. 이제 더 작고 저렴한 서버로도 충분한 확장성을 확보한 채 동일한 부하를 처리할 수 있습니다.

몇 가지 더 구체적인 수치를 살펴보겠습니다:

지표 (Metric)	결과 (Result)
처리량 (Throughput)	~1,167 workflows/second
...

이전에는 메모리가 어디로 사라졌을까요? 부하 상황에서 확장성을 확보하기 위해 워커 프로세스 (worker processes)와 큐 레이어 (queue layer)를 추가해야 했고, 각각의 요소가 더 많은 RAM을 소모했습니다. 이제는 베이스가 매우 가벼워져서 대부분의 경우 메모리 사용량에 대해 논할 필요조차 없습니다.

솔직한 이야기 (과장된 홍보를 싫어하니까요)

봇 자체의 응답 속도가 빨라진 것은 아닙니다. 그 이유는 다음과 같습니다. 봇이 대규모 언어 모델 (LLM)과 대화할 때, 속도를 결정하는 것은 주변 인프라가 아니라 LLM이기 때문입니다. 모델의 "생각" 시간은 정해져 있으며, 런타임 (runtime)을 교체한다고 해서 그 시간이 변하지는 않습니다.

그렇다면 제가 실제로 얻은 것은 무엇일까요? 숨 쉬는 듯 여유로운 서버, 훨씬 더 높은 동시성 (concurrency), 그리고 더 낮은 인프라 비용입니다. 단일 응답의 지연 시간 (latency)이 아니라, 안정성과 효율성을 얻은 것입니다. 만약 누군가 런타임 교체 덕분에 자신의 AI 봇이 "즉각적 (instant)"으로 변했다고 말한다면, 회의적으로 바라보십시오.

혼자서 이 모든 것을 해낸 방법

34개의 라이브 자동화 프로세스를 동작 방식이 동일하게 유지하며 코드로 변환하고, 각각을 테스트하며, 단 한 명의 고객도 눈치채지 못하게 프로덕션 (production) 환경에 배포하는 것은 혼자서 할 수 있는 일이 아닙니다. 역사적으로 이는 팀 단위로 몇 주에 걸쳐 수행되는 작업입니다.

저는 Claude Code와 함께 작업하며 이를 혼자 해냈습니다.

실제로 이는 시니어 엔지니어처럼 코드를 읽는 도구와의 대화였습니다. 이 도구는 제가 기존의 각 자동화 프로세스를 이해하고, 이를 TypeScript로 다시 작성하며, 프로덕션에 반영하기 전에 버그를 잡고, 각 흐름을 원본과 대조하여 검증하는 것을 도와주었습니다. 저는 지시하고, 결정하고, 승인하며, 도구는 힘든 작업을 빠르게 수행합니다.

그리고 마이그레이션 자체는 외부 세계에 전혀 드러나지 않았습니다. Caddy 리버스 프록시 (reverse proxy)가 WhatsApp, 웹훅 (webhooks), 양식 (forms) 등 모든 인바운드 트래픽을 라우팅하므로, 모든 송신자는 동일한 엔드포인트 (endpoints)에 계속 접속할 수 있었습니다. 저는 비행 중 엔진을 교체한 것이며, 아무도 눈치채지 못했습니다.

시사점

여기서 진짜 이야기는 DBOS 대 n8n의 대결이 아닙니다. 한계치 (ceiling) 자체가 높아졌다는 것입니다.

수년 동안 우리 모두는 한계 안에서 일하는 법을 배웠습니다. "직접 작성하기에는 너무 복잡하다", "팀이 필요하다", "몇 주를 투자할 가치가 없다"와 같은 것들 말입니다. 그러한 한계 중 상당수는 그저 조용히 사라졌지만, 우리의 습관은 아직 그 속도를 따라잡지 못했습니다.

그래서 제가 지금 스스로에게 계속 던지는 질문은 "이미 하고 있는 일을 어떻게 하면 조금 더 빠르게 할 수 있을까?"가 아닙니다. 바로 **"기술적 장벽이 없다면 나는 무엇을 만들 것인가?"**입니다. 제가 언젠가 하겠다고 적어둔 목록의 절반은 오늘날 이미 손에 닿을 수 있는 범위 안에 있다는 사실이 드러나고 있습니다.

다음 글: 실제 코드를 곁들인, 이번 마이그레이션(migration)을 가치 있게 만든 단 하나의 기능 — exactly-once durable execution (정확히 한 번의 내구성이 있는 실행) — 에 대한 기술적 심층 분석.

노코드(no-code)에서 코드 우선(code-first) 방식으로 무언가를 옮겨본 적이 있나요? 무엇이 당신을 결정하게 만들었나요? 진심으로 여러분의 이야기를 듣고 싶습니다.