2023년 파리에서 열린 No Code Summit에서 저는 강연을 했고, 이후 저희 블로그에서 이를 심층 분석(deep dive)으로 발전시켰습니다. 그 핵심 주장은 틀린 것처럼 들릴 수도 있습니다. 기능을 만드는 데 가장 어려운 부분은 코드를 작성하는 것이 아니라는 점입니다. 15년 동안 앱 플랫폼을 구축하며 배운 사실입니다. 또한 현재 모든 이가 판매하고 있는 '완전한 자유(total freedom)'—즉, 로우 코드(raw code), 바이브 코딩(vibe-coding), 무엇이든 구축할 수 있다는 약속—가 아무도 내역을 세분화하지 않는 청구서와 함께 찾아오는 이유이기도 합니다. 제가 그 내역을 세분화해 보겠습니다.

코드를 작성하는 것은 결코 어려운 부분이 아니었다

당신이 단순하다고 생각하는 어떤 기능이든 가져와 보십시오. 예를 들어 아이템 리스트가 있다고 합시다. 이제 이를 공식화(formalize)해 보세요. 상태(states)를 정의하십시오: 로딩(loading), 빈 상태(empty), 에러(error), 오래된 데이터(stale) 등. 데이터를 가져오는(fetch) 도중 네트워크가 끊기면 어떻게 할지 결정하십시오. 누군가 아무도 요청하지 않은 방식으로 두 가지 옵션을 조합했을 때 어떻게 작동할지 결정하십시오. 상태를 명명하고 예외 상황(edges)을 찾아내는 그 작업, 바로 그곳에 노력이 집중되어 있습니다. 그 이후에 나오는 코드는 단순히 이를 옮겨 적는 전사(transcription) 과정일 뿐입니다.

저는 이것을 책을 통해 배운 것이 아닙니다. 이러한 공식화 작업이 제 팀의 실제 업무인 플랫폼을 15년 동안 구축하며 기능 하나하나를 통해 배웠습니다. 그리고 일단 이를 깨닫고 나면, 현재의 툴링(tooling) 논쟁이 실제로 무엇에 관한 것인지 보이지 않을 수 없습니다. 그것은 코드를 누가 타이핑하느냐(당신인가 아니면 AI인가)의 문제가 아닙니다. 그것은 누가 공식화(formalizing)를 수행하느냐의 문제입니다.

"완전한 자유"가 실제로 청구하는 비용

로우 코드(raw code)와 바이브 코딩(vibe-coding)은 완전한 자유를 판매합니다. 당신을 위해 결정된 것이 아무것도 없고, 한계도 없습니다. 기계적으로 말하면, 이는 모든 공식화 작업이 당신의 몫임을 의미합니다. 인증 전략(Authentication strategy), 상태 관리(state management), 캐싱 정책(caching policy), 에러 컨벤션(error conventions), 네비게이션 아키텍처(navigation architecture), 빌드 파이프라인(build pipeline)까지 말입니다. 이 중 어느 것도 당신의 제품이 아니지만, 이 모든 것이 이제 당신의 문제입니다. 단 한 번이 아니라 지속적으로 말입니다. 소프트웨어에서의 결정은 일회성 이벤트가 아니라 구독(subscription)입니다. 그 결정은 기억되어야 하고, 문서화되어야 하며, 코드 리뷰(code review)에서 방어되어야 하고, 매 OS 업데이트마다 재검토되어야 하며, 새로 합류하는 모든 사람에게 다시 설명되어야 합니다.

그리고 청구서의 날짜는 2년 차로 찍혀 있습니다. 첫날은 자유롭게 느껴집니다. 빠르게 움직이고, 모든 것이 가능하며, 아직 아무것도 망가지지 않았습니다. 청구서는 아무도 예산을 책정하지 않은, 당신이 직접 만든 (hand-rolled) 프레임워크의 업데이트가 필요할 때, 그리고 영리하게 만든 캐싱 레이어 (caching layer)를 이해하던 사람이 떠나고 난 뒤에 도착합니다. 바이브 코딩 (vibe-coding)은 이를 완화하는 것이 아니라 더욱 날카롭게 만듭니다. AI는 결정을 내리는 비용은 무너뜨렸지만, 그 결정을 책임지는 (owning) 비용은 그대로 남겨두었습니다. 이제 당신은 이 산업의 역사상 그 어느 때보다 빠르게 아키텍처 부채 (architecture debt)를 생성할 수 있습니다.

이 중 어느 것도 새로운 것은 아닙니다. 전형적인 버전은 10년 전의 것입니다. Choose Boring Technology에서 Dan McKinley는 모든 팀이 비표준적인 선택에 사용할 수 있는 약 3개의 "혁신 토큰 (innovation tokens)"을 받는다고 주장했습니다. 모든 이색적인 결정은 장기적인 유지보수 약속이기 때문입니다. 업계는 그의 청구서를 계속해서 재발견하고 있으며, 가장 최근에는 바이브 코딩의 기술 부채 (vibe-coding's technical debt)에 관한 포스트들의 물결 속에서 나타났습니다. 진단이 무엇인지가 중요한 것이 아닙니다. 부족한 것은 울타리 반대편에서의 관점입니다. 즉, 프레임워크가 대규모로, 수년간 당신을 대신해 정형화 (formalizing)를 수행할 때 어떤 모습인지에 대한 관점입니다. 그 관점에서 볼 때, McKinley의 자유 예산은 비유가 아닙니다. 그것은 구체적인 숫자를 가지고 있습니다.

설계된 중간 지대 (The engineered middle)

그 관점을 보여드리겠습니다. 먼저, 제가 의도적으로 넓은 의미로 사용하는 "프레임워크 (framework)\

AI는 이러한 입장을 약화시킨 것이 아니라 오히려 강화했습니다. 당신이 무엇을 만들든, 대부분은 이미 정형화된 형태(formalized form)로 어딘가에 존재합니다: 목록(lists), 계정(accounts), 검색(search), 푸시(push), 결제(payments) 등 말이죠. 이 기능들은 수년간의 프로덕션(production) 환경을 통해 연구되고, 최적화되었으며, 디버깅(debugged)되었습니다. 이것들을 다시 만드는 것은 자유 예산(freedom budget)을 사용하는 가장 최악의 방법입니다. 합리적인 분할 방식은 그 90%를 있는 그대로 상속받고, 당신의 토큰을 진정으로 당신만의 것, 즉 어떤 플랫폼도 예측할 수 없었던 단 하나의 부분에 사용하는 것입니다. 그리고 그 부분은 이제 프레임(frame) 내부의 전용 섹션에서 바이브 코딩(vibe-code)할 수 있습니다. 이것이 AI 시대에 탈출구(escape hatches)가 되는 방식입니다. 또한 프레임은 비용을 제한된 범위 내로 유지합니다. 만약 당신의 커스텀 부분이 잘못된 아이디어로 판명되더라도, 그 영향 범위(blast radius)는 앱 전체가 아닌 단 하나의 섹션에 그칩니다.

이런 관점에서 보면, 프레임워크(framework)를 채택하는 것은 자유를 포기하는 것이 아닙니다. 그것은 당신이 직접 수행하지 않아도 될 10년 치의 정형화(formalization)를 획득하는 것입니다.

15년 동안 지켜온 선

마지막으로 한 가지만 더 말씀드리겠습니다. 왜냐하면 "중간(the middle)"이라는 말이 마치 아무런 입장도 취하지 않을 때 취하는 태도처럼 들릴 수 있기 때문입니다.

제가 만드는 플랫폼은 2011년부터 이 선을 지켜왔습니다. 프로젝트들이 서로 유사한 부분에서는 주관(opinionated)을 가지고, 그렇지 않은 부분에서는 개방적(open)입니다. 이 선을 무효화할 것처럼 보였던 모든 파도 속에서도 15년 동안 유지되었습니다. 가장 끈질겼던 것은 하이브리드 프레임워크(hybrid frameworks)였습니다. 이들은 회사가 존재해 온 기간 내내 몇 년마다 새로운 이름으로 우리의 대체재라고 발표되어 왔지만, 그때마다 우리는 네이티브(native)라는 동일한 결정을 내렸습니다. 그리고 이제는 지금까지 중 가장 강력한 자유의 서사인 AI 생성(AI generation)이 왔습니다. 각 파도는 '방법(how)'을 옮겨 놓았습니다. 하지만 경제적 논리는 결코 변하지 않았습니다: 누군가는 모든 정형화(formalization)에 대해 비용을 지불해야 합니다. 유일한 실제 선택지는 당신의 제품을 당신만의 것으로 만드는 부분에 비용을 지불할 것인지, 아니면 그 모든 것에 비용을 지불할 것인지의 여부뿐입니다.