제가 매일 사용하지만 하나의 제품으로 존재하지는 않는 작은 소프트웨어가 하나 있습니다. 이 소프트웨어는 저의 개인용, 업무용, 컨설팅용 캘린더(Calendar)를 감시하며, 바쁜 시간대를 모든 캘린더에 복사합니다. 덕분에 누군가가 어떤 캘린더 하나만 보더라도, 실제 바쁜 일정이 다른 곳에 있더라도 제가 언제 시간이 안 되는지 알 수 있습니다. 유료 도구들이 정확히 이 기능을 수행합니다. 저는 유료 도구들을 살펴본 뒤, Claude Code와 함께 저녁 시간을 보내며 스케줄에 따라 실행되는 스크립트(Script)와 루틴(Routine)을 작성했습니다. 그것은 몇 달 동안 조용히 실행되어 왔습니다. 저는 그것이 거기 있다는 사실조차 거의 잊고 지냅니다.

마지막 문장이 이 글의 핵심이지만, 천천히 이야기를 풀어보겠습니다.

지금 당장 유혹적인 결론, 즉 순간이 당신을 계속해서 몰아붙이는 결론은 극단주의적인 것입니다. Claude Code나 Codex와 같은 에이전트(Agent)가 있다면 거의 무엇이든 갑자기 손에 닿을 수 있는 범위에 들어오게 되므로, 왜 무언가에 비용을 지불해야 하느냐는 것이죠. 이를 극한까지 밀어붙이면, 당신에게 필요한 유일한 소프트웨어는 Claude나 ChatGPT에 대한 구독(Subscription)뿐이며, 그 외의 모든 것은 그냥 직접 만드는(build) 것이 됩니다. 여기에는 위험할 정도로 충분한 진실이 담겨 있으며, 바로 그렇기 때문에 잠시 멈춰서 생각해 볼 가치가 있습니다.

저렴해진 비용이 실제로 드러내는 것

에이전트(Agent) 시대를 단순히 "만드는 비용이 저렴해졌다"라고 읽고 거기서 멈추기는 쉽습니다. 맞는 말이지만, 흥미로운 부분은 아닙니다. 흥미로운 부분은 저렴해진 제작 비용이 무엇을 드러내는가(exposes) 하는 점입니다. 왜냐하면 '구매(buy) 대 제작(build)'은 결코 제작 비용에 관한 경합이 아니었기 때문입니다.

당신이 소프트웨어에 비용을 지불했을 때, 가격표는 대부분 코드를 위한 것이 아니었습니다. 코드는 가장 사소한 부분이었습니다. 당신이 사고 있었던 것은 코드가 조용히 담고 있는 세 가지였습니다:

• 다른 누군가가 유지보수(maintenance)를 흡수합니다. API가 변경될 때, 예외 케이스(edge case)가 나타날 때, 혹은 그 기반이 되는 플랫폼이 변할 때도 해당 기능은 계속 작동합니다. 그 책임(liability)은 당신이 아닌 제공자의 것이며, 이는 영구적이거나 혹은 당신이 구독을 취소할 때까지 지속됩니다.
• 다른 누군가가 이미 시행착오 비용(trial-and-error tax)을 지불했습니다. 완성된 제품은 당신에게 도달하기 전, "이게 맞을 줄 알았는데 아니었다"라는 과정을 수백 번 반복하며 루프를 거쳤습니다. 당신은 그 과정을 건너뜁니다. 당신은 학습 곡선(learning curve)의 저 너머를 구매하는 것입니다.
• 당신의 주의력(attention)을 소모하지 않습니다. 이것이 가장 중요하면서도 가장 적게 언급되는 부분입니다.

에이전트(Agents)는 모두가 이야기하는 첫 번째 비용인 '작성(writing)'의 비용을 무너뜨렸고, 그 과정에서 나머지 세 가지의 실체를 드러냈습니다. 당신이 지불해 온 비용은 사실 소프트웨어 자체를 위한 것이 아니었습니다. 그것은 소프트웨어에 대해 신경 쓰지 않아도 되기 위한 비용이었습니다.

병렬화할 수 없는 자원

그 세 가지 중에서도 제가 계속해서 되돌아오게 되는 것은 주의력입니다. 왜냐하면 주의력은 나머지 요소들과 다르게 작동하기 때문입니다.

시간은 에이전트가 진정으로 되돌려줄 수 있는 것입니다. 다섯 명의 에이전트를 동시에 펼쳐놓고 일주일 치의 업무를 오후 한때로 압축할 수 있습니다. 저는 그것이 당신에게 무엇을 사고 무엇을 사지 못하는지에 대해 이전에 글을 쓴 적이 있습니다.

하지만 주의력은 시간이 아닙니다. 다섯 개의 에이전트를 병렬로 실행할 수는 있지만, 다섯 가지 일에 동시에 주의를 기울일 수는 없습니다. 당신이 만드는 모든 도구는 당신의 주의력을 조금씩 점유하는 권리(standing claim)가 됩니다. 즉, 고장 나거나, 표류하거나, 당신을 놀라게 하거나, 조용히 살펴봐 달라고 요청할 수 있는 대상이 됩니다. 도구를 충분히 많이 만들면 당신은 자유를 산 것이 아니라, 다른 누구도 호출(page)할 수 없는 1인용 소프트웨어의 확산된 영역을 관리하는 온콜 엔지니어(on-call engineer)로 스스로를 임명한 꼴이 됩니다.

따라서 코드가 거의 공짜가 된 지금, 진정한 '직접 구축할 것인가(build) vs 구매할 것인가(buy)'의 문제는 "내가 이것을 만들 수 있는가?"가 아닙니다. 답은 거의 항상 '예'입니다. 진짜 질문은 이것입니다: 결국 누가 유지보수를 떠맡게 될 것이며, 결국 누가 나의 주의력을 점유하게 될 것인가?

그럼에도 불구하고 직접 구축하는 경우

이런 관점에서 볼 때, 두 가지 상황이 직접 구축하는 것을 명백한 선택으로 만듭니다.

사소한 작업이며 이후에는 조용해지는 경우. 캘린더 동기화가 전형적인 사례입니다. 저는 이것을 한 번 구축했고, 정해진 일정에 따라 실행되며, 저에게 더 이상 어떠한 요구도 하지 않습니다. 주의력 비용(Attention cost)은 단 한 번의 저녁 시간이었고, 그 이후로는 거의 제로에 가깝습니다. 이것이 바로 맥시멀리스트(Maximalists)들이 실제로 옳다고 말하는 지점입니다. 즉, 범위가 작고 명확하며, 한 번 설정하면 잊어버려도 되는(set-and-forget) 작업들입니다. 무언가를 빠르게 구축한 뒤 지켜볼 필요 없이 그대로 실행할 수 있다면, 직접 구축하는 것이 훨씬 유리합니다. 구독료를 건너뛸 수 있을 뿐만 아니라, 실제로 희소한 자산인 주의력을 거의 소모하지 않기 때문입니다.

시장의 어떤 제품도 충분히 적합하지 않은 경우. 저의 태양광 비타민 D 계산기인 VitaminD Explorer는 Claude artifact로 시작하여 실제 PWA(Progressive Web App)로 성장했습니다. 정확히는 제가 비용을 지불할 용의가 있는 형태로 원하는 것이 존재하지 않았기 때문입니다. 시장의 해답이 "비슷하긴 하지만, 바로 그것은 아닌" 상태일 때, 구축(Build)과 구매(Buy) 사이의 수학적 계산은 더 이상 비용의 문제가 아닙니다. 당신은 기존 제품의 가격을 깎으려는 것이 아니라, 제품이 결코 채우지 못했던 공백을 메우고 있는 것입니다.

이 두 가지 경우 모두 "구축하는 것이 공짜이기 때문에 구축한다"는 뜻이 아님을 주목하십시오. '공짜'는 구축을 고려할 수 있게 만드는 _전제 조건(precondition)_일 뿐, 그 자체가 이유는 아닙니다.

함정과 한계

반대 급부는 맥시멀리스트의 입장이 조용히 무너지는 지점입니다.

함정은 조용해지지 않는 모든 것입니다. 계속해서 돌봐줘야 하거나(babysitting), 예측할 수 없는 방식으로 고장 나거나, 상위 단계의 무언가가 바뀔 때마다 결정을 요구하는 도구 — 그것은 절약이 아니라 당신이 스스로에게 부여한 두 번째 직업입니다. 이 지점에서는 서비스 제공자의 제안이 정직하며 받아들일 가치가 있습니다. 즉, 우리에게 비용을 지불하면 유지보수(maintenance), 드리프트(drift), 새벽 3시의 장애 모드는 우리의 문제가 된다는 것입니다. 만약 직접 구축했을 때 당신의 주의력을 무기한으로 점유하게 될 작업이라면, 설령 주말 동안 구축할 수 있는 것이라 할지라도 구독이 더 나은 거래인 경우가 많습니다. 바로 이 지점에서 '할 수 있는 것(Could)'과 '해야 하는 것(Should)'은 갈라집니다.

그리고 "단순한 구독"이라는 프레임워크가 무시해버리는 명백한 한계들이 존재합니다. 사용량 상한(Usage ceilings)은 실재합니다. 에이전트(Agent)가 아무리 유능하더라도 어떤 것들은 진정으로 관리 없이 실행되어서는 안 됩니다. 돈, 신원, 또는 돌이킬 수 없는 결과가 걸려 있는 모든 일은 인간의 개입(Human in the loop)을 원하며, 이는 결코 당신의 주의력(Attention)에서 완전히 벗어날 수 없음을 의미합니다. "당신에게 필요한 유일한 소프트웨어는 구독 서비스뿐이다"라는 귀류법적 결론은 유용한 도발이 될 수는 있지만, 나쁜 운영 계획입니다. 구독은 작업장(Workshop)이지, 창고(Warehouse)가 아닙니다.

기업 규모에서의 동일한 논리

이것은 개인적인 계산에만 국한되지 않습니다. 기업 버전은 이미 이야기가 나올 대로 나온 부분입니다. "SaaS의 종말", 모든 회사가 소프트웨어 회사가 되는 것, 거대한 언번들링(Great unbundling) 같은 것들 말이죠. 저는 그 담론에 대해 덧붙일 말이 많지 않지만, 그 논쟁이 보통 다루는 축이 잘못되었다는 점을 지적하고 싶습니다. 논쟁은 비용과 역량에 집착합니다. 이제 우리가 내부 도구(Internal tools)를 저렴하게 구축할 수 있게 되었으니, SaaS 구매를 중단해야 할까요? 하지만 결정적인 변수는 개인의 경우와 동일합니다. 바로 주의력(Attention)이며, 다만 개인 대신 팀 전체로 확산될 뿐입니다.

저는 로그를 감시하고 자동화된 성능 및 코드 품질 리뷰를 수행하며 스스로 작동하는 내부 모니터링 시스템을 구축해 왔습니다. 그런 도구들은 시장에 분명히 존재합니다. 구축을 선택한 이유는 기능적 공백 때문이 아니었습니다. 기성 제품(Off-the-shelf)이 저렴하게 맞출 수 없었던 얇은 수준의 커스터마이징(Customization) 계층이 필요했기 때문이며, 일단 구축되면 대부분 스스로 작동하는 무언가 위에 얹기 위함이었습니다. 낮은 상시 주의력 비용(Low standing attention cost), 적절한 노력, 그리고 구매할 수 없는 적합성: 이것이 개인 차원의 스위트 스팟(Sweet spot)이 확장된 형태입니다.

동일한 함정이 규모가 커지면 더 심각해집니다. 기업은 무언가를 직접 구축할 수 있지만, 그 결과로 내부 소프트웨어를 관리하기 위해 실제 핵심 사업(line of business)에서 팀을 빼내어 영원히 인력을 배치해야 할 수도 있습니다. 이는 마치 급여가 추가된 형태의 온콜 확산(on-call sprawl) 문제와 같습니다. 기업이 던져야 할 질문은 "구매하는 대신 직접 만들 수 있는가?"가 아닙니다. 앞서 언급한 두 가지 질문과 동일합니다: 누가 유지보수를 담당하며, 누구의 주의력(attention)을 소모하는가? 전담 내부 도구(internal-tools) 팀을 꾸리는 것이 때로는 정확한 정답일 수도 있지만, 때로는 그냥 제품을 구매했어야 했다는 사실을 깨닫게 되는 가장 비싼 대가를 치르는 방법이 되기도 합니다.

나의 결론

나는 이제 예전보다 기본적으로 직접 구축(build)하는 편이며, 이를 부끄러워하지 않습니다. 코드가 저렴해졌고, 이는 진정으로 계산법을 바꾸어 놓았습니다. 하지만 유지할 가치가 있는 "모든 것을 구축한다"는 버전은 슬로건보다 훨씬 좁은 범위입니다: 계속 실행되도록 내버려 두기에 충분히 사소한 것들, 혹은 시장이 당신을 위해 만들어주지 않은 것들 — 그리고 특히, 일단 구축하고 나면 조용해져서 당신을 더 이상 찾지 않는 것들을 구축하십시오.

그 외의 모든 것에 대해, 유료 도구가 판매하는 가장 유용한 것은 소프트웨어가 아닙니다. 그것은 바로 주의력을 기울이지 않아도 될 권리입니다. 그것은 실질적인 제품이며, 어떤 날에는 그것이 구매할 가치가 있는 유일한 제품이 되기도 합니다.

Human Limits in Managing AI Agents 및 Results-Oriented Programming의 동반 글입니다. VitaminD Explorer는 getvitamind.app에서 확인할 수 있습니다.

원문은 javieraguilar.ai에 게시되었습니다.

더 많은 AI 에이전트 프로젝트를 보고 싶으신가요? 멀티 에이전트 시스템(multi-agent systems), MCP 개발, 그리고 컴플라이언스 자동화(compliance automation)를 소개하는 저의 포트폴리오를 확인해 보세요.