뿔뿔이 흩어져 있던 접속들이 어느 날 하나로 모여 보였다. GA4, Search Console, Clarity, Metricool——각각 별개의 화면, 별개의 스크립트, 별개의 "일단 돌아가게 만든" 기억이었다. 아침 확인 작업은 여전히 고통스러웠다. 하지만 connectors/라는 하나의 장소에 일일 데이터가 쌓이기 시작했을 때, 감각이 변했다. 연결되었다기보다, 같은 지도 위에 올라탔다는 느낌이었다.

비엔지니어(Non-engineer)인 나에게 그것은 기술적인 승리라기보다 심리적인 분기점이었다. 흩어져 있던 것들이 이름과 책임을 갖기 시작했다. 이름이 있으면 대화가 짧아진다. 짧은 대화는 판단을 빠르게 한다. 빠른 판단은 아침의 10분에 가까워진다.

Vol.05에서 SQLite를 선택한 이야기를 썼다. 선택한 이유는 "이력을 남기기 위해서"였다. 선택한 뒤에 남은 과제는 누가 언제 무엇을 넣는가였다. MCP로 라이브하게 보는 방법은 남겨두었다. 하지만 라이브만으로는 어제와의 비교가 불가능하다. 비교할 수 없으면 개선의 방향을 정할 수 없다.

접속은 늘어나고 있었다. WordPress, SEOPress, WP Rocket, Obsidian, GitHub, Canva, Make——각각 의미가 있었다. 하지만 데이터를 매일 쌓는 계열과 대화하며 조사하는 계열이 섞이면 머릿속이 복잡해진다. 복잡함은 AI의 제안을 받아들이기 쉽게 만든다. 받아들이기 쉬워지면 다시 범위가 넓어진다. 넓어진 범위는 리뷰를 통해 돌아온다. 돌아오는 비용은 높다.

그래서 "전부를 같은 타입으로 만든다"는 유혹이 찾아왔다. 유혹이 올 때마다 나는 한 가지만 멈췄다. 무리하게 같은 타입으로 만들지 않는다. 타입을 맞추는 것과 전체를 이해하는 것은 별개다. 이해를 위해 Connector Platform이라는 용어를 채택했다.

테마는, 흩어져 있던 접속들이 Connector Platform으로서 하나의 운영 지도가 된 날이다.

Connector Platform이란 화려한 제품명이라기보다 운영의 정리술에 가깝다. 일일 단위로 SQLite에 쌓는 것은 connectors/에 둔다. 취득, 변환, 저장, 실행 로그——흐름을 공통화한다. 이름은 {source}_{granularity}이다. 예를 들어 ga4_daily, gsc_daily, clarity_daily, metricool_daily. 이름이 통일되면 아침 확인을 "어떤 커넥터가 마지막으로 동작했는가"에서 시작할 수 있다.

한편으로는 전부를 배치(Batch)로 밀어넣지 않는 판단도 동시에 있었다. Ubersuggest가 그 대표적인 예다.

Connector Framework의 설계부터 시작되었다. Step25에서는 Python을 쓰지 않고 사양과 템플릿만 두었다. 명명, 책임, 에러, 로그. 수수한 문서지만, 수수한 문서가 이후 구현의 속도를 결정한다. 구현이 시작되자 GA4, Search Console, Clarity, Metricool의 일일 커넥터가 차례로 늘어났다.

내가 체감한 변화는 대시보드의 숫자가 아니었다. system_connector_runs에 행이 늘어나는 안도감이었다. 성공, 부분 성공, 실패, 스킵——상태에 이름이 있다. 이름이 없는 실패는 그저 "뭔가 안 된다"가 된다. 이름이 있으면 다음에 무엇을 고쳐야 할지 알 수 있다.

Metricool은 OAuth 이야기도 얽혀 있었다. 인증 파일의 유무로 스킵하는, 현실적인 동작을 할 수 있게 되었을 때, 이상적인 자동화보다 신뢰할 수 있는 자동화로 보였다. 작동하지 않는 날이 있더라도 거짓말을 하지 않는 메커니즘이 운영에는 더 적합하다.

Ubersuggest는 별도의 루트였다. 조사 결과, Python 일일 커넥터에는 넣지 않기로 결정했다. Cursor 상의 Interactive MCP로 남겨둔다. Interactive MCP Connector——대화 속에서 참조하며, 이력에는 무리하게 싣지 않는다. 실을 수 없는 것을 무리하게 실으면 망가진다. 망가진 신뢰는 복구하는 데 시간이 걸린다.

실패담도 있다. 처음에는 "커넥터만 늘리면 전부 해결된다"고 생각할 뻔했다. 늘리면 테이블은 늘어난다. 늘어난 테이블을 누가 아침에 볼 것인가가 정해져 있지 않으면, 그것은 그저 창고가 된다. 창고는 데이터가 있다는 것을 증명하지 않는다. 사용되는 것이 증명이다. 그래서 Dashboard 이야기로 자연스럽게 이어졌다. Platform은 화면과 세트로 구성되어야 비로소 의미를 갖는다.

또 다른 실패는 용어의 불일치를 방치한 것이다. MCP, API, Abilities, Connector——모두가 연결된 날이었기에, 언어가 흔들리면 지도가 두 장이 된다. 나중에 Architecture Review (아키텍처 리뷰) 단계에서 용어를 통일하게 되지만, 그전까지 나는 몇 번이고 "이거 MCP 맞지?"라고 되물어야 했다. 되묻는 시간은 낭비가 아니다. 다만, 더 빨리 문서화하는 편이 비용이 적게 들 뿐이다.

Platform (플랫폼) 이전에는 연결의 성공이 개별적인 축배였다. Platform 이후에는, 마지막으로 동작한 Connector (커넥터)와 SQLite의 행 수가 전체의 건강검진이 되었다. 건강검진이 있으면 개선의 우선순위를 정할 수 있다. 우선순위를 정할 수 있게 되면 AI에게 내리는 요청이 구체적이 된다. "전부 개선해 줘"가 아니라, "Metricool이 skipped (스킵됨) 상태이니 인증을 확인해 줘"가 된다. 구체성은 폭주를 막는다.

GA4와 Search Console의 커넥터를 따로따로 돌리던 시절에는, 성공 알림이 올 때마다 안도하곤 했다. 하지만 두 개가 성공한다고 해서 아침의 판단이 쉬워지지는 않았다. 쉬워지는 것은, 동일한 run (실행) 로그 형식으로 어제와 오늘이 나란히 놓일 때다. 나란히 놓이면 "둘 중 하나만 멈춰 있다"는 것을 한눈에 알 수 있다. 한쪽만 멈춰 있는 상태는 운영에서 흔히 발생하는 일이다. 그렇기에 시각화(Visualization)가 필요하다.

Imagify나 WP Rocket 같은 WordPress (워드프레스) 주변 환경은 Abilities나 MCP라는 또 다른 입구를 가진다. Platform화는 그것들을 없애는 것이 아니다. 없애면 현장이 혼란에 빠진다. 혼란은 비엔지니어(Non-engineer)의 부담이 된다. 입구가 여러 개 있더라도, 일간 분석 데이터는 하나의 강으로 흐르게 한다——그 약속만 지킬 수 있다면 지도를 읽을 수 있다.

모두 연결되었다는 표현은 조금 과장일지도 모른다. 완벽하게 통일된 것은 아니다. Interactive MCP는 별도 영역이고, WordPress 계열은 Abilities도 있다. 하지만, 일간 분석 데이터가 하나의 흐름이 되었다는 것은 사실이다. 사실이 있으면 Version (버전) 이야기를 할 수 있다. Version은 기능의 개수가 아니라, 운영자가 설명할 수 있는 단위다.

또한, Platform화는 "자동화의 완성"이 아니다. 오히려 반대다. 무엇을 자동으로 돌리고, 무엇을 사람이 볼 것인지에 대한 경계가 명확해지기 시작했다. 커넥터와 리포트(Report)와 백업(Backup)은 원칙적으로 자동화 측에 둘 수 있다. 공개, 삭제, 설정 변경, SNS——그것들은 별개의 이야기다. 별개의 이야기에는 별개의 사상이 필요하다. 다음 회차에서 다룰 Human Approval (휴먼 어프로벌)이 그 입구다.

비엔지니어가 여기까지 올 수 있었던 것은 코드를 작성했기 때문이 아니다. 흩어져 있음을 인정하고, 이름을 붙이고, 타입을 두 가지로 나누고, 실패를 로그(Log)에 남겼기 때문이다. 남길 수 있게 된 것은 AI가 구현하고, 내가 "이것은 같은 상자에 넣지 않는다"라고 말할 수 있었기 때문이다.

돌이켜보면, Version 0.3 이야기는 "구현이 끝났다"는 이야기가 아니라, "흩어져 있던 것들에 이름이 붙었다"는 이야기에 가깝다. 이름이 붙은 순간, README나 CHANGELOG의 업데이트도 의미를 갖기 시작했다. 업데이트는 미미하지만, 팀이 두 명(나와 AI)뿐이라도 같은 과거를 참조할 수 있게 한다. 참조할 수 있는 과거는 폭주 후의 복구 속도를 높여준다.

또한, 모두 연결되었다고 해서 매일 아침이 마법처럼 편해지는 것은 아니다. 편해지는 것은, 망설이는 포인트가 줄어들었기 때문이다. 망설임이 줄어들면 남은 망설임에 집중할 수 있다. 집중은 비엔지니어의 희귀한 자원을 보호한다. Connector Platform은 그것을 위한 토대였다.

• 연결이 늘어나도 일간 축적과 대화 참조는 분리하는 편이 잘 망가지지 않는다.
• connectors/와 SQLite를 통해 어제와의 비교가 가능해졌다.
• 실행 로그에 status (상태)가 있으면 아침의 판단이 빨라진다.
• 모든 것을 같은 타입으로 만들지 않는 판단 (Interactive MCP)은 무리한 자동화를 피했다.
• Platform은 화면과 세트로 구성될 때 비로소 운영 지도가 된다.
• 용어의 불일치는 연결된 후에 서서히 영향을 미친다.

다음에는 자동화와 승인의 경계——Human Approval이라는 사상——에 대해 쓰겠다. 연결된 이후, 드디어 "해도 좋은 조작"에 대한 이야기가 본론이 된다.

AI는 제안한다. 공개·삭제·설정은 사람이 승인한다——그 경계선을 쓰겠습니다.