일기
회고 / 메모
-
워치페이스 옵트인 정책을 설치무관 기준으로 통일
6개 워치페이스의 옵트인 게이트 정책을 확정했다. 그간 모호했던 "언제부터 사용자에게 이 페이스를 공개할 것인가"라는 질문에 명확한 답을 내린 작업이다.
읽기 → -
복잡한 릴리스 계획을 더 명확하게 정의
이번에는 릴리스 계획 문서(RELEASE_PLAN.md)를 손봤다. 웨어러블 기기용 새로운 폼팩터 지원, 특정 릴리스 버전을 막고 있는 블로커들, 그리고 워치페이스 단위의 상태 추적을 추가한 것이다. 문서 한 장인지라 코드 변경은 없지만, 팀이 나아가는 방향과 우선순위를 결정하는 데 꽤 중요한 작업이었다.
읽기 → -
앱 아이콘 불일치 수정하고 빌드 설정 현행화
여러 개의 변형(variant)으로 배포되는 안드로이드 앱을 관리하다 보니, 각 변형마다 일관되지 않은 설정들이 쌓이기 시작했다. SDK 버전 타겟팅, 런처 아이콘, 스토어 메타데이터—이런 것들이 하나하나는 작아 보이지만, 모여서는 사용자에게 혼란을 주고 스토어 심사 시 까다로운 항목들이 된다. 이번엔 그 불일치들을 정리한 작업이다.
읽기 → -
운세 타임아웃·트러스 동기화·깃 설정을 온보딩 문서 한 곳에 정리
CLAUDE.md에 세 가지 중요한 설정 가이드를 정리했다. 서버 트러스 동기화 방향, 깃 설정, fortune 타임아웃 관련 노트를 한데 모아서 팀 온보딩 문서화를 다시 정돈했다.
읽기 → -
마일스톤·출시게이트 갱신으로 프로젝트 방향 명확화
A4 완료, Phase B 작업보드, 출시게이트 갱신—이 세 가지 변경이 한 번에 들어갔다. 단순히 문서 업데이트처럼 보이지만, 이건 프로젝트가 한 단계 성숙해졌다는 신호다.
읽기 → -
dev 브랜치 PR 정책을 문서화해 팀 협업 신뢰도를 높였다
PROGRESS.md를 수정해서 브랜치 흐름을 정정했다. "slecs 작업도 dev에 직접 커밋하면 안 되고, dev PR을 통해야 한다"는 룰을 명시한 것인데, 사실 이건 이미 어느 정도 지켜지고 있던 관행을 문서로 명확히 한 거다.
읽기 → -
공용 작업 브랜치를 dev로 통일해 온보딩 비용을 줄인 이야기
"어디서 작업해야 하지?" 새로운 팀원이 묻던 질문이 반복되기 시작했다. 브랜치 규칙이 명시되지 않아서였다. 개발자들은 각자 편한 이름의 브랜치에서 작업했고, 통합은 누군가의 관습에 맡겨졌다. 이번에 결정했다: **모든 공용 작업 브랜치를 dev로 통일하기.** PROGRESS.md에 규칙을 명문화했다.
읽기 → -
진행 상황 문서 정기 갱신으로 팀 컨텍스트 맞추기
오늘 PROGRESS.md를 업데이트했다. 로그인 기능이 드디어 활성화 단계로 들어갔고, 중복 처리 버그도 고쳤으며, 새로운 브랜치인 slecs의 작업 현황까지 반영했다. 문서 하나 갱신하는 일처럼 보일 수 있지만, 이건 팀의 현재 지점을 정의하는 작업이었다.
읽기 → -
구글 로그인·코인 다리 완성 후 진행 문서로 팀 방향을 정렬한 경험
마일스톤을 지날 때마다 PROGRESS.md 를 꼼꼼히 업데이트했다. 구글 로그인이 활성화되고, 코인 다리 기능이 연결되었으며, 온보딩과 스플래시 스크린이 다음 작업으로 명시되는 순간, 문서를 정리하는 건 단순 기록이 아니라 팀의 흐름을 가시화하는 일이었다.
읽기 → -
진행 상황 문서로 팀 의사결정을 체계적으로 기록하는 법
PROGRESS.md를 갱신했다. 로그인, 친밀도, 사진업로드, fresh셀카, 외모, LLM 관련 결정들이 쌓여가면서 한번쯤은 정리해야겠다 싶어서다. 단순한 문서 갱신이지만, 이 작은 습관이 팀 운영에서 생각보다 큰 역할을 한다는 걸 계속 느끼고 있다.
읽기 → -
인물 카드·감정 케어 완료를 살아있는 진행 문서로 기록한 방법
이번엔 PROGRESS.md 파일을 갱신했다. 개별 인물 카드와 감정 케어 기능이 완료됨을 반영하는 작업이었는데, 단순한 체크리스트 업데이트가 아니라 팀이 지금까지 어디까지 왔는지를 어떻게 투명하게 기록하고 공유할 것인가 하는 문제에 시간을 썼다.
읽기 → -
서브도메인 신규 서비스, 스캐폴딩으로 팀 협업 기반 구축
새로운 서브도메인 서비스 프로젝트를 시작할 때, 가장 먼저 해야 할 일은 코드를 짜는 게 아니라 팀이 협업할 '뼈대'를 만드는 것이다. 이번에 진행한 프로젝트 스캐폴딩 작업이 정확히 그것이었다.
읽기 → -
Codex 런타임 검증 게이트 설계 의도를 팀 문서로 정리한 과정
Codex 시스템의 런타임 검증 게이트(codex_review.py)와 그 설계 철학을 CLAUDE.md에 정리하는 작업을 마무리했다. 단순히 "코드가 어떻게 돌아가는가"를 설명하는 것이 아니라, "이 검증 단계가 왜 여기에 있고, 어떤 의도로 작동하는지"를 팀이 공유할 수 있도록 문서화했다.
읽기 → -
Discord 토큰 모니터링 카드에서 모델별 주간 섹션을 걷어낸 이유
토큰 사용량 Discord 모니터링 카드에서 모델별 주간 섹션을 제거했다. 운영 신호와 정보 밀도의 트레이드오프를 놓고 고민한 작업이었다.
읽기 → -
App Store 리젝 여러 건을 팀이 함께 추적하는 문서 체계 구축
App Store 심사에서 리젝이 나올 때, 특히 여러 건이 동시에 들어오면 팀이 현황을 정확히 파악하기 어려워진다. "어디까지 수정했고, 어떤 부분이 남았는지" 를 공유하는 과정이 생각보다 복잡하기 때문이다. 메시지나 이슈로만 전달하면 시간이 지나면서 누가 뭘 하고 있는지 흐릿해지고, 특히 여러 사람이 동시에 다른 리젝에 대응할 때는 더 그렇다. 이번 작
읽기 → -
CLAUDE.md로 팀 배포 자동화 방향을 문서화한 이유
작은 팀 프로젝트에서 CLAUDE.md를 만들고, 풀오토 배포 아이디어를 문서화하기 시작했다.
읽기 → -
SMS 감지 후 텔레그램 포워딩 안드로이드 앱 초기 구조 완성
새로운 프로젝트를 시작했다. SMS 메시지를 자동으로 감지해서 텔레그램으로 포워딩하는 안드로이드 앱이다. 실시간 알림이 중요한 환경에서 SMS를 놓치지 않으면서도 특정 메시지만 선별해서 메신저로 받고 싶은 요구가 있었다. 이 커밋은 그 프로젝트의 초기 뼈대를 잡은 작업이다.
읽기 → -
이미지 생성 API 키 설정을 README에 문서화해 팀 온보딩을 개선
README.md에 GEMINI_API_KEY 환경 변수 설정 방법을 문서화했다. 이미지 생성 전용 키라는 점을 명확히 남겼는데, 이런 작은 문서화 하나가 팀 전체의 온보딩과 운영을 얼마나 부드럽게 만드는지를 다시 느꼈다.
읽기 → -
릴리즈 Firebase 설정 갱신으로 인증 오류 방지
안드로이드 프로젝트의 Google Services 설정 파일을 릴리즈 빌드용으로 갱신했다. 단순한 설정 파일 업데이트처럼 보이지만, 이 작업 흐름에는 릴리즈 배포 프로세스의 중요한 결정점들이 숨어 있다.
읽기 → -
유료기능·TTS 업그레이드·AAB 빌드가 한 주에 수렴된 개발 마일스톤
어제 STATUS.md를 갱신하면서 한 주의 개발 진행도를 정리했다. 유료기능 완결, TTS Chirp3-HD 적용, AAB 빌드 반영 — 세 가지 결과물이 한 번에 수렴되는 시점이었다.
읽기 →