사람이 조작하고 있는 낮이라면 통과할 텐데, 사람이 없는 아침의 자동 실행에서는 갑자기 어려워지는 처리가 있다. OAuth가 그 대표적인 예였다. 화면을 보면서 인증할 때는 어디서 헤매는지 보인다. 하지만 06:30의 무인 실행에서는, 헤매는 순간 멈춘다. 멈춘 이유가 인증 때문인지, 데이터 결손 때문인지, 아니면 실행 조건 때문인지도 구분하기 어렵다.

RC 검증 주간에 확인된 사실은 극적인 성공담이 아니다. Metricool OAuth는 통상 기동 중인 비대화형 (non-interactive) refresh에서 partial / 7 / 7의 성공 실적이 있었기에, 인증 방식 자체를 바꾸는 판단은 내리지 않았다. 한편으로, 아침 자동 실행이라는 맥락에서는 인증이 한 번 통과되었다고 해서 안심할 수 없다는 점도 보였다. 이번 테마는 그 「통과한다」와 「매일 아침 통과한다」의 차이다.

Vol.12와 Vol.13에서 썼듯이, RC 검증 주간의 논점은 Connector 단체의 성패만이 아니었다. 수동으로 움직이는가, launchd가 기동하는가, Mac이 끝까지 깨어 있는가. 여기에 더해 인증 주변에도 「대화가 있는 시간」과 「사람이 없는 시간」의 차이가 있었다.

Season 1의 이른 단계에서도, 같은 서비스 이름이라도 대화용과 정기 실행용은 경험이 다르다는 것을 몇 번이고 느꼈다. Cursor 안에서는 통과하는데, 터미널로부터의 정기 실행에서는 다른 전제가 필요하다. OAuth는 특히 그 차이가 눈에 잘 보인다. 대화 중에는 브라우저도 설명도 있지만, 무인 실행에는 그것이 없다.

이 시점에서 정식 v1.0.0은 미출시 상태다. 그래서 이 글에서도 「인증 문제는 해결했다」라고는 쓰지 않는다. 쓸 수 있는 것은 Current Context에 있는 범위, 즉 통상 기동 중인 비대화형 refresh에서 partial / 7 / 7 성공 실적이 있으며, 인증 방식은 바꾸지 않는 방침까지다.

테마는, OAuth를 「한 번 통과시킨 것」과 「사람이 없는 아침에도 통과한다고」 말할 수 있는 것은 별개였다는 이야기다.

로그인이나 최초 인증은 눈에 띈다. 그래서 그 단계를 넘으면 안심하기 쉽다. 하지만 운영에서는 그 이후의 지루한 지속이 더 무겁다. 일일 읽기(daily read)에서 필요한 것은 화려한 최초 성공이 아니라, 무인 시간대에 설명 없이 refresh가 계속 돌아가는 것이었다.

Current Context에서는 Metricool OAuth에 대해 두 가지 사실이 나란히 놓여 있다. 하나는 통상 기동 중인 비대화형 refresh에서 partial / 7 / 7의 성공 실적이 있다는 것. 다른 하나는 인증 방식을 바꾸지 않는 방침이라는 것이다. 여기서 중요한 것은 「partial」을 실패로 취급하지 않았다는 점이라고 생각한다.

Metricool은 일부 지표가 null이 될 수 있기 때문에, Current Context에서는 partial을 사양(specification)으로 허용하고 있다. 즉, 인증이 돌아갔는지 여부와 모든 값이 완전히 채워지는지는 별개로 보고 있었다. 이 부분을 혼동하면 인증 문제인지, 데이터 사양인지, 아니면 운용 조건인지가 한꺼번에 모호해진다.

RC 검증 주간에는 이러한 구분이 특히 중요했다. 왜냐하면 아침 자동 실행에서는 문제가 하나씩 나타나 주지 않기 때문이다. launchd, 수면, 네트워크, 인증, 지표 결손이 모두 똑같이 「오늘은 아침 결과가 약하다」라는 모습으로 보인다. 그렇기에 Metricool OAuth에 대해서는 「비대화형 refresh는 실적 있음」, 「partial은 사양으로 허용」, 「인증 방식은 바꾸지 않음」이라고 선을 그어 두었다.

이 선 긋기는 비엔지니어에게 상당히 컸다. 인증이라고 하면 즉시 「방식을 바꾸는 게 좋지 않을까」라고 생각하기 쉽다. 하지만 RC 검증 주간에는 신기능 추가도 인증 방식 변경도 피하는 방침이었다. 아침 무인 실행에서 마찰이 생기더라도, 우선 봐야 할 것은 거대한 재설계가 아니라 현재의 방식으로 확인되고 있는 사실을 어디까지 단언할 수 있는가였다.

또 하나 중요했던 것은 성공 실적을 쓰는 방식이다. partial / 7 / 7은 만능감을 주는 숫자가 아니다. 오히려 「일부는 null을 포함할 수 있다」는 전제가 포함된 성공이다. 하지만 전제를 포함해서 쓸 수 있다면 그것은 충분히 가치가 있다. 운영에서는 완벽하게 보이려 하는 것보다, 어떤 조건에서 통과했는지를 남기는 것이 다음 날 아침에 더 도움이 된다.

여기서 힘이 된 것은 Current Context에 이미 「Metricool은 미제공 지표가 있는 경우 partial을 사양으로 허용한다」라고 적혀 있었다는 점이다. 즉, 그 아침에 보이는 결손이 인증 파탄인지, 사양상 일어날 수 있는 결손인지를 구분할 전제가 문장으로 먼저 놓여 있었다. 문장으로 경계가 설정되어 있는 것만으로도 아침에 보이는 모습은 상당히 달라진다. 적어도 「전부 가져오지 못하니까 OAuth가 고장 났다」라고 단정 짓지 않을 수 있게 된다.

게다가 이러한 정리는 인증을 가볍게 보기 위함이 아니다. 오히려 그 반대라고 생각한다. 인증을 정말 중요한 논점으로 다룬다면, 무엇이든 인증 탓으로 돌리지 않는 것이 좋다. 인증 실패, 지표 제공 측의 사양(Specification), 무인 운용의 조건 부족을 분리해서 보지 않으면 다음에 수정해야 할 점도 흐릿해진다. RC 검증 주간에 남기고 싶었던 것은 '해결되었다'는 안도감이 아니라, 다음 날 아침에 동일한 흔들림이 발생하더라도 다시 관측할 수 있는 정리였다.

OAuth의 어려움은 기술 그 자체보다 '사람이 곁에 없다'는 점에 있을지도 모른다. 사람이 있다면 브라우저를 열거나, 확인하거나, 다시 시도하는 등의 도피처가 있다. 사람이 없는 아침에는 그러한 도피처가 없다. 따라서 아침 운용에서는 인증을 화려한 초기 설정이 아니라, 지속 조건 중 하나로 다룰 필요가 있었다.

여기서 배운 것은 인증을 너무 심각하게 받아들이지 않는 법이기도 하다. 너무 심각하게 받아들이면, 약간의 마찰이 생길 때마다 방식 변경(Method change)으로 달려가고 싶어진다. 하지만 RC 검증 주간의 역할은 크게 바꾸는 것이 아니라, 현 상태의 경계를 정확히 말하는 것이었다. 현재 방식에서 어디까지 확인할 수 있었는가. 어디서부터는 아직 말할 수 없는가. 그 구분이 아침의 안심을 조금씩 늘려간다.

비엔지니어(Non-engineer)의 입장에서는, '통과한다'라고 들었던 것이 왜 다른 시간대에 다시 의심스러워지는지 처음에는 이해하기 어려웠다. 하지만 지금은 대화 중의 성공과 무인 운용의 성공은 별개의 품질이라고 받아들이고 있다. 전자는 기능의 확인이고, 후자는 운용 조건의 확인이다. 조건이 다르면 동일한 OAuth라도 다른 난이도가 된다.

이러한 관점은 Human Approval의 사고방식과도 조금 닮아 있다. '누를 수 있는 것'과 '눌러도 되는 것'을 구분한다. '작동하는 것'과 '맡겨도 되는 것'을 구분한다. OAuth에서도 마찬가지로, refresh가 한 번 성공했다는 것과 그대로 아침 운용에 맡겨도 된다는 것은 같지 않았다. 그렇기에 RC 검증 주간에는 화려한 개선안보다 먼저, 어떤 조건이라면 맡겨도 되는지를 언어로 세밀하게 구분할 필요가 있었다.

바꿔 말하면, 여기서 다루고 있었던 것은 인증 테크닉보다 운영 판단이었다고 생각한다. 방식 변경을 서두르지 않는다, partial을 사양(Specification)으로서 허용한다, 통상 기동 중의 refresh 실적만을 우선 사실로서 남긴다. 이 순서를 지킴으로써 아침의 불안을 '전부 망가졌을지도 모른다'에서 '어느 계층을 보면 되는지 알 수 있다'로 조금 옮길 수 있었다. 비엔지니어가 AI와 운영 OS를 지속하기 위해서는 이 차이가 상당히 컸다.

• OAuth는 '한 번 통과했다'는 것만으로는 무인 운용의 안심이 되지 않는다
• 비대화형 (Non-interactive) refresh의 성공과 지표의 완전성(Integrity)은 분리해서 볼 필요가 있다
• Metricool의 partial은 실패가 아니라, 사양으로서 허용할 경계가 필요하다
• 인증에서 마찰이 생겨도 즉시 방식 변경으로 넘어가지 않고, 확인된 사실을 정리하는 편이 더 강력하다
• 사람이 없는 아침에는 인증도 지속 운용의 조건으로 다룰 필요가 있다

이 흐름을 이어간다면, Step50에서 ChatGPT / Cursor / GitHub / Human Approval의 역할을 고정한 이유로 이어진다. 다만 정식 v1.0.0은 미출시 상태이므로, 안정 운용의 완성된 이야기로서 작성하지는 않는다.