개발
코드 / 아키텍처 / 디버깅
-
결제 인증 화면 일관성 개선과 인증 방식 현대화
결제 플랫폼의 계정 검증 단계를 손봤다. 디자인 시스템 통일과 인증 수단 전환이 함께 들어간 작업이었는데, 이 과정에서 여러 고민이 있었다.
읽기 → -
결제 PG의 원가 설정값 정정
결제 게이트웨이 통합에서 원가와 사용자 수수료를 혼동하는 버그를 발견해서 수정했다. 한 PG사(jeju)의 설정 테이블에서 pgCost(PG에게 우리가 지불하는 원가)가 사용자 수수료로 잘못 입력되고 있었다. 문서, Java 코드, SQL 초기화 스크립트까지 세 곳을 동시에 정정해서 설정값의 일관성을 맞췄다.
읽기 → -
신규 결제 수단 추가로 충전 유입 다양화
지갑 결제 시스템에 두 가지 새로운 결제 수단을 추가했다: 특정 카드 결제 PG와 가상계좌 통합인증.
읽기 → -
셀카 이미지 6장 복구, gitignore 충돌 수정
최근 배포 파이프라인에서 캐릭터 미디어 에셋이 누락되는 문제가 발견됐다. 원인은 두 가지가 함께 작용했다: (1) 실제 이미지 파일이 저장소에서 유실됨, (2) .gitignore의 패턴 충돌로 파일이 제대로 추적되지 않음. 이번 작업에서 두 문제를 동시에 해결했다.
읽기 → -
결제 컷오버 범위 확대, 충전 수수료 로직 재설계
결제 시스템의 P6 단계 적용 범위를 14곳으로 확대하고, 동시에 충전 수수료 계산 로직 5곳을 재설계했다. 한 번에 여러 도메인을 건드리는 작업이었기에 그 의도와 과정을 정리해본다.
읽기 → -
API 비용을 모델별·계정별로 한눈에 보기
Claude API를 팀 단위로 쓰면서 가장 신경 쓰이는 게 비용 관리다. 이번에 계정별 사용량을 모델별로 분리해서 추적하고, Discord를 통해 자동으로 리포트하는 기능을 만들었다.
읽기 → -
크롤 콘텐츠 재구성을 2단계로 나눴더니 품질이 올랐다
최근에 크롤링한 콘텐츠를 재구성하는 파이프라인을 2단계로 분리했다. 기존에는 한 번의 프롬프트 호출로 "기획 + 작성"을 한꺼번에 처리했는데, 이제 Sonnet으로 먼저 구조를 잡고 Haiku로 실제 콘텐츠를 만드는 식으로 개선했다. 같은 입력인데도 결과물이 더 고유하고 일관성 있게 나오니까, 이제는 이렇게 하는 게 기본이 될 것 같다.
읽기 → -
결제 플랫폼과 거래 기록 시스템 통합
새로운 결제 게이트웨이(kp-pay)로 완전히 전환하면서, 거래 기록 관리 체계까지 함께 중앙화하는 대규모 마이그레이션의 P1~P6 골격을 완성했다.
읽기 → -
백업 계정 주기 교체로 인증 안정성 확보
백업 계정의 주기적 로테이션을 자동화하는 매니저를 구현했다. 기존엔 수동으로 처리되던 B레이어의 계정 교체를 Python 풀 매니저로 일괄 관리하고, 셸 스크립트로 인증 상태를 실시간 검증하는 구조로 변경했다.
읽기 → -
한도 초과할 때도 서비스 지속할 수 있게 상위 모델로 자동 전환
주간 API 호출 한도 제한이 있는 환경에서 기본 모델의 할당량이 떨어지면 상위 모델로 자동 폴백하는 기능을 A레이어에 추가했다. 이렇게 하면 사용자가 명시적으로 모델을 바꾸지 않아도 한도 초과 상황에서 서비스가 중단되지 않는다.
읽기 → -
자격 판별 용어 불일치로 매칭 오류 발생하던 문제 해결
HTML에서 파싱한 자격 조건 용어와 매칭 도구가 지원하는 옵션 목록이 어긋나 있었다. 이번 작업으로 두 데이터 소스의 어휘를 정렬(align)하고, 자격 판별 로직의 정확성을 높였다.
읽기 → -
포스트 등록 시 자격 요건을 자동 추출하도록 개선
새 포스트가 INSERT될 때 관련 자격 요건(eligibility)을 자동으로 추출하는 기능을 추가했다. 이전에는 포스트 생성 후 별도 단계에서 수동으로 자격 요건을 판별하거나, 일관성 없게 처리되곤 했는데, 이를 데이터 삽입 시점으로 당겨서 자동화한 작업이다.
읽기 → -
CMS 게시물의 자격요건을 자동으로 구조화
정부 규정 관련 CMS 게시물에서 자격 정보를 자동으로 추출하는 기능을 만들었다. 게시물이 텍스트 형태로 저장되어 있다면, 그 안에 산재된 자격요건들을 구조화된 데이터로 변환해야 하는 경우가 자주 생긴다. 이번 작업은 그 변환 과정을 체계화한 것이다.
읽기 → -
여러 제품군 스토어 이미지 정렬
마케팅 에셋 정정 작업을 했다. 여러 제품 라인의 스토어 표시 이미지들을 올바르게 정렬하는 작업이었는데, 이렇게 단순해 보이는 작업이 실은 팀 협업과 시스템 신뢰성의 척도라는 걸 다시 깨달았다.
읽기 → -
유료 워치페이스 앱 제출 상태 검증 완성
유료 watchface 앱 5개를 마켓플레이스 콘솔에 제출하고, 각 앱의 제출 상태를 자동으로 검증하는 기능을 완성했다. 이 작업은 단순해 보이지만, 여러 앱을 일괄 관리하면서 휴먼 에러를 줄이고 출시 프로세스를 재현 가능하게 만드는 데 꽤 중요했다.
읽기 → -
프로 테마, 독립된 서명으로 배포 관리 정리하다
프로 버전의 여러 테마(Crimson, Graphite, Ivory, Noir, Slate)들을 각각 독립적인 keystore로 서명하도록 전환했다. 각 테마 build.gradle.kts를 수정하고, 배포 계획 문서를 함께 업데이트했다.
읽기 → -
5개 워치페이스를 유료판으로 재패키징하다
5개의 워치페이스를 새로운 패키지명으로 통일하고 버전을 초기화해서 유료 재출시를 준비했다. 각 build.gradle.kts 파일을 돌면서 namespace를 com.hedvion.watchface.<face>pro 패턴으로 변경하고, versionCode를 1로 설정한 거다. 이건 단순한 빌드 설정 변경처럼 보이지만, 제품 전략과 기술 관리가 얽혀 있는
읽기 → -
블로그 서브도메인 분리로 서비스 구조 정리
메인 도메인 구조를 정리하면서 블로그 콘텐츠를 별도의 서브도메인으로 분리했다. 초기에는 메인 도메인 아래 /blog 경로로 호스팅했지만, 서비스가 성장하면서 콘텐츠와 메인 서비스를 물리적으로 분리해야 한다는 필요성이 생겼다. 특히 트래픽 분산, SEO 최적화, 그리고 향후 블로그 플랫폼의 독립적 관리를 고려하면 서브도메인 분리가 더 효율적이라고 판단했다.
읽기 → -
워치페이스 여러 변형, SDK 버전 동시 통일
최근에 Wear OS 워치페이스 프로젝트의 5개 워치페이스(crimson, graphite, ivory, noir, slate)를 동시에 새 SDK 버전으로 업그레이드하고, 클로즈드 테스트 전에 릴리스 체크리스트를 정리하는 작업을 했다. 이번 글에선 여러 워치페이스 변형을 관리할 때 마주하는 문제와 그걸 어떻게 풀어냈는지 회고해본다.
읽기 → -
여러 워치페이스 비공개테스트 한 번에 준비
Wear OS 기반 워치페이스 여러 개를 동시에 비공개테스트 단계로 옮기는 작업을 했다. RELEASE_PLAN.md 를 정리하고, Apex 및 Azure 워치페이스의 빌드 설정과 에셋을 정리한 뒤, 팀원들에게 6개 면을 핸드오프했다.
읽기 →