일기
회고 / 메모
-
프로젝트 전환 시 만나는 서버 함정 문서화
한 서비스에서 다른 서비스로 인수인계하거나 전환하는 과정은 생각보다 복잡하다. 겉으로는 "코드만 옮기고 배포하면 되지 않나" 싶지만, 실제로는 배포 환경, 네트워크 설정, 외부 연동 등 크고 작은 차이들이 도사리고 있다. psy에서 curiodot로 전환하면서 우리 팀이 마주한 서버 함정들—배포타겟, 포트, indexnow, 위젯 설정 관련 이슈들이—반복되
읽기 → -
검색 엔진 핑을 빌드 시스템으로 정식화
오래전부터 돌아가던 indexnow-ping 스크립트를 /opt/psy-build 라는 격리된 디렉토리에서 빼내 정식 빌드 파이프라인으로 옮기는 작업을 했다. 작은 변경으로 보일 수 있지만, 이 정식화 과정에서 배운 게 꽤 있어서 글로 남긴다.
읽기 → -
도메인 전수 정리, 설정부터 배포까지 한눈에 확인
도메인과 경로명을 이전 명칭에서 새 명칭으로 전체 통일하는 작업을 마쳤다. 단순한 코드 리팩토링이 아니라 프로젝트 전반의 설정, 문서, 빌드, 배포 스크립트까지 걸쳐 있었기 때문에 생각보다 꼼꼼한 검증이 필요했다.
읽기 → -
거짓 timeout으로 헷갈리던 slot 체크, 근본 수정
slot-checkup에서 거짓 timeout 판정이 계속 나타나곤 했다. 사용자 입장에선 "뭐가 문제지?" 싶은 상황이 반복되고, 개발팀도 그 원인을 추적하기 쉽지 않았다. 결국 근본 원인을 파악해 수정했고, 그 과정과 교훈을 문서에 남기는 작업을 했다.
읽기 → -
OAuth 요청 한도, 백필 스크립트로 우회하다
대량 초기 데이터를 로드할 때 OAuth 요청 한도에 자꾸 부딪혀서, 자동화 스크립트로 문제를 우회하는 방식을 택했다.
읽기 → -
팀 인수인계 시 함정을 미리 알려주는 문서 작성
새로운 세션(혹은 프로젝트 단계)이 시작될 때 이전 팀이 알던 내용을 어떻게 다음 팀에 효과적으로 넘길 것인가 하는 문제는 생각보다 복잡하다. 특히 개발 팀장이라면 단순히 코드 리뷰만 하는 게 아니라, 팀 구성원의 온보딩, 의사결정의 배경, 그리고 숨어 있는 함정까지 전달할 책임이 있다.
읽기 → -
핸드오프 플랜 검증 추적 명확해졌다
자동화 플랫폼의 핸드오프 문서에 "라이브 재검증 스탬프"를 추가했다. 작은 문서 업데이트지만, 팀의 운영 신뢰도에 꽤 영향을 미치는 변경이었다.
읽기 → -
법적 문서 중앙화로 운영 일관성 확보하기
privacy, cookies, policy 같은 법적 문서들을 전부 legal.hedvion.com 으로 옮기면서 기존의 분산된 on-site 예외를 폐기했다. 작은 구조 변경으로 보이지만, 팀이 문서를 관리하는 방식과 사용자가 접근하는 흐름을 깔끔하게 정리한 작업이었다.
읽기 → -
진행 상황과 다음 계획을 문서화하다
프로젝트의 진행 상황과 다음 단계의 계획을 docs/PLAN.md에 정리해서 팀에 핸드오프했다. 단순해 보이는 문서 하나지만, 팀과의 동기화와 컨텍스트 전달에서 생각보다 많은 역할을 한다.
읽기 → -
약관 운영 중앙화로 팀 일관성 확보
회사 내 약관 및 법무 문서 관리를 중앙 도메인(legal.hedvion.com)으로 통합하고, 운영 지침을 체계화해서 문서화했다. 단순한 폴더 정리가 아니라, 팀의 의사결정 구조와 책임 소재를 명확히 하는 작업이었다.
읽기 → -
새 프로젝트, 처음부터 협업이 쉽도록
새 프로젝트를 시작할 때 가장 먼저 하는 일은 폴더를 정리하고 각 팀원이 진입할 문을 만드는 것이다. 이번엔 음악 정보를 다루는 구조화 데이터 플랫폼의 초기 구조를 잡는 작업(scaffold)을 했는데, 생각보다 이 "첫삽"이 얼마나 중요한지 다시 깨달았다.
읽기 → -
도메인 변경 후 문서 참조 일괄 수정
서비스의 도메인 주소가 변경됨에 따라 문서에 하드코딩되어 있던 URL 참조를 일괄 업데이트했다. CLAUDE.md 파일에 분산된 4곳의 도메인 링크를 새로운 주소로 수정하는 작업이었는데, 생각보다 "찾기"가 핵심이었다.
읽기 → -
Discord 채널 설명에 도메인 명시해 혼동 방지
Discord의 채널 설명(channel description) 같은 작은 메타데이터도 팀 협업 효율에 생각보다 큰 영향을 미친다는 걸 다시 한 번 느낀다. 이번 커밋은 psy 채널 설명에 curiodot.com 도메인을 명시하는 작업인데, 얼핏 보면 한 줄 정도의 chore처럼 보이지만, 온보딩과 팀 커뮤니케이션 관점에서는 의외로 실질적인 개선다.
읽기 → -
스토어 리뷰 요청사항 반영한 빌드 업로드
앱 스토어 리뷰팀의 피드백에 따라 iOS 빌드를 재준비했다. Apple 로그인 capability를 추가하고, Google 관련 설정을 plist에 명시해야 했다. 요청사항 반영 후 1.0.0+6 버전으로 다시 배포했다.
읽기 → -
앱스토어 검수 거부에 대응하는 체계화
빌드 5번 거부는 단순한 실패가 아니다. 각 거부마다 다른 이유가 있었고, 팀은 매번 피드백을 해석하고 수정하고 다시 제출했다. 하지만 과정 속에서 "이전에 왜 거부되었는지", "지금 대응이 충분한지"를 명확히 추적하기 어려워졌다. 그래서 Apple의 회신문을 정리하고, 각 거부 사항에 대한 우리의 대응 계획을 체크리스트로 만들기로 했다.
읽기 → -
앱 심사 제출 전 체크리스트, 실제 환경 설정과 검증으로 다시 정리
빌드5를 앱 스토어에 제출하기 직전, 실제 환경에서 작동해야 할 광고와 결제 관련 설정들을 최종 점검했다. 이전 빌드들의 심사 과정에서 놓치기 쉬웠던 부분들을 문서로 정리하면서, 앞으로 팀 내에서도 심사 전 체크리스트로 활용할 수 있겠다는 생각이 들었다.
읽기 → -
여러 환경에 스키마를 배포하며 배운 점
제주 응답로그의 DDL(Database Definition Language)을 개발, 운영, 쇼핑몰 플랫폼 총 3개 환경에 반영 완료했고, 이 과정을 진행 상황 handoff 문서에 기록했다. 단순해 보이지만, 이것은 팀의 데이터 스키마 관리 및 배포 전략의 중요한 마일스톤이었다.
읽기 → -
결제 연동 준비 현황 문서화
결제 플랫폼 PG 시스템 연동 작업이 코드 단계에서는 거의 완료됐지만, 최종 인증 설정값을 기다리는 상황이었다. 그 과정에서 "라이브 배포 준비는 끝났는데, 왜 아직 못 가는가?"를 팀원들과 공유하려면 단순 구두 설명론 부족했다. 그래서 작업 지침 문서와 현재 상태 추적 문서를 함께 작성했다.
읽기 → -
결제 웹훅 핸들러 구현 완료 문서 업데이트
결제 플랫폼 연동 문서에서 웹훅 수신기 Controller가 완성되었음에도 TODO로 표기되어 있던 부분을 '구현완료'로 정정했다.
읽기 → -
웰컴 제거 진행 상황 실소스 기준으로 정정
며칠 전 이커머스 PG 플랫폼의 웰컴 기능 제거 작업을 진행하면서, 그동안 작성해둔 진행 문서들을 다시 읽어 보니 현재 상황과 맞지 않는 부분들이 있었다. 실제 코드베이스를 기준으로 다시 확인하고 문서를 정정했다. 함께 그 과정에서 느낀 것들을 공유한다.
읽기 →