"Postgres 하나로 내구성 있는 실행 시스템을 만든다는 이야기, 들었는가?" 최근 기사 중 가장 인상 깊게 읽은 주제다. 무려 5개월간 프로덕션에서 성공적으로 운영되었다는 Absurd 프로젝트에 대한 소식이었다. 이 소식을 접하며, 우리는 AI 시대의 복잡한 워크플로우를 어떤 관점으로 설계하고 운영해야 할지 중요한 통찰을 얻게 되었다.

간소함 속 견고함: Absurd의 교훈

Absurd의 핵심은 단순했다. "별도의 서비스나 컴파일러 플러그인, 혹은 전체 런타임이 필요하지 않다. 필요한 것은 SQL 파일 하나와 얇은 SDK뿐이다" 이 시스템은 태스크 관리, 체크포인팅, 이벤트 처리를 단일 SQL 파일 `absurd.sql`과 간단한 SDK를 통해 구현했다. 그 결과 이 시스템은 Postgres 위에서 태스크를 등록하고, 스텝별로 분해하며, 각 스텝을 체크포인트로 삼아 실패 시 마지막 완료 스텝부터 재시도하는 견고한 워크플로우를 제공했다. 심지어 태스크는 며칠, 몇 주 동안 슬립하거나 외부 이벤트를 기다릴 수도 있다.

이것이 왜 중요한가? AI 워크플로우는 종종 여러 단계의 복잡한 추론, 데이터 처리, 외부 시스템 연동을 포함한다. 이런 과정을 안정적으로 수행하기 위해 우리는 너무 쉽게 복잡한 분산 시스템, 메시지 큐, 전용 워크플로우 엔진을 떠올리곤 한다. 하지만 Absurd는 이미 익숙하고 강력하며 검증된 데이터베이스, 즉 Postgres가 가진 내구성 있는 트랜잭션과 저장 기능을 극대화하여 훨씬 간소하면서도 견고한 솔루션을 제시했다. "beginStep()/completeStep()" 같은 기능을 추가하여 의도적인 실패나 조건부 로직까지 모델링하게 만든 점, 그리고 태스크 결과를 비동기적으로 조회할 수 있게 한 점은 실제 프로덕션 환경에서 필요한 섬세한 제어 능력까지 제공한다는 의미이다.

우리는 AI 파이프라인이나 장기 실행 에이전트 시스템을 설계할 때, "과연 이 복잡성이 정말 필요한가?"라는 질문을 던져봐야 한다. Absurd의 사례는 기존 인프라의 잠재력을 재발견하고, 최소한의 기술 스택으로 최대의 안정성을 끌어내는 접근 방식이 복잡한 AI 워크로드에도 유효함을 보여주었다. 오늘 당장 우리 팀의 장기 실행 배치 작업이나 멀티스텝 AI 에이전트 워크플로우를 한번 훑어보는 것이 좋다. 혹시 Postgres의 트랜잭션과 테이블만으로도 충분히 구현 가능한 부분을 불필요하게 복잡한 다른 시스템으로 해결하고 있지는 않은가?

숨겨진 비용, 예측 불가능한 변수

Absurd가 통제 가능한 환경에서의 효율성을 보여준 반면, 클라우드 기반 AI 모델의 사용은 아직까지 예측 불가능한 변수들로 가득하다는 점을 한 기사에서 다시 한번 확인할 수 있었다. 클로드 Pro Max 5x(Opus) 사용자가 "cache_read 토큰이 요금에 정량으로 반영되는 버그" 때문에 불과 1.5시간 만에 할당량을 소진했다는 제보였다. 심지어 이전에는 훨씬 더 많은 작업을 5시간 동안 수행했음에도 불구하고 말이다.

이 문제는 `cache_read_input_tokens`, `cache_creation_input_tokens`, `input_tokens`, `output_tokens` 등 다양한 토큰 사용량 로그를 통해 밝혀졌다. 개발자들은 캐싱 메커니즘이 비용 절감에 도움이 될 것이라고 기대한다. 하지만 이 사례는 캐싱이 잘못 작동할 경우 오히려 예상치 못한 비용 폭탄으로 이어질 수 있음을 적나라하게 보여준다. 특히 1M 토큰이라는 거대한 컨텍스트 창을 사용하는 모델에서는 '프롬프트 캐시 미스' 한 번이 엄청난 비용으로 이어진다.

이것은 단순히 특정 모델의 버그 문제가 아니다. 클라우드 기반 AI API를 사용할 때 우리가 마주하는 근본적인 불투명성을 드러낸다. 서비스 제공자는 "우리의 캐싱 메커니즘이 효율적이다"라고 말하지만, 실제 과금 방식과 내부 동작은 베일에 싸여 있는 경우가 많다. 이 때문에 개발자는 "moderate usage(평범한 사용량)"라고 생각했던 것이 순식간에 할당량을 소진시키는 결과를 낳을 수도 있다.

AI API를 사용하는 개발자라면 단순히 `input_tokens`와 `output_tokens`만 볼 것이 아니라, `cache_read_input_tokens`와 같은 상세한 로그 항목들이 어떻게 과금에 반영되는지 면밀히 살펴봐야 한다. 우리의 AI 워크플로우가 클라우드 API에 크게 의존하고 있다면, 예상치 못한 비용 변동에 대한 대비책을 세우거나, 비용 모델을 더 투명하게 공개하는 대안을 찾아보는 것이 현명하다.

로컬 환경, 제어의 시작

이런 불투명한 클라우드 API 환경에서 벗어나 예측 가능성을 확보하려는 움직임도 활발하다. "내 맥에서 어떤 AI 모델을 돌릴 수 있을까?"라는 질문에 명쾌한 답을 주는 `whatcani.run`이라는 플랫폼 소식이 바로 그 방증이다. 이 플랫폼은 맥 사용자들이 어떤 로컬 LLM 모델을 자신의 하드웨어에서 돌릴 수 있는지 커뮤니티 벤치마크 데이터를 기반으로 알려준다.

API 비용이 계속 오르고 개인 정보 보호에 대한 우려가 커지면서 로컬 LLM의 중요성은 커지고 있다. 하지만 로컬 LLM은 "내 M1 Max 64GB 맥에서 Llama 3.1 70B를 돌릴 수 있을까? 얼마나 빠를까?"와 같은 질문에 답하기 어려웠다. `whatcani.run`은 `npx whatcanirun`이라는 간단한 CLI 명령어로 사용자의 맥을 벤치마크하고, "Decode 12 tok/s"와 같은 실제 성능 수치를 제공한다. `llama.cpp`와 `MLX` 같은 주요 런타임 간의 성능 비교도 가능하여, 어떤 런타임이 내 하드웨어에서 더 효율적인지 직관적으로 알 수 있다.

이 도구는 AI 개발자들이 로컬 환경에서 더 많은 제어권을 확보하고, 예측 가능한 성능과 비용으로 AI 모델을 활용할 수 있도록 돕는다. 클라우드 API의 예측 불가능한 과금과 개인 정보 보호 문제를 회피할 수 있는 현실적인 대안을 제시하는 것이다. 만약 AI 프로젝트에서 비용 효율성이나 데이터 보안이 중요한 고려사항이라면, 당장 `npx whatcanirun`을 실행해 보고 내 맥에서 어떤 로컬 LLM을 가장 효율적으로 돌릴 수 있는지 확인해봐야 한다. 이를 통해 클라우드 의존도를 줄이고, 자체적인 AI 인프라를 구축하는 첫걸음을 뗄 수 있다.

결론: AI 워크플로우, 통제와 예측 가능성의 가치

세 가지 기사는 서로 다른 기술과 문제를 다루지만, 공통적으로 AI 워크플로우를 얼마나 통제하고 예측 가능하게 만들 수 있는가라는 질문에 답하고 있다. Absurd는 기존 기술을 활용해 최소한의 복잡성으로 최대의 안정성을 확보하는 방식을, 클로드 할당량 문제는 클라우드 AI의 불투명성이 야기하는 예측 불가능한 비용 문제를, 그리고 `whatcani.run`은 로컬 환경에서 통제권을 되찾고 성능을 예측 가능하게 만드는 길을 제시한다.

AI 기술의 발전 속도는 눈부시지만, 그 속에서 우리는 결국 지속 가능하고 신뢰할 수 있는 시스템을 구축해야 한다. 이를 위해서는 외부 서비스에 대한 맹목적인 의존보다는, 우리가 직접 제어하고 예측할 수 있는 환경을 만드는 데 더 많은 노력을 기울여야 한다. AI 인프라와 워크플로우를 설계할 때, 과연 우리에게 필요한 것은 더 복잡하고 새로운 '블랙박스'인가, 아니면 이미 우리가 가진 도구들을 통찰력 있게 재해석하여 얻는 '투명하고 견고한 미니멀리즘'인가? 이 질문에 대한 답이 우리의 AI 미래를 결정할 것이다.

참고

  • In Production 2026-04-07: https://lucumr.pocoo.org/2026/4/4/absurd-in-production/
  • Pro Max 5x Quota Exhausted in 1.5 Hours Despite Moderate Usage 2026-04-12 · 댓글 218개: https://github.com/anthropics/claude-code/issues/45756
  • 맥 로컬 LLM, 커뮤니티 벤치마크로 최적화 (by 정상록 (Sangrok Jung)) 2026-04-12: https://www.linkedin.com/feed/update/urn:li:activity:7449062312436731904/