성공 직후의 자신감, 그리고 더 큰 실패
1부에서 이야기한 자동화 성공 이후, 나는 자신감에 차 있었다. 아이디어 저장을 넘어 초안 생성까지 완벽한 자동화를 꿈꾸며 작업을 이어갔다. 하지만 그 자신감은 곧 코딩 무식자의 비애 시즌 1의 서막을 열었다.
AI에게 의존해 Gemini API를 호출하려는 시도는 계속해서 원인 모를 오류를 뿜어냈다. 코딩을 모르다 보니, 나는 AI가 제시하는 길을 의심 없이 따를 수밖에 없었다. GPT, Gemini, Claude를 전전하며 해답을 구했지만, 나의 AI 파트너들은 JSON 스키마 문제일 거라는 엉뚱한 진단만 내놓았다. 1부에서 겪었던 뺑뺑이가 다른 형태로 반복되고 있었다. 나는 또다시 몇 시간을 허비하며 엉뚱한 곳을 파고 있었다.
진짜 문제의 발견
꽉 막힌 구간에서 헤매던 어느 순간, 나는 AI에게 질문하는 것을 멈췄다. 그리고 Make.com의 시나리오 모듈들을 처음부터 끝까지 하나씩, AI 안내 없이 직접 살펴보기 시작했다. 차분히 시나리오의 흐름을 따라가다 보니 각 모듈의 역할과 데이터가 어떻게 흘러가는지, 그 원리가 서서히 윤곽을 드러내기 시작했다. 여기서는 이래서 이 값을 선택해야 하는구나. 그렇게 한참을 들여다본 끝에, 마침내 문제의 원인을 찾아냈다. Notion 페이지의 속성만 가져오는 모듈을 본문을 가져오는 역할로 잘못 사용하고 있었던 것이다.
그것을 수정하자 시스템이 작동했다. 허무할 정도로 간단한 문제였다. 그 모든 좌충우돌의 끝에서 나는 거의 30년 전의 한 기억을 떠올렸다.
미국에 와서 처음으로 스포츠 경기를 보러 갔을 때였다. 나는 주차장 입구부터 내 좌석에 앉기까지, 길목마다 서서 다음 경로를 안내해주던 수많은 요원들을 보며 깊은 인상을 받았다. 단순히 질서 유지를 잘한다는 감상이 아니었다. 그 이면에는 하나의 목표를 달성하기 위해 모든 변수를 계산하고, 위험을 관리하며, 자원을 배분하는 미국식 프로젝트 관리의 전형이 보였다. 이 거대한 행사를 위해 몇 명의 인원이 필요하고, 각 구역에는 어떤 역할을 부여하며, 돌발 상황에는 어떻게 대응할지까지 미리 정의해 놓은 거대한 틀 말이다. 그때 어렴풋이 느꼈다. 나는 세세한 부분에 파고들며 실행하는 데는 익숙했지만, 이렇게 전체 그림을 먼저 그리고 세부 계획을 채워나가는 방식에는 서툴다는 것을.
시스템이 아닌, 프레임워크를 얻다
이번 디버깅 과정은 30년 전의 그 어렴풋한 느낌이 얼마나 정확했는지를 다시 한번 확인시켜 주었다. 1부에서 나는 큰 틀의 중요성을 알게 되었다고 생각했지만, 그것은 여전히 막연한 개념에 가까웠다. 이번의 실패를 겪고 나서야 비로소, 그 큰 틀을 의식적으로 세우고 따르는 나만의 퍼스널 프레임워크를 만들어야 한다는 사실을 절감했다.
결국 이 프로젝트를 통해 내가 얻은 것은 단순히 작동하는 자동화 시스템만은 아니었다. 그것은 이 모든 과정을 통해 얻은 시스템을 대하는 나만의 관점이었고, 앞으로 나의 모든 프로젝트는 퍼스널 프레임워크를 세우는 것에서부터 시작해야 한다는 분명한 확신이었다.
이 경험은 나에게 다시 한번 질문을 던진다. 프로세스 설계자에게 성공이란 무엇인가? 눈앞의 결과물을 빠르게 얻는 것인가, 아니면 시간이 걸리더라도 지속가능한 시스템을 구축하는 것인가? 이번의 길고 고통스러웠던 디버깅 과정 자체가, 나도 모르는 사이에 후자를 선택하고 있었음을 증명하는 시간이었다고 생각한다.
AI 시대에도 사람의 손길이 필요한 전문 번역을 찾고 계신가요? 29년간의 미국 생활과 기술 분야에 대한 깊은 이해를 바탕으로 한 저의 번역 서비스가 궁금하시다면, 제 크몽 프로필에서 자세한 정보와 포트폴리오를 확인하시거나 브런치 '제안하기'를 통해 직접 문의해 주셔도 좋습니다.