-
로그인 버튼 누르면 앱이 죽던 버그 수정
Firebase나 Google OAuth 같은 써드파티 인증을 모바일 앱에 연동할 때는 늘 신경 쓸 게 많다. 이번엔 일일 성경 앱에서 Google 로그인을 누르는 순간 앱이 죽어버리는 크래시가 발생했고, 동시에 로그인 버튼의 Google 로고도 제대로 표시되지 않던 문제를 함께 수정했다. 작은 문제처럼 보이지만 로그인은 앱의 첫 진입점이고, 이곳이 깨지면
읽기 → -
스토어 리뷰 요청사항 반영한 빌드 업로드
앱 스토어 리뷰팀의 피드백에 따라 iOS 빌드를 재준비했다. Apple 로그인 capability를 추가하고, Google 관련 설정을 plist에 명시해야 했다. 요청사항 반영 후 1.0.0+6 버전으로 다시 배포했다.
읽기 → -
의존성 버전 명시로 팀 빌드 일관성 확보
url_launcher pod 의존성을 Podfile.lock에 반영했다. 사소해 보이는 작업이지만, 팀 프로젝트에서는 꽤 중요한 동기화 작업이다.
읽기 → -
앱스토어 검수 거부에 대응하는 체계화
빌드 5번 거부는 단순한 실패가 아니다. 각 거부마다 다른 이유가 있었고, 팀은 매번 피드백을 해석하고 수정하고 다시 제출했다. 하지만 과정 속에서 "이전에 왜 거부되었는지", "지금 대응이 충분한지"를 명확히 추적하기 어려워졌다. 그래서 Apple의 회신문을 정리하고, 각 거부 사항에 대한 우리의 대응 계획을 체크리스트로 만들기로 했다.
읽기 → -
Apple 심사 다섯 번 거부를 거쳐 배운 것들
일일 성경 앱을 iOS에 출시하기 위해 Apple App Store 심사에 올린 지 몇 주. 빌드 1에서 4까지 줄줄이 리젝을 맞으며, 다섯 번째 제출 때야 비로소 통과 소식을 받았다. 이번 작업은 그 과정에서 불거진 로그인 버그, EULA 미비, 계정삭제 기능 부재, Kakao 로그인 권한 정책 등 여러 이슈를 한 번에 해결하는 수정이었다.
읽기 → -
머천트 계좌 검증 회귀 버그 수정
결제 플랫폼의 WELCOME 시스템에서 머천트 잔액 조회 및 계좌 검증이 일부 코드 경로에서 누락되었던 로직을 보충했다. 주요 변경은 파트너 관리 웹 계층과 공통 유틸리티 계층에 걸쳐 이루어졌다.
읽기 → -
앱 심사 제출 전 체크리스트, 실제 환경 설정과 검증으로 다시 정리
빌드5를 앱 스토어에 제출하기 직전, 실제 환경에서 작동해야 할 광고와 결제 관련 설정들을 최종 점검했다. 이전 빌드들의 심사 과정에서 놓치기 쉬웠던 부분들을 문서로 정리하면서, 앞으로 팀 내에서도 심사 전 체크리스트로 활용할 수 있겠다는 생각이 들었다.
읽기 → -
iOS 앱 광고·결제 프로덕션 ID 본격 적용
처음으로 광고와 인앱 결제 기능을 실제 운영 환경 설정으로 전환했다. 개발 단계에선 테스트 ID를 썼다면, 이제 실제 사용자가 만나볼 애플리케이션으로 준비하는 단계였다.
읽기 → -
판매자 출금이 잘못된 결제사로 전송되던 버그 고침
이번에는 멀티 PG(결제 게이트웨이) 환경에서 출금 처리 시 잘못된 결제사로 라우팅되던 버그를 고쳤다. sysId별로 사용하는 PG가 다른데, 머천트 잔액조회 로직에서 이 분기를 제대로 반영하지 않아서 웰컴(쇼핑몰 플랫폼)의 출금 기능이 재차 깨지는 회귀가 생겼던 것.
읽기 → -
한글 슬러그 301 리디렉션으로 SEO 중복 콘텐츠 문제 해결
초기에 구축한 서비스에서 한글 문자가 포함된 슬러그(URL 경로)를 레거시 형태로 그대로 두고 있었는데, 이게 결국 검색 엔진 입장에서 중복 콘텐츠로 인식되는 문제가 발생해서 301 리디렉션으로 정리하게 됐다. 단순한 URL 정리처럼 보이지만, SEO 관점에서 생각할 점들이 꽤 많이 있었다.
읽기 → -
한글 URL을 정규화해서 검색 엔진 최적화 완성
한글 문자가 직접 포함된 기존 URL들을 정규 형태로 301 리다이렉트했다. cms_legacy_slug 필드로 레거시 경로와 새 경로를 매핑하고, DB 쿼리와 라우팅 로직에서 이를 처리하는 식이다.
읽기 → -
레거시 게시물 URL을 새 주소로 자동 이동
지난 세션에서 콘텐츠 경로 구조를 /{slug} 에서 /p/{id} 로 개편했는데, 이때 이전 URL들이 깨지면 사용자가 북마크한 링크나 외부 인링크가 모두 dead link 가 되어 버린다. 특히 검색 엔진이 그 페이지들을 색인 해제하려고 기다리는 동안 SEO 손실이 누적된다. 그래서 301 리다이렉트를 사용해 레거시 경로를 새로운 구조로 자동 이동시키는
읽기 → -
레거시 URL 경로 유지로 검색 가시성 보존
구 URL 구조(/{slug})에서 새로운 구조(/p/{id})로 마이그레이션하면서, 기존에 인덱싱된 모든 레거시 경로를 301 영구 리다이렉트로 자동 연결하는 작업을 했다. 작은 변경처럼 보이지만 SEO 손실, 사용자 경험, 외부 인바운드 링크 유지 관점에서 꽤 중요한 결정 포인트였다.
읽기 → -
레거시 경로를 새 구조로 301 리다이렉트 구성
레거시 URL 구조(/{slug})에서 새로운 경로(/p/{id})로 마이그레이션하면서 기존 링크들을 301 영구 리다이렉트로 연결하는 작업을 했다. Astro의 동적 라우팅을 활용해 SEO 손실을 최소화하면서 깔끔하게 처리했는데, 이런 류의 경로 마이그레이션은 생각보다 신경 쓸 부분이 많더라.
읽기 → -
레거시 경로 영구 리다이렉트로 검색 트래픽 보존
기존 /{slug} 형태의 레거시 URL 구조를 새로운 /p/{id} 형태로 정리하면서, 301(Moved Permanently) 상태 코드를 이용해 검색 엔진과 사용자를 자동으로 안내하는 작업을 했다. 단순히 URL을 바꾼 것이 아니라, SEO 손실을 방지하고 기존 유입경로를 보존하는 리다이렉트 전략이 핵심이었다.
읽기 → -
레거시 퍼머링크를 301 리다이렉트로 통합했다
몇 달 전부터 서비스의 URL 구조를 /{slug} 형식에서 /p/{id} 형식으로 정리하고 있었다. 당시엔 신규 구조로의 전환만 진행했는데, 이번엔 **여전히 구형 URL로 들어오는 트래픽을 301 영구 리다이렉트**로 깔끔하게 처리했다.
읽기 → -
블로그 URL 마이그레이션에서 검색 순위 보존하기
블로그 포스트의 URL 구조를 /{slug} 에서 /p/{post_sn} 로 변경하면서, 기존 링크들을 301 리다이렉트로 연결했다. 미미해 보이지만 이 작업이 없었으면 SEO 관점에서 큰 손실이 있었을 작업이었다.
읽기 → -
결제 플랫폼 전환 완료, 출금·로그 강화
기존 결제 플랫폼에서 새로운 PG로 컷오버하는 작업을 마쳤다. 단순한 결제 모듈 교체가 아니라 파트너 정산, 출금, 잔액 계산, 청구 배치까지 연쇄적으로 영향받는 작업이었기 때문에 여러 모듈을 동시에 수정하고 안정성을 높였다.
읽기 → -
PG 원가를 DB 조회로 파라미터화
결제 게이트웨이의 원가를 하드코딩된 값에서 데이터베이스 조회로 전환했다. 운영 환경에서 코드 배포 없이 원가 정보를 유연하게 관리하기 위한 작업이었다.
읽기 → -
여러 환경에 스키마를 배포하며 배운 점
제주 응답로그의 DDL(Database Definition Language)을 개발, 운영, 쇼핑몰 플랫폼 총 3개 환경에 반영 완료했고, 이 과정을 진행 상황 handoff 문서에 기록했다. 단순해 보이지만, 이것은 팀의 데이터 스키마 관리 및 배포 전략의 중요한 마일스톤이었다.
읽기 →