백효석
내 기억력을 믿지 않는다. 꾸준히 기록하자.
지난 글의 문제의식을 이어받아 OpenAI가 말한 Harness Engineering의 개념, 기술적 구조, 안정화 방식, 그리고 이를 Git Ranker Workflow에 점진적으로 적용하기 위한 방향과 단계를 정리한 글입니다.
teo님의 글들과 토스의 글, 그리고 개인 프로젝트와 레거시 고도화 경험을 바탕으로 AI 시대의 주니어 백엔드 개발자가 어디까지를 AI에게 위임하고 무엇을 끝까지 책임져야 하는지 정리한 글입니다.
운영 지표에서 한국어 사용자가 절대다수라는 사실을 확인한 뒤, Git Ranker를 외국인도 이해할 수 있는 서비스로 확장하기 위해 메시지 흐름을 국제화한 기록
사용자 소유권 확인을 위해 OAuth를 도입했지만, 가입/수동 갱신과 배치가 서로 다른 토큰으로 GitHub를 조회하면서 점수 일관성이 깨졌다. 세션 기반 사용자 토큰 설계에서 Token Pool과 쿠키 구조를 정리해간 회고
HTTPS를 붙인 뒤에도 www 유무에 따라 404와 인증서 범위 문제가 남았고, DNS, 인증서, Nginx 정책을 맞춰 대표 도메인으로 정규화한 과정
배지 API는 최신 SVG를 반환하는데 GitHub README는 이전 점수에 머물렀다. 원인은 SVG 렌더링이 아니라 GitHub 프록시 앞에서 비어 있던 캐시 계약이었고, Git Ranker는 Cache-Control: max-age=3600, must-revalidate로 지연과 부하의 경계를 다시 설계했다.
요청 단위 trace_id, 구조화 로그, 배치와 GitHub API 관측, Loki/Grafana 검색까지. Git Ranker가 로그를 운영 데이터로 바꾼 과정을 정리한다.
공인 IP와 포트 번호를 직접 노출하던 홈서버에 DNS, DDNS, Nginx, Let’s Encrypt를 조합해 사람이 읽을 수 있는 도메인과 HTTPS 진입점을 만든 과정
SSH 키 인증을 적용한 뒤에도 반복되던 접속 시도를 auth.log에서 확인하고, Fail2ban으로 자동 차단까지 구성한 과정을 정리했다.
인터넷에 노출된 홈서버 SSH를 비밀번호 인증에서 Ed25519 공개키 인증으로 전환하며, 왜 바꿔야 하는지와 Ubuntu 24.04에서 안전하게 적용하는 순서를 정리했다.
Search API의 호출 수와 리뷰 데이터 한계를 넘기 위해 Git Ranker가 GraphQL 기반 연도별 병렬 조회 구조로 바뀐 과정과, 현재 구현이 1년 제약·동적 응답·비용 관리를 어떻게 다루는지 정리한다.
매일 자정 배치를 설계하면서 ‘어제 데이터만 더하는 방식’을 버리고, 현재는 기준선 + 올해 데이터 재조회 + GraphQL 비용 제어로 진화한 Git Ranker의 Spring Batch 구조를 정리한다.
가입 직후에는 COUNT 쿼리로 즉시 순위를 계산하고, 전체 분포는 MySQL Window Function과 Spring Batch Tasklet으로 다시 맞췄다. 서비스 초기의 ‘1등인데도 낮은 티어’ 문제를 하이브리드 티어 규칙으로 정리한 구현 기록
최근 활동 타임라인을 주는 GitHub Events API가 랭킹 서비스에 맞지 않았던 이유와, Search API 기반 count 집계 방식으로 설계를 바꾼 과정
사용자 수가 많지 않은 GitHub 랭킹 서비스에서, 단순 @Scheduled 대신 Spring Batch를 선택한 이유와 현재 배치 구조를 코드 기준으로 정리한다.
미니 PC 홈랩에서 실제 운영 부담을 만들기 위해 GitHub 활동 랭킹 서비스 Git Ranker를 기획했다. 초기 아이디어가 OAuth, Spring Batch, GraphQL, 관측성 설계로 구체화된 이유를 정리한다.
코딩테스트를 위한 Java 기초부터 자료구조까지 정리 (Java 8 기준, Stream/Lambda 미사용)
Spring Boot + MySQL 구조의 성능 병목을 Redis Stream 비동기 처리로 해결하여 1,666 RPS 달성과 66% 성능 향상을 이룬 과정을 다룹니다.
대기 진료 견적서 상세 조회 API에서 569ms 걸리던 3개의 개별 쿼리를 JOIN과 인덱스 최적화를 통해 50ms로 단축시킨 과정을 다룹니다.
모놀리식 아키텍처의 한계를 극복하기 위해 도메인 주도 설계(DDD)와 포트-어댑터 패턴을 적용한 멀티 모듈 아키텍처로 전환한 과정입니다. 장애 격리와 도메인 경계 명확화를 통해 확장성 있는 시스템을 구축했습니다.
반복되는 JWT 토큰 검증 코드를 제거하기 위해 Spring MVC의 HandlerInterceptor와 ArgumentResolver를 활용한 토큰 처리 시스템 구축 과정을 다룹니다.
매일 선착순 100명에게 도서를 증정하는 이벤트 시스템을 개발하며 직면한 동시성 문제와 성능 병목을 분석하고, 비관적 락과 DB 커넥션 풀의 한계를 경험한 과정을 다룹니다.
Redis 대신 JPA의 Pessimistic Lock과 MySQL을 활용하여 좋아요 기능의 동시성 문제를 해결하고, 시스템 복잡도를 줄이면서 데이터 정합성을 보장한 과정을 다룹니다.
미용사 및 병원 검색 API에서 발생한 N+1 문제를 분석하고, Fetch Join의 한계를 극복하여 Native Query를 활용해 성능을 최적화한 과정을 다룹니다.
100만 개 데이터 환경에서 6.57초 걸리던 API를 409ms로 단축시킨 SQL 튜닝 과정입니다. 인덱스 설계 전략, 복합 인덱스 활용, JOIN 최적화를 통해 94% 성능 향상을 달성했습니다.
