n8n 자격증명 토큰 회전 자동화, 3단계로 나눈 이유

라이프케어로그 이름으로 플랜씨 같은 서비스를 만들면서, SNS 계정 운영은 n8n 워크플로에 맡겨 두고 있어요. 문제는 여기 쓰이는 Meta 계열 토큰이 만료가 있다는 점이에요. 주기적으로 새로 받아서 n8n 자격증명에 다시 넣어 줘야 하는데, 이걸 매번 손으로 하다가 이번에 스크립트로 넘겼어요. 9월 6일 밤에 시작해 8일까지 커밋 7건이 들어간 작업이에요.

덮어쓰기 한 번이 왜 위험한가

첫 버전은 단순했어요. 새 토큰 받고, n8n 자격증명을 PATCH로 덮어쓰고, 끝. 직접 만들어 보니 성공 경로는 금방인데 실패 경로가 문제였어요. 새 토큰은 받았는데 n8n에 쓰는 건 실패한 상태가 생기면, 어느 쪽이 살아 있는 토큰인지 스크립트도 저도 알 수 없어요.

curl이 전송 자체에 실패하는 경우도 있었어요. 응답 코드가 아예 없으니 성공도 실패도 아닌 채로 다음 단계로 흘러가더라고요. 이건 별도 커밋으로 막았어요. 전송 실패도 갱신 FAIL로 보고 종료 코드 1로 빠지게요. 테스트해 보면 실패 경로가 성공 경로보다 훨씬 많다는 걸 매번 다시 느껴요.

3단계로 쪼개기

그래서 회전을 3단계로 나누고 각 단계를 저널에 남기게 했어요.

staged 토큰 보관→n8n 자격증명 PATCH→commit·회전 저널 기록

1. staged: 새 토큰을 받아 Keychain에 임시 보관만 해요. n8n은 아직 손대지 않아요.
2. PATCH: n8n 자격증명을 새 토큰으로 갱신해요.
3. commit: 저널에 회전 기록을 남기고 staged 토큰을 정식으로 승격해요.

중간에 실패하면 rollback 창 안에서 이전 토큰으로 되돌리고, 연속 실패엔 circuit을 걸어 같은 갱신을 계속 두드리지 않게 했어요. 여기에 credential-probe 워크플로 템플릿을 따로 만들어 배포 스크립트에 --probe 옵션으로 붙였어요. 헤더 자격증명으로 n8n 쪽이 새 토큰을 실제로 읽는지 확인하는 용도예요. 저널에 "성공"이라고 적혀 있어도 n8n이 못 읽으면 의미가 없으니까요.

테스트하며 고친 것들

테스트를 돌려 보면서 fixture를 보강했더니 빠져 있던 경로가 드러났어요. Keychain 접근 자체가 오류를 내는 경우예요. 이때 에러 메시지에 토큰 값이 섞여 나오면 로그에 비밀이 남으니, 오류 시엔 토큰을 아예 출력하지 않도록 바꿨어요. deactivate 호출도 try로 감싸서 그 한 줄 때문에 회전 전체가 멈추지 않게 했고요.

인스타그램 전용이던 갱신 스크립트는 스레드까지 받도록 채널 인자를 일반화했어요. staged 단계만 따로 실행하는 --stage 옵션도 이때 들어갔어요. 적용해 봤더니 채널이 2개가 되니 이름부터 refresh-meta-token처럼 바꾸는 게 맞더라고요.

무인으로 넘기기

스레드 토큰 갱신은 launchd에 주 1회로 걸었어요. 다만 실제 회전이 한 번 끝까지 통과하는 걸 확인하는 실측 게이트는 자동에 맡기지 않고, 제가 직접 실행하는 절차로 문서에 남겨 뒀어요. 자동화라도 첫 회전은 눈으로 보는 게 맞다고 봤어요.

• ✓staged로 먼저 보관
• ✓프로브로 실제 읽힘 확인
• ✓실패는 전부 종료 코드 1
• ✓오류 로그에 토큰 금지