'팀도 없고, 투자도 없고, SaaS 경험도 없었다. 그냥 나, AI 도구 3개, 그리고 30일.' dev.to에 올라온 솔로 빌더의 회고록은 단숨에 공유되기 시작했다. 인증, DB, 결제, 대시보드, 랜딩페이지, 이메일 알림까지—한 달 안에 혼자 완성한 SaaS. 같은 시기, OpenAI는 Codex 대규모 업데이트를 공개했다. 컴퓨터 직접 제어, 90개 이상의 플러그인, 장기 작업 자동 스케줄링, 메모리 기능까지. 두 소식이 같은 날 타임라인에 나란히 뜨는 걸 보면서 나는 이런 생각이 들었다. '이제 진짜 장벽은 만드는 속도가 아니구나.'
솔로 빌더의 실전 워크플로우는 생각보다 정교했다. Claude로 설계하고, Copilot으로 코드를 빠르게 쓰고, 다시 Claude로 리뷰하는 3단계 파이프라인. 특히 코딩 시작 전 이틀을 Claude와의 대화로만 썼다는 부분이 인상적이다. 최소 DB 스키마를 함께 설계하고, v1에 필요 없는 기능을 쳐냈다. '그 대화가 나중에 3개 기능을 안 만들게 해줬다'는 회고는 AI 워크플로우의 핵심을 찌른다. AI는 속도 도구이기 전에 범위 통제 도구다.
Codex 업데이트를 둘러싼 Hacker News 반응은 흥미롭게도 기능 자체보다 '무엇을 위한 도구인가'에 집중됐다. '코드를 숨기려는 경향이 강해졌다', '프롬프트가 진짜 소스고, 코드는 귀찮은 중간 산출물처럼 다뤄진다'는 관찰은 도구의 진화 방향을 날카롭게 짚는다. 반면 '코드 구조를 머릿속에 두고 AI와 페어 프로그래밍하듯 대화하면 결과물이 내가 직접 쓴 코드처럼 나온다'는 반론도 있었다. 추상화 층위가 높아질수록, 개발자의 역할이 '쓰는 사람'에서 '설계하는 사람'으로 이동한다는 신호다.
여기서 세 번째 글이 개입한다. dev.to의 'As We May Code'는 Vannevar Bush의 1945년 에세이 "As We May Think"를 소환하며 근본적인 질문을 던진다. 소프트웨어는 논리 문제처럼 보이지만, 실제로는 인간 중심의 설계 문제라는 것. Fred Brooks가 1986년 구분한 두 종류의 복잡성이 여기서 다시 유효해진다. 도구가 제거할 수 있는 우발적 복잡성과, 문제 자체에서 오는 본질적 복잡성. AI가 아무리 빠르게 코드를 생성해도, '누구를 위해 무엇을 만드는가'라는 본질적 복잡성은 줄어들지 않는다.
이 프레임으로 솔로 SaaS 사례를 다시 보면, 성공의 이유가 다르게 읽힌다. 30일 빌드가 가능했던 건 AI 도구가 빠르기 때문만이 아니었다. 문제 정의가 선명했기 때문이다. 'AI API로 개발하는 사람들이 프롬프트를 테스트하고 비교할 수 있는 플레이그라운드'—타깃 사용자, 핵심 기능, 과금 구조가 Day 1에 이미 결정되어 있었다. AI는 그 위에서 가속 페달을 밟았을 뿐이다. 문제 정의 없이 Codex에게 '앱 만들어줘'를 입력하면, 더 빠르게 잘못된 방향으로 달릴 수 있다.
인터페이스를 '사악한 문제(wicked problem)'로 규정한 Horst Rittel의 개념도 여기서 맞닿는다. 정답이 없고, 풀수록 문제가 바뀌며, 같은 해결책이 다른 맥락에선 실패한다. 색상 선택 하나가 저시력 사용자를 배제하고, 모달 다이얼로그 하나가 키보드 사용자를 가두는 것처럼. Codex가 프론트엔드 반복 작업을 빠르게 처리할 수 있어도, '이 버튼이 어디 있어야 하는가', '이 알림이 사용자를 압박하는가'라는 판단은 여전히 사람의 몫이다. AI는 <div>를 <button>으로 바꿔줄 수 있지만, 왜 버튼이어야 하는지를 알지는 못한다.
실천적인 시사점으로 좁혀보면, 솔로 빌더든 팀이든 AI 워크플로우에서 먼저 세워야 할 것은 세 가지다. 첫째, 문제 정의 문서—누가, 어떤 상황에서, 왜 이 제품을 쓰는가. 이걸 Claude와 나눈 대화로 만들어도 좋다. 둘째, 범위 통제—v1에 없어도 되는 기능을 명시적으로 쳐내는 의사결정. 솔로 빌더가 2일을 계획에 쓴 이유가 바로 이것이다. 셋째, 검증 트리거—무엇이 확인되면 다음 단계로 넘어갈 것인가. Codex가 장기 작업을 자동 스케줄링하는 시대에, 인간이 붙잡아야 할 체크포인트를 미리 설계해두지 않으면 에이전트는 그냥 계속 달린다.
전망은 분명하다. Codex의 업데이트 방향—컴퓨터 직접 제어, 90개 플러그인, 장기 작업 지속성—은 '만드는 것'의 마찰을 계속 줄여갈 것이다. 솔로 빌더가 30일에 SaaS를 만들 수 있다면, 내년에는 2주가 될 수도 있다. 하지만 Bush가 80년 전에 그은 선은 여전히 유효하다. 기술은 인간의 사고를 대체하는 것이 아니라 증폭해야 한다. 속도가 빨라질수록, '무엇을 증폭하고 있는가'를 묻는 시간은 오히려 더 길어져야 한다. 빠르게 만들 수 있다는 것과, 만들 가치가 있는 것을 알고 있다는 것은—여전히 전혀 다른 능력이다.