1Dev Log

이번 회고록은 조금 색다른 시작을 가진 프로젝트 이야기다. 팀을 직접 꾸린 것도 아니고, 학교 수업도 아니었다. 컨퍼런스에서 우연히 만난 인연으로 시작된 사이드 프로젝트, KBO:NOTE 이야기다.우연한 시작어느 날 갔던 컨퍼런스에서 우연히 한 분을 만났다. 사이드 프로젝트를 같이 만들 개발자를 구하고 있다고 하셨다. 야구 관련 앱이었고, 겨울방학 동안 만들어서 KBO 시즌이 시작되기 전에 런칭하는 게 목표라고 했다. 재밌겠다는 생각이 먼저 들었다.사실 그 당시 이미 진행 중인 프로젝트가 두 개나 있어서 처음엔 부담스러워 거절했다. 그런데 이야기를 더 들어보니 작은 역할만 맡으면 될 것 같아서 결국 하게 됐다.제안해주신 분이 PM을 맡았는데, 팀원을 각자 따로 모으다 보니 기술 스택이 다 다를 수 있다고..

1편에서 이어지는 이야기다. 이번 편은 화려한 결과물 이야기는 아니다. 오히려 그 반대에 가깝다. 왜 우리가 시작한 고도화가 흐지부지 끝났는지에 대한 기록이다.다시 모인 이유3-2학기에 자투리 프로젝트를 마쳤지만, 짧은 시간에 밀어붙이다 보니 아쉬움이 많이 남았다. 특히 디자인 쪽이 걸렸다. 그래서 방학에 다시 모여 고도화를 진행하기로 했다.이번엔 디자이너 한 명을 새로 영입했다. 팀은 나와 편입 동기, 기존 AI 팀원, 그리고 새로 합류한 디자이너까지 총 4명이었다. 가장 큰 목표는 명확했다. 디자인이었다. 디자이너가 들어온 만큼 UI를 중심으로 확 바꾸고 싶었고, 동시에 "AI가 할루시네이션을 일으킬 수 있다"는 피드백을 받았던 터라 이를 줄이는 것도 목표로 잡았다.결과부터 말하면, 절반은 성공이고 ..

오늘부터 그동안 진행했던 프로젝트들에 대한 회고록을 하나씩 써보려고 한다. 진작 했어야 했는데, 계속 미루다 보니 지금까지 와버렸다. 많지 않은 프로젝트지만 천천히 하나씩 정리하면서 그때의 감정도 다시 꺼내보려 한다.이번 글은 회고록 시리즈의 첫 번째, 편입 후 처음 하게 된 프로젝트 이야기다.배경작년에 편입을 했는데, 1학기는 학교에 적응하느라 정신이 없었다. 그렇게 1학기를 보내고 2학기가 되자 필수 수업으로 'P-실무 프로젝트'라는 수업을 듣게 됐다. 나는 백엔드를 지망하고 있었기 때문에, 팀도 백엔드 위주로 구성하고 싶었다.팀 구성총 5명이 함께하게 됐다. AI 1명, 프론트 2명, 백엔드 2명. 같은 편입 동기 한 명을 설득해서 함께 백엔드를 맡기로 했고, 나머지 3명은 학교 커뮤니티 에브리타임..

최근 /api/admin/publications/{paperId} 상세 조회 API를 확인하던 중, 서버에서는 크게 느리지 않은데 로컬에서 유독 지연이 큰 현상을 발견했다.처음에는 단순 환경 차이일 수 있다고 생각했지만, 데이터를 바꿔가며 호출해 보니 패턴이 분명했다.기사 38개인 케이스: 약 18초기사 51개인 케이스: 약 28초측정값 자체는 환경에 따라 달라질 수 있다.다만 기사 수가 늘어날수록 지연이 크게 증가한다는 점이 명확해서, 이 구간을 병목으로 보고 로직을 점검했다.원인: N+1 쿼리 패턴상세 조회 로직에서 기사 목록을 가져온 뒤, 각 기사마다 키워드를 개별 조회하고 있었다.즉, 기사 N개면 키워드 조회가 N번 추가되는 구조였다.이런 N+1 패턴은 데이터가 적을 때는 잘 드러나지 않지만, 데..

배포 방식을 기존의 서버에서 git pull + 빌드 방식에서,CI에서 이미지 빌드 + GHCR 푸시 + 서버는 pull만 하는 구조로 바꿨다.작지만 확실한 개선이었고, 실제로 겪은 오류와 해결 과정을 정리해본다.왜 바꿨나?기존 방식은 서버가 직접 빌드했다.서버 상태(자바/그레이들/캐시)에 따라 결과가 달라질 수 있음/home/ubuntu/BE 같은 경로 의존성이 큼배포 실패 시 원인 추적이 어려움롤백이 명확하지 않음그래서 목표를 이렇게 잡았다.빌드는 CI에서만서버는 이미지 pull/run만커밋 태그 기반 배포실패 시 자동 롤백기존 방식 (Before)GitHub Actions가 SSH로 서버 접속서버에서 git pull./gradlew clean build -x test기존 프로세스 kill 후 jav..

최근 KBO:NOTE 프로젝트에서 Docker + Nginx + GitHub Actions 기반 Blue-Green 무중단 배포 환경을 구축하면서 몇 가지 예상하지 못한 문제를 겪었다.이번 글에서는 배포 과정에서 실제로 발생했던 문제와 해결 과정을 정리해보려고 한다.1. Health Check 실패로 배포 중단문제 상황배포 로그에서 Health Check 단계에서 반복적으로 실패했다.예시 로그===== Health Check =====Health check retry...Health check retry...Process exited with status 1 하지만 서버에서 직접 확인해보면 서비스는 정상적으로 실행되고 있었다.curl localhost:8081/api/v1/feeds/health 응답{"..

들어가며이전 글에서는 Docker 이미지를 GitHub Container Registry(GHCR)에 업로드하고Blue-Green 컨테이너 환경을 구성하여 수동 배포 방식으로 Blue-Green 전환을 검증했다.이 과정에서 다음과 같은 작업을 완료했다.Dockerfile 작성 및 이미지 빌드GitHub Container Registry(GHCR) 사용서버에서 이미지 Pull 테스트Blue / Green 컨테이너 환경 구성NGINX Reverse Proxy 트래픽 전환 테스트즉 Blue-Green 배포가 실제로 동작하는 환경은 이미 구축된 상태였다.하지만 실제 운영 환경에서는 다음과 같은 문제가 남아 있다.코드 변경↓Docker 이미지 빌드↓이미지 Push↓서버 접속↓컨테이너 실행↓NGINX 전환 이 과정..

들어가며이전 글에서는 현재 Feed Server의 서버 구조를 분석하고Blue-Green 배포 전략을 설계하는 과정을 정리했다.특히 다음과 같은 사항을 확인했다.Docker 기반 MSA 환경NGINX Reverse Proxy 구조Docker host network 사용Blue-Green 포트 전략 설계 (8081 / 8082)이번 글에서는 이 구조를 기반으로 실제 Blue-Green 배포 환경을 구축하는 과정을 정리하려고 한다.이번 단계에서 진행한 작업은 다음과 같다.Docker 이미지 생성GitHub Container Registry(GHCR) 사용서버에서 이미지 Pull 테스트Blue / Green 컨테이너 환경 구성NGINX 트래픽 전환 테스트즉 Blue-Green 배포가 실제로 동작하는 환경을 구..

들어가며현재 진행 중인 프로젝트는 MSA(Microservice Architecture) 기반으로 구성되어 있고,각 서비스는 서비스별 GitHub Repository로 분리되어 관리되고 있다.나는 이 중 Feed Server를 담당하고 있으며, 초기 개발 단계에서 Docker 컨테이너 환경도 직접 구성했다.이번에 새로 진행하려는 작업은 Feed Server에 Blue-Green 배포 전략을 적용하고 자동 배포 환경을 구축하는 것이다.최종적으로 목표로 하는 배포 구조는 다음과 같다.GitHub Push ↓GitHub Actions ↓Docker Image Build ↓Container Registry Push ↓Server Pull ↓Blue-Green 배포 ↓NGINX 트래픽 전환 하지만 자동 배포를 구..

1. 배경지역신문 QR 유입을 대비하여 운영 전 API 안정성을 점검하고자 부하 테스트를 진행했다.프론트엔드: Vercel백엔드: EC2 + Nginx테스트 도구: k6테스트 대상 API:https://api.qroad.info/api/qr/3 목표는 다음과 같았다.동시 사용자 30~50명 시나리오 테스트p95 500ms 이하 유지에러율 1% 미만 유지2. 1차 실수: 잘못된 레이어 테스트처음에는 다음 주소를 테스트했다.https://www.qroad.info/a/3 하지만 curl 응답을 확인해보니:Server: Vercel 즉, 프론트엔드 정적 페이지를 테스트한 것이었다.DB 조회 API가 아닌 레이어를 테스트하고 있었던 것이다.→ 테스트 대상을 api.qroad.info로 수정.3. 실제 API 테..