개발
코드 / 아키텍처 / 디버깅
-
Apple 심사 다섯 번 거부를 거쳐 배운 것들
일일 성경 앱을 iOS에 출시하기 위해 Apple App Store 심사에 올린 지 몇 주. 빌드 1에서 4까지 줄줄이 리젝을 맞으며, 다섯 번째 제출 때야 비로소 통과 소식을 받았다. 이번 작업은 그 과정에서 불거진 로그인 버그, EULA 미비, 계정삭제 기능 부재, Kakao 로그인 권한 정책 등 여러 이슈를 한 번에 해결하는 수정이었다.
읽기 → -
머천트 계좌 검증 회귀 버그 수정
결제 플랫폼의 WELCOME 시스템에서 머천트 잔액 조회 및 계좌 검증이 일부 코드 경로에서 누락되었던 로직을 보충했다. 주요 변경은 파트너 관리 웹 계층과 공통 유틸리티 계층에 걸쳐 이루어졌다.
읽기 → -
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 조회로 파라미터화
결제 게이트웨이의 원가를 하드코딩된 값에서 데이터베이스 조회로 전환했다. 운영 환경에서 코드 배포 없이 원가 정보를 유연하게 관리하기 위한 작업이었다.
읽기 → -
검색 결과에서 낡은 글·짧은 글 차단
블로그의 SEO 건강도를 해치는 얇은 포스트와 백데이트된 오래된 글들에 noindex 메타 태그를 붙였다. 단순한 기술 수정처럼 보이지만, 시스템에서 "어떤 콘텐츠를 중요하게 보일 것인가"를 결정하는 정책 개선이었다.
읽기 → -
본인인증 정보 저장 범위 확대
결제 플랫폼에 연동된 본인인증 PG(제주)에서 제공하는 응답값을 전부 활용하지 못하고 있었다. 이번 작업은 기존에 저장하던 **이름, 휴대폰**에 더해 **생년월일·통신사·내외국인 여부** 3개 필드를 새로 저장하도록 시스템을 확장한 거다.
읽기 → -
누락된 서비스 로깅 설정 추가
신규 웹 서비스가 추가되었는데 페이지뷰 분석 시스템(site-pv)에 로그 수집 설정이 빠져 있었다. 전용 로그 채널을 등록해서 이 서비스의 트래픽 추적을 활성화했다.
읽기 → -
조회수 대시보드 확장하며 배운 설계 포인트
사내 여러 서비스의 트래픽을 한눈에 보기 위해 조회수 대시보드를 운영 중인데, 최근 life/name 서비스를 새롭게 추적 대상으로 추가했다. 단순히 로그 수집만 늘리는 게 아니라, 로그 전용화(DEDICATED_LOGS)와 표시 순서 제어(DISPLAY_ORDER)라는 구조를 도입하면서 대시보드를 어떻게 확장할 것인가에 대해 한두 가지 배운 게 있다.
읽기 → -
서비스 접근 로그 독립 추적 체계 구축
특정 도메인의 사용자 접근 패턴을 더 정확히 추적하기 위해 기존 통합 로깅 시스템에서 전용 로그 채널을 등록했다.
읽기 → -
포트폴리오 섹션 순서를 언어별로 통일하다
개인 포트폴리오 사이트에서 한국어판과 영문판 간의 레이아웃 순서를 맞추는 작업을 했다. 구체적으로는 영문판에서 블로그 섹션을 About 섹션 위로 이동시켜 한국어판과 동일한 배치로 만들었다.
읽기 →