일기
회고 / 메모
-
폐기된 줄 알던 추적 기능, 문서 현황 정정
한동안 문서를 정리하다가 흥미로운 발견을 했다. 공용 문서에서 자세히 봐야 할 게 있다는 생각이 든 거다. site-pv 라는 추적 기능이 도큐멘테이션에는 '폐기/부활금지' 상태로 표기되어 있었는데, 실제로 시스템을 살펴보니 여전히 운영 중이었다. 무심코 지나칠 수 있지만, 이런 작은 오류가 팀 전체의 의사결정과 시스템 이해에 꽤 큰 영향을 미친다.
읽기 → -
프로젝트 종료 후 흩어진 문서들을 한 곳으로 정리
어떤 프로젝트가 일단락되거나 운영 단계로 접어들 때, 그 과정에서 쌓인 설계 문서, 연동 규격서, 검증 계획 같은 것들이 클라우드 저장소 곳곳에 흩어져 있는 경우가 많다. 이번 작업은 바로 그런 상황—404_pjt 라는 프로젝트의 잔여 문서들을 정리해서 체계적으로 아카이빙한 것이다.
읽기 → -
벤더 API 규격서 한곳에서 관리하기
이커머스 플랫폼에서는 여러 외부 벤더와 API 연동을 하게 된다. 결제 PG, 배송 시스템, 인증 솔루션, 상품권 발송 등 비즈니스 도메인별로 각각 다른 벤더와 작업하다 보니, API 규격서들이 여기저기 흩어져 있었다. 이번 작업은 그 모든 벤더 연동규격서를 .claude/pdf 디렉토리에 한곳으로 모으고, 신규 벤더 2종을 추가하는 문서화 작업이었다.
읽기 → -
본인인증 SMS 전환 완료, 다음 단계 정의
어느 정도 규모가 되는 팀에서 진행 중인 작업을 파악하고 다음 사람에게 넘겨주는 건 생각보다 복잡하다. 특히 개발과 운영이 나뉘어 있거나, 여럿이 같은 영역을 건드려야 할 때는 더더욱. 이번 커밋은 본인인증 SMS 마이그레이션이 완료되었다는 사실을 팀 핸드오프 문서에 기록하고, 동시에 다음 우선순위를 명시하는 작업이었다.
읽기 → -
진행 상황을 문서로 정리하고 팀의 다음 방향 결정하다
프로젝트를 진행하다 보면 특정 지점에서 그간의 성과를 정리하고 다음 단계를 명확히 하는 시간이 필요하다. 특히 팀 규모가 커지고 기간이 길어질수록 말이다. 이번에 한 인증 서비스의 핸드오프 문서를 작성하면서 느낀 것들을 정리해본다.
읽기 → -
API 한도 폴백을 2단계로 설계하고 문서화하다
주간 API 한도 초과 시 자동으로 작동하는 폴백 메커니즘을 문서화했다. 단순한 실패 처리가 아니라, 모델 폴백(A)과 계정 로테이션(B) 두 겹으로 방어하는 구조를 명시하고, 팀이 이해하기 쉽도록 정리했다.
읽기 → -
임시 검증 파일 저장소에서 자동 제외
임시 검증용 이미지 파일들을 git 추적에서 빼고 .gitignore에 패턴 추가하는 작업을 했다. 이미 저장소에 들어있던 dc-1827부터 dc-1833까지의 PNG 파일들을 제거한 뒤, 향후 captures 디렉토리의 파일들이 자동으로 무시되도록 설정한 것.
읽기 → -
여전히 필수인 통계 시스템, 폐기로 표기되다
사내 통계 시스템 문서에 떠 있던 오류를 정정했다. archive/stats-legacy/README.md에 남겨진 "폐기 예정" 표시를 제거하고, 실제 현행 상태를 명확히 하는 작업이었다.
읽기 → -
서버 백업 데이터가 git에 올라가는 문제 해결
최근 한 작업은 **git 저장소의 정본성(canonical structure)**을 되찾는 것이었다. 서버의 /opt/stats 디렉토리—실제 운영 중인 통계 백업과 크론 작업의 결과물들—이 버전 관리 대상에서 빠져야 한다는 걸 명확히 했고, 동시에 그 감시 체계를 개선했다.
읽기 → -
유료 상품 재출시 정책 결정 확정
유료화로 전환하는 결정을 최종 확정하고, 실행 계획을 문서에 담았다. 패키지 이름, 가격, 결제 정책, 그리고 단계별 실행 순서까지 한 곳에 정리한 것인데, 이렇게 단순해 보이는 문서화 작업이 팀의 방향성을 얼마나 명확하게 만드는지 다시 느껴본다.
읽기 → -
무료에서 유료로, 5개 기능 재출시 계획
유료앱 재출시 계획을 문서로 정리했다. 기존에 무료인데 사용 잠금 상태로 있던 5개 기능을 새 패키지명으로 유료화하는 전략을 PAID_RELEASE_PLAN.md에 담았다.
읽기 → -
워치페이스 옵트인 정책을 설치무관 기준으로 통일
6개 워치페이스의 옵트인 게이트 정책을 확정했다. 그간 모호했던 "언제부터 사용자에게 이 페이스를 공개할 것인가"라는 질문에 명확한 답을 내린 작업이다.
읽기 → -
복잡한 릴리스 계획을 더 명확하게 정의
이번에는 릴리스 계획 문서(RELEASE_PLAN.md)를 손봤다. 웨어러블 기기용 새로운 폼팩터 지원, 특정 릴리스 버전을 막고 있는 블로커들, 그리고 워치페이스 단위의 상태 추적을 추가한 것이다. 문서 한 장인지라 코드 변경은 없지만, 팀이 나아가는 방향과 우선순위를 결정하는 데 꽤 중요한 작업이었다.
읽기 → -
앱 아이콘 불일치 수정하고 빌드 설정 현행화
여러 개의 변형(variant)으로 배포되는 안드로이드 앱을 관리하다 보니, 각 변형마다 일관되지 않은 설정들이 쌓이기 시작했다. SDK 버전 타겟팅, 런처 아이콘, 스토어 메타데이터—이런 것들이 하나하나는 작아 보이지만, 모여서는 사용자에게 혼란을 주고 스토어 심사 시 까다로운 항목들이 된다. 이번엔 그 불일치들을 정리한 작업이다.
읽기 → -
운세 타임아웃·트러스 동기화·깃 설정을 온보딩 문서 한 곳에 정리
CLAUDE.md에 세 가지 중요한 설정 가이드를 정리했다. 서버 트러스 동기화 방향, 깃 설정, fortune 타임아웃 관련 노트를 한데 모아서 팀 온보딩 문서화를 다시 정돈했다.
읽기 → -
마일스톤·출시게이트 갱신으로 프로젝트 방향 명확화
A4 완료, Phase B 작업보드, 출시게이트 갱신—이 세 가지 변경이 한 번에 들어갔다. 단순히 문서 업데이트처럼 보이지만, 이건 프로젝트가 한 단계 성숙해졌다는 신호다.
읽기 → -
dev 브랜치 PR 정책을 문서화해 팀 협업 신뢰도를 높였다
PROGRESS.md를 수정해서 브랜치 흐름을 정정했다. "메인 작업도 dev에 직접 커밋하면 안 되고, dev PR을 통해야 한다"는 룰을 명시한 것인데, 사실 이건 이미 어느 정도 지켜지고 있던 관행을 문서로 명확히 한 거다.
읽기 → -
공용 작업 브랜치를 dev로 통일해 온보딩 비용을 줄인 이야기
"어디서 작업해야 하지?" 새로운 팀원이 묻던 질문이 반복되기 시작했다. 브랜치 규칙이 명시되지 않아서였다. 개발자들은 각자 편한 이름의 브랜치에서 작업했고, 통합은 누군가의 관습에 맡겨졌다. 이번에 결정했다: **모든 공용 작업 브랜치를 dev로 통일하기.** PROGRESS.md에 규칙을 명문화했다.
읽기 → -
진행 상황 문서 정기 갱신으로 팀 컨텍스트 맞추기
오늘 PROGRESS.md를 업데이트했다. 로그인 기능이 드디어 활성화 단계로 들어갔고, 중복 처리 버그도 고쳤으며, 새로운 브랜치인 메인의 작업 현황까지 반영했다. 문서 하나 갱신하는 일처럼 보일 수 있지만, 이건 팀의 현재 지점을 정의하는 작업이었다.
읽기 → -
구글 로그인·코인 다리 완성 후 진행 문서로 팀 방향을 정렬한 경험
마일스톤을 지날 때마다 PROGRESS.md 를 꼼꼼히 업데이트했다. 구글 로그인이 활성화되고, 코인 다리 기능이 연결되었으며, 온보딩과 스플래시 스크린이 다음 작업으로 명시되는 순간, 문서를 정리하는 건 단순 기록이 아니라 팀의 흐름을 가시화하는 일이었다.
읽기 →