website: 인프라 인수인계 문서 초안 — "손 뗀다"의 기준부터 정하기

문서를 쓰기 전에 먼저 정리해야 했던 건 "손 뗀다"가 정확히 뭘 의미하는지였다. 그냥 "문서를 잘 써두면 다음 사람이 읽고 알아서 한다"는 가정으로 시작하면 안 될 것 같았다. 인수인계 대상자는 이 프로젝트에 최소한의 노력만 들이고 싶어하는 사람이라고 전제하는 게 맞다고 봤다. 그러면 목표는 지식을 잘 전달하는 게 아니라, 다음 사람이 알아야 하는 지식의 총량 자체를 줄이는 쪽이 된다. 그래서 "손 뗀다"를 세 가지로 쪼갰다 — 계속 떠 있는다, 알림이 실제로 누군가에게 간다, 다음 담당자가 최소한만 헤매고 운영을 이어받을 수 있다.

이 기준으로 지금 인프라 상태를 두 줄로 나눠봤다. 이미 역할이 아니라 자동화/계정에 묶여서 사람이 사라져도 계속 도는 것 — 배포는 dev/main 머지로 CD가 자동 실행되고, 백업은 cron이 매일 스냅샷을 프라이빗 버킷에 올리고, 컨테이너는 unless-stopped로 재시작 정책이 걸려 있어서 크래시나 재부팅 후 자동 복구된다. 반대로 아직 내 개인 계정/머릿속에 묶여 있는 것도 꽤 있었다. OCI Administrators 그룹이 내 개인 계정 하나뿐이고, 서버 SSH 키도 내 로컬 키 하나뿐이다. DB 접근 계정 등록은 셀프서비스가 아니라 내가 직접 SSH로 들어가 공개키를 등록해줘야 하는데, 이건 공유 서버에 새 SSH 접근 수단을 만드는 일이라 의도적으로 자동화하지 않은 부분이다.

문서를 쓰다가 실제로 확인된 공백도 하나 있었다. 김우진이 "알림 오면 누구한테 가고 받으면 뭘 해야 하는지 정해져 있냐"고 물었는데, 수신처는 정리할 수 있었다(OCI Monitoring 알람은 ONS 토픽에 동아리 메일 + PM 개인 메일, UptimeRobot은 동아리 메일 + Discord 웹훅). 근데 "받으면 뭘 해야 하는지"는 문서화된 게 하나도 없었다. 지금은 알람이 오면 내가 SSH로 들어가서 그때그때 원인을 진단하는데, 이 진단 순서(runbook)가 어디에도 안 적혀 있다는 걸 이번에 문서 쓰면서 처음 명확히 인지했다. 인수인계 관점에서 가장 먼저 메워야 할 구멍이라 체크리스트 맨 위에 남겨뒀다.

체크리스트는 인수인계 시점에 실제로 손으로 해야 할 일 위주로 뽑았다 — OCI Administrators 계정 신규 발급/이전, ONS 구독자 갱신, UptimeRobot Alert Contact 갱신, 서버 SSH 키 교체, GitHub Secrets 회전, 로컬에만 있는 .env 류 비밀 인계. 그리고 별도 판단이 필요한 것도 하나 걸려 있었다. Flyway를 지금 stage에만 적용해뒀는데(#133/#172), 인수인계 관점에서는 stage·prod가 스키마 관리 방식이 다르면 다음 담당자가 "왜 둘이 다르지"를 또 배워야 해서 통일이 유리하지만, prod는 clean이 비활성이라 실수하면 되돌릴 방법이 백업뿐이다. 이건 문서에 판단만 적어두고 김우진에게 따로 확인하기로 했다.

문서는 인프라 파트만 채웠고, PM·프론트·백엔드·디자인 파트는 각 팀이 채울 자리로 비워뒀다. 인프라가 실제 구성을 근거로 먼저 초안을 잡아두면, 다른 파트도 같은 틀(자동화로 옮긴 것 / 아직 개인에게 묶인 것 / 알림 수신자 / 체크리스트)을 그대로 따라 채우기 쉬울 거라고 판단했다. 이 문서는 인수인계 시점에 몰아서 쓰는 게 아니라 지금부터 계속 갱신하는 걸 전제로 만들었다 — 뭔가 새로 개인 계정에 묶이면 그 목록에 추가하고, 자동화나 공용 계정으로 옮기면 반대쪽으로 옮기는 식이다. pm/docs/learnings.md에 쌓아온 "왜 이렇게 했는지"도 이 문서와 같은 역할을 하고 있어서, 인수인계 시점에 새로 쓰는 대신 지금까지 쌓인 걸 그대로 넘기는 게 목표다.