에이전트에게 블로그 글 올리기를 맡겼더니, 글 쓰는 것보다 올리는 길에서 더 자주 막혀요. 이 글은 그 막힘을 정리한 기록이에요.
로그인에서 막혀요
저장소 동기화를 시키려고 에이전트에게 GitHub 로그인을 맡겼어요. 그런데 에이전트는 내 계정으로 들어가지 못했어요. 저는 구글 계정으로 가입해서 비밀번호로 로그인하는 계정이 아니었고, 저장해 둔 건 비밀번호가 아니라 접근 토큰이었어요. 토큰은 코드로 저장소에 접근할 때 쓰는 열쇠지, 웹 로그인 화면에 넣는 열쇠가 아니에요.
구글 로그인은 사람이 직접 승인하는 단계가 따라와요. 에이전트가 반복해서 시도해도 열리지 않고, 계정이 잠길 위험만 커져요. 그래서 한 번 시도해 보고 멈추게 했어요.
그래서 다른 길로 배포했어요
제 블로그를 올리는 호스팅 서비스 Vercel은 GitHub 저장소와 연결되어 있지 않아요. 저장소에 올리면 자동으로 사이트가 바뀌는 방식이 아니라, 명령줄 도구로 지금 만든 파일을 직접 올리는 방식이에요. 이 방식은 GitHub에 들어가지 못해도 쓸 수 있었어요. 이미 로그인된 Vercel 세션에서 기기 승인 한 번만 누르면 되니까요.
그 결과 저장소와 사이트가 달라졌어요
문제는 그다음이에요. 사이트는 계속 바뀌는데 저장소에는 그 변경이 들어가지 않았어요. 어느 날 보니 저장소에 있는 파일과 실제 사이트 파일이 달랐어요. 작업이 겹친 날은 한 번 올린 변경이 그다음 배포에서 덮이기도 했고요. 에이전트가 새 글을 올리려면 먼저 "지금 사이트에 올라가 있는 파일"을 받아서 그 위에 더해야 했어요. 저장소를 믿고 작업하면 어제 만든 것이 사라져요.
새벽 자동 발행도 사람 승인이 필요해요
저는 매일 새벽에 에이전트가 글을 올리게 해 두었어요. 그런데 이 배포 방식은 승인을 눌러 줄 사람이 필요해요. 사람이 자고 있는 시간에는 글을 쓸 수는 있어도 올릴 수는 없는 거예요. 자동화라고 불렀지만 마지막 한 걸음이 사람 손에 걸려 있었어요.
여기서 배운 것
에이전트가 어려워하는 건 글쓰기나 코딩보다 계정과 권한인 경우가 많았어요. 일을 맡기는 쪽에서 미리 정해 둬야 할 것은 이런 것들이에요.
- 어디가 기준 원본인가. 저장소인가, 지금 올라간 사이트인가
- 에이전트가 쓸 수 있는 열쇠는 무엇이고, 어떤 일에는 못 쓰는가
- 사람이 승인해야 하는 단계는 어디이고, 그 단계 때문에 어느 시간에는 멈추는가
비밀번호나 토큰을 에이전트에게 더 많이 주는 건 답이 아니라고 생각해요. 권한을 넓히기 전에, 기준 원본과 승인 지점부터 정리하려고 해요.