-
백업 로그인 중 cron 동시 실행 방지
백업 로그인 기능을 추가하면서 동시성 제어의 중요성을 다시 한 번 깨달았다. 계정 관리 스크립트가 자동화되면서 여러 작업이 병렬로 실행될 가능성이 높아졌고, 특히 사용자가 수동으로 백업 로그인을 수행 중일 때 cron이 동시에 계정 상태를 변경하려 하면 상태 불일치나 데이터 손상이 발생할 수 있다는 걸 깨달았다.
읽기 → -
여전히 필수인 통계 시스템, 폐기로 표기되다
사내 통계 시스템 문서에 떠 있던 오류를 정정했다. archive/stats-legacy/README.md에 남겨진 "폐기 예정" 표시를 제거하고, 실제 현행 상태를 명확히 하는 작업이었다.
읽기 → -
백업 계정 주기 교체로 인증 안정성 확보
백업 계정의 주기적 로테이션을 자동화하는 매니저를 구현했다. 기존엔 수동으로 처리되던 B레이어의 계정 교체를 Python 풀 매니저로 일괄 관리하고, 셸 스크립트로 인증 상태를 실시간 검증하는 구조로 변경했다.
읽기 → -
서버 백업 데이터가 git에 올라가는 문제 해결
최근 한 작업은 **git 저장소의 정본성(canonical structure)**을 되찾는 것이었다. 서버의 /opt/stats 디렉토리—실제 운영 중인 통계 백업과 크론 작업의 결과물들—이 버전 관리 대상에서 빠져야 한다는 걸 명확히 했고, 동시에 그 감시 체계를 개선했다.
읽기 → -
한도 초과할 때도 서비스 지속할 수 있게 상위 모델로 자동 전환
주간 API 호출 한도 제한이 있는 환경에서 기본 모델의 할당량이 떨어지면 상위 모델로 자동 폴백하는 기능을 A레이어에 추가했다. 이렇게 하면 사용자가 명시적으로 모델을 바꾸지 않아도 한도 초과 상황에서 서비스가 중단되지 않는다.
읽기 → -
자격 판별 용어 불일치로 매칭 오류 발생하던 문제 해결
HTML에서 파싱한 자격 조건 용어와 매칭 도구가 지원하는 옵션 목록이 어긋나 있었다. 이번 작업으로 두 데이터 소스의 어휘를 정렬(align)하고, 자격 판별 로직의 정확성을 높였다.
읽기 → -
LLM 없이도 정확한 정부 지원금 자동 판정
정부 지원금 자격 판단을 LLM에서 규칙 기반 파서로 전환했다. 자동 매칭 도구의 신뢰도를 높이기 위한 결정이었다.
읽기 → -
포스트 등록 시 자격 요건을 자동 추출하도록 개선
새 포스트가 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로 설정한 거다. 이건 단순한 빌드 설정 변경처럼 보이지만, 제품 전략과 기술 관리가 얽혀 있는
읽기 → -
유료 상품 재출시 정책 결정 확정
유료화로 전환하는 결정을 최종 확정하고, 실행 계획을 문서에 담았다. 패키지 이름, 가격, 결제 정책, 그리고 단계별 실행 순서까지 한 곳에 정리한 것인데, 이렇게 단순해 보이는 문서화 작업이 팀의 방향성을 얼마나 명확하게 만드는지 다시 느껴본다.
읽기 → -
무료에서 유료로, 5개 기능 재출시 계획
유료앱 재출시 계획을 문서로 정리했다. 기존에 무료인데 사용 잠금 상태로 있던 5개 기능을 새 패키지명으로 유료화하는 전략을 PAID_RELEASE_PLAN.md에 담았다.
읽기 → -
워치페이스 옵트인 정책을 설치무관 기준으로 통일
6개 워치페이스의 옵트인 게이트 정책을 확정했다. 그간 모호했던 "언제부터 사용자에게 이 페이스를 공개할 것인가"라는 질문에 명확한 답을 내린 작업이다.
읽기 → -
블로그 서브도메인 분리로 서비스 구조 정리
메인 도메인 구조를 정리하면서 블로그 콘텐츠를 별도의 서브도메인으로 분리했다. 초기에는 메인 도메인 아래 /blog 경로로 호스팅했지만, 서비스가 성장하면서 콘텐츠와 메인 서비스를 물리적으로 분리해야 한다는 필요성이 생겼다. 특히 트래픽 분산, SEO 최적화, 그리고 향후 블로그 플랫폼의 독립적 관리를 고려하면 서브도메인 분리가 더 효율적이라고 판단했다.
읽기 → -
복잡한 릴리스 계획을 더 명확하게 정의
이번에는 릴리스 계획 문서(RELEASE_PLAN.md)를 손봤다. 웨어러블 기기용 새로운 폼팩터 지원, 특정 릴리스 버전을 막고 있는 블로커들, 그리고 워치페이스 단위의 상태 추적을 추가한 것이다. 문서 한 장인지라 코드 변경은 없지만, 팀이 나아가는 방향과 우선순위를 결정하는 데 꽤 중요한 작업이었다.
읽기 → -
워치페이스 여러 변형, SDK 버전 동시 통일
최근에 Wear OS 워치페이스 프로젝트의 5개 워치페이스(crimson, graphite, ivory, noir, slate)를 동시에 새 SDK 버전으로 업그레이드하고, 클로즈드 테스트 전에 릴리스 체크리스트를 정리하는 작업을 했다. 이번 글에선 여러 워치페이스 변형을 관리할 때 마주하는 문제와 그걸 어떻게 풀어냈는지 회고해본다.
읽기 →