낙관적 허무주의 개발자

AI Native 시대에 개발자란?

겨울단추 — Sun, 12 Jul 2026 21:03:01 +0900

5줄 요약

2025년, 갑자기 늘어난 인프라 업무를 감당하기 위해 Kiro와 MCP로 반복 업무를 자동화
회사 환경은 회고록/ 장애 분석 자동화에 이어서 실제 보안 운영 자동화인 SIEM Bot Monitor 대응 체계 구축
개인 환경에서는 Claude가 구현하고 Codex가 독립적으로 검토하는 AI 작업 운영체제 생성
이 방식으로 AI 서비스의 핵심 백엔드와 인프라를 재설계하고 실제 생성·과금·백업·복구 흐름을 검증.
AI Native는 도구를 많이 쓰는 사람이 아니라, AI가 안전하게 결과를 내도록 맥락·역할·검증을 설계하고 끝까지 책임지는 사람

이전 회고에서
2025년 회고에서 개인 AI 워크플로우를 소개하며 이런 문장을 썼다.

매주 급격하게 발전하는 ai 생태계처럼 내 워크플로우도 매주 새롭게 변화하는데,
기회가 된다면 관련해서 글을 자세하게 써볼까 고민 중이다

마중물에서 물줄기로, 2025년 회고

마중물명사, '마중'과 물이 결합된 단어로, 물을 '마중' 나가는 물이라는 뜻에서 유래 올해는 블로그를 거의 쓰지 않아서 글 목록에서 조금만 내리다 보면 볼 수 있는 2024년 회고에서, 마중물 같

jun10920.tistory.com

그때는 Kiro에 역할과 컨텍스트를 부여하고, MCP를 연결하고, Codex에게 코드를 검토시키는 정도까지 와 있었다.
당시에도 나름 열심히 만든 환경이었지만 지금 돌아보면 가능성을 확인한 초기 버전에 가까웠다.

그 뒤 반년 동안 꽤 많은 일이 있었다.

회사에서는 반복 업무를 처리하던 Kiro 환경이 실제 보안 운영 자동화로 이어졌고,

개인적으로는 Claude와 Codex를 함께 사용하는 하네스를 만들었다.

그리고 그 하네스를 이용해 AI 서비스의 백엔드와 인프라를 다시 설계했다.

그래서 이번 글에서는 특정 AI 도구의 사용법보다, 내가 AI와 일하는 방식이 어떻게 바뀌었는지를 정리해 보려고 한다.

솔직히 처음부터 "AI Native 인재가 되어야지"라고 생각하며 거창한 시스템을 만든 것은 아니다.

시작은 훨씬 현실적이었다.

해야 할 일은 계속 늘어나는데, 사람의 시간은 늘어나지 않았기 때문이다.

시작은 AI 전략이 아니라, 일을 감당하기 위해서

회사에서 팀 내 인사 변동으로 인프라 담당 역할이 갑자기 커졌다.

기존 업무도 익혀야 했고, 장애와 운영 요청도 처리해야 했으며, 문서가 부족한 영역은 직접 분석해서 다시 정리해야 했다.

처음에는 내가 더 많이 일하는 방식으로 대응했다. 실제로 몇 주 동안 평일 밤, 주말내내 계속 일했다.

하지만 단기간에는 어떻게든 버틸 수 있었지만 이 방식이 오래갈 수 없다는 것은 명확했다.

그래서 처음 자동화한 것은,
반복해서 콘솔을 열고 -> 로그를 찾고 -> 메일을 확인하고 ->결과를 다시 문서로 옮기는 일을 줄이기로 했다.

그때 만든 것이 Dynatrace MCP와 회사 내부용 Google Workspace MCP였다.

MCP는 쉽게 말하면 AI가 외부 도구와 정해진 방식으로 대화할 수 있게 만드는 연결 규격이다.

기존에는 사람이 Dynatrace 콘솔에 들어가 현재 장애를 확인하고, 관련 로그와 메트릭을 찾아야 했다.

MCP를 만든 뒤에는 Kiro에게 다음처럼 요청할 수 있었다.

현재 열린 장애가 있는지 확인하고, 관련 서비스의 로그와 자원 사용량을 비교해 줘.

처음에는 Dynatrace API를 다루는 15개 도구로 시작했다.
이후 실제 업무에서 사용하다 보니 이름으로 엔티티를 찾는 기능, 예외 분석, 쿼리 검증, 비용 확인처럼 부족한 부분이 계속 보였고,

현재는 32개 도구까지 확장했다.

Google Workspace도 같은 방식으로 연결했다.

메일과 일정, 문서에 있는 맥락을 확인하고 코드와 운영 데이터를 함께 비교할 수 있게 하자,

서로 떨어져 있던 업무가 하나의 흐름으로 이어지기 시작했다.

여기서 중요한 것은 "AI가 콘솔을 대신 봐준다"는 점만은 아니었다.

업무를 AI에게 맡기려면 먼저 사람이 하던 일을 단계로 설명해야 했다.

어떤 데이터를 먼저 보고, 무엇이 이상 신호이며, 어디까지 자동으로 처리하고 어느 시점에 사람에게 다시 물어야 하는지를 정리해야 했다.

결국 AI 자동화를 만들면서 오히려 내 업무를 더 정확하게 이해하게 됐다.

일회성 프롬프트 to 자동화

초기에는 매번 긴 프롬프트로 상황을 설명했다.

잘될 때는 놀라울 정도로 잘했지만, 세션이 바뀌면 같은 설명을 다시 해야 했고 가끔은 중요한 조건을 빼먹었다.

그래서 반복되는 작업을 스킬과 검증 절차로 옮기기 시작했다.

회고록 작성 자동화가 대표적인 예다.

처음에는 하루 작업 중 주제가 바뀌거나 퇴근하기 전에 kwork save를 실행했다.

이 alias는 Kiro CLI의 세션 저장 명령을 클립보드에 준비해 주는 작은 셸 도구였다.

하루에 저장한 세션을 퇴근 전에 kwork end로 하나로 병합하고, 미리 정한 회고 템플릿과 프롬프트를 넣어 AI가 그날의 작업을 정리하게 했다.

초기 방식은 분명 도움이 됐다. 사람이 기억에 의존하면 놓치기 쉬운 명령어, 문제를 푼 순서, 실패한 시도까지 세션에 남아 있었기 때문이다. 회고는 단순히 “오늘 무엇을 했다”가 아니라, 다음에 같은 일을 다시 할 때 참고할 수 있는 작업 기록이 됐다.

하지만 세션이 쌓일수록 다른 문제가 생겼다. 세션을 병합한 원본이 6만 줄을 넘는 날도 있었고, 긴 기록을 구간별로 분석하려던 서브에이전트가 컨텍스트 한계로 실패하기도 했다. 저장된 대화를 모두 읽히는 방식은 기록을 많이 남길수록 비용과 시간이 커지는 구조였다. 프롬프트를 더 길게 쓰거나 더 큰 모델에 다시 맡기는 것으로는 해결되지 않는 문제였다.

그래서 회고의 원본을 세션에서 작업문서로 바꿨다. 작업을 시작하거나 중요한 판단이 생길 때마다 배경, 목표, 수행 내용, 결과, 남은 리스크, 다음 액션을 정해진 템플릿에 기록했다. 문서에는 작성일과 업데이트 이력도 남겼다.

그다음 kwork end를 다시 설계했다. 해당 날짜에 바뀐 작업문서를 먼저 찾고, 작업문서가 있으면 그것을 회고의 주 원본으로 사용한다.

세션은 누락된 단발성 작업이나 명령어, 오류, 검증 근거를 보강하는 자료로만 쓴다. 작업문서만 있는 날, 세션과 작업문서가 모두 있는 날, 세션만 남아 있는 날, 둘 다 없는 날을 각각 처리하도록 분기했고, 네 가지 경우를 따로 테스트했다.

이 변경 이후에는 세션을 저장하지 않은 날에도 회고를 만들 수 있게 됐고, 회고의 각 항목에서 원래 작업문서로 다시 돌아갈 수 있게 됐다. kwork save는 더 이상 매일 반드시 해야 하는 절차가 아니라, 세션 자체를 증거로 남겨야 할 때만 선택해서 쓰는 도구가 됐다.

이 경험에서 배운 것은 단순했다.

AI에게 과거 대화를 전부 먹이는 것보다, 사람이 먼저 판단과 결과를 구조화해 두고 AI가 필요한 근거만 읽게 하는 편이 더 오래 간다.

자동화의 품질은 모델 이름보다 원본 데이터를 어떻게 남기고 다시 찾아볼 수 있게 만드는지에 더 크게 좌우됐다.

Kiro의 컨텍스트도 비슷한 과정을 거쳤다.

AI가 실수할 때마다 규칙을 추가하다 보니 핵심 규칙 파일이 어느 순간 458줄까지 늘어났다.

많이 알려주면 더 잘할 것 같았지만, 오래된 정보와 충돌하는 규칙이 섞이고 정작 중요한 지시를 놓치는 문제가 생겼다.

결국 핵심 규칙을 116줄로 줄이고, 세부 업무 지식은 필요할 때만 읽도록 분리했다.

실제 업무 상황 20개와 위험하거나 애매한 상황 6개를 합쳐 총 26개의 평가 과제도 만들었다.

"잘해 줘"라고 부탁하는 대신, 실제 업무에서 올바르게 행동하는지 반복해서 시험할 수 있게 바꾼 것이다.

Kiro 업무 시스템이 SIEM Bot Monitor로 이어지다

이렇게 Kiro가 회사의 맥락을 읽고, API와 로그를 조회하고, 반복 작업을 스킬로 실행하며, 결과를 검증하는 기반이 쌓였다.

그리고 이 기반이 가장 크게 활용된 사례가 SIEM Bot Monitor였다.

당시 홈페이지를 공격하는 BOT 트래픽이 급증했다.

겉으로 보면 단순한 보안 공격처럼 보이지만, 문제의 본질은 트래픽 양만이 아니었다.

BOT 공격은 실제 외부 예약 시스템을 호출한다.

BOT이 조회를 반복하면 홈페이지가 정상적으로 열리고 있어도 외부 시스템 사용량과 비용 위험은 계속 커질 수 있었다.

기존에는 이를 막기 위해 사람이 보안 로그를 확인하고, 공격 후보를 찾고, 차단 정책을 만든 뒤, 배포 결과를 다시 확인해야 했다.

공격 패턴은 계속 달라지는데 모든 과정을 수동으로 처리하니 대응 속도와 야간 운영 부담에 한계가 있었다.

그래서 아래의 흐름을 하나의 보안 대응 체계를 구축하였다.

보안 로그 수집
공격 후보 분석
자동 조치 후보와 수동 검토 후보 분리
담당자 보고와 미리보기
승인 후 정책 반영
정상 사용자 영향 확인
필요 시 롤백

Kiro는 API 연동 코드 초안, 원본 로그 구조 분석, 탐지 조건별 테스트, 긴 로그의 패턴 요약과 배포·롤백 과정의 예외 검토에 활용했다.

반대로 어떤 신호를 실제 차단 기준으로 사용할지, 정상 사용자가 함께 차단될 가능성은 없는지, 운영 환경에 반영하거나 되돌릴지는 내가 실제 로그와 콘솔을 확인하며 판단했다.

이 방식으로 금요일부터 일요일까지 3일 동안 운영에 투입할 수 있는 초기 버전을 만들었다.

이후에는 팀원들의 피드백과 실제 운영하면서 실제 공격과 오탐 사례를 반영하며 기준과 검증 절차를 계속 바꿨다.

그 결과 반복되던 수동 분석과 배포는 사람이 승인과 예외 판단에 집중하는 흐름으로 바뀌었고,

공격 후보 발견부터 조치와 검증까지 걸리는 시간도 크게 줄었다.

이 사례를 통해 AI Agent는 보안 판단을 대신하는 도구가 아니라,

운영자가 정의한 문제를 더 빠르게 구현하고 검증하게 해주는 도구라는 점을 체감했다.

회사에서 만든 습관을 개인 하네스로 옮기다

회사에서는 Kiro를 중심으로 업무 환경을 만들었다면, 개인 프로젝트에서는 Claude Code를 주로 사용하기 시작했다.

처음에는 좋은 플러그인과 에이전트를 많이 설치하면 자연스럽게 생산성이 올라갈 것이라고 생각했다.

그런데 실제 사용량을 측정해 보니 서브에이전트 위임률이 5.2%에 불과했다.

기능은 많았지만 메인 에이전트가 대부분의 작업을 혼자 처리하고 있었다.

그래서 개인 AI 하네스를 체계적으로 정리했다.

이 하네스에는 다음과 같은 구조가 들어 있다.

위험 명령과 시크릿 접근을 실행 전에 차단하는 훅
탐색, 외부 문서 조사, 설계 자문, 적대적 검토를 나눈 서브에이전트
작업 맥락에 따라 적절한 도구를 제안하는 25개의 라우팅 규칙
Claude가 만든 변경을 Codex가 독립적으로 검토하는 교차 리뷰
작업문서 → 회고 → 다음 자동화 후보로 이어지는 일상 루프
한 번 발생한 실수를 다음 세션의 규칙으로 남기는 메모리

이 환경을 만들면서 가장 아찔했던 일도 있었다.

시크릿 유출을 막기 위해 작성한 코드 한 줄에 오히려 명령어 삽입 취약점이 생겼다.

안전을 위해 만든 코드가 새로운 보안 문제를 만든 셈이다.

Claude의 현재 작업 맥락 안에서는 이 문제를 발견하지 못했지만, 별도의 입력으로 변경 내용을 검토한 Codex가 취약점을 찾아냈다. 이후 네 번의 수정과 재검토를 거치며 블로커를 8개에서 4개, 2개, 최종 0개로 줄였고 총 14개의 결함을 닫았다.

이 일을 겪고 나니 "AI가 작성했다"와 "검증된 결과다"는 완전히 다른 말이라는 게 더 명확해졌다.

AI는 생각보다 자주, 그리고 꽤 자신 있게 틀린다.

그래서 지금은 한 모델에게 더 긴 프롬프트를 주는 것보다,

역할이 다른 모델이 서로의 결과를 반박하고 실제 테스트와 실행 로그가 그 사이에서 판정하도록 만드는 편을 선호한다.

AI 서비스에서 백엔드와 인프라 전체 흐름을 다시 구축하다

이 하네스를 가장 크게 사용한 곳은 개발 중인 AI 서비스다.

내가 맡은 기술 범위는 생성형 AI 작업을 처리하는 백엔드와 이를 안정적으로 운영하기 위한 인프라 전반이었다.

처음에는 기능이 실제로 동작하고 있었기 때문에 겉으로 보기에는 큰 문제가 없어 보였다. 하지만 운영을 준비하며 구조를 자세히 살펴보니 개발 환경과 운영 환경이 충분히 분리되지 않았고, 작업 상태와 과금 규칙이 DB 함수, 생성 워커, 엣지 함수와 여러 프론트 경로에 흩어져 있었다.

특히 같은 요청이 두 번 들어왔을 때 결과와 비용이 중복 처리되지 않는다는 보장이 일부 구현에 의존하고 있었다.

AI가 생성하는 서비스에서 재시도는 예외가 아니라 흔한 일이기 때문에 이 부분을 그대로 둘 수 없었다.

우선 Claude의 서브에이전트를 나누어 현재 구조와 과금 경로를 지도화했다.

그다음 상태 전이와 과금을 하나의 안전한 경로에서 처리하는 Command Core를 설계했다.

쉽게 설명하면 다음의 과정을 각각 따로 처리하지 않도록 만든 것이다.

작업이 정말 완료됐는지 확인한다.
생성 결과를 사용자에게 공개한다.
사용 금액을 정확히 한 번만 차감한다.
실패했다면 다시 실행할 수 있는 상태를 남긴다.

첫 설계안은 검토에서 탈락했다. 문제를 고쳐 만든 두 번째 설계도 다른 모델의 공격적 리뷰를 통과하지 못했다.

빨리 구현하고 싶은 마음도 있었지만 결제와 상태를 다루는 구조였기 때문에 애매한 상태로 진행할 수는 없었다.

결국 세 번째 설계에서 인증, 멱등성, 동시성, 결과 공개 시점과 권한 경계를 정리한 뒤 구현을 시작했다.

백엔드 코드만 바꾼 것도 아니다.

운영 환경과 분리된 개발 환경을 만들고, 생성 워커와 저장소를 분리했으며, 코드 변경과 DB 변경이 안전한 순서로 배포되도록 CI/CD를 구성했다. AI 리뷰 결과와 현재 코드가 일치하지 않으면 머지를 막는 게이트도 추가했다.

모니터링과 백업도 같은 원칙으로 접근했다.

백업 파일이 생성됐다는 로그만으로는 복구 가능하다고 볼 수 없었다.

그래서 암호화 백업을 만든 뒤 일회용 DB에 직접 복원하고, 핵심 데이터가 원본과 일치하는지 확인하는 복구 리허설까지 자동화했다.

최근에는 운영 환경과 같은 조건의 개발 환경에서 실제 AI 생성 작업을 처음부터 끝까지 실행했다.

작업은 정상 완료됐고, 비용은 중복 없이 정확히 한 번 처리됐으며, 최종 산출물도 실제 저장소에 생성됐다.

여기서 개인적으로 가장 의미 있었던 것은 코드의 양이 아니었다.

문제 조사, 아키텍처, 과금 정확성, 개발 환경, 배포 게이트, 모니터링, 백업과 복구까지 서비스가 운영되기 위해 필요한 전체 흐름을 AI와 함께 연결했다는 점이었다.

AI가 맡은 일과 내게 남겨 둔 일

AI를 적극적으로 사용한다고 말하면 가끔 "그러면 실제로 본인이 한 일은 무엇인가"라는 질문을 받는다.

이 질문은 타당하다고 생각한다.

AI가 만든 결과를 그대로 받아들이면 사용한 도구만 다를 뿐 책임 없는 외주와 크게 다르지 않을 수 있기 때문이다.

현재 내가 나누는 기준은 아래와 같다.

AI가 주로 맡는 일 / 내가 직접 남겨 두는 일

코드와 문서 구조 탐색 / 어떤 문제를 풀지 정의
구현 초안과 반복 수정 / 제약과 완료 기준 결정
테스트 케이스와 반례 제안 / 운영 위험 수용 여부 판단
긴 로그와 변경 내용 요약 / AI 제안의 채택·기각과 근거 기록
다른 모델 결과의 적대적 검토 / 실제 배포·롤백·비용 결정 승인

물론 경계가 항상 완벽하게 나뉘는 것은 아니다. 나도 AI의 제안을 보고 생각을 바꾸고, AI도 내가 만든 기준의 모순을 찾아낸다.

다만 최종 결과에 대해 "AI가 그렇게 했다"고 말하지 않기 위해, 결정과 검증의 책임만큼은 사람에게 남겨 두려고 한다.

내가 생각하는 AI Native

처음에는 AI를 잘 쓰는 사람이 프롬프트를 잘 작성하는 사람이라고 생각했다.

지금은 조금 다르게 생각한다.

AI Native는 특정 모델의 숨겨진 명령어를 많이 아는 사람이 아니라, 아래의 질문에 답할 수 있는 사람에 가깝다.

AI가 일을 시작하기 전에 어떤 맥락을 줘야 하는가?
큰 문제를 어떤 역할과 작업으로 나눌 것인가?
어디까지 자동화하고 언제 사람에게 다시 물어야 하는가?
AI가 만든 결과가 맞는지 무엇으로 검증할 것인가?
이번 실수를 다음 작업에서 반복하지 않게 어떻게 남길 것인가?

2025년 회고에서 나는 작은 물줄기가 꾸준히 흐르다 보면 언젠가 강이 될 것이라고 썼다.

그때 만든 AI 워크플로우도 비슷했던 것 같다.

처음에는 늘어난 일을 감당하기 위한 작은 자동화였다.
그 자동화가 회사의 운영 시스템이 됐고, 다시 개인 하네스로 이어졌으며,
지금은 새로운 서비스의 백엔드와 인프라를 만드는 방식이 됐다.

AI가 내 일을 대신 책임지게 만든 것은 아니다.

AI와 함께 내가 더 크고 복잡한 문제를 끝까지 책임질 수 있는 방식을 만들었다.

아마 지금 내가 AI Native라는 표현에 가장 가깝다고 생각하는 이유도 여기에 있는 것 같다.

오랜만에 글을 쓰다보니 굉장히 긴 글이 되었네요.
긴 글 읽어주셔서 감사합니다!

관련 링크

• 2025년 회고: https://jun10920.tistory.com/55
• GitHub: https://github.com/jun10920

마중물에서 물줄기로, 2025년 회고

겨울단추 — Wed, 7 Jan 2026 13:01:23 +0900

마중물
명사, '마중'과 물이 결합된 단어로, 물을 '마중' 나가는 물이라는 뜻에서 유래

올해는 블로그를 거의 쓰지 않아서 글 목록에서 조금만 내리다 보면 볼 수 있는 2024년 회고에서,

마중물 같은 개발자의 2024년 회고

마중물명사. 펌프질을 할 때 물을 끌어올리기 위하여 위에서 붓는 물- 표준국어대사전 2024년 상반기는 이미 아래 글에서 회고해서, 2024년 하반기의 회고를 작성할 예정이다. 잠은 죽어서 자는

jun10920.tistory.com

나를 '마중물 같은 개발자'라고 표현했다. 잠재성을 이끌어내는 계기를 만들어 내는,

2025년을 돌아보니, 이제는 마중물에서 시작된 물이 하나의 줄기가 되어 흐르기 시작한 것 같다.

2025년 회고는 크게 주제를 회사와 개인으로 나누어 작성할 예정이다.

회사

입사와 적응 (4월~6월)

작년 회고에서 '내년 상반기에도 내가 원하는 회사에 들어갈 때까지 끊임없이 도전할 것이다'라고 썼는데,

감사하게도 그 도전이 결실을 맺었다.

항공학부 출신이라 대한항공이라는 회사가 낯설지는 않았지만, 정비사가 아닌 개발자로 이 회사에 들어오게 될 줄은 몰랐다.

주변의 지인들도 정비사로 입사한 것인지 헷갈릴 정도였는데, 정말 인생은 어떻게 흘러갈지 알 수 없는 것 같다.

신갈연수원에서 보낸 시간은 당시에도 즐겁고 좋았는데, 지금 생각해보면 정말 그때가 제일 즐거운 때였다.

그 이후 전체 교육 -> 직무 교육 -> 팀교육까지 받고 지금의 자리에 오게 되었다.

본격적인 업무 시작 (7월~8월)

7~8월에서 본격적으로 일에 투입되었다.

당시 팀에 Dynatrace 재계약 시점이 다가오면서, Datadog으로 마이그레이션 할지 검토하는 PoC를 진행하게 되었다.

억 단위의 계약이 오가는 일이었고 타 업체의 임원분들과 직접 커뮤니케이션하면서 피드백을 주고받는 자리였는데,

신입이 이런 자리에 있어도 되나 싶으면서도 배우는 게 많았다.

가장 어려웠던 건 이미 운영 중인 환경에 Datadog을 실제로 적용하는 것이었다.
ECS Task Definition에 Datadog Agent 사이드카를 붙이고, pidMode 설정하고, APM/LOG/RUM을 연계하고, FluentBit으로 multiline log 처리하고, trace_id로 로그와 트레이스를 연결하고... 문서대로 했는데 안 되는 것들이 많아서 하나씩 삽질하며 해결했다.
그러던 중 결정적인 사건이 터졌다. 새벽에 1A측 장애로 홈페이지가 먹통이었는데, Datadog은 이걸 장애로 감지하지 못했다. Anomaly Detection을 PRD 환경에서 평가하던 중에 정작 실제 장애는 놓친 것이다.

반면 Dynatrace는 서드파티 장애까지 정확하게 root cause을 잡아내어 Problem으로 판단했다.

이 사건을 계기로 Dynatrace 재계약으로 결정되었다.

이 경험으로 억 단위 의사결정에 기여한 경험을 해보았다.

또한 해당 PoC를 진행하면서 '모니터링 툴로서 다양한 신기능이 있어도 본질적으로 장애를 못 잡으면 무슨 소용인가'라는 질문을 던져보며 본질이 더 중요한 것을 깨닫게 된 계기였다.

교육의 연속 (9월)

9월은 교육의 달이었다

Datadog 실습 워크숍
DevOps 교육 (IaC, EKS)
if(kakao) 2025 참가
Akamai University - Security Fraud

회사의 여러 조직마다 운영하는 방법이 다르지만, 우리 팀의 경우 당시 콘솔로 관리하고 있어 운영환경의 설정을 변경해야 할 때마다 불편함이 커서 이를 코드로 관리하고 싶은 마음이 있었다.

그때 마침 좋은 기회로 회사와 정영진 멘토 형님에게 IaC 교육을 들었다.

현재는 여러 일들 때문에 미뤄지고 있지만, 순차적으로 Migration 할 예정인데 그때 큰 도움이 될 것 같다.

그리고 팀에서 CDN과 Security 쪽을 관리하는 솔루션인 Akamai의 대면 교육을 들었는데,

당시에는 외계어 수준으로 들렸던 관련 용어들이 몇 달 지난 지금은 대부분 내용을 이해하고 설정할 수 있으며 동시에 팀 내에서 내가 대표하여 운영까지 하게 되었다. 도리어보니 짧은 기간 안에 많은 성장을 한 것 같아 새삼 뿌듯하다.

if(kakao)는 추첨에 당첨되어 갔는데, 당시 가장 인상 깊었던 세션이 있었다.

그것은 카카오에서 발표한 '국내 최초오픈소스 가드레일: Kanana-Safeguard'였는데, LLM 응답의 안전성을 검증하는 오픈소스 프로젝트였다.

보안에 민감해진 최근 한국의 시류와 더불어 최근 팀에서 진행 중인 챗봇 프로젝트에 적용하면 좋겠다는 생각이 들었다.

그래서 바로 하루 만에 발표자료를 만들어 3분기 팀 발표 세션에서 팀원들에게 공유했다.

신입이 컨퍼런스에서 배운 걸 팀 전체 앞에서 발표한다는 게 떨렸지만 다행히 좋은 호응을 얻었다.

배운 걸 바로 적용하려는 시도 자체가 의미 있었던 것 같다.

실전 경험 (10월~12월)

10월부터는 실전이었다. 몇 가지 예를 들자면,

Java Version Upgrade (8 to 17)

우선 첫 번째로 Java 17 PRD 배포였다.

전체 라이브러리와 마이크로서비스를 Java 17로 빌드하도록 옵션을 변경하고, base image도 업데이트했다.

버전 업그레이드는 단순해 보이지만, 운영 환경에서는 수많은 검증이 필요하다. 실제로 Admin 서비스에서 한글 인코딩 문제가 발생했는데, 8에서와 달리 버전 17에서 빌드 옵션을 지정하지 않으면 task의 기본 인코딩 옵션으로 진행되는 문제였고 관리자 서비스를 통해서 사용하는 공항 담당자분들의 내부 고객 문의를 통해서 깨닫게 되었다.

이처럼 사소해 보이는 이슈 하나가 실제 서비스에 큰 영향을 줄 수 있다는 걸 배웠다.

FluentBit 로그 아키텍처 개선

내가 처음으로 메인으로 잡고 처음부터 끝까지 진행한 첫 작업이었다.
기존에는 Task 안에서 Firehose Appender를 통해 CloudWatch로 로그를 전송하는 구조였다.

문제는 로그가 과다하게 쌓이는 경우, 로깅 자체가 메인 Task에 과부하를 주는 상황이 종종 발생했다는 것이다.
사수도 이 문제를 인지하고 FluentBit 사이드카 방식으로 전환하려 했지만, 리소스 부족으로 미뤄지다가 내가 팀에 합류하면서 맡게 되었다.
막상 파고들어 보니 문제가 하나가 아니었다.

1. 로그 중복 저장 문제

마이크로서비스의 로그가 버킷 2개에 중복 적재되고 있었다. 원인을 추적하니 FluentBit OUTPUT 설정에서 Match 패턴이 문제였다. 이를 현재 로그 구조와 비교하여 변경해서 해결했는데, 간단해 보이지만 이 한 줄을 찾기까지 로그 흐름을 전부 추적해야 했다.

2. Task ID 추적 불가 문제
장애가 발생했을 때 어떤 Task에서 문제가 생겼는지 추적이 안 됐다.

ECS 메타데이터 API를 호출해서 Task ID를 추출하고, 이를 S3 경로에 포함시키는 작업을 했다.
처음에는 Task ID를 파일명에 넣으려 했는데, Athena 파티션 구조와 충돌할 것 같아서 고민했다. 문서에는 '파티션 추가 필요'라고 되어 있었는데, 실제로 테스트해 보니 Athena가 파티션 Location 하위를 재귀적으로 스캔해서 Task ID 폴더가 있어도 정상 조회됐다.

결과적으로, 아래의 성과를 얻었다.
- FluentBit 사이드카 구조로 전환 → 메인 Task 과부하 해소
- Match 패턴 수정 → 로그 중복 저장 해결
- Task ID를 S3 경로에 포함 → 장애 시 Task별 추적 가능

이후 DEV 환경 15개 마이크로서비스에 모두 적용하고 Athena 쿼리와 WCM 플랫폼 정상 동작까지 확인했다.

처음으로 '내가 온전히 진행한 첫 작업'이라 개인적으로 뜻깊었다.

Dynatrace MCP, Google workspace MCP 개발

팀 내의 인사 변동으로 인해 갑자기 팀의 인프라 담당이 되어버렸다.

기존에 가장 많은 역할을 해주시던 분의 부재로 일이 과하게 많이 생겨버렸는데 어떻게든 과도한 로드를 감당하기 위해서 몇 주간 주말 내내 일하는 환경을 계속 개선했다.

그중 하나가 Dynatrace MCP, Google workspace MCP 개발이다.

현재 회사 내에서 사용하는 솔루션이 Dynatrace와 모든 업무 관련 SaaS인 Google Workspace의 api를 가지고, 사내에서 사용할 수 있는 Kiro CLI가 사용할 수 있는 MCP를 제작했다.

Dynatrace의 경우 API 공식 문서를 기반으로 제작해서, 터미널에서 바로 Dynatrace를 조작할 수 있게 15개 도구를 TypeScript로 구현했다.

Google Workspace는 이미 기존의 mcp 오픈소스들이 존재했지만 사내 환경에서 사용하기에는 보안을 완벽하게 보장할 수 없을 것 같아 Dynatrace와 같은 구조로 구현했다.

그래서 이제 터미널에서 AI Agent와 연동해서 "현재 열린 Problem 있어?"라고 물으면 바로 답변을 받을 수 있게 됐고,

'~~ 제목의 메일을 검토해서 현재 ~ 경로에 ~ 소스를 검토해서 무슨 문제인지 파악해 줘'라고 하면 이 모든 워크플로우를 진행하고 나한테 보고하게끔 자동화하였다.

덕분에 늘어난 업무량을 그나마 감당하게 되었는데, 업무 효율화를 위해 직접 도구를 만들어 쓰는 경험을 통해서 오랜만에 개발자로서 큰 즐거움을 얻었다.

스크럼 마스터

DevOps 엔지니어 역할 외에도 MY 페이지, 공항 페이지의 스크럼 마스터를 맡고 있다.

스크럼 마스터 역할을 하면 기획-개발-도급업체 사이에서 조율하고, 일정을 관리하고, 이슈를 해결하는 역할을 맡는다.

와중에 대부분이 나보다 연차로나 직급으로나 윗사람들과 논의해야 하는 상황이 대부분이지만,

프로젝트 리딩을 많이 해봤던 과거의 경험 덕분에 다행히 잘 리딩하면서 넘어갈 수 있었던 것 같다.

그중 스크럼 마스터로서 가장 기억에 남는 업무는 마일리지 캐시 불일치 VOC 분석이다.

고객이 메인페이지에서 보는 마일리지와 상세조회 페이지에서 보는 마일리지가 다르다는 민원이 들어왔다.

원인을 파고들어 분석한 결과, 계약해서 사용 중인 솔루션이 제대로 캐시를 갱신하지 못해서 발생하는 문제였다.

이 과정에서 윗선까지 보고되어 여러 팀이 엮이게 되었는데, 당시 우리 팀은 괜히 도와줬다가 끼게 된 애매한 상황이었다.

내 성격상 내 일 아니어도 최대한 돕자는 마인드였는데, 이 일을 계기로 항상 좋은 마음으로 모든 일을 돕는 것이 능사는 아니라는 생각하게 되었다.

문서화의 힘

올해 가장 많이 한 일 중 하나가 문서화다.

팀에 들어오니, 인프라 파트를 제외한 다른 부분에선 인수인계가 거의 없었다.

그래서 맨 땅에 헤딩하는 식으로 직접 부딪히며 배워가보니, 다음 사람은 뭔가 배울 수 있는 가이드 문서가 있으면 좋을 것 같았다.

그 김에 나도 잘 모르는 내용들에 대해서 같이 배우는 느낌으로 가이드 문서들을 비롯해서 많은 내용들을 문서화했다.

팀에 제대로 합류한 것이 6월이니, 약 6개월 동안 140+개의 문서를 문서화했다.

문서화를 하는 것 자체는 시간과 정성이 꽤나 드는 작업이지만 하고 난 이후에 다른 사람에게 내 지식과 경험을 공유할 때 훨씬 편리하고, 결론적으로 나뿐만 아니라 많은 사람들의 시행착오를 줄여준다는 점에서 조직적인 관점에서는 오히려 일하는 시간을 줄여주는 윈윈하는 수단이었다.

회고록 시스템 구축

문서화의 일환으로, 10월 말부터 매일 회고록을 작성하기 시작했다. 처음에는 귀찮았지만 지금은 습관이 되어 꽤나 익숙해졌다.

오늘 뭘 했는지, 뭘 배웠는지, 내일 뭘 해야 하는지를 정리하면 업무를 다시 시작할 때 몰입하는데 드는 시간이 줄어들고 장기간의 템포를 가지고 가는 작업을 할 때 계속 진행되는 듯한 느낌을 받을 수 있다.

또한 회고록을 작성하기 시작한 이유는 추후에 설명할 AI 워크플로우에서 핵심이 되는 '컨텍스트'를 유지하기 위함이었다.

# YYYY-MM-DD 회고

## 진행한 업무
## 트러블슈팅
## 회의 및 커뮤니케이션
## 배운 점 / 궁금한 점
## 내일 할 일

결론적으로 회고록을 쓰게 됨으로써,

1. 하루를 정리할 수 있게 되고

2. 현재 일의 진행사항을 트래킹 할 수 있고

3. AI의 컨텍스트를 지속적으로 관리할 수 있으며

4. 내 업무 성과를 증명할 자료를 만들 수 있었다.

그리고 이 회고록들이 모여서 지금 이 연말 회고를 쓸 수 있게 됐다.

개인

위에 내용과 일부분 겹칠 수 있지만, 아래는 개인적으로 성장한 것에 대한 내용이다.

개인 AI 워크플로우 구축

회사 업무 외에도 개인적으로 jchat이라는 AI 개발 환경을 구축했다.

(근데 지금은 또 opencode를 이용한 새로운 환경으로 이관 중이다ㅋ..)

(++ 글을 쓰는 와중에 opencode에서 또 opencode처럼 kiro cli를 wrapping 한 새로운 라이브러리를 tui 환경을 구축 중이다)

단순히 'AI를 사용했다'가 아니라, 최대한 AI의 구루들의 아이디어와 Open AI, Gemini, Antrophic 등의 회사에서 매주 발표하는 방법론들과 팁들을 녹여가며 나만의 AI 워크플로우 아키텍처를 구축하려고 노력했다.

핵심 철학은, 단순히 AI를 도구로만 사용하는 것이 아니라 하나의 팀원으로 두고 사용하려고 노력했다.

AI를 단순 코드 생성기로 쓰면 한계가 명확하다. 맥락을 모르니까 엉뚱한 답을 하고, 같은 실수를 반복한다.

그래서 AI에게 role과 context를 부여하는 시스템을 만들었다.

1. 역할 기반 전환 시스템 (16개 역할)
작업 유형에 따라 AI가 자동으로 역할을 전환한다. architect, frontend, backend, reviewer, bug-fixer, security 등 16개 역할을 정의하고, 각 역할마다 체크리스트와 행동 규칙을 만들어뒀다.
예를 들어 '설계해 줘'라고 하면 architect 역할로 전환되어 SOLID 원칙, 트레이드오프 분석, ADR 작성 등을 자동으로 고려한다.

2. Scale Adaptive System
모든 작업을 같은 프로세스로 처리하면 비효율적이다. 그래서 복잡도에 따라 워크플로우를 자동 선택하는 시스템을 만들었다.
Quick Flow: 버그픽스, 소기능 → 바로 개발
Standard Flow: 새 기능 → Tech Spec → TODO → 개발 → 리뷰
Full Flow: 새 프로젝트 → 기획 → 리서치 → 개발 → 테스트 → 배포

3. 3단계 합의 프로세스
AI가 마음대로 파일을 수정하면 위험하다. 그래서 모든 생성/수정/삭제 작업에 3단계 합의를 적용했다.
1) Kiro 계획 수립 → 사용자 승인 요청
2) Codex 리뷰 → 피드백 수집
3) Kiro + Codex + 사용자 합의 → 실행

4. Compounding Engineering (실수 누적 방지)
AI가 같은 실수를 반복하면 steering 문서에 기록해서 다음부터 같은 실수를 안 하도록 했다.

AI가 학습하는 게 아니라, 규칙 문서가 점점 정교해지는 방식이다.

5. MCP 서버 연동 (7개)
Kiro CLI에 MCP 서버 7개를 연동해서 AI의 능력을 확장했다. codex(코드 리뷰), github(이슈/PR 관리), notion(문서 연동), context7(라이브러리 문서 검색), memory(세션 간 기억), sequential-thinking(복잡한 작업 분해), playwright(브라우저 자동화) 등등이 있다. 여기에 필요한 경우 직접 mcp를 구축해서 더 하였다.

이외에도 매주 AI 관련 소식을 아카이빙 하고, 주말마다 내 워크플로우에 반영할 부분들을 검토 후에 반영하는 등 끊임없이 개선하고 효율적으로 일을 하려고 노력한다.

안드레 카파시가 말한 것처럼, 프로그래밍이 점점 코드를 짜는 게 아니라 AI 도구를 엮어내는 능력의 싸움이 되고 있는 것을 느낀다.

현재도 구현하는 부분에서 많은 개발자들을 뛰어넘는 수준을 보이는데, 불과 몇 년 안에 구현하는 것은 아예 비교가 되지 않을 거라고 생각한다.

다만 AI는 안드레 카파시의 비유처럼 AI는 '사용설명서 없는 외계 도구'와 같은 상태이고,

이를 잘 다루기 위해선 agent, tools, context 같은 새로운 추상화 계층을 다루는 방법을 배워야 한다.

매주 급격하게 발전하는 ai 생태계처럼 내 워크플로우도 매주 새롭게 변화하는데, 기회가 된다면 관련해서 글을 자세하게 써볼까 고민 중이다.

운동

올해 운동 부분에선 큰 변화가 생겼다.

작년 회고에서 '내년 상반기부터는 헬스를 다시 제대로 시작해 볼 생각이다'라고 작성했고 실제로 이전의 고점인 450에 거의 근접한 440 정도까지 중량을 복구했었다.

다만 운동을 건강 관리의 목적보다는 순전히 재미 때문에 하였는데, 갑자기 어느 순간 얼굴에 실핏줄 터져가며 중량을 드는 게 말 그대로 재미 없어졌다.

그래서 그날 바로 회원권을 동생에게 넘기고, 운동 장비를 전부 처분했다.

약 5년 넘게 꾸준히 해오던 헬스라서 나에게도 큰 변화였지만 즐거움 없이 파워리프팅을 하는 이유를 찾지 못한 게 컸다.

그리고 새로운 취미로 주짓수, 클라이밍, 러닝을 후보로 두고 고민하다가, 러닝으로 시작하였다.

이유는 헬스와 마찬가지로 자세가 괜찮다면 나이가 들어서도 꾸준히 할 수 있는 운동이라는 것이고,

초기 비용이 들지 않으면서, 현재 체력이 부족해 하고싶은 게 많아도 못하는 이 상황을 타개할 수 있을 것이라 생각했다.

그래서 군대에서도 전부 특급이었지만 구보가 2급이어서 특급전사를 못했던 내가 달리기를 시작했고,

처음에 3km 7분 페이스도 힘들었는데 한 달 만에 515 페이스로 10km를 달릴 수 있게 되어 큰 성취감을 느꼈다.

그래서 회사에서 점심에 요가 또는 간단한 맨몸운동을 하고, 퇴근 후에 러닝을 하는 게 내 새로운 운동루틴으로 자리 잡게 되었다.

2026년 목표는 풀마라톤 330이다.

생각만 해도 고되지만, 뭐 안되면 말고~

독서

올해 읽은 책은 많지 않다. 작년 회고에서 읽을 책 목록을 잔뜩 적어놨는데, 거의 못 읽었다. 이 부분은 좀 아쉽다.

그나마 읽은 책:

마법의 연금 굴리기
행복의 기원
자몽살구크럽

2026년에는 월 1권이라도 읽는 것이 목표다.

재테크

작년에 부동산 공부를 시작하겠다고 했는데, 아직 시작 못 했지만 대신 주식 투자는 꾸준히 하고 있다.

연금저축펀드, ISA 계좌 등을 통해 세금 공제를 이용한 장기 투자를 진행하고,

기본적으로 자산 배분 + 계절성을 통한 안정성 포트폴리오와 공격적인 자산에 투자하는 투더문 포트폴리오로 나누어 진행하고 있다.

그리고 이를 매번 수동으로 관리하는 게 어려워, 12월에 Folio라는 사이드 프로젝트를 시작했다.

노션에 정리해 둔 재테크 전략들을 자동으로 실행하고, 실제로 자산 관리를 자동화하는 개인 자산 관리 플랫폼이다.

아직 MVP 단계지만, 2026년에는 제대로 완성해 볼 예정이다.

마무리하며

작년 회고에서 이렇게 썼다:

다음에 회고할 때의 내가 지금의 나를 귀엽다 생각할 수 있도록 2025년도 열심히 살아볼 예정이다

근데 취준 하는 당시에 너무 고생하며 열심히 했어서, 아직도 그때의 내가 귀여워 보이기는커녕 참 고생 많이 했다는 생각이 든다.

지금도 열심히 자기 계발을 하지만 하기 싫은 걸 하는 능력이 정말 바닥을 치고 있다(예를 들어서 토익스피킹)

매일 번아웃이 오면서, 하기 싫은 것을 매일 했었던 과거의 나에게 위로를 보내고 싶다.

그런 노력 끝에 시작된 마중물이 이제 하나의 줄기가 되어 흐르고 있다.

아직 작은 물줄기지만, 꾸준히 흐르다 보면 언젠가 강이 될 거라고 믿는다.

2026년 목표는 아래 3가지다.

업무: 연차나 직급에 한계를 두지 않고 프로젝트를 제대로 책임지고 이끌기
기술: AI 워크플로우 지속적으로 발전시켜 사이드 프로젝트 하기, AWS SAA, SAP 자격증 취득
개인: 풀마라톤 3시간 30분 / 영어회화 (비즈니스 활용) / Folio 프로젝트 완성 / 책 월 1권 이상 독서

위 목표를 성공하든 못하든, 내년에도 또 돌아와 회고 글을 남기기를~

긴 글 읽어주셔서 감사합니다.

[DevOps] Terraform 1차 멘토링 by 정영진님 - Terraform 기초 및 Atlantis

겨울단추 — Mon, 21 Jul 2025 22:16:55 +0900

오랜만입니다. 회사에 입사해서 여러 교육을 받고 팀에 배치받아 열심히 회사생활에 적응 중입니다.
여러 일을 병행하지만, 평소에도 관심 있었던 데브옵스를 주로 맡게 되었습니다.
회사의 대규모 인프라를 테라폼으로 형상화시켜 관리하고 싶어,
멘토이자 항상 감사한 형님이신 정영진 님께 공부법을 여쭤보던 중 좋은 기회로 멘토링을 받게 되었습니다.
당분간 멘토링에서 배운 내용이나, 데브옵스에 대한 내용, 그리고 추가적으로 개발 고려 중인 사이드 프로젝트들을 위주로 블로그를 작성할 것 같습니다 :>

Assignment - Atlantis deploy

우선 영진 님이 제공해 주신(다시 한번 감사 :>) 레포지토리를 클론 해서, atlantis를 배포하고 이를 이용해서 GitOps를 경험해 보았다.

아직 HCL에 익숙하지 않기 때문에 코드를 하나씩 읽으며 VPC, ALB, ECS, IAM 등 주요 구성 요소를 파악을 먼저 했다.

이 과정 중에 배운 것과 문제를 디버깅한 내용 중 일부를 정리해 보겠다.

우선 배운 것은, 코드를 이용해서 인프라 자원을 관리하기 때문에 인프라 상태 관리 파일(tfstate)을 주로 S3에서 관리하는 것이 글로벌 스탠더드이다.

이 경우 인프라 관리 권한을 가지고 있는 누구나 사용할 수 있다면 같은 시간에 같은 인프라를 만약 수정해서 생기는 동시성 문제를 어떻게 해결할까?

여러 가지 방법이 있겠지만 DynamoDB를 이용해서 상태 파일을 Lock 걸어 동시 접근을 방지하고 일관성을 보장하게끔 한다.

좀 더 설명하기 위해 작업 흐름을 서술하자면,

1. 테라폼에 명령을 내림(ex. apply, plan)

2. 테라폼에서 DynamoDB 테이블에 Lock 아이템 생성

2-1. Lock이 없다면? -> Lock을 생성하고 작업을 시작

2-2. Lock이 있다면? -> 다른 사람이 작업 중인 것으로, locked 에러를 발생하고 대기 또는 실패 처리

3. 작업이 끝난다면 Lock 아이템을 삭제

물론 2주 차가 지난 현재 시점에서는 provisioning을 다른 방식으로 진행해서 DynamoDB를 이용하지 않았지만

이에 대해선 2주 차 멘토링 글에서 작성하도록 하겠다.

과제를 하면서 발생한 문제는, 클론 하는 레포지토리를 실수로 atlantis-deploy 관련 레포지토리만 하는 것으로 오해하여

과제에서 설정해야 하는 ACM과 DNS 관련 설정을 false(무효화) 처리하고 진행했다.

물론 실습용으로 로컬에서 작동하고 AWS에 띄워보는 정도라 문제는 없었지만, 이후 회사에서 실제로 사용해 보는 것을 목적으로 멘토링을 받는 상황에서 약식으로 진행한 것이라 이번 주에 다시 제대로 진행할 예정이다.

그래서 이후에는 ACM 등을 제대로 구성하여 HTTPS로 통신하는 프로덕션 환경과 비슷하게 구성해 볼 예정이다.

1차만 진행했던 당시에도, 영진님 실력의 깊이를 엿볼 수 있었고 위에 것들을 제외하고도 웹훅이나, 테라폼 등등 이외에도 많은 것을 배울 수 있었다.
현재 2차 멘토링까지 받은 상태인데 이번에는 더욱 많은 것들을 배우고, 더 많은 것들을 공부해야 하는 상황이 되어서 즐겁다 :>

강연 이후에 여러 커피챗과 연락을 이어나가며 지속적으로 인연을 이어나가고 있는 영진님께,

후학을 위해서 아낌없이 시간을 내어 멘토링해 주셔서 다시 한번 감사하다는 말씀을 드리고 싶다.

꼭 성장한 이후에 누군가에게도 도움 되는 멘토링을 할 수 있을 때까지 열심히 하고 있고, 할 것이다.

아래는 멘토링 중 정리한 개념

Mentoring Content

HCL : 테라폼의 핵심 언어 / main.tf, variables.tf

Provider : AWS, GCP, Azure과 같은 플랫폼에 통신할 수 있게 해주는 플러그인

Resource : 실제로 관리할 인프라 (EC2, S3, VPC 등) - 코드로 관리하기 때문에 인프라 상태를 일관되게 재현 가능

Data Source : 이미 있는 리소스나, 정보(기존 VPC, 특정 태그를 가진 S3)를 읽어서 테라폼에서 활용할 때 사용

Variables :

- input: 외부에서 입력받음 (var 플래그나 변수파일)

- output: 실행 후 결괏값 반환 (예: public IP)

- local: 디렉터리 범위에서만 쓰는 임시 변수 (함수와 결합해서 값 가공 가능)

Module : VPC, ALB, EC2 등 자주 쓰는 패턴을 만든 형태, 환경 별로 변수만 기입하여 반복 사용

Plan : 어떻게 변경되는지 미리 시뮬레이션(dry - run), 오류나 변경 사항을 미리 확인

Apply : Plan의 결과를 실제 클라우드에 생성 / 수정 / 삭제

State :

- 테라폼이 '현재 인프라가 어떤 상태인지' 추적하는 파일, 현업 시 S3 등 외부에 두고, 동시에 여러 명이 같은 인프라를 작업 못하게 lock 걸어둠

- S3에 저장할 때 동시에 작업 못하게 lock 기능 지원 (보통 DynamoDB로 lock 관리)

- S3버킷에 bucket policy, IP 제한 등

- 직접 권한이 없어도 IAM Role - Assume Role을 통해서 필요한 작업만 수행 가능

Atlantis와 GitOps (TACOS : Terraform Automation and COllaboration Sofrware )

Atlantis란?

테라폼 작업을 Git PR(pull request) 기반으로 자동화해 주는 툴
PR 올리면, Atlantis가 plan/apply를 자동 실행(혹은 승인 후 apply)
IaC의 GitOps(=모든 인프라 작업은 깃 PR로만!) 완성에 핵심

Atlantis Workflow

dev가 main.tf, variables.tf 등 변경 → PR 생성
PR에 코멘트로 /plan 입력 → Atlantis가 terraform plan 자동 실행, 결과를 PR에 댓글로 남김
리뷰어가 확인 후 /apply 입력 → Atlantis가 terraform apply 실행, 실제 인프라 변경

webhook으로 Atlantis가 PR 알림 받음
Atlantis에게는 실제 인프라 리소스를 생성/변경할 admin-level IAM 권한 필요

Multi Account/Assume Role

회사에서 AWS 계정이 여러 개일 때, 각 계정별로 Atlantis가 필요한 리소스만 assume role로 들어가서 작업
하나의 Atlantis가 여러 계정/환경 관리 가능

긴 글 읽어주셔서 감사합니다.

2025년 3월, 드디어 취업_당근 / 라인 / 대한항공 / 데브시스터즈

겨울단추 — Thu, 13 Mar 2025 11:37:06 +0900

2024년 하반기와 2025년 상반기 공채 사이에 라인과 대한항공, 당근 등에서 좋은 기회가 찾아왔습니다.
이에 대해서 간략한 회고를 작성하겠습니다.
참고로 회사 순서는 올해 전형을 진행한 순서입니다.

열심히 싸피에서 13기 동기들과 알고리즘 공부를 병행하면서, 취업 준비 활동을 병행했습니다.

올해는 운좋게도 라인 최종 면접, 대한항공 최종면접, 당근 과제 전형, 데브시스터즈 코테를 진행하였고

그중에서 최종으로 합격하여 기나긴 취준 생활이 끝나게 되었습니다.

당근

대학생 윈터 인턴십 인프라 직군에 지원하여 서류를 합격하고, 이후 과제 전형을 진행하였습니다.

당시 연휴와 겹쳐서 준비할 시간이 많아졌다고 좋아했습니다만,

열심히 당근이랑 다른 IT회사의 테크 블로그를 참고해서 기획과 전반적인 구현을 하였지만

B형과 A형 독감이 모두 유행하던 2월에 저 역시 제대로 걸려서 한 일주일 간 거의 쓰러져있었던 것 같습니다.

마무리를 완벽히 하고 Read.me 작성까지 확실히 했으면 면접까진 봤을 것 같은데, 건강 이슈로 못해서 아쉬웠습니다.

라인

라인은 데브옵스 직무로, 현재 신입 공채를 뽑지 않고 수시 채용만 하기에 각 팀마다 채용 절차가 다릅니다.

제가 지원한 직무의 경우 서류 - 1차 - 최종 면접 - 처우 협의 및 레퍼런스 체크 를 통해서 뽑았습니다.

작년 12월 초쯤에 지원하였고, 1월 중순에 서류 합격 연락이 왔습니다.

이후 1차 면접을 보았는데 다른 라인 면접 후기들을 보면 알 수 있듯이 정말 지구 내핵까지 파고드는 CS 질문들을 하셨습니다.

특히 각 팀마다 사람을 뽑는 수시 채용이다 보니까 전반적인 CS에 대한 질문을 주시기보다는,

제 포트폴리오를 기반으로 해서 해당 직무와 연관된 기술질문으로 들어가 계속 깊어지는 방식으로 질문을 주셨습니다.

다행히 그런 식으로 나올 것을 어느정도 예상하였고,

GPT와 같은 방식으로 DFS 알고리즘처럼 면접 준비를 하여 1차 면접을 통과하였습니다.

사실 1/3 정도는 대답을 제대로 못하거나, 경험이 없다고 했기 때문에 면접 통과를 못 할 것이라고 생각했는데 합격해서 놀랐습니다.

이후 최종 면접도 라인은 더 깊은 CS 질문이 나온다고 해서, 훨씬 깊고 넓게 기술 면접 준비를 했습니다.

근데 의외로 한 80%정도 인성 위주로 질문이 들어왔습니다.

3분 중에 2분은 우호적이셨는데,

1분은 처음부터 공격적으로 질문을 하셨고 해당 부분에 대해 면접관님이 만족할 수준으로 대답을 못 했던 것 같습니다.

그래도 전반적으로 분위기는 좋았고, 면접도 잘 마무리했습니다.

대한항공

대한항공은 작년 11월에 시작한 2024 하반기 공채인데, 올해 3월이 되어서야 전형이 마무리되었습니다.

원래 이렇게 절차가 느린지 타 직무의 지인들한테 물어봤는데,

원래 대한항공은 직무와 상관없이 절차가 엄청 느린 편이라고 하더라고요.

전형은 서류 - 1차 면접(화상) - 2차 면접(영어, PT, 기술) - 3차 면접(임원 면접) - 신체검사로 구성되어 있습니다.

서류 통과 후 1차 면접의 경우 약 10분에서 15분 정도 소모된다고 안내되었고,

이전 면접 후기들을 참고했을 때 인성 면접 질문이 나올 것으로 예상했는데 갑자기 기술 질문이 들어와서 당황했습니다.

하지만 제가 프로젝트하면서 익히 알고 있던 부분들을 물어봐서 다행히 대답을 잘했고 통과할 수 있었습니다.

2차 면접은 영어 면접과 PT면접 이후 기술면접이 이어서 진행됩니다.

영어 면접의 경우 오픽처럼 나온다고 해서 그렇게 준비했는데, 생각보다 대답하기 어려운 질문이 나와서 대답을 잘 못 했습니다.

이후 PT와 기술 면접에서는 저랑 같이 본 조원들 중에서는 압도적으로 잘했다고 끝나고 판단해서,

만약 떨어지면 무조건 영어 때문이라고 생각했고 다행히도 합격하였습니다.

이후 최종 면접은 임원 2분 : 지원자 5명씩 해서 저희 직무 같은 경우 총 10명이 최종으로 올라왔습니다.

최종임에도 불구하고 경쟁률이 5대 1에서 많으면 10대 1이었던 상황이었고,

저처럼 쌩신입 말고 대부분이 중고신입이어서 나름 면접을 잘 마무리했음에도 합격을 확신하지 못했던 것 같습니다.

데브시스터즈

데브시스터즈의 서버 직군의 서류에 합격하게 되어 코딩테스트를 보았습니다.

이후 코딩테스트를 보았는데, 한참 싸피에서 알고리즘 공부를 많이 하던 때라 쉽게 풀었던 것 같습니다.

이후 코딩테스트를 합격하고 면접을 준비하던 중에 다른 기업에서 최종합격을 하여 중도 포기 의사를 회사에게 전달하고 절차를 마무리했습니다.

결과

결론적으로, 여러 상황과 제 성향을 고려했을 때 가장 가고 싶었던 기업에 최종 합격하게 되었습니다.

준사관을 준비했던 시절부터 개발자로 전향하고 취업하게 된 지금까지 거의 3년간 쉰 적이 거의 없어서

당분간 좀 쉬면서 지내려고 합니다.

싸피에서 매 기수 취업과 관련한 설명회를 진행하는데,

매년 올해가 가장 힘들다고 하지만

12기까지는 그래도 도메인 별로 취업을 기대해 볼 만하다, 여긴 이번에 안 좋다 이런 지표를 보여주는데

올해 처음으로 모든 도메인의 취업시장이 동결이라 지표를 보여주지 못한다고 컨설턴트님께서 말씀하셨습니다.

이밖에도 뉴스와 여러 기사에서 현재 IMF 시절만큼 취업률이 떨어진 굉장히 어려운 시기라고 여러 증거들을 제시합니다.

이처럼 경제가 힘든 시기에는 어느 정도 대기업에 서류가 붙을 정도의 수준이 되었다면,

그 이후부턴 운의 영역이니 떨어지더라도 실력이 부족해서 그런 것이 아니기 때문에 낙담하지 말고

계속 운이 붙을 수 있게 꾸준히 지원하면서 때를 기다리는 것이 좋을 것 같습니다.

정말 열심히 노력하긴 했지만, 저 역시 많은 분들께 조언을 구하며 도움을 받으며 준비했기 때문에 얻은 결과라고 생각합니다.

피드백이나 취업과 관련해서 도움이 필요하신 분들은 편하게 연락 주시면, 도움드리겠습니다.
모든 취준생 분들 파이팅입니다

[SSAFY] 알고리즘 역량 A+ 취득

겨울단추 — Thu, 20 Feb 2025 16:42:17 +0900

오랜만에 블로그 글이네요!
싸피에 들어오고 약 1.5개월 정도 지났습니다.
최근엔 프로젝트보다는 실력 기복이 심한 알고리즘을 안정적으로 잘하기 위해서 알고리즘을 집중해서 공부하고 있어서 글을 자주 작성하지 못했습니다.
그래도 최근에 어느정도 성과가 있어서 정리할 겸 글을 오랜만에 적습니다 :>

싸피를 시작하고 약 1.5개월 동안 스타트캠프, 자바, Js에 대한 학습과 평가시험 그리고 1번의 관통 프로젝트를 경험했습니다.

현재는 싸피에서 알고리즘 수업을 듣고, 매일 문제 풀고 발표하는 과정을 하고 있습니다.

또한 입과할 때 코딩테스트를 좋은 성적으로 들어와, 입과생들 중에서 선발되어 삼성 B형 취득을 위한 특강을 알고리즘 업계에서 유명한 '류호석' 강사님께 배우고 있습니다.

추가로 코딩테스트 스터디를 싸피 동기들과 진행하며, 특강 진도에 맞게 추가적으로 문제를 풀고 스터디원들과 공유하며 복습 및 실력을 기르는데 많은 도움을 받고 있습니다.

코테 스터디에서도, 동기중 백준에 문제도 출제하는 알고리즘 고수 동기가 직접 문제를 선별하고, 발표 시 부족한 부분도 강의해주고 있습니다.

과거에 혼자서 주먹구구식으로 알고리즘을 학습했을 때보다 훨씬 좋은 환경에서 알고리즘에 몰입하며 학습하였더니, 짧은 기간 동안 빠르게 성장한 것 같습니다.

그래서 싸피에서 진행한 첫 번째 삼성 알고리즘 A형 역량테스트에서 최고득점인 A+ 결과를 얻었습니다.

파이썬으로만 코딩테스트를 풀다가, 자바로 보는 첫 번째 코딩테스트 결과여서 더욱 기분이 좋았던 것 같습니다.

왜 싸피 수료생들이 다른 건 몰라도 코딩테스트는 잘하는지 궁금했는데,

직접 들어와서 알고리즘과 관련된 모든 활동들을 지원하고 진행하다 보니

이를 제대로 소화만 하더라도 못하기는 어렵겠다는 생각이 들었습니다.

또한 문제 푸는 것 자체에도 즐거움을 느끼기 시작해서, 추후에 취업을 하더라도 하루에 1문제씩은 꾸준히 풀고 싶네요.

앞으로도 공유할만한 좋은 소식이 있으면 또 글 적으러 오도록 하겠습니다

글 읽어주셔서 감사합니다. 꽃샘 추위 때문에 감기 걸리시는 분들이 많은데 다들 감기 조심하세요~~!

마중물 같은 개발자의 2024년 회고

겨울단추 — Mon, 30 Dec 2024 19:29:16 +0900

마중물
명사. 펌프질을 할 때 물을 끌어올리기 위하여 위에서 붓는 물
- 표준국어대사전

2024년 상반기는 이미 아래 글에서 회고해서, 2024년 하반기의 회고를 작성할 예정이다.

잠은 죽어서 자는 건가 싶었던 2024년 상반기 회고

원래 회고를 1년 주기로 작성하려 했는데, 상반기만 해도 많은 일들을 해서 올해는 반년 단위로 회고를 하려고 합니다.과장하는 게 아니라, 정말 하루도 최선을 다하지 않은 날이 없는 것 같습니

jun10920.tistory.com

새로운 2025년을 시작하기 전에, 2024년을 되돌아보고 정리해야 활기찬 시작을 할 수 있다고 생각해 올해도 회고를 진행한다.

글을 보다가 주황/파란색으로 표시된 부분은 링크가 포함되어 있는 부분이다.

해당 부분이 궁금하다면 들어가서 읽어보는 걸 추천한다.

크게 주제를 개발과 인생으로 나누어 작성할 예정이다.

작년 2023 회고의 말미에 언급했던 것처럼, 올해 2024년의 개발과 관련된 목표는 아래와 같았다.

학교를 4점대 이상으로 졸업
하반기에 1순위 취업 / 2순위 메이저 부트캠프 합격
졸업프로젝트 + 괜찮은 프로젝트 2개
SQLD 취득
정보처리기사 취득

이 중에서 의문의 5번 빼고는, 전부 달성했다.

개발

취업

올해 가장 열심히 한 활동을 꼽자면 취업이라고 할 수 있다.

이에 대해서 KPT로 회고를 해보자면,

KEEP

2023년에 취업 준비한 친구들도 취업 시장이 너무 혹한기라 힘들다고 했는데, 올해 2024년엔 TO가 더 줄어들었다.

(참고 기사 링크: https://www.mk.co.kr/news/world/11120521)

하지만 취업시장 한파에도 불구하고 아직도 수많은 개발자 지망생들이 몰려오고 있다.

가장 많은 블로그 조회수를 기록했던 9월의 TOP5를 보면, 개발자 취업을 위한 부트캠프인 SSAFY와 Ureka 관련 글이 1, 2등이다.

이를 보면 아직도 수많은 개발자 지망생들이 몰려오는 것 같다.

실제로 이번에 유플러스 백엔드 개발자와 데브옵스 개발자의 TO가 1명이었다는 걸 보면,

수천 명이 지원해도 1명 뽑는 요즘 시장인데 내년엔 더욱 힘들어질 것 같다.

그래서 나 같은 신입 개발자 말고 경력이 있는 개발자들도 100곳 넘게 써야 서류 합격을 조금이라도 하는 상황이라

200곳 넘게 도전해 본 것이 잘한 일이라고 생각된다.

이만큼 서류 작성 - 코테 - 면접 등을 경험해 보면서 점점

나의 컨셉이 확실한 Resume도 작성하게 되고, 주로 나오는 코테 유형, 면접 질문 등도 파악하게 된 것 같다.

올해 하반기에 남은 곳들이 모두 떨어지게 되더라도 내년 상반기에도 내가 원하는 회사에 들어갈 때까지 끊임없이 도전할 것이다.

PROBLEM

사실 여름방학 시기에 처음 서류를 넣자마자 면접을 본 곳이 카카오였고,

그 이후에도 내로라하는 기업들에 은근히 서류와 코테를 통과를 많이 했었다.

그래서 상시채용에서도 이 정도 성적인데, 하반기 공채는 생각보다 수월하겠다는 안일한 생각을 했다.

하지만 웬걸, 상시채용의 성적이 하반기 전체 지원한 결과보다 좋았던 것 같다.

개인적으로 생각한 원인은, 너무 자소서가 개발과 관련된 얘기 위주이기에 실무진이 바로 서류를 검토하는 상시채용이

인사담당자가 검토하고 이후 실무진에게 전달되는 하반기 공채보다 더욱 서합률이 높았던 것 같다.

정리한 내용을 보면 주로 붙은 곳들도 서비스 IT나 대기업 SI이고, 금융권은 거의 붙지 못했다.

이 역시 위에 언급한, 내 이력서와 자소서가 성장과 개발에 초점이 맞춰져 있어서 인 것 같다.

또한 도메인을 다양하게 준비하다 보니

필기에서만 코딩테스트, NCS, 전산 필기, CS면접, 잡다 역검 등 다양한 종류의 시험을 준비했었다.

그래서 전부 적당히는 하는데, TO가 1~2명인 요즘 채용 시장에서 그 1~2명에 들어갈 정도의 수준인 것은 없어 불합격한 적이 많다.

TRY

이제 대학교 졸업도 했고 대외활동과 프로젝트에서는 부족하지 않을 만큼 경험을 쌓은 것 같다.

그래서 내년 상반기에는 주로 코딩테스트, NCS, 전산 필기 이렇게 3개에 집중해서 준비할 것 같다.

교육

교육은 크게 유레카, 싸피, 오픈소스 멘토링, 오픈소스 컨트리뷰션 아카데미 4개로 분류했다.

유레카

4학년 1학기를 마치고 싸피 12기와 유레카 합격을 했지만, 졸업 예정자가 아니었기 때문에 유레카에 입과했다.

좋은 강사님과 학생들과 함께 해서 즐겁게 했던 것 같다.

또한 비대면 과정이라 강사님께서 배려해 주셔서, 하반기 공채가 시작한 시점부터는 학업과 취준 생활을 병행할 수 있었다.

이 과정 동안 프로젝트를 여러 번 진행했는데, 그중 의미 있던 프로젝트는

최종 프로젝트인 Filmeet과 종합 프로젝트인 Naviya였다.

Filmmet에서는 보통 나와 비슷한 실력을 가진 개발자와 프로젝트를 진행하다가, 처음으로 나보다 개발을 더 잘하는 백엔드 개발자들과 프로젝트를 진행하면서 많은 인사이트를 얻었다.

거기에 더해 개인적으로 DevOps 역할을 맡아 인프라 경험도 쌓고, 멘토님들의 조언을 통해 이전의 성능테스트 경험보다 발전하여 Pinpoint와 Query Plan 분석을 통한 최적화도 진행했다.

덕분에 데브옵스의 즐거움과 고충도 경험하고, 좀 더 깊이 있게 최적화하는 방법에 대해서도 배웠다.

Naviya에서는 과제 조건이었던 대규모 트래픽 응모 시스템 구축을 맡아, Redis와 Redis Streams를 이용해 해당 시스템을 구축했다.

실제로 안정성 있게 기능 구축을 했지만, 짧은 기간 안에 구축하느라 Redis에 대해 깊이 있는 이해를 하지 못하고 기능 구현 위주로 진행해서 약간은 아쉽다. 그랬기에 Redis에 대해서 추가로 더 학습할 생각이다.

싸피

12기 엠배서더, 12기 코테까지 합격, 13기 최종합격까지 어쩌다 보니 많은 인연이 있는 싸피다.

졸업 전 취업이 최우선 목표였기 때문에, 13기에 최종합격할 때는 기쁨보다는 안심이 컸던 거 같다.

하반기에 모두 떨어지더라도, 100만 원씩 받으면서 1년간 더 취업에 도전할 수 있다는..?

현재 기업은행 인턴 결과도 기다리고 있는데, 범용적인 싸피냐 금융권 특화 기업은행 인턴이냐를 가지고도 고민이 많이 된다.

2025년 1월 7일부터 시작하기 때문에 활동에 대해서는 적을 게 없지만,

싸피를 시작하기 앞서 왕복 3시간이 넘는 본가에서 다니는 것은 시간이 금인 취준생에게 너무 손해인 것 같아,

관악구에 자취방을 구했다.

해당 자취방을 구하면서 개발자답게 정보를 입력하면 내가 원하는 조건의 가중치 로직을 바탕으로 랭킹을 짜는 DB를 노션에 구현해서 랭킹을 매겼다.

그리고 랭킹 상위권들에 대해서 같이 조사해 준 희준이와 토론하고, 부동산들에 전화해서 직접 임장을 다녔다.

이때 하루에 12곳 이상의 매물을 확인하고, 계약하면서 배운 것들이 많다.

주식 투자에 관심이 많아 군대를 가기 전부터 공부했던 나에게, 부동산 투자 또한 재밌을 것 같다는 생각이 들었다.

또한 내 집 장만을 위해서 알아야 하는 최소한의 부동산 지식의 필요성을 느껴,

취업을 하고 나서 안정이 되면 부동산 공부를 시작하겠다는 다짐을 했다.

오픈소스 멘토링

김인제 님이 진행하는 오픈소스 멘토링의 6기에서 활동했다.

오픈소스 라이브러리인 Spring AI에 기여하였는데,

결론적으로 메인테이너와 토론 끝에 좀 더 나은 방안을 가져온 중국 컨트리뷰터가 Merged 되긴 했다.

그래도 해당 경험을 하면서 우매함의 봉우리를 느끼고 오픈소스 기여의 심리적 장벽을 무너뜨리는데 좋은 경험이었다.

자세한 얘기는 링크된 글을 읽어보길 바란다.

오픈소스 컨트리뷰션 아카데미

과학기술정보통신부가 주최하는 오픈소스 컨트리뷰션 아카데미(체험형)에 참여하고 수료하였다.

OKKY 제작자이신 최광모 멘토님께 교육을 받았다.

학생들의 발표 위주로 멘토링이 진행되어 사실 역량 발달에는 큰 도움이 되지 않았지만,

멘토님과 더불어 같이 수강하는 멘티들의 수준이 높아 좋은 개발자 분들과의 네트워킹이 좋았던 것 같다.

실제로 같이 함께 했던 멘티 분들 중에서는 이런 취업한파 속에서도 카카오 헬스케어와 금융결제원에 이번 하반기에 취업하셨다.

프로젝트

유레카에서 진행한 프로젝트와 별개로, 직접 실제 유저들에게 쓰임 받는 프로덕트를 만들고 싶어 기획하고, 팀원을 모아 서비스를 운영했던 Now, Here 프로젝트를 진행했다.

프로젝트 링크 : https://www.now-here.site/

해당 프로젝트를 진행하면서 고객 중심의 가치 실현과 깊이 있는 고민을 통한 개발을 경험해 본 것 같다.

실제로 유저들에게 서비스하면서 개발자가 고려했을 때 좋은 것이 아니라, 유저가 원하는 것들을 직접 피드백받아 반영해 보면서 관점의 차이를 느끼게 되었다.

또한 수많은 로그를 처리하는 방법이나, 다양한 클라우드 서비스를 이용하면서 어떻게 하면 비용 절감을 할 수 있는지 고민하는 등

일반적인 사이드 프로젝트에서 느끼지 못하는 현업과 비슷한 고민들을 경험할 수 있었다.

또한 한정된 프리티어 자원을 최대한 사용하려다 보니, 최소한의 자원에서 착즙 해보는 경험을 해보면서 깊이 있는 고민을 통해서 개발을 하였다.

이는 실시간으로 유저들의 활동을 기반으로 한 데이터 기반 매칭 알고리즘을 구축하거나, 고가용성 보장을 위한 M-S 아키텍처 설계, 성능 테스트 이후 단계별 최적화 등을 의미한다.

이렇게 노력한 과정 중에 디스콰이엇에 개발기를 작성하고 디스콰이엇 이번주 뉴스레터에도 뽑혔다.

(관련 글)

Log.info(”Now, Here BE 난중일기”) | Disquiet*

들어가며세상에 좋은 프로젝트는 많지만, 실제로 쓰이는 프로젝트가 더 유의미하다고 판단하기에 유저가 실제로 사용하는 프로젝트를 만들기 위해서 Now, Here 프로젝트를 기획했습니다.이번 서

disquiet.io

디스콰이엇 이번주 뉴스레터

이를 통해서 워케이션 플랫폼에서 협찬 제의도 오는 등 다양한 기회도 같이 얻았다.

아마 다양한 일들을 병행하고 있지 않았다면, 어떻게든 시간을 내서 참여했을 것 같다.

자격증

올해 목표한 자격증은 정보처리기사와 SQLD 자격증이었다.

SQLD의 경우 하루 반을 공부해서 간단하게 취득하였다.

정보처리기사가 희한한데, 1차 때 필기를 합격하고 2차 때 첫 실기를 봤을 때는 내가 시험장에서 끝나고 가채점 확인을 할 때 생각보다 실수를 많이 해서 합격 컷에서 1개 더 틀려 아쉽게 불합격했었다.

그래서 3차 때 한 번 더 시험을 보았는데, 이번엔 시험 끝나고 3번 가채점해 본 결과 모두 75점이어서 가볍게 합격했다고 생각했다.

하지만 합격 발표날 또 합격 컷보다 5점이 부족해서, 가채점인 75점과 약 20점이나 차이 나는 것이 이상해 재확인을 요청하였지만 문제없다는 답변을 들었다.

다시 복기를 해봐도 분명 75점인데, 왜 55점이 또 나왔는지...

OMR도 아니고 단답식 문제인데 실수를 4개나 했다는 게 내 잘못이지만 정말 이해가 안 된다.

아무튼! 내년 1회 차에 다시 도전해 볼 생각이다.

어학으로는 OPIC을 준비하지 않고 봐서 IM3를 받았는데, 상반기에 준비해서 IM1을 받은 걸 보면 운이 좋았던 것 같다.

그저 팁이라곤, 좀 더 자신감 있게 얘기한 것 밖에 없다.

인생

작년과 마찬가지로 올해도 쉬는 날 거의 없이 개발만 하면서 살았기 때문에, 개발 외적인 내 인생에 대해서 정리할 내용이 별로 없다.

그래도 한 번 모아서 정리해 보자면,

학교

2018년에 항공 전공으로 들어간 학교, 이후에 준사관 시험을 위해서 1년간 휴학하고 복학해서 복수전공도 하면서

열심히 다닌 학교를 이제야 마무리했다.

1학기까지 대부분의 졸업 요건을 마쳤기 때문에 2학기에는 온라인 강의로만 수강하였다.

그래서 최종적으로 전체 학점 4.03으로 학교를 졸업하게 되었다.

열심히 학습한 SW복수전공 같은 경우는 4.35로 졸업하였다.

2개의 학위를 따기 위해 2번의 졸업시험, 졸업프로젝트가 있었지만 결론적으로 하길 잘했다고 생각한다.

특히 이렇게 빡세진 취업 시장에서 비전공보다는 훨씬 낫다고 생각하기 때문이다.

블로그

블로그의 경우 현재 기준으로 조회수가 31500이 넘는다.

작년 12월 말에 시작했는데, 보다시피 5월까지는 한 달 내내 조회수가 5~600회도 안 나오던 시기였다.

하지만 이제껏 내가 살아온 인생같이,

우직하게 꾸준히 작성하다 보니 오히려 글을 적게 쓴 하반기에 과거의 글들이 떠오르면서 한 달 평균 7000회 이상 조회수가 나왔다.

이는 대단한 조회수는 아니지만 나름의 성과를 얻었다고 생각한다.

운동과 블로그를 통해서 배운 것은 결과는 운칠기삼이라는 것이다.

하지만 기술 3이 있어야 운이 왔을 때 잡을 수 있고, 기술은 성실함에서 생긴다는 것을 배웠다.

취업도 실제로 여름방학 시기에 운이 찾아왔었지만, 내가 알아보지 못해 잡지 못했다.

다른 경험들에서 배운 것처럼 다시 운이 찾아왔을 때 꼭 잡을 수 있도록 내년 한 해 동안도 성실하고 우직하게 해 볼 생각이다.

운동

내 인생에서 가장 중요한 부분 중 하나를 차지하는 헬스를, 올해 하반기에는 아예 1번도 하지 못했다.

그래서 운동으로 키운 몸무게 83kg에서 무려 75~6kg로 헬스인이 가장 무서워하는 근손실도 무지막지하게 났다..

운동을 못한 이유는 기본적으로 운동을 다녀와서 씻고 하면 2~3시간이 걸리고, 이후에 졸려서 집중력이 확 낮아지는데, 하반기에 기본적으로 3~4개 이상을 병행했던 나에게 시간이 너무 부족했다.

그래서 유산소를 기피하던 헬창인 내가 시간은 부족하고 운동은 해야겠으니 겨울이 시작되기 전까지 하루 30분 러닝으로 바꾸어서 진행했다.

평생 유산소를 싫어했고, 군대에서도 전부 특급인데 구보만 2급이라 특급 전사를 따지 못했던 내가 러닝을 하였는데,

이때 느낀 것은 정말 싫은 것을 해낼 때 쾌감은 엄청나다는 것이다.

특히 한 번도 쉬지 않고 30분을 뛰는 것을 성공했을 때 깨달은 것은,

이렇게 힘들지만 한걸음 한걸음 가다 보면 목표에 도달할 수 있다는 것을 머리가 아니라 몸으로 느끼게 된 순간이었다.

그래서 거대한 근육질 몸만을 추구했던 내가,

적당히 유산소와 헬스를 겸비한 적당히 탄탄한 몸으로 추구하는 육체미도 바뀌게 된 것 같다.

내년 상반기부터는 대학교와 유레카는 끝나니, 헬스를 다시 제대로 시작해 볼 생각이다.

감사한 분들

올 한 해도 정말 열심히 살았다.

그 한 해를 더욱 풍성하게 채워준 감사한 사람들이 있다.

개발 블로그이기에 개발과 관련된 분들만 작성할 예정이다.

우선 멘토의 역할을 해주신 정영진 님과, 장원익 님이다.

한 분은 강연을 통해서 , 한 분은 유레카를 통해서 알게 된 사이이고 내가 개인적으로 커피챗을 요청해 인연이 시작된 사이다.

한 분은 개발 철학을, 한 분은 실제 취업을 위한 유용한 내용들을 알려주셨다.

현재도 두 분과는 종종 연락하면서 지내고 있는데, 앞으로 내가 성장해서 도움을 드릴 수 있는 사람이 되었으면 좋겠다.

그리고 중간에 잠깐 일본 취업에 대한 고민이 들어, 유투버이신 브라운님께 연락을 드려 2시간 동안 조언을 들었다.

멘토링을 하면서 지금까지 쌓아온 것이 아까우니 한국에서 킵고잉 하라는 결론이 났지만 고민을 더 오래 하면서 시간을 낭비하지 않게 조언해 주시고 원래는 1시간 조언해 주신다고 하셨는데 2시간 동안 정성 들여서 조언해 주신 브라운님께 감사하다.

그리고 다양한 좋은 동료들을 만났다.

상반기 회고에 적었던 희준이는 하반기에도 최고의 동료였다.

취준 역시 계속 서로 공유하면서 진행하였는데, 결론적으로 희준이는 좋은 SI 기업에 취업하게 되었다.

희준이가 최종 발표를 기다릴 때는 내가 취업할 때 결과를 기다린 것보다 더욱 마음 졸이며 기다렸던 것 같다.

좋은 개발자가 좋은 기업에 취업한 것이라,

당연한 결과라고 생각하지만 요즘 같은 힘든 취업 시장에 좋은 결과를 얻게 되어서 너무 반가웠다.

이외에도 개발자의 길을 걷게 조언했던 인수, 교현이, 프로젝트를 진행하면서 많은 인사이트를 줬던 재진, 동현이 형, 힘든 취준 생활에 서로 많은 응원을 했던 지윤 누나와 금융권 관련해서 조언을 준 우진이, 그리고 다양한 대외활동에서 알게 된 감사한 분들이 많다.

마지막으로 가장 고마운 사람은 바로 나 자신이다.

한 해를 돌아보면서, 좀 더 나은 선택을 했으면 어땠을까 하는 아쉬움도 있지만 매사에 최선을 다해서 후회하지는 않는다.

상반기에는 번아웃의 연속이었으며 번아웃이 아닌 순간이 있었나 싶은데, 이제는 역치가 높아져 편안한 마음으로 잘 지내고 있다.

직업적으로 열심히 사는 삶과, 워라밸을 챙기는 삶에 대해서도 고민이 많았는데 기왕 사는 거 최선을 다해보고 싶다는 결심이 들었다.

그래서 인생의 방향을 결정하는 큰 결정을 내릴 때도 과거에 비해 고민 없이 결정하게 되는 것 같다.

즐거우면서 동시에 고난했던 2024년을 잘 이겨낸 나 자신에게 가장 고맙다.

마무리하며

회고의 서두에 마중물이라는 단어를 썼다.

마중물이란, 비유적 표현으로는 '약간의 계기를 마련하여 잠재성을 이끌어내 주는' 의미로 자주 쓰인다.

개발을 시작하고 가장 많은 것을 공유한 희준이에게 들은 나에 대한 피드백은

'주체적으로 목표를 설정하고 어떻게든 달성하는 능력'과 '프로젝트 성공을 위한 마중물 같은 리딩 능력'이었다.

생각해 보면 항공정비 -> 준사관 -> 개발로 넘어간 것은 나의 주체적인 선택이었다.

그리고 복수전공, 수많은 프로젝트, 부트캠프, 취업 경험, 다양한 대외활동 등 수동적으로 한 것이 하나도 없다.

전부 내가 주체적으로 하기로 마음먹고 이루어낸 것들이었다.

그리고 어떤 활동을 하든 간에 모두가 합의한 큰 목표를 달성하기 위해

크게는 효율적인 협업 프로세스를 도입하고, 협업하기 위한 다양한 인프라를 세팅하는 것뿐만 아니라

작게는 모두의 요구사항과 불만을 수용하고 일정을 놓치지 않게 노티를 주는 등

최종적인 목표를 이루기 위한 '마중물' 같은 역할을 수행한다는 것이다.

개발자들의 기술적 능력이 상향 평준화된 지금,

이런 소프트 스킬이 더욱 중요하다고 생각하는데 희준이의 피드백을 듣고 잘 나아가고 있다고 생각했다.

회고를 진행하면서 재밌는 것은 매번 회고 글을 작성할 때는

'와 진짜 이렇게까지 많은 것을 했다고? 대단한데?' 이런 마음으로 글을 작성한다.

그러고 반년이나 1년 뒤에 해당 글을 다시 읽어보면, 귀여웠던 수준의 나를 보게 된다.

그러면서 내가 알지도 못하는 사이에 그만큼 성장했다는 것을 체감하고, 앞으로 성장할 내가 기대되게 된다.

다음에 회고할 때의 내가 지금의 나를 귀엽다 생각할 수 있도록 2025년도 열심히 살아볼 예정이다.

긴 글 읽어주셔서 감사합니다.

[SSAFY] 싸피 13기 전공자 합격 후기 - 최소한의 준비를 곁들인...

겨울단추 — Sat, 28 Dec 2024 16:45:12 +0900

현재도 몇 개의 회사에서 전형을 진행 중이지만, 혹시나 이번 하반기에 모두 떨어졌을 때를 대비해서
유레카를 수료한 이후 공백기를 위해 싸피에 지원했습니다.
대학교 4-2학기, Ureka 프로젝트, 많은 회사들의 자소서-코테-면접들을 병행하고 있었기 때문에
싸피를 위해 다른 준비를 하진 않았고 그냥 취업준비 하면서 정리한 내용들을 바탕으로 지원했습니다.
결론적으로 감사하게도 최종합격을 수월하게 하였네요.
어느 정도 포폴 / 실력이 갖춰진 전공자분이라면 최소한의 노력으로 합격을 하는데 도움이 될만한 후기라고 생각합니다.

서류 지원

싸피는 기업 자소서와 다르게, 교육을 위한 기관이라 그런가 간단한 인적사항과 간단한 에세이 1문항만 작성하면 됩니다.

향후 어떤 SW 개발자로 성장하고 싶은지 SW 관련 경험을 토대로 기술하고, SSAFY에 지원하신 동기에 대해서도 작성 바랍니다. (500자 내외 작성), 최대 600자까지 입력 가능

짧은 글 안에 저를 어필해야 하고, 실제로는 교육기관이기 때문에 나의 기술적 역량을 강조하기보다는

적당한 SW 경험 + 부족한 점 + 싸피를 통해 어떻게 채우겠다

이런 느낌으로 작성하는 게 좋다고, Ureka에서 함께 프로젝트 진행한 팀원의 조언이 있었습니다.

하지만..!

저는 서론에서 말씀드린 바쁜 상황이었기 때문에 싸피를 위해서 자소서를 첨삭하고 글을 다듬을 시간은 없었고,

그냥 자소서를 150건..? 이상 작성한 상황이라 적당히 비슷한 질문에 답변했던 내용을 가지고 와 글자 수에 맞게만 수정하여 제출했습니다.

해당 내용은 위의 추천과 다르게, 굉장히 저의 SW 역량을 강조하는 글이었지만 별다른 문제없이 합격하였습니다.

참고로 과거에 저는 12기 때 대학교 졸업예정자는 아니라서 면접은 포기했지만, 코딩테스트까지는 합격한 경험이 있습니다.

그때도 그냥 자소서에는 힘들이지 않고, 코테를 올솔했더니 쉽게 붙은 것을 보면 전공자에게 자소서가 그렇게 중요한 것 같지는 않은..? 뇌피셜이 있습니다.

https://jun10920.tistory.com/31

[SSAFY] 싸피 12기 자소서 & 코딩테스트 합격 후기 (전공자)

결과적으로는 사정상 다른 부트캠프를 갔지만, 최소한의 시간을 들여 싸피 자소서와 코딩테스트에 합격하였습니다.이 과정을 공유하면 도움이 될 분들이 계실 것 같아서 글을 작성합니다.지원

jun10920.tistory.com

SW 적성진단

위 블로그 글에서 언급한 것처럼, 코테도 이미 합격한 경험이 있습니다.

코테 난이도는 백준 기준 브론즈 상위 ~ 실버 중간 정도의 난이도가 출제되고 구체적인 알고리즘보단 구현 위주의 문제가 출제됩니다.

그리고 오전/오후 반을 나눠서 문제가 다르게 출제되는데요, 12-13기를 모두 경험했을 때 단순히 2 기수를 비교한 거지만 오전보단 오후가 상대적으로 쉽게 출제가 됐습니다.

물론 합격자는 오전과 오후를 나눠서 뽑겠지만, 그래도 코테에 자신감이 부족하신 분은, 오후에 시험을 보고 올솔을 하는 게 합격 가능성이 더 높지 않을까? 생각이 듭니다.

저의 경우 12기, 13기 모두 오후 반을 봤고, 주어진 70분 중에 40분 내로 검산까지 마무리한 다음 퇴실 시간까지 쉬다가 바로 퇴실했습니다.

현재 취업준비도 병행하느라 코테도 종종 보고 있던 상황이라서, 싸피 코테를 위해서 별다른 준비를 하진 않았습니다.

인터뷰

두둥..!

대망의 코딩테스트를 합격하셨군요.

여기서 약간 의외였던 게 저처럼 Ureka 소속의 개발자 중에서 회사에 꽤나 자주 서류-코테를 붙는 다른 개발자들이 저와 같은 생각으로 공백기를 위해 싸피를 넣었는데 이 단계에서 전부 떨어졌습니다.

카카오 부트캠프에 다닌 지인을 통해서 들었을 때, 카카오 부캠에서도 모두 떨어졌다고 하더라고요.

심지어 그중에선 올솔하셨다던 분들도 꽤 있었는데, 의외였습니다.

싸피 뿐만 아니라, 이번에 유레카 2기 지원 경쟁률도 훨씬 높아졌다는 걸 보면,

취업시장이 계속 힘들어지는데 개발자로 유입되시는 분들은 계속 많은 상황이라서 개발자 취업을 위한 부트캠프의 경쟁률 역시 더 올라간 것 같습니다.

그래서 과거보다 더 엄격한 기준으로 사람들을 뽑기 시작한 것 같아요.

아무튼 인터뷰는 PT 면접과 개인 면접 두 가지로 나눠져 있습니다.

면접 내용에 대해서는 대외비라 자세하게 말씀드릴 수는 없지만, 팀플 같은 곳에서 발표 많이 해봤고, 팀장이나 토론이나 이런 대중 앞에서 얘기를 많이 해본 분이라면 굳이 따로 준비를 안 해도 될 것 같습니다.

(반대로, 이런 경험이 부족하다면 면접스터디 같은 걸 하면 좋겠죠?)

저는 항상 리더 역할을 많이 맡았고, 팀플 할 때는 주로 발표를 맡았습니다.

또한 현재 바쁜 상황이라 면접을 따로 준비할 시간이 없어서 지금은 취업한 친한 동생이 정리한 자료를 바탕으로

면접 전날 저녁 1분 자기소개 작성 + IT 관련 뉴스 좀 읽다 자기 정도만 하고 가서 면접 봤습니다.

++ 추가로! 지하철 타고 가는 길에 봤던 PT 면접 영상이 꽤나 도움이 됐습니다.

참고하시면 좋을 것 같습니다.

최종 결과 발표

그래서 결론적으로..! 거의 노력을 들이지 않고 합격했습니다.

제가 수료한 Ureka와 같은 교육기관인 멀티캠퍼스에서 주최하는 거라, 교육 내용이 크게 다르지는 않겠지만

월 100만 원씩 지원해 주고, 많은 취업 지원 혜택 그리고 금융권 서류 가점 등 큰 혜택이 많은 싸피에 합격해서 든든한 보험이 생긴 것 같아 안심했습니다.

약간 싸피가 노력 없이도 붙을 수 있는 부트캠프라고 오해하실 수도 있는데 전혀 아닙니다.

제가 취업 문턱의 최종에서 아깝게 미끄러지는 상황이라 취업 준비의 전 단계인 교육 프로그램은 상대적으로 수월하게 통과했던 것 같습니다.

싸피를 위해서 회사를 퇴사하고 오신 분들도 있을 망정이니, 최선을 다해서 보실 여유가 있으시다면 꼭 열심히 준비하시면 좋을 것 같습니다!

다만 저처럼 매우 바빠서, 최대한 효율적으로 지원해야 하는 어느 정도 실력 있는 개발자 분들은 참고해 주시면 좋을 것 같아요!

그리고 댓글로 궁금하신 점 남겨주시면 답변드리겠습니다.

그럼 다음은, 취업한 내용이나 회고로 돌아오겠습니다.

기왕이면 싸피의 목표인 취업을 미리 성공해서, 취업 후기로 돌아오고 싶네요 :>

긴 글 읽어주셔서 감사합니다.

[Filmeet] 야, 공짜로 할 수 있을 때 AWS 써라. (부제 : DevOps는 정말 어려워)

겨울단추 — Mon, 23 Dec 2024 23:06:24 +0900

유플러스 수료를 하루 앞두고 적는 Filmeet의 인프라 구축기입니다.
프론트와 백엔드의 CI/CD 파이프라인을 구축하고, 테스트 환경을 팀원 모두 동일하게 가져가기 위해서 인프라를 설정한 경험은 매우 값지고, 어려운 경험이었습니다.
진정으로 데브옵스는 백엔드의 2차 전직 같은... 느낌을 받았습니다.
네트워크 전공 시간에 배운 내용을 인프라를 우선 돌아가게 구축하고 추후에 공부하면서 깨닫는 부분이 많았던 것 같습니다.

아키텍처

우선 제가 크게 3가지로 나누어서 진행했습니다.

1. 프론트엔드 CI/CD 파이프라인 구축

2. 백엔드 CI/CD 파이프라인 구축

3. 배포 환경과 테스트 환경을 분리

또한 사용한 스택은 정리하자면

백엔드: ECS (Fargate) + Amazon ECR + ALB
데이터: Amazon RDS (MySQL)
이미지 저장소: AWS S3
CI/CD: GitHub Actions
모니터링: AWS CloudWatch
프론트엔드: Amplify

각 파트에 대해서 설명하면서 자세하게 어떤 이유에서 해당 스택들을 선택하게 되었는지 설명드리겠습니다.

프론트엔드 CI/CD 파이프라인 구축

순서상 프론트엔드 CI/CD 파이프라인 구축을 마지막에 했지만, 제일 처음으로 소개하게 됐네요.

우선 CI/CD란 무엇일까요?

바로 'Continuous Integration(지속적 통합) & Continuous Deployment(지속적 배포) '를 의미합니다.

이를 풀어서 설명하면,

지속적 통합 : 코드 변경 사항을 자주 통합, 자동화된 빌드와 테스트를 통해 코드 품질 보장
지속적 배포 : 코드 변경 사항이 자동으로 배포

를 의미합니다.

왜 CI/CD를 구축할까요?

그 이유를 찾기 위해선 우선 DevOps라는 개념부터 알아야 합니다.

DevOps란 개발(Development)과 운영(Operation)의 합성어로,

소프트웨어 개발과 운영 팀 간의 효율적인 협업을 목표로 하는 문화를 지칭합니다.

이는 결론적으로 효율적인 협업을 목표로 하며, 기업의 거대화했을 때 나타나는 팀 간의 벽인 사일로와 정반대의 개념입니다.

이런 '효율적인 협업'이라는 목표를 달성하기 위해서 DevOps는 크게 4가지 원칙을 지킵니다.

자동화 : 빌드, 테스트, 배포와 같은 작업을 자동화하여, 반복 작업을 줄입니다.
CI/CD : 코드 변경 사항을 자동으로 통합하고 테스트해서, 배포 과정에서의 오류를 줄입니다.
모니터링과 피드백 : 서비스 상태를 실시간으로 모니터링하고, 문제를 해결합니다.
협업과 소통 : 개발과 운영 팀이 공통의 목표를 달성하기 위해서 소통합니다.

아무튼 돌고 돌아서 설명한 효율적인 협업을 지향하는 DevOps라는 문화를 정착시키기 위해서 쓰이는 도구가 바로 CI/CD입니다.

이를 통해서 코드 변경 사항이 자동으로 통합되고 테스트되기 때문에 팀원 간의 협업이 쉬워지고, 이를 통해 빠르게 배포하여 서비스에 빠르게 적용할 수 있습니다.

그래서 결론적으로 프로젝트의 목표 달성을 위한 팀 전체의 생산성을 극대화할 수 있습니다.

프론트엔드의 경우, AWS Amplify와 S3+CloudFront를 사용해 직접 하는 방법 두 가지 중에서 고민했습니다.

사실 Amplify 역시 S3 기반의 환경에 정적 리소스를 업로드하고, CloudFront를 통해 배포하는 것 똑같지만 이를 직접 설정하지 않고 자동으로 처리해 준다는 차이가 있습니다.

S3와 CloudFront에 대해서 간략히 설명하자면,

S3는 Simple Storage Service의 약자로, 이미지, 동영상 그리고 HTML/CSS/JS와 같은 정적 리소스를 저장하고 관리합니다.

또한 특정 버킷을 웹 호스팅 용도로 설정하고 퍼블릭 액세스를 허용하면 HTTP/HTTPS를 통해 웹 콘텐츠를 제공할 수 있습니다.

그리고 CloudFront는 AWS의 CDN으로, CDN는 콘텐츠 전송 네트워크를 의미하며 S3와 같은 origin에서 데이터를 가져와 사용자와 가장 가까운 엣지 서버를 통해 콘텐츠를 제공함으로써 latency를 최소화하는 기능을 합니다.

또한 캐싱도 하여 자주 액세스 되는 콘텐츠를 엣지 서버에 저장하여 원본 서버에서 I/O 하는 작업 자체를 줄여 성능 또한 향상합니다.

아무튼! Amplify를 통한 방법과 직접 S3+CloudFront를 설정하는 방법 각각의 장점은

Amplify의 경우 CI/CD 파이프라인이 내장되어 있어 Git 레포지토리만 연동하면 코드 변경 사항이 자동으로 빌드되고 배포되어 큰 설정 없이 진행될 수 있다는 장점이 있습니다.
그리고 S3+CloudFront의 경우 좀 더 배포 환경을 세부적으로 설정할 수 있고, 비용을 좀 더 절약할 수 있다는 장점이 있습니다.

결론적으로 프론트엔드는 Amplify를 통해서 구현했습니다.

그 이유는, 백엔드의 경우 첫 주차에 Github actions + docker + ECR + ECS + Route53 등등을 통해서 CI/CD 구축을 완료했었는데, 프론트엔드의 경우 프로젝트 마지막 주에 CI/CD 구축을 하자는 팀원 간의 합의가 있었습니다.

마무리하면서 발표도 하고 다양한 것들을 함께 해야 하는 팀장의 역할도 하면서 했던 거라, 최대한 빠르게 배포가 가능한 Amplify를 선택했고, 비용의 경우도 현재는 Ureka에서 팀에게 105만 원을 지원해 줘서 편하게 사용이 가능한 상황이라

비용 < 시간이라는 조건이라고 생각이 들어 Amplify를 선택했습니다.

또한 AWS에서 도메인 구매와 호스팅까지 해주는 Route53을 통해서 filmeet.me 도메인을 통해서 접속할 수 있게 구현을 했습니다.

링크 : https://filmeet.me/

(하지만 여러분이 이 글을 볼 때는, 이미 Ureka의 지원이 끝나 링크가 안 열릴 가능성이 높습니다. 하하)

어려웠던 점

인프라를 세팅하면서, 팀 전체 관리를 하면서, API 개발과 연동, 테스트까지 짧은 프로젝트 기간 내에 진행하느라 우선 기능이 돌아갈 수 있게 구현하고 추후에 학습을 하며 이해하였습니다.

근데 제가 넉넉하게 지원해 주는 지원금 덕분에 백엔드만 배포가 되어있는 환경에서도 filmeet.net에 배포를 하여

api 요청을 https://filmeet.net/~ 이렇게 하게끔 했는데, 나중에 프론트엔드 배포할 때 제대로 이해하지 않고 사용자 지정 도메인을 구매하고 연결하는 과정에서 꼬여서 한참 씨름했던 경험이 있습니다.

또한 실제 프론트엔드 분들의 로컬 환경에서는 import문의 대문자와 소문자가 다르더라고 배포가 되는 반면,

Amplify의 경우 하나라도 철자가 다르면 빌드 에러가 발생해 컨벤션을 지키지 않은 프론트엔드 개발자 분들의 레거시가... 저에게 돌아와... 하나하나 수정하고 빌드하고 하는 과정을 거의 50번은 한 것 같습니다.

그래도 백엔드 CI/CD 구축할 때와 비교해서는 비교적 수월하게 구축한 것 같습니다.

백엔드 CI/CD 파이프라인 구축

처음 사용해 본 AWS라, 첫 주차에 바로 CI/CD 구축을 하기 위해서 목차를 정해서 진행했습니다.

IAM 사용자 생성 및 권한 관리
S3 버킷(이미지 저장용) 생성 및 설정
애플리케이션 컨테이너화 및 ECR 설정
AWS RDS 및 ElasticCache(Redis) 설정
ECS(Fargate) 설정
대상 그룹 및 ALB 설정
오토스케일링 설정
CI/CD 파이프라인 구축
모니터링을 위한 CloudWatch 설정

1. IAM 사용자 생성 및 권한 관리

우선 첫째로, CI/CD 작업 및 AWS 리소스 관리를 위해 전용 IAM 사용자를 생성했습니다.

또한 최소 권한 원칙에 따라, 아래와 같은 권한을 부여했습니다.
(근데 사실 개발할 때는 AdminFullAccess로 다 풀어놓고 나중에 배포할 때 세팅했던 건 안비밀입니다 )

AmazonEC2ContainerRegistryFullAccess: ECR 접근
AmazonECS_FullAccess: ECS 및 클러스터 관리
CloudWatchFullAccess: 로그와 모니터링 데이터 관리
RDSFullAccess: RDS 관리
S3FullAccess: 이미지 파일 저장 및 관리

2. S3 버킷(이미지 저장용) 생성 및 설정

그다음으로는, 애플리케이션에서 사용하는 용량이 큰 이미지 파일을 저장하고 실제 RDS에서는 url 형태로 저장하기 위해서 S3 버킷을 생성했습니다.

3. 애플리케이션 컨테이너화 및 ECR 설정

그 이후, 애플리케이션을 Docker 컨테이너로 빌드하고,

자바 프로젝트의 경우 간단하게 빌드 및 푸시할 수 있는 라이브러리인 Jib 플러그인을 통해 ECR로 푸시했습니다.

그리고 AWS의 ECR 레지스트리를 생성하여, Jib 플러그인을 통해 푸시한 Docker 이미지를 저장하고,

ECR에 최신(LATEST) 이미지 파일이 업로드되면 자동으로 ECS에 정의한 태스크가 배포되도록 설정했습니다.

4. AWS RDS 및 ElasticCache(Redis) 설정

또한 팀원들과 동일한 DB를 사용하기 위해서 AWS에 RDS(MySQL) 인스턴스와 ElasticCache(Redis)를 생성했습니다.

그리고 거기에 추가로, 로컬에서도 지속적으로 ElastiCache를 확인할 수 있게 확인용 EC2를 SSL 터널용으로 열어 연결했습니다.

왜냐면, ElastiCache는 AWS의 인스턴스에서만 접근이 가능하기 때문에 로컬에서 바로 접근하면 연결이 되지 않았기 때문입니다.

5. ECS(Fargate) 설정

이후에 ECS 클러스터를 생성하여, Fargate를 사용해 서버리스 컨테이너 실행 환경을 구성했습니다.

배포하는 다양한 방식이 있지만 ECS 그리고 Fargate를 선택한 이유는

프론트엔드 배포할 때 언급한 시간이 가장 중요한 자원이었기 때문인 게 첫 번째 이유였고,

실제 유저들에게 배포되는 서비스가 아니기 때문에 사용량에 따라 비용이 결정되는 ECS의 Fargate 모드가 오히려 고정적으로 비용이 지출되는 EC2보다 비용 절감에 이득일 거라 생각한 점이 두 번째 이유였습니다.

각설하고, 태스크 정의에서 Docker 이미지를 설정하고 새 컨테이너 배포 시 무중단 배포(Blue/Green) 방식 설정하였습니다.

무중단 배포(Blue/Green) 방식이란?

기존 버전(Blue)과 새로운 버전 (Green)을 동시에 운영하여 서비스 중단 없이 배포를 진행하는 방식입니다.

마치 과거에 DB 관점에서 고가용성을 보장하기 위해서 제가 Master-Slave 아키텍처로 DB를 구성한 적이 있는데, 이와 비슷하게 서버 관점에서 고가용성을 보장하기 위한 전략입니다.

(Master-Slave 아키텍처 관련글)

https://jun10920.tistory.com/43

[Now, Here] 성능 테스트_인덱싱과 트랜잭션 관리 최적화

성능 테스트 가이드 시리즈 / 클릭 시 이동1. 성능 테스트_성능 목표 잡기2. 성능 테스트_HikariCP의 연결 최대 풀 설정3. 성능 테스트_Caffeine 캐시 설정 및 적용4. 성능 테스트_인덱싱과 트

jun10920.tistory.com

6. 대상 그룹 및 ALB 설정

추가로, 로드밸런싱을 위한 ALB 설정과, ALB에서 트래픽을 ECS의 컨테이너로 전달하기 위한 대상 그룹을 설정했습니다.

구현 당시에는 블로그와 AI를 통해서 로드밸런싱이라는 목적 달성을 위해 급하게 구현했는데, 추후에 직접 손으로 그려가며 학습하니 이해가 되었습니다.

위 필기를 요약하자면 아래와 같습니다.

Route 53은 도메인 요청을 ALB로 전달.
ALB는 트래픽을 다중 서브넷(AZ)으로 분산.
대상 그룹(Target Group)은 헬스 체크를 통해 정상 서버를 식별.
트래픽은 정상 서버로만 전달되어 안정성을 유지.

또한 SSL 인증서를 통해서 HTTPS를 활성화시켜서 사용하였습니다.

7. 오토스케일링 설정

그다음으론, 오토 스케일링을 설정하여 트래픽에 따라 컨테이너를 자동으로 확장/축소하였습니다.

스케일링 조건으론 CPU 사용률을 70%가 초과하면 컨테이너를 2개로 확장하게 설정하였습니다.

사실 꼭 필요한 설정은 아니었지만, 유레카에서 오토스케일링을 배웠으니 이를 사용해 보는 것에 의미를 두며 설정했습니다.

8. CI/CD 파이프라인 구축

이후엔 CI/CD 파이프라인 구축을 위해서 workflow 파일 작성을 했습니다.

이때 GitHub Actions를 활용해 코드를 빌드, 테스트, 배포를 진행했습니다.

name: Deploy on PR Merge to Main

on:
  pull_request:
    types: [closed]  # PR이 닫힐 때 실행
    branches:
      - main  # main 브랜치에 머지될 때 작동
jobs:
  deploy:
    if: >
      (github.event_name == 'push') ||
      (github.event_name == 'pull_request' && github.event.pull_request.merged == true)
    runs-on: ubuntu-latest  # GitHub Actions 실행 환경 설정

    # 작업 디렉토리 기본값 설정
    defaults:
      run:
        working-directory: filmeet  # 'filmeet' 디렉토리에서 명령 실행

    # 전역 환경 변수 설정
    env:
      AWS_REGION: ap-northeast-2  # AWS 리전 설정

    steps:
      # 1️⃣ 저장소 체크아웃
      - name: 소스 코드 체크아웃
        uses: actions/checkout@v3

      # 2️⃣ AWS 자격 증명 설정
      - name: AWS 자격 증명 구성
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}  # AWS Access Key ID (GitHub Secrets에서 가져옴)
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}  # AWS Secret Access Key (GitHub Secrets에서 가져옴)
          aws-region: ${{ env.AWS_REGION }}  # AWS 리전 설정

      # 3️⃣ Java 17 설치
      - name: Java 17 설정
        uses: actions/setup-java@v3
        with:
          java-version: '17'  # 사용하려는 Java 버전
          distribution: 'temurin'  # Java 배포판 설정

      # 4️⃣ Gradle 실행 권한 부여
      - name: Gradle 실행 권한 설정
        run: chmod +x ./gradlew  # Gradle Wrapper에 실행 권한 부여

      # 5️⃣ Amazon ECR에 로그인
      - name: Amazon ECR 로그인
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1  # ECR에 로그인하여 인증 토큰 획득

      # 5️⃣ Docker 이미지 빌드 및 푸시
      - name: Docker 이미지 빌드 및 푸시
        run: ./gradlew jib --no-build-cache
        env:
          AWS_ECR_PASSWORD: ${{ steps.login-ecr.outputs.ecr-login-password }}
          SPRING_DATASOURCE_URL: ${{ secrets.SPRING_DATASOURCE_URL }}
          SPRING_DATASOURCE_USERNAME: ${{ secrets.SPRING_DATASOURCE_USERNAME }}
          SPRING_DATASOURCE_PASSWORD: ${{ secrets.SPRING_DATASOURCE_PASSWORD }}
          SPRING_DATA_REDIS_HOST: ${{ secrets.SPRING_DATA_REDIS_HOST }}
          SPRING_DATA_REDIS_PORT: ${{ secrets.SPRING_DATA_REDIS_PORT }}
          SPRING_CLOUD_AWS_S3_BUCKET: ${{ secrets.SPRING_CLOUD_AWS_S3_BUCKET }}
          SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_GOOGLE_CLIENT_ID: ${{ secrets.SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_GOOGLE_CLIENT_ID }}
          SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_GOOGLE_CLIENT_SECRET: ${{ secrets.SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_GOOGLE_CLIENT_SECRET }}
          SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_KAKAO_CLIENT_ID: ${{ secrets.SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_KAKAO_CLIENT_ID }}
          SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_KAKAO_CLIENT_SECRET: ${{ secrets.SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_KAKAO_CLIENT_SECRET }}
          SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_NAVER_CLIENT_ID: ${{ secrets.SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_NAVER_CLIENT_ID }}
          SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_NAVER_CLIENT_SECRET: ${{ secrets.SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_NAVER_CLIENT_SECRET }}
          KOBIS_APIKEY: ${{ secrets.KOBIS_APIKEY }}
          KMDB_APIKEY: ${{ secrets.KMDB_APIKEY }}
          OMDB_APIKEY: ${{ secrets.OMDB_APIKEY }}
          FIREBASE_CONFIG: ${{ secrets.FIREBASE_CONFIG }}
          JWT_SECRET: ${{ secrets.JWT_SECRET }}
          JWT_VALIDITY_ACCESS: ${{ secrets.JWT_VALIDITY_ACCESS }}
          JWT_VALIDITY_REFRESH: ${{ secrets.JWT_VALIDITY_REFRESH }}
          FRONT_REDIRECT_URL: ${{ secrets.FRONT_REDIRECT_URL }}

      # 6️⃣ ECS 서비스 업데이트
      - name: ECS 서비스 업데이트
        run: |
          aws ecs update-service \
            --cluster filmeet-cluster \
            --service filmeet-service \
            --force-new-deployment \
            --deployment-configuration maximumPercent=200,minimumHealthyPercent=75 \
            --health-check-grace-period 300

workflow 파일은 구체적으로 설명하자면,

(1) 이벤트 트리거 설정

on: pull_request: PR(Pull Request)이 닫히고 main 브랜치에 병합되었을 때 워크플로우가 실행

(2) AWS 자격 증명 구성

AWS 서비스와 상호작용하기 위해 aws-actions/configure-aws-credentials를 사용하여 AWS Access Key와 Secret Key를 설정
리전은 ap-northeast-2 (서울 리전)으로 설정하여 지연 시간을 최소화

(3) Java 17 및 Gradle 설정

Java 17: 애플리케이션은 최신 Java LTS 버전인 Java 17을 기반으로 작성
actions/setup-java를 통해 실행 환경에 필요한 Java 버전을 설치
Gradle Wrapper 권한 부여: Gradle 명령 실행을 위한 권한을 추가하여 워크플로우가 원활히 진행되도록 설정

(4) Docker 이미지 빌드 및 푸시

Amazon ECR: Docker 이미지를 Amazon ECR에 업로드해 ECS에서 사용할 수 있도록 설정
Gradle Jib 플러그인: ./gradlew jib 명령을 사용해 Docker 이미지를 빌드
환경 변수(Secrets)를 활용하여 민감한 정보를 안전하게 관리

(5) ECS 서비스 업데이트

force-new-deployment: 기존 컨테이너를 교체하여 새 이미지로 배포
maximumPercent=200, minimumHealthyPercent=75: 배포 중 최소 75%의 컨테이너가 가용 상태를 유지하도록 설정
health-check-grace-period=300: 새로운 컨테이너가 시작된 후 5분간 상태를 확인할 유예 시간 설정

초반에 헬스 체크를 할 유예 시간을 너무 짧게 줬더니, 계속 배포 실패가 나와서 정말 한참을 배포했던 것 같습니다...

결론적으로 수많은 설정 변경과 노가다를 하였지만,

단순히 5분간 상태를 확인하는 설정 하나만 하였더니 멀쩡하게 배포를 성공하였습니다.

9. 모니터링을 위한 CloudWatch 설정

마지막으로 CloudWatch에 배포한 ECS 서비스의 로그를 전송하여 실시간을 애플리케이션 상태를 확인하도록 설정했습니다.

성과

결론적으로, 위와 같은 과정을 통해서 세 가지 성과를 얻었습니다.

무중단 배포: Blue/Green 방식과 ALB를 통해 사용자에게 끊김 없는 서비스 제공
트래픽 최적화: 오토스케일링과 ALB로 성능과 비용을 모두 최적화
자동화와 안정성 강화: GitHub Actions와 CloudWatch로 CI/CD와 모니터링이 완벽히 통합

배포 환경과 테스트 환경을 분리

마지막으로, 성능테스트를 위해서 배포 환경과 테스트 환경을 분리했습니다. 자세한 내용은 아래 글을 참고해 주시면 감사하겠습니다.

https://jun10920.tistory.com/48

[Filmeet] 24초에서 0.1초로: DB 성능 최적화의 여정 _ Query Plan 분석 / 커넥션 풀 조정 심화

오랜만입니다.계속 취준, 학업, 부트캠프까지 병행하다 보니 블로그에 글을 많이 못 올렸는데매일 300명 이상의 분들이 읽어주셔서 조만간 조회수 30000을 달성하겠네요. 감사합니다 :>벌써 6월 11

jun10920.tistory.com

이때 docker를 통해서 쉽게 pinpoint를 설정하려고 했지만, 오히려 정확하게 docker를 이해하지 못한 채 디버깅을 하려 하니 계속 먼 길을 돌아가는 기분이었습니다.

그래서 그냥 ec2 인스턴스에 pinpoint web, collector, hbase 등등을 직접 다운로드하여 세팅하였더니 훨씬 빠르게 세팅을 완료했던 경험이 있습니다.

역시 제대로 이해하지 않고 사용하면, 에러가 발생했을 때 대응을 못하는 경우가 생겨 오히려 비효율적인 경우가 있는 것 같습니다.

마무리하며

이번 Filmeet 프로젝트를 통해 단순히 기술을 사용하는 것을 넘어 서비스를 운영하는 데 필요한 인프라 구축과 DevOps의 중요성을 몸소 경험할 수 있었습니다. 특히, AWS의 다양한 서비스를 활용하면서 클라우드 기반의 아키텍처 설계와 CI/CD 파이프라인 구축이 얼마나 서비스의 생산성을 높이는지 깨달았습니다.

배운 점

DevOps와 협업의 중요성:
- 개발과 운영이 긴밀히 연결된 DevOps 문화를 실천하면서, 팀원들과의 협업이 얼마나 중요한지 실감했습니다.
- CI/CD 파이프라인을 통해 인당 배포 시간을 1시간 -> 5분 내로 줄이면서 얼마나 효율적인지 체감했습니다.
기술 이해의 깊이:
- 처음에는 "작동하는 것"에 초점을 두었지만, 시간이 지날수록 "왜 그렇게 작동하는지"를 이해하는 것이 중요하다는 것을 깨달았습니다.
  - 특히 디버깅을 하는 과정에서 이해하지 못하고 사용한 대가를 톡톡히 치렀습니다.
  - 물론 시간이 여유롭지 못한 상황에서 어쩔 수 없는 선택이라고 생각하지만, 조금이라도 여유를 가질 수 있다면 확실하게 이해를 하고 사용을 하는 것을 목표로 하려고 합니다.
실수로부터의 학습:
- 잘못된 설정으로 인해 수차례 배포가 실패했지만, 이 과정에서 문제를 진단하고 해결하는 능력을 키울 수 있었습니다.
- "실수는 성장의 기회"라는 말이 얼마나 사실인지 다시 한번 느꼈습니다.

아쉬운 점

짧은 프로젝트 기간 동안 많은 것을 구현하려다 보니, 기술의 깊이 있는 학습보다는 "작동하게 만드는 것"에 초점이 맞춰졌습니다.
프론트엔드 CI/CD 구축 과정에서 Amplify를 선택하며 시간은 절약했지만, S3와 CloudFront를 직접 설정하는 경험을 놓친 점은 조금 아쉽습니다.

앞으로의 계획

프로젝트를 통해 경험한 AWS 서비스와 DevOps 프로세스를 더 깊이 학습하고, 배운 내용을 정리하여 다른 사람들에게도 공유하고 싶습니다.
이후 프로젝트에서는 기능 구현을 넘어, 코드 품질과 아키텍처의 최적화까지 신경 쓰는 개발자로 성장하고 싶습니다.

Filmeet 프로젝트를 함께한 팀원들에게도 감사의 마음을 전하고 싶습니다.
각자의 역할을 충실히 해낸 덕분에 프로젝트를 성공적으로 마무리할 수 있었습니다.

프로젝트를 진행하며 수많은 도전과 장애물을 만났지만, 그 모든 과정이 성장과 배움의 계기가 되었습니다.
이 글을 통해 AWS 서비스와 DevOps를 처음 접하거나 CI/CD 파이프라인을 구축하는 분들에게 참고 자료가 되었으면 합니다. 제가 겪었던 어려움과 해결 과정이 다른 분들에게 도움이 되길 바랍니다.

[Filmeet] 24초에서 0.1초로: DB 성능 최적화의 여정 _ Query Plan 분석 / 커넥션 풀 조정 심화

겨울단추 — Wed, 18 Dec 2024 02:39:56 +0900

오랜만입니다.
계속 취준, 학업, 부트캠프까지 병행하다 보니 블로그에 글을 많이 못 올렸는데
매일 300명 이상의 분들이 읽어주셔서 조만간 조회수 30000을 달성하겠네요. 감사합니다 :>
벌써 6월 11일에 시작한 유레카 1기의 수료를 일주일 앞두고 있습니다.
최종 프로젝트에서 훌륭한 백엔드 팀원들에게 많이 배우면서, 짧은 기간 동안 많은 성장이 있었습니다.
데브옵스 역할을 맡아, CI/CD 파이프라인을 구축하고 다양한 툴들을 세팅한 경험도 무척 좋았습니다.

하지만 오늘 글의 주제는, 성능 테스트를 통한 병목지점 최적화 얘기입니다.
연속으로 세 프로젝트에서 성능 테스트를 진행했지만 감히 예상하건대 이번 최적화가 가장 많은 성능개선을 이룬 것 같습니다.
잘 읽어주시면 감사하겠습니다.

성능목표 잡기

앞선 성능 테스트 글에서도, 어떤 성능 테스트를 하더라도 성능 목표를 우선적으로 잡아야 한다고 언급한 적이 있습니다.

[Now, Here] 성능 테스트_성능 목표 잡기

안녕하세요!이전에 언급했던 것처럼 Now, Here 글로 다시 찾아왔습니다.현재 출시가 얼마 남지 않았고, 대부분의 기능 구현은 완료한 상태입니다.그래서 성능 테스트를 통해 웹 서비스의 성능을

jun10920.tistory.com

이번 최적화 과정에서도 팀원과 논의를 하고,

추가로 유플러스 현업 개발자 분과의 주기적인 멘토링 시간에도 이에 대한 조언을 받아서 성능 목표를 결정했습니다.

처음엔 이전 글에 적혀있는 것처럼,

TTFB (Time To First Byte) 기준으로 평균 응답시간이 3초 이내로 들어오는 것을 목표로 했습니다.

그 근거로는 이전 글에 적혀있는 것처럼 아래의 통계 내용이 있기 때문입니다.

주요 통계
- 모바일 웹사이트 방문자의 53%는 웹페이지 로딩에 3초 이상 걸리면 해당 사이트를 떠납니다.
- 평균적으로 모바일 사이트의 로딩 시간은 3G 연결에서 19초, 4G 연결에서 14초입니다.
로딩 속도의 영향
- 5초 내에 로딩되는 모바일 사이트는 19초가 걸리는 사이트에 비해 다음과 같은 이점이 있습니다:
  - 25% 더 높은 광고 가시성
  - 70% 더 긴 평균 세션 시간
  - 35% 더 낮은 이탈률
- 페이지 로딩 시간이 1초에서 3초로 증가하면 이탈 확률이 32% 증가합니다.
사용자 기대치
- 인터넷 사용자의 약 50%는 웹페이지 로딩 시간이 2초 미만이기를 기대합니다.
- 성능이 좋지 않은 경험을 한 사용자의 약 80%는 해당 페이지를 영구적으로 피하고 다시 방문하지 않습니다.

하지만 실제 현업에 계신 멘토님의 조언을 들은 결과,

유플러스 측에선 목표를 평균 응답시간을 모두 0.1s 내로 받는 것으로 한다고 하셨습니다.

그래서 다소 어려운 목표라고 생각했지만, 저희 역시 평균응답시간 0.1s를 성능 목표로 잡았습니다.

성능테스트 환경 및 방법

환경

APM : Pinpoint

부하테스트 툴 : Postman의 Run collection test 기능(제한적으로 유료)

APM 툴로는 일반적으로 Grafana나, 프로메테우스를 주로 사용합니다.

20년 이상의 경력을 가지신 네이버 출신 멘토님의 다른 툴들에 비해 추천한다는 조언에 Pinpoint를 사용하기로 했습니다.

프로메테우스 + 그라파나 조합과 비교해서 아래와 같은 차이점이 있습니다.

기능	Pinpoinit	Grafana + Prometheus
목적	애플리케이션 성능 모니터링 및 추적	시계열 데이터 시각화 및 메트릭 모니터링
분산 추적	지원 (트랜잭션 추적)	Prometheus 자체로는 불가 (Jaeger 같은 추가 도구 필요)
설치 및 설정	에이전트 설치만으로 가능	Prometheus + Grafana 설정 필요
실시간 모니터링	상세한 트랜잭션 및 리소스 모니터링	메트릭 기반 시계열 데이터 모니터링
데이터 수집 및 저장	자동으로 애플리케이션 메트릭 및 로그 수집	Prometheus는 메트릭 수집, Grafana는 시각화만 담당
개발 언어	Java, PHP	언어 제한 없음
시스템 분석	트랜잭션 병목 파악에 강점	시스템 리소스 수준 메트릭 파악에 강점

이중 아래와 같은 경우 Pinpoint를 사용하는 것을 더 추천하기에 최종적으로 Pinpoint를 사용하기로 했습니다.

Pinpoint를 사용하면 좋은 경우

분산 시스템에서 트랜잭션 단위로 병목을 분석해야 할 때
Java 또는 PHP 기반 애플리케이션을 사용 중일 때
간편한 설치 및 빠른 도입이 필요할 때

다음으로는, 테스트 환경을 고민했습니다.

테스트 환경을 구성하는 방법에 대해서는 세 가지 선택지가 있었습니다.

부하 테스트 실행 환경
- (1) AWS에 모든 부하 테스트 구성(부하테스트 툴, Spring 서버, RDS)을 실행.
  - 장점: 실제 AWS 환경과 동일한 조건에서 테스트.
  - 단점: 높은 비용, 운영 데이터와 테스트 데이터 간 혼란 가능성.
- (2) 로컬에서 Spring 서버 실행 + AWS에 부하테스트 툴, RDS 구성.
  - 장점: 비용 절감, 효율적인 협업 가능.
  - 단점: 테스트의 일부는 네트워크 환경을 반영하지 못함.
- (3) 로컬에 모든 테스트 환경 구성.
  - 장점: 비용 없음, 간단한 설정.
  - 단점: 네트워크 및 실제 운영 환경과의 괴리, 테스트 데이터 공유 어려움.

또한 Pinpoint 설치 역시 2가지 방법이 있었습니다.

Pinpoint 배포 위치

로컬에 설치.
- 장점: 비용 없음, 간단한 설정.
- 단점: 팀원 간 협업 어려움, 중앙 집중 데이터 수집 불가.
AWS에 설치.
- 장점: 팀원이 공유할 수 있는 중앙 집중형 모니터링 환경 제공.
- 단점: EC2 및 HBase 리소스 사용으로 비용 발생.

결론적으로, 돈을 유레카에서 지원받고 있는 상황이지만 ECS(Fargate)가 사용량에 비례해서 지불하는 금액이 올라가는 방식이기에 괜히 수십 번 성능테스트 하는 상황에서 예상치 못한 금액이 나올 것 같아 결론적으로 아래와 같이 설정하게 되었습니다.

최종 설계:

AWS에 부하테스트, Pinpoint, 테스트용 RDS를 구성하고, 각자의 로컬에서 Spring 서버를 실행하여 부하 테스트를 수행

설계의 이유:

비용 효율성:
- 로컬에서 Spring 서버를 실행함으로써 ECS(Fargate) 사용 비용을 절감.
- AWS의 공용 리소스(부하테스트, Pinpoint, RDS)는 최소한의 비용으로 유지.
협업 및 중앙 관리:
- AWS RDS와 Pinpoint를 통해 중앙에서 데이터를 관리하며, 모든 개발자가 동일한 환경에서 테스트 가능.
- Pinpoint Web을 활용해 실시간 트랜잭션 흐름과 병목 지점 분석 가능.
테스트 데이터 분리:
- 테스트용 RDS를 별도로 구성하여 운영 데이터와 테스트 데이터를 철저히 분리.
- 테스트 완료 후 데이터를 초기화하거나 삭제하여 관리 용이.
확장 가능성:
- 추후 팀 전체의 Spring 서버를 AWS ECS로 옮기거나, AWS 리소스를 확대하여 더 높은 트래픽 테스트 가능.

AWS에 테스트용 RDS나 다른 세팅을 하는 것은 쉬웠으나, Pinpoint를 세팅하는 것은 매우 매우 매우 오래 걸렸습니다.

하지만 이 과정까지 적으면 너무 글이 길어질 것 같아 넘기겠습니다.

성능테스트는 아래와 같은 절차로 진행했습니다.

성능 테스트 방법

API 요청 후 핀포인트로 확인
병목지점 확인 / 응답시간 확인
SQL 문 확인
DB 콘솔 창에 SQL 문 실행
- 여러 번 반복해서 응답시간 확인
- EXPIAIN, EXPAIN ANALYZE로 실행 계획 확인
확인한 결과를 통해서 최적화
- EXPIAIN, EXPAIN ANALYZE로 실행 계획 결과 재확인
API 요청해서 핀포인트로 최적화된 결과 재확인

처음 결과

사실 맨 처음에 데이터를 적당히 넣은 상태에서 부하테스트를 했을 때는 상당히 괜찮은 성능을 보였습니다.

하지만 이전에 데이터를 많이 넣은 상태에서 부하테스트를 진행하면 다른 결과를 보인 적이 있다는 팀원 분의 의견을 반영하여,

각 엔티티에 100만 개의 데이터를 넣은 상태에서 다시 부하테스트를 진행했습니다.

그리고 그 결과는 다음과 같습니다.

기존에 데이터가 없었을 때 > 100만 데이터 삽입 후
총 요청 수 : 약 5만 > 1019

평균 응답 시간 : 약 3초 > 24초

에러율 : 0% > 56%

이와 같이 상당히 결과가 안 좋게 나왔습니다.

특히 응답시간 worst 5개의 평균응답시간을 보면 약 30초로, 정말 말도 안 되는 성능을 보여줬습니다.

DB 커넥션 풀 조정

대부분의 에러를 보면 DB 커넥션 풀이 부족해서 타임아웃이 발생해 생기는 에러가 대부분이었습니다.

그래서 과거에 기본 DB 커넥션 풀인 10에서 20으로 늘리고 확인을 했습니다.

HikariCP Connection Pool 설정

maximum-pool-size: 20
- 기본값: 10
- 효과: 최대 동시 커넥션을 20개까지 지원. 트래픽이 많아도 커넥션 부족으로 인한 요청 대기 시간을 줄임.

결과

에러 발생률은 늘었지만, 응답시간이 24초에서 13초로 약 절반정도 줄어들음
최대 응답시간 api들도 30초에서 → 20초로 줄어들음

하지만 계속 에러가 발생을 하는 상황이어서, DB 커넥션 풀을 약 30~50씩 증가시키면서 계속 테스트를 진행했습니다.

그래서 여러 번의 테스트를 거친 결과, 결론적으로 200으로 늘렸을 때 에러가 발생하지 않고 끝까지 진행할 수 있었습니다.

결론적으로 초기 테스트 데이터 대비 아래와 같은 결과가 있었습니다.

총 요청 수 : 1019 -> 1913 약 87.7% 증가

평균 응답 시간 : 24초 -> 5초 약 79.2% 단축

에러율 : 56% -> 0% 100% 개선

초기 테스트 결과 치고는 많은 성능 향상이 있었지만, 아직 처음 성능 목표로 잡은 0.1초까지는 길이 한참 남았습니다.

하지만 아직 Pinpoint를 통한 각 API의 메서드 단위까지 응답시간을 나누어 분석하고 최적화하는 과정은 시작도 안 했습니다.

이어서 팀원들과 나누어서 Response time worst API 목록들을 하나씩 최적화하기로 했습니다.

최적화한 API 목록으로는

지금 뜨는 리뷰 조회 API (복합 인덱스)

영화 개봉 예정일 쿼리 (단일 인덱스)

영화 제목 검색 쿼리 (FULLTEXT INDEX)

개인 맞춤형 추천 영화 리스트 조회 (단일 인덱스)

컬렉션 제목 검색 API(Generated Column, FULLTEXT INDEX, 필요한 인덱스만 Query)

등등..

다양한 API를 개선했지만 대부분의 병목의 원인과 최적화 절차는 비슷했고,

그중 가장 많은 과정을 거친 컬렉션 제목 검색 API 최적화 과정을 중점적으로 설명하겠습니다.

Pinpoint와 Query Plan 분석을 통한 개선

API 요청 후 핀포인트로 확인

총 응답시간: 1,464 ms

executeQuery 쿼리 시간: 1,234 ms

즉 결과에 분석하면 쿼리 실행이 가장 큰 병목 구간임을 확인할 수 있습니다.

해당 부분의 SQL문을 확인하고, 콘솔에서 5번 정도 실행하여 평균 시간을 확인했습니다.

[2024-12-14 16:33:25] 0 rows retrieved in 1 s 648 ms (execution: 1 s 274 ms, fetching: 374 ms)
[2024-12-14 16:33:38] 0 rows retrieved in 1 s 375 ms (execution: 1 s 262 ms, fetching: 113 ms)
[2024-12-14 16:33:41] 0 rows retrieved in 1 s 627 ms (execution: 1 s 270 ms, fetching: 357 ms)
[2024-12-14 16:33:44] 0 rows retrieved in 1 s 472 ms (execution: 1 s 281 ms, fetching: 191 ms)
[2024-12-14 16:33:46] 0 rows retrieved in 1 s 315 ms (execution: 1 s 248 ms, fetching: 67 ms)

각 실행 시간 합계: 1.648, 1.375, 1.627, 1.472, 1.315초

평균 총 실행 시간: 약 1.487초

위에서 API를 통해 확인했던 것과 비슷하게, 단순히 쿼리만 입력해도 걸리는 시간이 1회당 평균적으로 1.487초 이상 걸렸습니다.

Query Plan을 통한 분석

MySQL의 EXPIAIN, EXPAIN ANALYZE를 통해 쿼리 실행 계획을 더 자세히 분석할 수 있습니다.

Query Plan이란?
- DBMS가 SQL 쿼리를 처리하기 위해 사용하는 실행 계획으로, 쿼리 실행에 대한 단계를 보여주며 각 단계에서 필요한 리소스와 처리 시간을 단계적으로 보여준다.

Query Plan 분석과 최적화를 통해 쿼리 실행에 필요한 최소한의 리소스를 사용하면서 최적의 성능을 제공할 수 있습니다.

-> Limit: 11 row(s)  (cost=520425 rows=11) (actual time=1297..1297 rows=0 loops=1)
    -> Nested loop inner join  (cost=520425 rows=1.59e+6) (actual time=1297..1297 rows=0 loops=1)
        -> Sort: c1_0.created_at DESC  (cost=161895 rows=1.59e+6) (actual time=1297..1297 rows=0 loops=1)
            -> Filter: ((c1_0.is_deleted = 0) and (lower(c1_0.title) like <cache>(lower(concat('%','제목','%'))) escape '') and (c1_0.member_id is not null))  (cost=161895 rows=1.59e+6) (actual time=1297..1297 rows=0 loops=1)
                -> Table scan on c1_0  (cost=161895 rows=1.59e+6) (actual time=0.0766..736 rows=1.6e+6 loops=1)
        -> Single-row index lookup on u1_0 using PRIMARY (member_id=c1_0.member_id)  (cost=0.251 rows=1) (never executed)

해당 Query Plan을 분석한 내용은 다음과 같습니다.

Table Scan on collection
- 작업 내용: collection 테이블의 모든 행을 읽습니다.
- 실제 소요 시간: actual time=0.0766ms.. 736ms 이 단계에서 약 736ms 동안 전체 테이블을 읽었습니다.
- 결론: Full Table Scan으로 인해 테이블 전체를 스캔하는 데 736ms가 소요되었습니다.
WHERE 조건과 정렬 작업 (Filter + Sort)
- 작업 내용:
  - WHERE 조건:
  - (c1_0.is_deleted = 0)
  - (lower(c1_0.title) like '% 제목%')
  - (c1_0.member_id IS NOT NULL)
- 실제 소요 시간:Table Scan이 끝난 후부터 정렬이 완료될 때까지 걸린 시간 1297ms - 736ms = 약 561ms
- 병목 원인: 조건이 전체 데이터를 대상으로 작동하므로 시간 소모가 큼.

시간 계산 요약

전체 테이블 읽기 (Full Table Scan): 736ms
WHERE 조건 평가 + 정렬: 561ms
총 소요 시간 = 736ms + 561ms = 1297ms

Query Plan 분석을 통해 알 수 있듯이,

현재 테이블을 Full Table Scan 하고 정렬하는 부분에서 지연시간이 발생하는 것을 알 수 있습니다.

이를 하나씩 최적화하면서 확인하였습니다.

LOWER 문제 해결 (Generated Column과 인덱스 추가)

Generated Column 추가:
- LOWER(title)의 결과를 저장할 lower_title 컬럼을 생성하고, 인덱스를 추가합니다.
```
ALTER TABLE collection
ADD lower_title VARCHAR(255) GENERATED ALWAYS AS (LOWER(title)) STORED;
```
Generated Column에 인덱스 추가:
- lower_title에 인덱스를 생성하여 WHERE 조건을 최적화합니다.
```
CREATE INDEX idx_lower_title ON collection (lower_title);
```
쿼리 수정:
- 기존 쿼리에서 LOWER(c1_0.title) 대신 lower_title을 사용합니다.
```
SELECT ...
FROM collection c1_0
WHERE lower_title LIKE '%제목%';
```

Generated colomn이란?
Generated Column은 MySQL 테이블에 있는 다른 컬럼의 값을 기반으로 계산된 값을 저장하거나 계산하는 컬럼입니다.
lower_title 같은 컬럼을 Generated colomn으로 만들어, 값이 추가될 때마다 자동으로 정렬되어 있는 컬럼을 생성해 index를 생성하면 쿼리를 실행할 때마다 정렬을 하지 않아도 됩니다.

결과

-> Limit: 11 row(s)  (cost=342903 rows=11) (actual time=1185..1185 rows=0 loops=1)
    -> Nested loop inner join  (cost=342903 rows=1.59e+6) (actual time=1185..1185 rows=0 loops=1)
        -> Sort: c1_0.created_at DESC  (cost=162152 rows=1.59e+6) (actual time=1185..1185 rows=0 loops=1)
            -> Filter: ((c1_0.is_deleted = 0) and (c1_0.lower_title like '%제목%' escape '') and (c1_0.member_id is not null))  (cost=162152 rows=1.59e+6) (actual time=1185..1185 rows=0 loops=1)
                -> Table scan on c1_0  (cost=162152 rows=1.59e+6) (actual time=0.0736..806 rows=1.6e+6 loops=1)
        -> Single-row index lookup on u1_0 using PRIMARY (member_id=c1_0.member_id)  (cost=0.251 rows=1) (never executed)

쿼리 비용 감소
- 첫 번째 쿼리 비용: 520425
- 두 번째 쿼리 비용: 342903
  → 약 34.1% 비용 감소
실행 시간 개선
- 첫 번째 쿼리 실행 시간: 1297 ms
- 두 번째 쿼리 실행 시간: 1185 ms
  → 약 8.6% 시간 단축

필요한 인덱스만 읽기

이번엔 엔티티의 모든 Column을 읽지 않고, 필요한 인덱스만 읽는 식으로 수정해 결과를 확인했습니다.

-> Limit: 11 row(s)  (cost=342903 rows=11) (actual time=1037..1037 rows=0 loops=1)
    -> Nested loop inner join  (cost=342903 rows=1.59e+6) (actual time=1037..1037 rows=0 loops=1)
        -> Sort: c1_0.created_at DESC  (cost=162152 rows=1.59e+6) (actual time=1037..1037 rows=0 loops=1)
            -> Filter: ((c1_0.is_deleted = 0) and (c1_0.lower_title like '%제목%' escape '') and (c1_0.member_id is not null))  (cost=162152 rows=1.59e+6) (actual time=1037..1037 rows=0 loops=1)
                -> Table scan on c1_0  (cost=162152 rows=1.59e+6) (actual time=0.0702..659 rows=1.6e+6 loops=1)
        -> Single-row index lookup on u1_0 using PRIMARY (member_id=c1_0.member_id)  (cost=0.251 rows=1) (never executed)

쿼리 실행 시간 개선
- 처음 실행 시간: 1297 ms
- 새로운 실행 시간: 1037 ms
  → 약 20% 단축
쿼리 비용 감소
- 처음 비용: 520425
- 새로운 비용: 342903
  → 약 34.1% 비용 감소

개선이 상당히 됐지만, 아직도 쿼리를 실행하는데 1초가 걸리는 문제와 row는 전체를 다 순회하는 문제가 있었다.

Full Text Index 활용

Full Text Index 추가

LIKE 대신 MATCH를 사용하여 검색

SELECT ...
FROM collection
WHERE MATCH(title) AGAINST ('제목' IN NATURAL LANGUAGE MODE);

Full Text Index란?
텍스트 검색 전용:긴 텍스트 데이터(CHAR, VARCHAR, TEXT)에 적합한 인덱스.
일반 인덱스와 달리, 단어 단위로 데이터를 인덱싱하여 검색 속도를 크게 향상.

결과

-> Limit: 11 row(s)  (cost=1.28 rows=1) (actual time=0.0132..0.0132 rows=0 loops=1)
    -> Nested loop inner join  (cost=1.28 rows=1) (actual time=0.0127..0.0127 rows=0 loops=1)
        -> Sort row IDs: c1_0.created_at DESC  (cost=1.05 rows=1) (actual time=0.0121..0.0121 rows=0 loops=1)
            -> Filter: ((c1_0.is_deleted = 0) and (match c1_0.lower_title against ('제목')) and (c1_0.member_id is not null))  (cost=1.05 rows=1) (actual time=0.00655..0.00655 rows=0 loops=1)
                -> Full-text index search on c1_0 using lower_title (lower_title='제목')  (cost=1.05 rows=1) (actual time=0.006..0.006 rows=0 loops=1)
        -> Single-row index lookup on u1_0 using PRIMARY (member_id=c1_0.member_id)  (cost=0.451 rows=1) (never executed)

쿼리 실행 계획 최적화 전후 비교

전체 테이블 읽기	736ms	0.006ms	Full Table Scan → Full Text Index로 최적화.
WHERE 조건 평가 + 정렬	561ms	0.0121ms	조건 및 정렬 최적화로 처리 속도 대폭 개선.
총 소요 시간	1297ms	0.0132ms	총 소요 시간이 약 99% 이상 감소.

여기까지 진행하고 부하테스트를 진행한 결과

총 요청 수 : 1019 -> 102855

평균 응답 시간 : 24초 -> 0.16초

에러율 : 56% -> 0%

로 개선되었습니다.

캐시

사실 이미 최적화의 목표는 거의 다 이루었지만, 목표였던 최종 평균 응답시간 0.1초를 위해서

worst 1순위인 개인 맞춤형 추천 영화 리스트 조회 API를 개선했습니다.

개인 맞춤형 추천 영화 리스트 조회할 때는 인기 TOP 10 영화를 제외한 영화들 중에서 선택을 하는데,

매번 TOP10 영화를 계산하는 과정이 굉장히 비효율적이었습니다.

그래서 TOP10 영화를 조회하는 API에서 Redis에 캐시를 하고, 개인 맞춤형 추천 영화 리스트 조회 API에서는 캐시 한 TOP10 영화를 조회해서 해당 영화들을 제외하고 나머지 로직을 진행했습니다.

커넥션 풀 최적화 - 심화

처음에 에러가 발생하지 않도록 200까지 DB 커넥션 풀을 증가해서 테스트를 진행했지만,

사실 직관적으로 '트래픽이 많으니 더 많은 연결이 필요하겠지'라는 판단은 사실 틀렸습니다.

실제로 Oracle에서 실제 성능 테스트를 진행한 결과 커넥션 풀을 2048개에서 96개로 줄여 응답 시간이 100ms에서 2ms로 오히려 줄어든 결과가 있습니다.

아래 글에서 적혀있듯이, 데이터베이스 커넥션 풀의 작동 원리를 CPU, 디스크, 네트워크 관점에서 심층적으로 살펴보고 실제 환경에서 최적의 풀 크기를 선정하였습니다.

About Pool Sizing

光 HikariCP・A solid, high-performance, JDBC connection pool at last. - brettwooldridge/HikariCP

github.com

최적의 풀 크기를 구하다 보면 직관적으로 생각하는 '많다' 보다 오히려 훨씬 적은 수의 커넥션 풀이 좋다는 것을 알 수 있습니다.

운영체제 관점에서 살펴보면,

CPU 코어가 하나인 컴퓨터도 여러 개의 스레드를 동시에 실행하는 것처럼 보입니다.

하지만 실제로는 하나의 코어에서 한 번에 하나의 스레드만 실행할 수 있고, OS가 context switching 하면서 다른 스레드의 코드를 실행하는 방식으로 동작합니다.

이는 운영체제의 Concurrency과 관련 있는 내용이죠.

그래서 스레드 수가 CPU 코어수를 초과하면, 스레드를 추가할수록 성능이 향상되는 것이 아니라 오히려 저하됩니다.

하지만 데이터베이스 관점에서 생각하면,

데이터는 일반적으로 디스크에 저장하는데, HDD 같은 경우 읽기와 쓰기를 하는 헤드가 데이터에 접근하기 위해 이곳저곳을 이동하면서 조회하는 탐색 시간이 필요합니다.

그래서 이런 I/O 대기 시간 동안 디스크 작업이 완료되기를 기다리며 스레드를 block 시키고, OS가 블록 된 스레드를 제외하고 다른 스레드의 코드를 실행함으로써 CPU 리소스를 좀 더 효율적으로 사용합니다.

그래서 스레드가 I/O 작업으로 블록 되는 동안 물리적 CPU 코어 수보다 많은 스레드를 실행할 때 최종적인 처리량을 높이는 것입니다.

그럼 최적의 스레드 개수는 몇 개일까요?

SSD의 경우 탐색 시간이 없기 때문에 블로킹이 발생하지 않고, 그래서 블록 > 다른 스레드 실행하는 걸 오히려 줄이는 게 효율적입니다.

그래서 코어 수에 가까운 더 적은 수의 스레드가 더 많은 스레드보다 성능이 좋을 가능성이 높습니다.

최적의 연결 수 계산 공식

여러 곳의 벤치마크 결과를 통해 검증된 공식은 아래와 같습니다.

활성 커넥션 수 = ((CPU 코어 수 * 2) + 유효 스핀들 수)

스핀들이란, HDD의 물리적 플래터(데이터 저장 원반)를 움직이는 축을 의미하므로 유효 스핀들 수는 HDD에서 동시에 읽고 쓸 수 있는 독립된 경로를 의미합니다.

위 공식은 하이퍼스레딩(물리적 코어를 두 개의 논리적 스레드로 나누어 동작하게 하는 기능)이 적용되어 있더라도

HT스레드(논리적 스레드, 여기선 물리적 코어보다 많음)를 제외한 실제 물리적 코어 수만을 계산합니다.

그래서 위 공식을 다시 정리하자면,

CPU 코어 수: 물리적 CPU 코어 수(하이퍼스레딩 무시).
× 2: CPU 하나가 I/O 대기 시간을 줄이고 효율적으로 스레드를 처리할 수 있도록 두 개의 연결을 할당
유효 스핀들 수: 하드 디스크에서 동시에 데이터를 읽고 쓸 수 있는 경로 수
- SSD를 사용하면 유효 스핀들 수 = 0으로 계산

예제

4 코어 i7 CPU와 HDD

물리적 CPU 코어: 4개
유효 스핀들 수: 1 (하드 디스크가 1개)

활성 커넥션 수 = (4 * 2) + 1 = 9의 커넥션이 최적입니다.

예제

4코어 i7 서버 + SSD:

활성 커넥션 수 = (4 * 2) = 8개의 커넥션이 최적입니다.

그래서 저희가 사용한 RDS는 M4.2xlarge로, 코어가 4이기 때문에 (4 * 2) = 8 (RDS는 대부분 SSD 사용)

200개에서 8개의 커넥션 풀로 설정하고 마지막 부하테스트를 진행했습니다.

최종 결과

총 요청 수 : 1019 -> 131734

평균 응답 시간 : 24초 -> 0.1초

에러율 : 56% -> 0% 100% 개선

1. 요청 수 증가율

최초 값: 1019
최적화 후 값: 131734

2. 평균 응답시간 감소율

최초 값: 24초
최적화 후 값: 0.1초

결론적으로 목표했던 평균 응답시간 0.1초를 만족할 수 있었습니다.

마무리하며

이번 최적화 경험을 통해서

새로운 테스트 환경 구축 방법
병목지점 분석의 체계적인 접근법

을 배웠습니다.

단순히 코드 개선뿐만 아니라 데이터베이스 최적화와 쿼리 구조를 이해하고 실질적인 개선 효과를 확인하는 과정이 매우 값진 경험이었습니다. 또한 최적화를 진행하면서 많은 조언을 해주신 멘토님과 팀원들의 의견을 통해서 더 나은 개발자로 성장할 수 있었습니다.

초기에 평균 응답 시간이 24초까지 치솟았을 때는 도대체 어떻게 0.1초로 줄이지,라는 좌절감도 있었지만,

문제를 단계적으로 분석하고 해결하면서 결국 목표를 달성한 순간 개발자로서 성장을 확실히 느낄 수 있었습니다.

다음 글에는, 이번 최적화만큼 프로젝트에서 열심히 했던 CI/CD 구축 경험과 데브옵스 설정 과정에 대해서도 글을 작성해 공유할 계획입니다. 기대해 주세요!

긴 글 읽어주셔서 감사합니다.
최적화는 끝이 없지만, 제 글이 작은 힌트가 되었길 바라며 앞으로도 꾸준히 나아가겠습니다

참고 블로그 글

더 적은 연결로 50배 빠른 데이터베이스 구현하기 - 당신의 커넥션 풀은 과유불급인가요?

10,000명의 동시 접속자도 10개의 커넥션으로 충분하다고?

maily.so

[Naviya] Queue와 Cache를 통한 대규모 응모 이벤트 파이프라인 구축기

겨울단추 — Wed, 30 Oct 2024 12:03:18 +0900

현재 저는 유레카(유플러스 채용 연계 부트캠프)에서, 종합 프로젝트를 진행 중입니다.
그중에 아이 성향을 주제로 하는 응모 시스템을, 대규모 트래픽(1초에 10만 트래픽을 10초간 버티는 안정성)을 안정적으로 버티게 구축하는 역할을 맡았습니다.
해당 기능을 포함해서 Naviya 프로젝트를 진행하며 고민했던 점들을 회고하며 글을 작성해 보겠습니다.

필수 요구사항

해당 시스템을 구축하기 위해서 주어진 최소한의 요구사항은 다음과 같습니다.

자녀 성향을 응모하는 100명 한정 선착순 이벤트 페이지 시스템

응모 페이지는 회원의 이름과 전화번호를 받는다
중복으로 응모는 되지 않는다
선착순 응모 페이지는 매일 오후 1시 정각에 가장 높은 트래픽을 받는다 -> 1분에 10만 요청을 10분간 받는다
응모 결과는 다음날 오후 1시에 발표한다.

평가 기준은 개인 맞춤형 서비스와 대규모 트래픽 처리

팀원들이 진행하는 자녀 성향 진단 시스템, 콘텐츠 추천 시스템에서 구현하는 개인 맞춤형 서비스와 달리,

제가 맡은 부분이 대규모 트래픽 처리가 가능한 지를 보여줄 수 있는 부분이라고 생각했습니다.

다른 팀들은 그럼에도 대용량 트래픽 처리보다는 여러 이벤트를 확장성 있게 개설하고, 질문 문항을 수정할 수 있는 식으로 구현하였지만, 저의 경우 직접 K6를 통해 성능 테스트를 진행하고, 하나씩 병목 지점을 찾아 개선해 가며 최종적인 로직과 아키텍처를 완성해 나가는 것을 목표로 프로젝트를 진행했습니다.

초기 설계

대규모 응모 시스템 구축만 신경 쓰려면, 사실 대단히 많은 엔티티가 필요하지 않습니다.

추가로 기존의 여러 프로젝트 경험을 미루어보았을 때, 꼭 필요하지 않은 연관관계를 굳이 부여하면 오히려 여러 부가적인 문제(N+1 문제, 테스트 시나리오 복잡성 증가 등등)가 발생합니다.

항상 프로젝트를 할 때 제일 중요하게 생각하는 것은

이 프로젝트를 왜 하는가?

이 프로젝트를 통해서 어떤 걸 얻고 싶은가?

등의 질문에 확실한 결론을 짓고, 모든 결정을 거기에 맞춰서 진행하는 것입니다.

실제로 유저에게 서비스를 할 목적으로 개발했던 Now, Here의 경우에는 그에 맞춰서 개발했지만

지금 개발하는 Naviya의 주된 목표는 아래와 같았습니다.

1. 대규모 부하테스트

2. Redis기반 실시간 대규모 트래픽 처리

3. 메시지 큐 시스템을 통한 안정적인 트래픽 처리 데이터 파이프라인 구축

그래서 초기 ERD는

Redis : 전화번호(PK), 이름, 선착순 100명을 측정할 수 있는 count

DBMS : Id(PK), 이름, 전화번호, 생성날짜(응모 성공자 파악을 위함)

과 같이 매우 간단하게 구현했습니다.

(최종에는 살짝 수정)

우선 초기 설계에서 Redis를 사용한 이유는, Redis는 NoSQL 기반의 인메모리 데이터 저장소로써 데이터를 디스크에 저장하지 않고 메모리에 저장하기 때문에, 매번 디스크 I/O보다 훨씬 빠른 속도로 조회 및 사용이 가능하기 때문입니다.

그래서 중복 응모 방지를 할 때 Redis를 사용하면 키 값인 번호를 메모리에서 조회해 매우 빠른 속도로 중복을 방지할 수 있습니다.

또한 선착순 100명을 세기 위한 count를 중복 아닌 경우에 추가하고, 이후에 100명이 된다면 저장이 아니라 바로 마감 응답을 보낼 수 있게 처리하였습니다.

앞으로 어떤 테스트 결과와 최적화를 통해 최종 아키텍처로 향하는지 같이 확인하시죠.

부하 테스트 K6

부하 테스트 툴로도 굉장히 다양한 툴이 많습니다.

이전 프로젝트의 경우 Postman의 유료 기능에 있는 성능 테스트 기능을 통해서 진행하였습니다.

이번에는 좀 더 범용적으로 많이 사용하는 K6, nGrinder, Jmeter 중에서 선택을 하고 싶었습니다.

유플러스 현직자 분들과의 멘토링에서 현재 유플러스에서는 nGrinder를 많이 사용하지만 각 프로젝트의 상황에 맞춰서 툴을 선택하는 것이 좋겠다고 조언을 들었습니다.

그래서 조사한 각 테스트 툴의 장단점은 아래와 같습니다.

장점

1. Go언어 기반으로 높은 성능과 낮은 자원 소비

2. Js기반 테스크 스크립트 작성을 통해 상대적으로 시나리오 테스트 코드를 쉽게 구현

3. 다른 도구에 비해 VU(가상 유저) 생성 시 낮은 하드웨어 리소스를 사용

단점

1. 단일 스레드 실행

2. GUI 없음

nGrinder

장점

1. Jython 또는 Groovy로 작성

2. 분산테스트 가능

3. 웹 인터페이스를 제공해 테스트 관리와 모니터링이 쉬움

단점

1. 높은 자원 사용량

2. 복잡한 설정

JMeter

장점

1. Java로 작성

2. GUI 제공

3. 오랜 역사로 큰 커뮤니티 보유와 다양한 정보 제공

단점

1. 높은 자원 사용량

이번 프로젝트의 경우 단일 로컬 서버에서 1초당 10만 트래픽을 10초간 처리하는 테스트를 작성하는데, K6도 로컬에서 작동하고 서버도 로컬에서 띄우다 보니 셋 중에서 가장 하드웨어 리소스가 적게 드는 K6를 선택하였습니다.

GUI가 없는 것이 편의성 측면에는 문제였지만, 저와 같은 상황에서는 오히려 리소스가 적게 드는 희소식이었습니다.

그래서 도커를 통해서 간편하게 K6를 세팅하여 사용했습니다.

크게 선착순 100개가 순차적으로 잘 들어가는지 확인하는 테스트와, 원래 프로젝트의 목표인 대규모 트래픽 테스트 두 가지를 진행했습니다.

이번 프로젝트는 여러 편의 분량이 되는 글들을 그냥 한 편으로 작성할 예정이라, 이 부분도 할 말이 많지만 대규모 트래픽 테스트에 관해서만 작성하겠습니다.

대규모 트래픽 테스트의 시나리오는 대규모 사용자 수와 높은 요청 빈도를 기반으로 한 부하 테스트 시나리오로, Redis와 포함한 응모 이벤트 시스템이 대규모 트래픽 상황에서 얼마나 안정적으로 작동하는지를 평가합니다.

이 시나리오는 점진적으로 가상 유저 수(VUs)를 증가시키며, 최종적으로 500명의 유저가 동시에 초당 200번씩 10초간 시스템에 접근하는 상황을 재현합니다.

각 유저는 고유한 응모 데이터를 사용해 서버에 반복적으로 요청을 전송하며, 이를 통해 시스템의 최대 처리 능력과 응답 시간, 실패율을 측정합니다.

테스트 구성 요소

부하 단계 (stages):
- 첫 번째 단계: 5초 동안 VUs를 50명까지 점진적으로 증가시켜 초기 부하를 가함.
- 두 번째 단계: 5초 동안 100 VUs를 유지해 서버가 일정한 부하를 처리할 수 있는지 확인.
- 세 번째 단계: 10초 동안 500 VUs를 유지하여 대규모 동시 접속 시나리오를 재현.
임계값 설정 (thresholds):
- 응답 시간: 95% 이상의 요청이 3000ms 이내에 완료되어야 함.
- 실패율: 전체 요청의 1% 미만이어야 함.

테스트 로직

요청 데이터: 각 VU는 자신의 고유 userId와 전화번호 정보를 포함한 JSON 형식의 요청 데이터를 생성
요청 반복: 각 VU는 200번의 POST 요청을 서버에 전송하며, 요청 사이에 0.1초 간격을 두어 부하 분포를 조정
성공 여부 확인: 각 요청의 응답 상태와 메시지 형식을 검사하여 성공적으로 처리된 응모만 카운트

추후에 체험형 이벤트 선택 기능을 추가하고 나선 약간의 수정이 있었지만, 우선 큰 흐름은 위와 같은 형식으로 진행했습니다.

그리고 처음에 테스트 결과로는

  ✗ response is a string
      ↳  72% — ✓ 43438 / ✗ 16120

     checks.........................: 72.93% 43438 out of 59558
     data_received..................: 14 MB  285 kB/s
     data_sent......................: 9.4 MB 193 kB/s
     http_req_blocked...............: avg=176.82ms min=0s     med=0s    max=19.65s p(90)=13.03µs p(95)=910.79ms
     http_req_connecting............: avg=158.83ms min=0s     med=0s    max=18.09s p(90)=0s      p(95)=904.81ms
   ✗ http_req_duration..............: avg=767.64ms min=0s     med=0s    max=27.25s p(90)=2.13s   p(95)=3.03s
       { expected_response:true }...: avg=1.56s    min=31.7ms med=1.21s max=27.25s p(90)=3.04s   p(95)=4.17s
   ✗ http_req_failed................: 50.89% 45176 out of 88761
     http_req_receiving.............: avg=966.78µs min=0s     med=0s    max=2.62s  p(90)=58.89µs p(95)=91.84µs
     http_req_sending...............: avg=7.09ms   min=0s     med=0s    max=3.44s  p(90)=85.5µs  p(95)=6.67ms
     http_req_tls_handshaking.......: avg=0s       min=0s     med=0s    max=0s     p(90)=0s      p(95)=0s
     http_req_waiting...............: avg=759.57ms min=0s     med=0s    max=27.25s p(90)=2.11s   p(95)=3.01s
     http_reqs......................: 88761  1828.145604/s
     iteration_duration.............: avg=7.2s     min=1.07s  med=3.73s max=41.32s p(90)=19.48s  p(95)=24.49s
     iterations.....................: 54249  1117.327102/s
     vus............................: 1207   min=0              max=46613
     vus_max........................: 100000 min=12122          max=100000

라고 나왔는데, 이중 중요한 지표만 요약해서 설명드리면 아래와 같습니다.

response is a string: 72.93%
- 테스트에서 응답이 문자열임을 확인하는 검사가 약 73% 성공
  43,438개의 요청에서 응답이 문자열이었지만, 16,120개의 요청에서는 문자열로 확인되지 않음
http_req_failed: 50.89%
- 설명: 전체 요청의 약 51%가 실패했습니다. 88,761개의 요청 중 45,176개가 실패
- 해석: 서버가 부하를 감당하지 못해 절반 이상의 요청이 실패, 타임아웃 또는 서버 자원 부족으로 인한 문제
http_req_duration: avg=767.64ms
- 설명: 요청의 평균 응답 시간이 약 768ms
- 해석: 일부 요청의 응답 시간이 매우 길어졌고, 27초 이상의 응답 지연이 발생
http_reqs: 88,761
- 설명: 총 88,761개의 요청이 이루어졌으며, 초당 약 1,828건의 요청이 발생
- 해석: 트래픽은 잘 발생했으나, 요청의 절반 이상이 실패하여 실제 성공한 요청은 상대적으로 적음

물론 맨 처음에는 큐 시스템 도입을 하지 않았기도 하였지만 결과와 같이 다소 많이 구린 서버 성능이었는데 덕분에 최적화할 거리가 많아져서 좋았습니다.

수백 명의 유저가 동시에 수백 건의 요청을 보내다 보니, 성능 문제뿐만 아니라 동시성 문제도 발생하였습니다.

아직 A의 요청이 진행 중인데 B의 요청이 반영돼 COUNT 가 100이 되어서 A의 요청에 영향을 미친 다던지와 같은 문제들 말입니다.

그래서 제가 생각한 방안은 아래와 같습니다.

1. 스레드 풀, DB 커넥션 풀, Redis 커넥션 풀 수 조정, 타임아웃 시간 증가

2. Redis 캐시 형태 list -> set형으로 최적화

3. Lua 스크립트를 통해 count 증가와 응모 처리를 원자적 단위로 처리

4. 큐 시스템 도입으로 응답은 빠르게, 처리는 순차적으로 진행

1번의 경우 단순히 config 파일을 수정하거나, properties파일을 수정하는 것이니, 2~4번에 해당하는 내용을 설명하겠습니다.

최적화 - 캐시 자료형 Set로 전환

알고리즘 문제를 풀 때 처음에는 완전 탐색으로 풀고 추후에 하나씩 로직을 개선해 나가는 것처럼, 이번 프로젝트에서도 처음에 빠르게 기능을 구현할 때는 List 형태로 구현했습니다.

@Override
    @Transactional
    public String submitLotteryEntry(LotteryEntryRequest request) {
        try {
            String phone = request.getPhone();
            String name = request.getName();
            String selectedProgram = request.getSelectedProgram();
            String entryData = String.format("%s:%s:%s", name, phone, selectedProgram);

            log.info("새로운 응모 요청 처리 중 - 이름: {}, 전화번호: {}, 프로그램: {}",
                    name, phone, selectedProgram);

            // Redis에서 중복 체크
            List<String> winnersList = redisTemplate.opsForList().range(LOTTERY_WINNERS_LIST, 0, -1);
            if (winnersList != null) {
                boolean isDuplicate = winnersList.stream()
                        .map(data -> data.split(":")[1]) // 전화번호 추출
                        .anyMatch(p -> p.equals(phone));

                if (isDuplicate) {
                    log.warn("중복 응모 시도 - 전화번호: {}", phone);
                    return "이미 응모한 전화번호입니다.";
                }
            }

            // 응모 카운트 확인
            Long currentCount = redisTemplate.opsForValue().get(LOTTERY_COUNT_KEY) != null
                    ? Long.parseLong(redisTemplate.opsForValue().get(LOTTERY_COUNT_KEY))
                    : 0;

            if (currentCount >= 100) {
                log.info("응모 마감 - 현재 응모자 수가 100명을 초과하였습니다.");
                return "응모가 마감되었습니다.";
            }

            // 성공한 응모 처리
            redisTemplate.opsForList().rightPush(LOTTERY_WINNERS_LIST, entryData);
            redisTemplate.opsForValue().increment(LOTTERY_COUNT_KEY);

            log.info("응모가 접수되었습니다 - 이름: {}, 전화번호: {}, 프로그램: {}",
                    name, phone, selectedProgram);
            return "응모가 접수되었습니다. 결과는 내일 오후 1시에 발표됩니다.";

        } catch (Exception e) {
            log.error("응모 처리 중 오류 발생 - 이름: {}, 전화번호: {}, 프로그램: {} 오류: {}",
                    request.getName(), request.getPhone(), request.getSelectedProgram(), e.getMessage());
            return "응모 처리 중 오류가 발생했습니다. 다시 시도해주세요.";
        }
    }

List 형으로도 현재 요구사항은 잘 만족할 수 있지만, List형으로 구현할 경우 중복된 응모 방지를 위해서 전체 리스트를 순회하며 비교해야 합니다. 이는 시간복잡도가 O(n)입니다.

하지만 Hash 구조를 이용하면 Key-Value 상으로 저장되기 때문에 응모자의 전화번호를 고유한 키로 두어 O(1)의 시간 복잡도로 찾을 수 있습니다.

또한 Hash는 각 키가 고유한 값을 가지므로, 중복된 전화번호로 응모하는 경우 즉시 중복 응모를 방지할 수 있는 이점이 있습니다.

마지막 이점으로는, Value값을 이용하면 MySQL로 이전할 때 전체 응모 데이터를 상대적으로 values() 메서드를 통해 가져오고 별다른 변환을 하지 않아 이전 작업이 간단해집니다.

서비스 안의 다른 메서드들을 포함해서, 응모를 요청하는 메서드를 아래와 같이 set() 자료형을 이용하게끔 수정하였습니다.

@Override
    @Transactional
    public String submitLotteryEntry(LotteryEntryRequest request) {
        try {
            String phone = request.getPhone();
            String name = request.getName();
            String selectedProgram = request.getSelectedProgram();
            String entryKey = phone;
            String entryData = String.format("%s:%s:%s", name, phone, selectedProgram);

            log.info("새로운 응모 요청 처리 중 - 이름: {}, 전화번호: {}, 프로그램: {}",
                    name, phone, selectedProgram);

            Boolean isDuplicate = redisTemplate.opsForHash().hasKey(LOTTERY_HASH_KEY, entryKey);
            if (Boolean.TRUE.equals(isDuplicate)) {
                log.warn("중복 응모 시도 - 전화번호: {}", phone);
                return "이미 응모한 전화번호입니다.";
            }

            String countStr = redisTemplate.opsForValue().get(LOTTERY_COUNT_KEY);
            Long currentCount = 0L;

            if (countStr == null) {
                redisTemplate.opsForValue().set(LOTTERY_COUNT_KEY, "0");
            } else {
                try {
                    currentCount = Long.valueOf(countStr);
                } catch (NumberFormatException e) {
                    log.warn("Invalid count value in Redis. Resetting count to 0.");
                    currentCount = 0L;
                    redisTemplate.opsForValue().set(LOTTERY_COUNT_KEY, "0");
                }
            }

            if (currentCount >= 100) {
                log.info("응모 마감 - 현재 응모자 수가 100명을 초과하였습니다.");
                return "응모가 마감되었습니다.";
            }

            redisTemplate.opsForHash().put(LOTTERY_HASH_KEY, entryKey, entryData);
            redisTemplate.opsForValue().increment(LOTTERY_COUNT_KEY, 1);

            log.info("응모가 접수되었습니다 - 이름: {}, 전화번호: {}, 프로그램: {}",
                    name, phone, selectedProgram);
            return "응모가 접수되었습니다. 결과는 내일 오후 1시에 발표됩니다.";

        } catch (Exception e) {
            log.error("응모 처리 중 오류 발생 - 이름: {}, 전화번호: {}, 프로그램: {} 오류: {}",
                    request.getName(), request.getPhone(), request.getSelectedProgram(), e.getMessage());
            return "응모 처리 중 오류가 발생했습니다. 다시 시도해주세요.";
        }
    }

최적화 및 동시성 문제 해결 - Lua 스크립트, 중복 및 응모 처리 메시지 캐싱

대용량 트래픽을 처리하는 상황에서, 최대한 서버를 거치지 않고 Redis에서 처리하기 위해서 중복 및 응모 처리 메시지 자체도 Redis에 캐싱을 하여 사용했습니다.

또한 위에서 작성한 것처럼 set() 자료형을 통해서 구현했던 응모 처리 메서드에서 Lua 스크립트를 통해

중복 응모 여부 처리
응모 처리 - 성공 / 실패
성공 시 count 증가
++ value 값을 string이 아니라 json 형태로 파싱 하는 걸로 변경

위 작업을 하나의 원자적 단위로 처리하게끔 수정하였습니다.

그래서 아래와 같이 기존의 set() 자료형에서 생길 수 있는 문제들을 한 번에 해결했습니다.

데이터 일관성 : 응모자가 많은 경우 중복 체크, 데이터 저장, 카운트 증가 등의 상황에서 race condition 문제가 발생
성능 저하 : redis의 네트워크 호출이 많아질수록 네트워크와 Redis의 부하가 높아지고 성능이 저하

@Override
    @Transactional
    public String submitLotteryEntry(LotteryEntryRequest request) {
        String script =
                "local count_key = KEYS[1] " +
                        "local hash_key = KEYS[2] " +
                        "local entry_key = ARGV[1] " +
                        "local entry_data = ARGV[2] " +
                        "local max_entries = 100 " + // 선착순 100명 제한
                        "local current_count = tonumber(redis.call('GET', count_key) or '0') " +

                        // 중복 체크
                        "if redis.call('HEXISTS', hash_key, entry_key) == 1 then " +
                        "   return redis.call('GET', KEYS[3]) " +  // 중복 응모 메시지
                        "end " +

                        // 선착순 제한 체크
                        "if current_count >= max_entries then " +
                        "   return '응모가 마감되었습니다.' " + // 선착순 마감 메시지
                        "end " +

                        // 응모 데이터 저장 및 카운트 증가
                        "redis.call('HSET', hash_key, entry_key, entry_data) " +
                        "redis.call('INCR', count_key) " +
                        "return redis.call('GET', KEYS[4])";       // 응모 완료 메시지

        String entryKey = request.getPhone();
        String entryData = String.format("{\"name\":\"%s\", \"phone\":\"%s\"}", request.getName(), request.getPhone());

        try {
            byte[] resultBytes = redisTemplate.execute((RedisCallback<byte[]>) connection ->
                    connection.scriptingCommands().eval(
                            script.getBytes(),
                            ReturnType.VALUE,
                            4,
                            LOTTERY_COUNT_KEY.getBytes(),
                            LOTTERY_HASH_KEY.getBytes(),
                            DUPLICATE_RESPONSE_KEY.getBytes(),
                            ENTRY_PROCESSED_RESPONSE_KEY.getBytes(),
                            entryKey.getBytes(),
                            entryData.getBytes()
                    )
            );

            String result = resultBytes != null ? new String(resultBytes) : "오류 발생";
            log.info("응모 처리 결과: {}", result);
            return result;

        } catch (Exception e) {
            log.error("응모 처리 중 오류 발생 - 이름: {}, 전화번호: {} 오류{}", request.getName(), request.getPhone(), e.getMessage());
            return "응모 처리 중 오류가 발생했습니다. 다시 시도해주세요.";
        }
    }

최적화 - Redis Streams

마지막으로 최적화하기 위해서 도입한 부분은 바로 비동기 큐 시스템입니다.

우선, 대규모 트래픽 처리를 위해서 주로 어떤 선례가 있는지 확인해 봤고, 크게 나온 부분이

비동기 큐 시스템 vs Spring Framework Reactive Stack

이렇게 2가지였습니다.

저의 경우에는 로컬 단일 서버에서 프로그램을 돌리고, 현재 하드웨어 리소스를 수평 확장 시키기 어려운 상황이기 때문에 고성능 병렬 처리를 좋게 만들지만 과도한 리소스를 사용할 우려가 있는 Spring Framework Reactive Stack 보다는 비동기 큐 시스템을 사용하기로 결정했습니다.

그럼 비동기 큐 시스템은 뭐고, 또 어떤 종류가 있을까요?

간단하게 비동기 큐 시스템에 대해 설명드리면, 이는 메시지를 큐에 넣고 consumer가 비동기적으로 처리하여 고부하를 분산시켜 처리하는 방식입니다. 주로 RabbitMQ와 Kafka 같은 메시지 큐 시스템은 특정 작업을 별도의 큐에 담아 소비자가 처리할 수 있도록 합니다.

이것 외에도 아래 표와 같은 큐 시스템이 있습니다.

이 중에서 많은 기업들의 JD에도 적혀있는 kafka와 지금 제가 사용하는 Redis에 포함된 Redis Streams에 대해 조사해 보았습니다.

현재 서비스에서 Redis를 기반으로 구현 중이기도 하여서 설치와 설정이 간편하다는 장점, 지연 시간이 짧고 실시간 응답이 필요할 때 유리하다는 점, 현재 저의 부하테스트에는 초당 수십만 메시지까지의 성능이면 충분하다는 점을 생각해서 Redis Streams를 사용하기로 결정했습니다.

그런데 여기서 살짝의 문제가 있었습니다..!
제가 윈도우 운영체제를 쓰고 있고, 윈도우 운영체제에서는 다운로드하여서 사용할 수 있는 Redis의 버전이 3.0.0대의 버전이 가장 최근이었습니다.

근데 현재 Redis는 7 버전까지 나온 상황이고, Redis Streams은 5 버전 이상부터 사용할 수 있다는 점이었습니다.

이를 해결하기 위해서 구글링 해본 결과 WSL2를 통해서 Ubuntu를 다운로드하여서 사용하는 방법이 있었습니다.

그래서 Ubutu에 redis를 다운로드하고 이후에 이를 로컬 서버에 연결해서 사용하는 방식으로 구현했습니다.

여기까지 구현하고 위에서 작성한 테스트 시나리오로 테스트한 결과는 어땠을까요?

참고로 한 번에 위와 같은 과정들을 한 것이 아니라, 매번 최적화하고 K6를 통해서 테스트하는 과정들을 수십 번 반복했습니다.

하지만 앞으로도 글의 분량이 많은데, 매번 테스트한 결과를 모두 첨부하면 글이 너무나도 길어질 것 같아서 처음 테스트 결과와 마지막 테스트 결과만 첨부하였습니다.

     ✓ is success or correct message

     checks.........................: 100.00% 98748 out of 98748
     data_received..................: 31 MB   591 kB/s
     data_sent......................: 20 MB   372 kB/s
     http_req_blocked...............: avg=137.94µs min=1.39µs  med=7.62µs  max=124.54ms p(90)=11.19µs  p(95)=13.06µs
     http_req_connecting............: avg=127.33µs min=0s      med=0s      max=124.31ms p(90)=0s       p(95)=0s
   ✓ http_req_duration..............: avg=54.15ms  min=2.26ms  med=41.85ms max=1.33s    p(90)=110.63ms p(95)=137.1ms
       { expected_response:true }...: avg=54.15ms  min=2.26ms  med=41.85ms max=1.33s    p(90)=110.63ms p(95)=137.1ms
   ✓ http_req_failed................: 0.00%   0 out of 98748
     http_req_receiving.............: avg=93.4µs   min=10.97µs med=65.37µs max=295.03ms p(90)=139.73µs p(95)=187.97µs
     http_req_sending...............: avg=35.29µs  min=3.8µs   med=23.7µs  max=8.72ms   p(90)=66.33µs  p(95)=98.33µs
     http_req_tls_handshaking.......: avg=0s       min=0s      med=0s      max=0s       p(90)=0s       p(95)=0s
     http_req_waiting...............: avg=54.02ms  min=2.2ms   med=41.72ms max=1.33s    p(90)=110.47ms p(95)=136.97ms
     http_reqs......................: 98748   1861.989901/s
     iteration_duration.............: avg=31.48s   min=24.86s  med=31.99s  max=33.95s   p(90)=33.03s   p(95)=33.19s
     iterations.....................: 421     7.938366/s
     vus............................: 79      min=10             max=499
     vus_max........................: 500     min=500            max=500

여러 노력 끝에 얻은 최종 결론이니, 좀 자세히 해석을 해보겠습니다.

1. 전체적인 성공률과 처리량

✓ checks: 100.00% (98,748 out of 98,748)
- 모든 요청이 성공적으로 처리됨
- 총 98,748개의 요청이 처리됨

http_reqs: 98,748 (1,861.99/s)
- 초당 약 1,862개의 요청을 처리

- 하드웨어 리소스의 영향으로 10만 개의 요청을 10초 안에 보내지는 못했지만, 보낸 모든 요청을 100% 성공적으로 응답했습니다.

2. 응답 시간 분석

http_req_duration (중요 지표):
- 평균: 54.15ms
- 최소: 2.26ms
- 중간값: 41.85ms
- 최대: 1.33s
- 90% 요청: 110.63ms 이하
- 95% 요청: 137.1ms 이하

- 보다시피 원래 목표했던 95%의 요청이 3초 안에 들어올 뿐만 아니라 최대로 올린 시간 역시 1.33초 굉장히 많이 줄었습니다.

결론적으로

성공률 73% -> 100%

최대 응답시간 27초 -> 1.3초로

각각 37%, 95% 개선되는 성과를 보였습니다.

(테스트 실행 동영상 / 4배속)

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

부가 기능 - 체험형 이벤트 선택 기능 및 프론트 수정

이제 기존의 목표인

1. 대규모 부하테스트

2. Redis기반 실시간 대규모 트래픽 처리

3. 메시지 큐 시스템을 통한 안정적인 트래픽 처리 데이터 파이프라인 구축

를 다 완료했습니다.

근데 '아이의 성향을 가지고 응모 페이지 구현'하라는 요구사항을 만족해야 하고, 아이를 위해서 또는 아이가 사용하는 서비스인 만큼 이런 부분을 기획과 디자인에 반영해서 개발을 진행했어야 했습니다.

그래서 생각한 아이디어는 아이의 성향에 따라서 체험할 수 있는 프로그램을 4가지 고르고, 해당 프로그램과 이름, 전화번호를 선착순으로 입력한 100명이 체험형 프로그램을 무료로 진행할 수 있는 이벤트를 기획했습니다.

또한 디자인을 팀원과 논의하여 노란색의, 아이에게도 친화적인 디자인으로 최종 수정했습니다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

최종 아키텍처 및 결론

최종적으로 위와 같이 10만 * 10초의 트래픽을 감당하기 위한 아키텍처를 설계했습니다.

이번 대규모 응모 처리 시스템을 구현하면서 좋았던 점은

1. Redis 캐시를 사용해 본 경험

2. 대용량 트래픽을 위한 큐 시스템 적용 경험

3. K6를 통한 테스트 시나리오 작성 및 성능 테스트 경험

4. 실질적인 성능 향상 경험

이렇게 4가지였습니다.

그리고 아쉬운 점은 하드웨어의 한계로 10만 * 10초의 트래픽을 실제로 테스트하지 못하고, 1만 * 10초의 트래픽으로 테스트한 것입니다.

물론 클라우드 서비스를 이용해서 해도 되지만, 사이드프로젝트에서 프리티어를 이용하려고 하다 보면 훨씬 안 좋은 하드웨어 자원을 사용한다는 것을 알아서 그냥 로컬에서 진행했습니다.

마무리하며

나중에 현업에 간다면, 실제로 경험하게 되는 수십, 수백만의 트래픽을 가지고 최적화해 보는 경험을 꼭 해보고 싶고, 이번 경험이 그 경험을 위한 초석이 될 거라고 생각합니다.

그리고 개발을 시작한 지 얼마 안 됐을 때는 쉘 프롬프트만 봐도 머리가 쥐 날 것 같았는데, 이제는 하나의 컴퓨터에서 우분투에 Redis, 윈도우 쉘에 도커 띄워서 K6 부하테스트, 로컬에 서버 올려서 작동하는 걸 한 번에 수월하게 다루는 것을 보고 그래도 나름대로 개발 실력이 계속 늘고 있다는 게 느껴져서 좋았습니다.

이제 코테랑.. 다른 부분도 매우 좋아지기를 바라면서 글을 마칩니다.

긴 글 읽어주셔서 감사합니다.

각자의 전쟁터에서

겨울단추 — Sun, 20 Oct 2024 18:24:35 +0900

개발 블로그지만, 개발과 관련 없는 제 생각에 대해서 조금 글을 써보려고 합니다.

인터넷이란 창을 통해 세상의 모든 소식을 접하다 보니, 희극과 비극을 동시에 너무나도 쉽게 알게 되는

이 시대가 묘하게 다가옵니다.
저희 본가에서 차로 약 30분만 가면 북한이 보입니다.

그 북한의 제 나이대 청년들은 지금 러시아에서 전쟁에 참전하고 있습니다.
https://lnkd.in/gV8znz7P

그리고 그 반대편 우크라이나에서는, 평범하게 일상을 살아가던 이들이 군대에 강제로 징집되고 있죠.
https://lnkd.in/gNyhiRpi

이런 소식을 접할 때면, 하반기에 취준을 이어가고 있는 저의 모습과

그들의 현실이 너무 달라 보여서, 묘한 괴리감을 느끼곤 합니다.
각자 나름의 전쟁을 치르고 있다고들 하지만, 그 무게감이 과연 같을까요?

얼마 전 가족들과의 식사 자리에서 이야기를 나눈 적이 있습니다.
이런 상황들이 악화되어 진짜 전쟁이 나게 된다면 어떻게 할 건지에 대한 대화였죠.
특히 저와 동생은 둘 다 징병 대상자라, 그 순간만큼은 분위기가 꽤나 무겁게 가라앉았습니다.
전쟁터에 나가기 싫어서 나라를 떠나거나 범죄자가 되어 해외에 망명하는 이들이 있다는 걸 잘 압니다.
그들은 ‘개인’의 입장에서 생존을 택한 것이겠죠.

그리고 그와는 반대로, 나라를 위해 목숨을 바친 이들도 있습니다.
각자의 선택이 있겠지만, 저는 그들의 결정을 결코 쉽게 비난할 수 없다고 생각합니다.
저는 우주가 끝없다 해도, 제가 죽으면 제 우주는 끝나버리니까요.

그런 의미에서 나의 우주를 지키기 위해 도망가는 사람을 이해할 수밖에 없습니다.

그럼에도 불구하고, 저는 전쟁이 나가면 꼭 참전하려구요.
나라를 지키겠다는 대단한 마음은 아니지만,

모든 사람이 저런 마음으로 도망간다면 제가 사랑하는 사람들은 누가 지킬까요?
저같은 사람들이 모여서 사랑하는 사람들이 잘 살 수 있는 나라를 지키기 위해

저는 당연하지만 당연하지 않은 참전을 꼭 하려구요.

끝없는 취준 속에도 종종 힘들지만, 그럼에도 오늘 할 수 있는 일을 하면서 또 하루가 저뭅니다.

긴 글 읽어주셔서 감사합니다.

[Now, Here] 프로젝트 서비스가 오픈 되었습니다!

겨울단추 — Sun, 29 Sep 2024 11:54:09 +0900

안녕하세요~! 주말 잘 지내고 계신가요.

제가 사이드로 팀원을 직접 모아서 진행한 프로젝트가 서비스가 시작했습니다!

가을 축제 기간 동안 운영하는 서비스로, 완전 무료이니 마음껏 사용하시고 편하게 피드백 주시면 감사하겠습니다!
(지인이나, SNS(에타같은..) 공유도 해주시면 감사.. :>)

아래는 홍보 멘트입니다!

-------------------------------------------------------------------------------------

가을, 새로운 인연의 계절이 왔습니다!
여러분의 특별한 만남을 위해 나우히어(Now, Here)가 찾아왔습니다!
전국 대동제 기간 동안만 만나볼 수 있는 이 특별한 기회, 놓치지 마세요!

나우히어에서 당신의 인연을 찾아보세요
- MBTI 기반 맞춤 매칭: 당신의 성향에 꼭 맞는 상대를 만나보세요!
- 무제한 매칭: 마음에 드는 상대를 찾을 때까지 계속!
- 간편한 가입: 복잡한 절차는 No! 몇 가지 정보만으로 시작해요.
- 안전한 정보 관리: 축제 종료 후 모든 정보는 안전하게 삭제됩니다.

완전 무료 서비스!
나우히어는 여러분의 특별한 만남을 위해 100% 무료로 제공됩니다. 개발자들은 어떠한 금전적 이득도 취하지 않습니다. 순수한 열정으로 만들어진 서비스입니다!

여러분의 소중한 피드백을 기다립니다
서비스를 이용하신 후, 꼭 피드백을 남겨주세요! 여러분의 의견은 더 나은 서비스를 만드는 데 큰 힘이 됩니다.

지금 바로 나우히어 시작하기
링크: https://www.now-here.site/login/MTAyOTM4NDU

⏰ 10월 31일까지만 운영됩니다! 이 특별한 기회, 놓치지 마세요! ⏰

당신의 특별한 가을, 나우히어와 함께 시작하세요. 지금 이 순간, 당신의 인연이 기다리고 있습니다!

[Now, Here] 성능 테스트_하드웨어 리소스 업그레이드

겨울단추 — Mon, 16 Sep 2024 23:57:24 +0900

성능 테스트 가이드 시리즈 / 클릭 시 이동
1. 성능 테스트_성능 목표 잡기
2. 성능 테스트_HikariCP의 연결 최대 풀 설정
3. 성능 테스트_Caffeine 캐시 설정 및 적용
4. 성능 테스트_인덱싱과 트랜잭션 관리 최적화
5. 성능 테스트_하드웨어 리소스 업그레이드

결과

Total Average response time

7575ms → 4,465 ms(41.06%의 성능 향상)

Top 5 slowest requests based on their average response times.

API 성능 개선 요약

각 API별 성능 개선율

API 엔드포인트	평균 응답 시간 개선율	90th 응답 시간 개선율
GET /matching/senderList (받은 하트 페이지 조회)	72.10%	66.42%
GET /matching/getNotificationList (알림 목록 조회)	21.00%	7.08%
GET /matching/summaryDetail (매칭 현황 페이지 조회)	43.29%	37.79%
GET /matching/summary (매칭 요약 조회)	35.74%	34.25%
GET /matching/banner (배너 대칭 목록 조회)	88.33%	86.52%
GET /matching/getNotification (알림 개수 조회)	54.33%	39.83%

상세 성능 개선 데이터

GET /matching/senderList (받은 하트 페이지 조회)

평균 응답 시간: 33,288ms → 9,289ms (72.10% 개선)
90th 응답 시간: 44,404ms → 14,911ms (66.42% 개선)

GET /matching/getNotificationList (알림 목록 조회)

평균 응답 시간: 23,766ms → 18,774ms (21.00% 개선)
90th 응답 시간: 28,215ms → 26,218ms (7.08% 개선)

GET /matching/summaryDetail (매칭 현황 페이지 조회)

평균 응답 시간: 23,865ms → 13,533ms (43.29% 개선)
90th 응답 시간: 28,220ms → 17,555ms (37.79% 개선)

GET /matching/summary (매칭 요약 조회)

평균 응답 시간: 18,525ms → 11,905ms (35.74% 개선)
90th 응답 시간: 25,130ms → 16,522ms (34.25% 개선)

GET /matching/banner (배너 대칭 목록 조회)

평균 응답 시간: 32,414ms → 3,784ms (88.33% 개선)
90th 응답 시간: 50,631ms → 6,825ms (86.52% 개선)

GET /matching/getNotification (알림 개수 조회)

평균 응답 시간: 23,766ms → 10,854ms (54.33% 개선)
90th 응답 시간: 28,215ms → 16,976ms (39.83% 개선)

전체 평균 개선율

평균 응답 시간 개선율: (72.10% + 21.00% + 43.29% + 35.74% + 88.33% + 54.33%) / 6 ≈ 52.47%
90th 응답 시간 개선율: (66.42% + 7.08% + 37.79% + 34.25% + 86.52% + 39.83%) / 6 ≈ 45.32%

이와 같이 전체 API 성능이 크게 개선되었다.

평균 응답 시간은 약 약 52.47% 개선되었고, 90th 백분위 응답 시간은 약 45.32% 개선되었다.

이를 통해서 비효율적인 프로세스 개선을 통한 리소스 사용 줄이기 목표는 달성하였다고 생각한다.

사용 방법으로는

HikariCP의 연결 최대 풀 설정
Caffeine 캐시 설정 및 적용
엔티티 인덱싱
트랜잭션 최적화

이고 추가로

DB 아키텍처 설계할 때 Master - Slave 형태로 설계해 로드 밸런싱한 것
스키마 설계할 때 event_id를 기준으로 파티셔닝

을 해 놓은 것은 반영되지 않은 결과이기 때문에 실제로 사용할 때는 더 좋은 성능을 예상할 수 있다.

하지만, 목표 성능 예산이었던 3초는 어떻게 달성할 것인가?

→ 바로 아직 사용하지 않은, 리소스 성능 향상을 사용할 것이다.

GCP에서 훨씬 좋은 성능의 DB 서버를 실제 상용 DB 서버로 사용하기 때문에

리소스 향상이 매우 압도적으로 일어날 것을 예상할 수 있는데

아직 서비스를 개선하기 전에 예산이 없는 상황에서 과도한 금액이 나가는 것을 우려해

로컬 DB를 연결해 리소스 증가시 어느 정도의 성능을 발휘하는지 파악했다.

리소스 자원 업그레이드 테스트

Total Average response time

7575ms → 88 ms ( 98.84%의 성능 향상)

Top 5 slowest requests based on their average response times.

결과를 통해서, 프로세스 최적화 진행 전과 진행 후 모두 리소스 자원 업그레이드 한 상황과 비교하면,

프로세스 최적화 진행 전과 비교한 계산 과정

개선된 시간 = 7575ms - 88ms = 7487ms
개선율 = (개선된 시간 / 원래 시간) * 100 = (7487 / 7575) * 100 ≈ 98.84%

따라서, 7575ms에서 88ms로의 성능 개선은 약 98.84%의 향상

프로세스 최적화 이후와 비교한 계산 과정

개선된 시간 = 4,465ms - 88ms = 4,377ms
개선율 = (개선된 시간 / 원래 시간) * 100 = (4,377 / 4,465) * 100 ≈ 98.03%

따라서, 4,465ms에서 88ms로의 성능 개선은 약 98.03%의 향상

역시…. 가장 좋은 것은 돈을 들여서 리소스 자원을 업그레이드하는 것이다.

이 경험을 통해서 배운 것은

성능 테스트의 중요성
실제로 서비스를 운영하기 전에 테스트 환경에서 성능을 측정하고 개선하는 과정이 얼마나 중요한지 깨달았다.
특히 우리 서비스처럼 축제 때 트래픽이 폭주하는 상황을 고려하면 더욱 그렇다.
500명의 유저가 약 25만 개의 매칭 데이터를 요청하는 상황을 가정하고 테스트했는데
초기에는 평균 응답 시간이 무려 7575ms나 걸렸다. 이런 식으로 미리 문제를 파악하고 개선할 수 있었다.
단계별 최적화의 효과
문제를 한 번에 해결하려고 하지 않고, 하나씩 파악하고 개선해 나가는 방식이 효과적이었다.
HikariCP 설정 최적화로 연결 풀 고갈 문제를 해결하고, Caffeine 캐시 적용으로 전체 응답 시간을 39.68% 개선했다. 인덱싱과 트랜잭션 최적화를 통해 처음 대비 41.06%의 성능 향상을 이뤘고
이런 식으로 단계별로 접근하니 각 단계에서의 효과를 명확히 볼 수 있었다.
DB 최적화의 중요성
DB 최적화가 전체 성능에 미치는 영향이 엄청나다는 걸 직접 경험했다.
특히 매칭 엔티티에 복합 인덱스를 추가하니까 조회 성능이 크게 향상됐다.
트랜잭션 관리도 중요했는데, 읽기 전용 메서드에 @Transactional(readOnly = true)를
적용하니까 불필요한 락을 방지하고 성능이 개선됐다.
캐싱의 효과
Caffeine 캐시를 제대로 설정하니 배너 매칭 목록 조회 API의 응답 시간이 32,414ms에서 3,784ms로 줄어들었다.
이건 무려 88.33%의 개선이다. 캐시 설정을 제대로 하니까 전체 응답 시간도 40% 가까이 개선되었다.
하드웨어 리소스의 영향
소프트웨어 최적화도 중요하지만, 역시 가장 좋은 건 돈을 들여서 리소스 자원을 업그레이드하는 것이다.
로컬 DB로 테스트했을 때 평균 응답 시간이 7575ms에서 88ms로 줄어들었는데
최적화를 진행하지 않았을 때 대비 98.84%의 성능 향상
최적화하고 리소스만 업그레이드 했을 때 대비 98.03% 성능 향상이 되었다.
아키텍처 설계의 중요성
Master-Slave 구조로 DB를 설계하고, event_id 기준으로 파티셔닝을 해 놓았다.
이런 설계가 성능에 미치는 영향을 고려하면서 개발하는 게 중요하다는 걸 배웠다.

이번 경험을 통해서
성능 최적화가 단순히 코드 몇 줄 바꾸는 게 아니라
전체적인 시스템 설계부터 세세한 설정까지 모든 게 연관되어 있다는 걸 배웠다.
그리고 무엇보다 수치로 개선 정도를 확인할 수 있어서 좋았다.
다음 프로젝트에서는 이런 경험을 바탕으로 처음부터 성능을 고려한 설계를 할 수 있을 것 같다.

[Now, Here] 성능 테스트_인덱싱과 트랜잭션 관리 최적화

겨울단추 — Mon, 16 Sep 2024 23:16:26 +0900

성능 테스트 가이드 시리즈 / 클릭 시 이동
1. 성능 테스트_성능 목표 잡기
2. 성능 테스트_HikariCP의 연결 최대 풀 설정
3. 성능 테스트_Caffeine 캐시 설정 및 적용
4. 성능 테스트_인덱싱과 트랜잭션 관리 최적화
5. 성능 테스트_하드웨어 리소스 업그레이드

결과

Total Average response time

7575ms → 4569ms (39.68% 최적화)

이번 테스트에서는 이렇게 DB 성능이 나왔는데 이전의 테스트 당시 모니터링 화면과 양상이 유사하지 않은가?

왜냐면 테스트할 때 R관련 API가 실행될 때 데이터가 25만 개 이기 때문에

Tuples out이 계속 증가하다가 이후 CUD관련 API가 실행되면 이는 줄어들고 Tuples in이 되는 것을 볼 수 있다.

Top 5 slowest requests based on their average response times.

캐시를 제대로 설정하니 전체 응답 시간은 약 40%가 개선되었고

문제가 됐던 배너 매칭 목록 조회 API는 아예 느린 순위에서 빠졌다.

자세하게 설명하자면

배너 매칭 목록 조회 API의 평균 시간과 상위 90프로까지 시간이 각각 5081ms, 9220ms이 되었는데

이는 평균시간 기준과 상위 90프로 기준

32414ms -> 5081ms의 경우: 개선된 시간 = 32414 - 5081 = 27333ms 개선율 = (27333 / 32414) * 100 ≈ 84.32%
50631ms -> 9220ms의 경우: 개선된 시간 = 50631 - 9220 = 41411ms 개선율 = (41411 / 50631) * 100 ≈ 81.79%

따라서,

32414ms에서 5081ms로의 개선은 약 84.32%의 성능 향상
50631ms에서 9220ms로의 개선은 약 81.79%의 성능 향상

을 이룬 것이다.

이를 통해 이제껏 문제가 됐던 배너 매칭 목록은 worst top 5 목록에서 아예 사라졌고 다른 5개가 리스팅 됐다.

원인 분석

한 단계씩 적용해 가며 단계적으로 최적화를 진행할 생각이어서 이전에 찾은 원인을 이어서 분석하였다.

각 엔티티에서 pk나 유니크 제약 조건과 별개로 비즈니스 로직에 맞게 인덱싱을 적용

트랜잭션 관리 최적화를 통해서

간단하게는 R 기능만 사용하는 트랜잭션임을 밝혀 성능 최적화
추후에 상용 DB를 연결할 때는 Master와 Slave에 각각 다른 트랜잭션을 날려 로드 밸런싱까지 할 수 있게 설정했다.

성능 개선

worst top 5 api는 전부 매칭과 관련된 API로 매칭과 관련해서

각 비즈니스 로직에 맞게 필요한 인덱싱 추가
service와 repository의 모든 메서드를 참고해서 R기능의 메서드를 트랜잭션 관리 최적화
- 읽기 전용 메서드에는 @Transactional(readOnly = true)를 적용하여 성능을 향상하고
  데이터베이스의 불필요한 락을 방지.
- 쓰기, 삭제, 업데이트 작업을 하는 메서드에는 기본 트랜잭션 (@Transactional)을 사용하여 데이터 일관성을 유지

를 적용했다.

엔티티 클래스에서 인덱스 지정

현재 내 서비스는 JPA를 사용하기 때문에 어노테이션 안에 @Index 어노테이션을 통해 인덱스를 정의할 수 있다.

@Entity
@Table(name = "matching", indexes = {
    @Index(name = "idx_matching_status", columnList = "status"),
    @Index(name = "idx_matching_created_at", columnList = "createdAt"),
    @Index(name = "idx_sender_receiver_member_id", columnList = "sender_member_id, receiver_member_id", unique = true)
})
public class Matching {
    // 엔티티 필드들
}

@Index: 특정 칼럼에 대한 인덱스를 지정.
name: 인덱스의 이름을 지정.
columnList: 인덱스를 적용할 칼럼(들)을 지정.
unique = true: 복합 인덱스를 유니크 인덱스로 설정할 수 있음.
여기서 sender_member_id와 receiver_member_id를 묶어서 유니크 인덱스로 지정한 것은
두 멤버의 매칭이 중복되지 않게 보장해 줌.

특히 @Index(name = "idx_sender_receiver_member_id", columnList = "sender_member_id, receiver_member_id", unique = true)와 같이 복합 인덱스를 설정하면 두 칼럼을 조합해서 조회하는 경우 성능이 크게 향상된다.

예를 들어 한 명의 회원이 보낸 매칭 또는 받은 매칭을 조회하는 쿼리들이 빠르게 처리된다.
또한 unique = true를 사용하면 두 멤버가 서로 매칭되는 관계가 중복으로 발생하지 않도록 데이터베이스 레벨에서 제약을 설정
- 즉, 동일한 두 멤버가 여러 번 매칭되는 것을 방지할 수 있어. 예를 들어, sender_member_id = 1과 receiver_member_id = 2로 매칭된 경우, 동일한 두 사람에 대해 다시 매칭을 생성하려고 하면 오류가 발생

트랜잭션 최적화

읽기 전용 트랜잭션 적용

읽기 전용으로 처리되는 메서드는 데이터베이스에서 데이터를 변경하지 않으므로@Transactional(readOnly = true)를 적용

@Transactional(readOnly = true)
@Override
public List<Matching> findByReceiverId(Long memberId) {
    return em.createQuery("SELECT m FROM Matching m WHERE m.receiver.id = :memberId", Matching.class)
             .setParameter("memberId", memberId)
             .getResultList();
}

@Transactional(readOnly = true)
@Override
public List<BannerListResponse> getBannerList() {
    List<Object[]> results = matchingRepository.findMemberForBanner(Status.ACCEPTED);
    return matchingListToDto.convertToBannerListResponse(results);
}

이렇게 하면 읽기 작업 시 불필요한 락을 방지하고 성능을 개선된다.
또한 데이터베이스에서의 읽기 작업이 더 가볍게 처리되어, 시스템 전체 성능 향상된다

쓰기/수정 트랜잭션

쓰기 작업은 데이터베이스에 변경을 일으키므로, 기본 트랜잭션을 적용한다.

@Transactional
@Override
public void save(Matching matching) {
    try {
        em.persist(matching);
    } catch (Exception e) {
        log.error("매칭 저장 중에 실패: {}", matching, e);
    }
}

@Transactional
@Override
public void update(Matching matching) {
    try {
        em.merge(matching);
    } catch (Exception e) {
        log.error("매칭 업데이트 중 실패: {}", matching, e);
    }
}

→ 하지만 서비스 자체의 도메인이 크지 않기 때문에 Matching을 하는 김에
모든 엔티티에 인덱싱과 트랜잭션 관리 최적화를 진행했다.

결과는 다음에..

[Now, Here] 성능 테스트_Caffeine 캐시 설정 및 적용

겨울단추 — Mon, 16 Sep 2024 23:03:39 +0900

성능 테스트 가이드 시리즈 / 클릭 시 이동
1. 성능 테스트_성능 목표 잡기
2. 성능 테스트_HikariCP의 연결 최대 풀 설정
3. 성능 테스트_Caffeine 캐시 설정 및 적용
4. 성능 테스트_인덱싱과 트랜잭션 관리 최적화
5. 성능 테스트_하드웨어 리소스 업그레이드

결과

Total Average response time

7575ms

Top 5 slowest requests based on their average response times.

연결 풀을 설정한 결과로, 문제가 됐던 에러는 발생하지 않게 되었다!

하지만 평균시간과 기준치로 삼았던 90th TTFB를 보면 가장 높은 경우 무려 32414ms, 50631ms가 걸리는 기염을 토했다.

테스트 서버 리소스가 적은 탓(512MB…)이 가장 크겠지만

우리의 목표는 현재 상황에서 얼마나 개선하는가 가 목표이기에 이를 우선 배너 매칭 목록 조회부터 원인 파악을 하기로 했다.

원인 파악

우선 해당 API에 관련된 코드를 확인했다.

 // controller
 @GetMapping("/banner")
    public ResponseEntity<ResponseForm> getMemberForBanner() {
        List<BannerListResponse> bannerList = matchingService.getBannerList();

        if (bannerList == null) {
            bannerList = List.of();
        }

        return ResponseEntity.ok(ResponseForm.of(ResponseCode.BANNER_LIST_QUERY_SUCCESS, bannerList));
	
	// service
    @Cacheable("bannerListCache")// 메서드의 결과를 캐시하여 동일한 인자로 호출되면 캐시된 결과 반환
    @Override
    public List<BannerListResponse> getBannerList() {
        // 최적화된 쿼리로 데이터를 가져옴
        List<Object[]> results = matchingRepository.findMemberForBanner(Status.ACCEPTED);

        // 데이터를 DTO로 변환하여 반환
        return matchingListToDto.convertToBannerListResponse(results);
    	}
    }

	// repository
    @Override
    public List<Object[]> findMemberForBanner(Status status) {
        try {
            return em.createQuery("SELECT s.nickname, s.mbti, s.gender, r.nickname, r.mbti, s.gender " +
                            "FROM Matching m " +
                            "JOIN m.sender s " +
                            "JOIN m.receiver r " +
                            "WHERE m.status = :status " +
                            "ORDER BY m.createdAt DESC", Object[].class)
                    .setParameter("status", status)
                    .setMaxResults(10)
                    .getResultList();
        } catch (Exception e) {
            log.error("배너에 적힐 10명의 매칭을 찾는 도중에 에러가 발생했습니다: {}", status, e);
            return List.of(); // 빈 리스트 반환
        }
    }

이렇게 로컬 캐시도 적용하고, 쿼리를 날릴 때 엔티티 자체를 가져오지 않고 필요한 칼럼만 조회해서 가져오는 등 나름 깔끔하게 코드를 작성했는데 왜 이렇게 오래 걸리는지 의문이였다.

그래서 캐시 관련 설정을 다시 한번 검토하기로 했다.

캐시 활성화 문제

우선 Spring에서 캐시 기능을 활성화하기 위해서는 @EnableCaching 어노테이션을 추가해야 한다.

import org.springframework.cache.annotation.EnableCaching;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
@EnableCaching  // 캐시 기능 활성화
public class NowHereApplication {

    public static void main(String[] args) {
        SpringApplication.run(NowHereApplication.class, args);
    }
}

이후 캐시 설정을 추가해야 하는데 크게

캐시 타입 지정
최대 캐시 크기 및 만료 시간 설정

두 가지가 있다.

캐시 타입에는

Caffeine
- 자바 기반 로컬 캐시
- 단일 서버 환경에서 캐시가 필요한 경우
- 빠른 C/R 기능이 중요한 DB 서버에서 데이터를 캐싱하는 경우
- 장점
  - 로컬이라 읽기 쓰기 성능이 뛰어남
- 단점
  - 여러 서버 인스턴스에서 동일한 데이터를 캐싱해야 한다면 분산 캐시가 아니라 문제가 발생 가능
Ehcache
- 자바 기반 로컬 캐시
- 장점
  - 디스크 기반 캐시를 지원해 메모리 제한을 초과해도 디스크에 데이터 저장
  - 클러스터링을 통해 분산 캐시처럼 사용 가능
- 단점
  - 로컬 캐시인 경우 서버 인스턴스마다 다른 캐시 데이터를 가질 수 있는 위험
Redis
- 인메모리 데이터베이스로서 분산 캐시 용도로 사용
- 장점
  - 키-값 저장소로 동작하여 메모리에 모든 데이터를 저장하여 매우 빠른 성능 제공
  - 여러 서버 인스턴스에서 동일한 캐시 일관성 보장
- 단점
  - 외부 서버 의존
  - 이를 위한 추가적인 리소스 비용 발생
Hazelcast
Memcached

등등이 있다.

이런 캐시에 대한 설정이 미흡하여 제대로 캐싱이 되지 않는 것이 문제였다.

성능 개선

위에서 설명한 캐시 중에서 기본적으로 개발 환경에서는

빠른 캐싱 성능을 제공하고 설정이 간단한 Caffeine 캐시를 사용하는 것을 추천하고는 한다.

하지만 우리 서비스와 같은 경우 DB를 Master - Slave 구조로 멀티 데이터베이스 소스 형태로 구축해기에

Redis나 Hazelcast 같은 분산 캐시를 추천한다.

그렇지만 나는 Redis, Hazelcast를 학습하고

이를 응용하기 위한 러닝 커브가 현재 우리 서비스의 규모를 봤을 때 오버 엔지니어링이라는 판단을 했다.

또한 Master - Slave를 구축할 때 CUD는 Master가, R는 Slave가 담당하도록 구축하게 했기 때문에

단일 서버에 Master에서 주기적으로 Slave와 동기화하고, Slave에서 Caffeine을 통해서 로컬 캐시를 사용해도

충분히 성능 개선이 이뤄질 것이라고 판단했다.

그래서 아래와 같이 캐시는 caffeine, 최대 500개의 캐시 항목 저장, 10분 후에 만료되도록 설정하였다.

결과는 다음 글에..

spring.cache.type=caffeine  # 캐시 타입 지정
spring.cache.caffeine.spec=maximumSize=500,expireAfterWrite=10m

[Now, Here] 성능 테스트_HikariCP의 연결 최대 풀 설정

겨울단추 — Mon, 16 Sep 2024 22:51:12 +0900

성능 테스트 가이드 시리즈 / 클릭 시 이동
1. 성능 테스트_성능 목표 잡기
2. 성능 테스트_HikariCP의 연결 최대 풀 설정
3. 성능 테스트_Caffeine 캐시 설정 및 적용
4. 성능 테스트_인덱싱과 트랜잭션 관리 최적화
5. 성능 테스트_하드웨어 리소스 업그레이드

문제 원인 파악

기본적으로 테스트를 진행할 때는 에러가 발생하면 안 되는데, 첫 번째 테스트를 진행하던 중에 에러가 발생했다.

딱 특정 지점에만 에러가 발생하는 것을 보고 해당 부분의 log를 분석하였다.

2024-09-16T04:22:39.013+09:00  WARN 24884 --- [now_here] [.0-8080-exec-72] o.h.engine.jdbc.spi.SqlExceptionHelper   : SQL Error: 0, SQLState: null
2024-09-16T04:22:39.013+09:00  WARN 24884 --- [now_here] [.0-8080-exec-35] o.h.engine.jdbc.spi.SqlExceptionHelper   : SQL Error: 0, SQLState: null
2024-09-16T04:22:39.014+09:00 ERROR 24884 --- [now_here] [.0-8080-exec-72] o.h.engine.jdbc.spi.SqlExceptionHelper   : HikariPool-1 - Connection is not available, request timed out after 30001ms (total=10, active=10, idle=0, waiting=88)
2024-09-16T04:22:39.014+09:00 ERROR 24884 --- [now_here] [.0-8080-exec-35] o.h.engine.jdbc.spi.SqlExceptionHelper   : HikariPool-1 - Connection is not available, request timed out after 30002ms (total=10, active=10, idle=0, waiting=88)
2024-09-16T04:22:39.015+09:00 ERROR 24884 --- [now_here] [.0-8080-exec-35] c.n.n.d.m.service.MemberAuthService      : get Member By Token Error =Could not open JPA EntityManager for transaction
2024-09-16T04:22:39.016+09:00 ERROR 24884 --- [now_here] [.0-8080-exec-35] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception

java.lang.NullPointerException: Cannot invoke "com.now_here5.now_here.global.security.dto.AuthenticatedMemberDto.getRoleNamesDto()" because "memberDto" is null

이 에러는 애플리케이션이 데이터베이스의 연결을 얻지 못해 발생한 것이다.

HikaraiCP 연결 풀이 고갈되어서 그런데, 로그를 좀 더 분석해 보면

HikariPool-1 - Connection is not available, request timed out after 30001ms (total=10, active=10, idle=0, waiting=88)
total=10: 최대 10개의 연결이 설정
active=10: 현재 모든 연결이 사용 중
idle=0: 유휴 상태의 연결이 없음
waiting=88: 88개의 스레드가 연결을 대기
이로 인해 연결을 얻지 못한 요청들이 30초 후에 타임아웃

이와 같은 이유로

java.lang.NullPointerException: Cannot invoke "com.now_here5.now_here.global.security.dto.AuthenticatedMemberDto.getRoleNamesDto()" because "memberDto" is null

해당 에러를 통해 알 수 있듯이 memberDto 객체가 생성되지 않아 NullPointerException이 발생하는 것이었다.

성능 개선

성능 개선을 위한 내용을 작성할 때 설명을 위해서

HikariCP의 JDBC 커네션 풀의 설정 파라미터와 모니터링 툴의 지표에 대해 설명하겠다.

HikariCP의 JDBC 커네션 풀의 설정 파라미터

maximum-pool-size
- 최대 풀 크기를 설정하는 파라미터로 HikariCP가 동시에 유지할 수 있는 최대 데이터베이스 연결 수를 지정
  - 늘릴 때 장점
    - 동시 처리 가능한 요청 수가 증가해 타임아웃 발생 가능성이 줄어듦
  - 단점
    - 데이터베이스 서버 과부하 우려
minimum-idle
- 최소 idle 연결 수를 설정하는 파라미터
  - 기본값이 10개이므로 새로운 요청이 들어올 때 빠르게 연결을 제공하도록 함
  - 늘릴 때 단점
    - 불필요한 idle 연결 수가 많아지면 자원 낭비가 발생
connection-timeout
- 연결 타임아웃을 설정하는 파라미터, 데이터베이스 연결을 위해 API 서버가 기다릴 최대 시간을 밀리초 단위로 설명
- 풀 고갈 상황에서 요청들이 빠르게 실패하고 예외 처리를 적절하게 대응 가능
  - 너무 짧으면 일시적인 트래픽 급증 시 불필요한 타임아웃 발생
  - 너무 길면 사용자 만족도 감소
idle-timeout
- idle 상태의 타임아웃을 설정하는 상태
  - 위와 맥락을 같이함
max-lifetime
- 연결의 풀에서 유지될 수 있는 최대 수명을 설정
  - 기본적으로 30분으로 설정해 오래된 연결이 자동으로 폐기되고 새로 생성되게함
  - 너무 짧은 경우 연결을 재성성하게 되어 성능에 영향

pgAdmin4 Dashboard

Database Sessions (데이터베이스 세션):
- 파란색(Total)은 전체 세션 수, 주황색(Active)은 활성 세션, 녹색(Idle)은 유휴 상태의 세션
- 처음에는 총 세션 수가 약간 변동하다가, 이후 안정적으로 유지
- 활성 세션과 유휴 세션은 전체 세션과 비슷하며 이는 전체적인 세션 관리가 원활하게 이루어지고 있음을 나타냄
Transactions per second (초당 트랜잭션):
- 초당 트랜잭션 수가 처음에는 상당히 많다가 급격히 줄어들고, 이후 거의 유지
- 트랜잭션이 처음에는 활발하게 일어났으나 이후 줄어드는 패턴을 볼 수 있습니다.
  - 이는 특정 작업이 완료되면서 트랜잭션 수가 감소
Tuples in (데이터 삽입):
- 튜플 삽입(Inserts), 업데이트(Updates), 삭제(Deletes)에 대한 정보
Tuples out (데이터 출력):
- Fetched(가져오기)와 Returned(반환)된 튜플
- 초기에는 데이터 가져오기와 반환 작업이 활발하게 일어나다가 급격히 줄어듬
- 이는 처음에 데이터베이스로부터 데이터를 많이 조회했다가 작업이 완료되면서 감소
Block I/O (블록 입출력):
- 데이터베이스 블록 입출력에서 Read(읽기)와 Hit(히트)에 대한 정보
- 읽기 작업이 초기에는 상당히 활발하다가 감소하는 경향
- 이는 초반에 데이터 읽기 작업이 집중적으로 이루어졌다는 것을 의미

모니터링 툴에서 갑자기 지표들이 감소한 이유는 에러를 우선적으로 처리하고 다음 테스트를 진행하기 위해
테스트를 중지했기 때문이다.

위에서 분석한 문제 원인과 해결 방안을 통해서 내린 결론은

HikariCP의 최대 풀 크기가 10으로 고정되어 있어 스레드가 대기를 하다가 타임아웃이 발생해 에러가 발생한 것이다.

그래서 이를 20으로 조정하고 2번째 테스트를 진행했다.

결과는 다음 글에..

[Now, Here] 성능 테스트_성능 목표 잡기

겨울단추 — Mon, 16 Sep 2024 22:33:54 +0900

안녕하세요!
이전에 언급했던 것처럼 Now, Here 글로 다시 찾아왔습니다.
현재 출시가 얼마 남지 않았고, 대부분의 기능 구현은 완료한 상태입니다.
그래서 성능 테스트를 통해 웹 서비스의 성능을 측정하고, 병목지점을 찾아 성능 개선을 이루는 경험을 공유합니다.

성능 테스트 가이드 시리즈 / 클릭 시 이동
1. 성능 테스트_성능 목표 잡기
2. 성능 테스트_HikariCP의 연결 최대 풀 설정
3. 성능 테스트_Caffeine 캐시 설정 및 적용
4. 성능 테스트_인덱싱과 트랜잭션 관리 최적화
5. 성능 테스트_하드웨어 리소스 업그레이드

성능 목표 잡기

성능이 좋다는 의미는 무엇인가?

보통 웹 성능이 좋다는 의미는 웹사이트에 접속했을 때 이들이 원하는 콘텐츠가 로딩될 때까지 걸리는

Average response time이 적다는 것을 의미한다.

그래서 웹 성능이 좋다 → 콘텐츠가 빨리 로딩된다로 해석할 수 있다.

그렇다면 웹 성능 예산은? 목표로 둔 웹 로딩 시간을 의미한다.

세부적으로는 여러 가지 과정에 대하여 최대 허용 시간을 배분하는 것을 의미하는데

총예산 3초, DB 조회 1초, API 요청 처리는 0.5초 이런 식이다.

또한 성능 개선은 비용, 시간이 많이 드는 작업이라 모든 서비스 페이지를 빠르게 만드는 것은 ROI가 좋지 않고

가장 중요하고, 성능이 안 좋은 페이지에 성능 개선을 하는 것이 권장된다.

사진에서 보다시피 로컬 DB, 서버에서 간단하게 테스트했을 때

가장 많은 비즈니스 로직을 가지고 있는 매칭 엔티티와 관련된 API에서 가장 느린 로딩 시간이 측정됐기 때문에

해당 부분에 원인 분석 및 성능 개선을 하기로 했다.

웹 성능 예산을 잡고 최적화하는 이유는 사용자들이 해당 성능에 만족하지 못하는 경우

서비스를 이탈할 확률이 높아지기 때문이다.

하지만 아무리 좋은 성능 목표를 가지고 있더라도 이를 위한 비용이 현재 서비스의 수익이나 리소스에 따라서

많이 좌우되기 때문에 적절한 성능 목표를 잡는 것이 중요하다.

우리 서비스의 현재 목표는 2학기 대학교 축제에 MVP를 출시해 시장 반응을 보기 위함이고

MVP에는 결제 기능을 넣지 않아 오히려 기부를 하며…? 서비스를 하는 것이라

더욱 오버스러운 성능 예산을 잡지 않도록 하는 것이 중요했다.

목표 지표

웹 성능을 측정하기 위한 지표는 여러 가지가 있다.

TTI(Time To Interative)
- 사용자가 상호작용이 가능해지기까지 걸리는 시간
LCP(Largest Contentful Paint)
- 가장 큰 비주얼 콘텐츠가 표시되는 시간
FCP(First Contentful Paint)
- 첫 번째 비주얼 콘텐츠가 표시되는 시간
TTFB (Time To First Byte)
- 서버가 첫 번째 바이트를 보내는 데 걸리는 시간을 측정하며, 이는 서버의 응답 속도 표현

이 중에서 우리는 서버의 입장에서 TTFB를 기준으로 한 것이고

그중에서 평균 응답 시간과 백분율 90까지의 응답 시간을 기준으로 측정했다.

응답 시간과 관련된 설명은 아래와 같다.

Perplexity에서의 설명

주요 통계
- 모바일 웹사이트 방문자의 53%는 웹페이지 로딩에 3초 이상 걸리면 해당 사이트를 떠납니다.
- 평균적으로 모바일 사이트의 로딩 시간은 3G 연결에서 19초, 4G 연결에서 14초입니다.
로딩 속도의 영향
- 5초 내에 로딩되는 모바일 사이트는 19초가 걸리는 사이트에 비해 다음과 같은 이점이 있습니다:
  - 25% 더 높은 광고 가시성
  - 70% 더 긴 평균 세션 시간
  - 35% 더 낮은 이탈률
- 페이지 로딩 시간이 1초에서 3초로 증가하면 이탈 확률이 32% 증가합니다.
사용자 기대치
- 인터넷 사용자의 약 50%는 웹페이지 로딩 시간이 2초 미만이기를 기대합니다.
- 성능이 좋지 않은 경험을 한 사용자의 약 80%는 해당 페이지를 영구적으로 피하고 다시 방문하지 않습니다.
참고 링크

이 정보를 바탕으로 약 90 퍼센트까지의 TTFB가 3초 이내인 것을 목표로 두었다.

테스트

테스트란, 특정한 상황을 가정하고 발생하는 문제를 사전에 찾기 위한 작업이다.

성능 테스트란 특히 트래픽이 많은 상황에서 발생하는 문제를 찾는 작업이다.

트래픽이란?

1초 동안 서버로 요청되는 수이고, RPS(Request Per Second)로 표현된다

트래픽이 많아서 생길 수 있는 문제는

서버의 리소스 부족으로 인해 사용자의 요청에 응답 X
서비스 처리 속도가 느려진다.

이런 문제에 대비하기 위해 성능 테스트를 진행하고, 문제를 미리 찾아내 해결하는 것을 목표로 한다.

이를 통해서 고객 중심의 서비스와 고가용성을 만족하는 서비스를 구축할 수 있다.

트래픽 산정

Now, Here 프로젝트는 축제 때 무작위 번호팅을 좀 더 쉽게 이용할 수 있게 만든 것으로

벤트 단위로 서비스와 데이터를 운영한다.

가장 메인 로직이자 TTFB가 가장 높게 나온 매칭과 관련해서

한 대학교의 축제에서 50명씩, 총 10개의 축제에 동의를 구해 프로젝트를 진행했다고 가정한다.

최대 가능한 매칭 수 계산:

총 유저 수: 500명
각 유저는 자신을 제외한 499명과 매칭 가능
총 가능한 매칭 수: 500 * 499 / 2 = 124,750개 (양방향 매칭 고려)가 된다.

하지만 부하를 주는 것이 목표이고, 양방향 매칭이 가능하다는 것을 생각해

25만 건의 매칭 데이터를 가지고 테스트를 진행했다.

이 정도 규모의 서비스에 테스트를 진행할 때는 postman의 유료 기능 중 하나인

api 성능 테스트로 충분하다는 판단이 들어 이를 통해 진행했다.

또한 postgreSQL을 사용 중이라, DB 관련해서는 pgAdmin4에 있는

대시보드를 통해 db 성능을 모니터링하였다.

목표

성능 테스트를 통해서 문제 원인을 파악하고 이를 성능 개선하는 것이 목표다.

문제 원인을 파악하기 위해서 k6, Grafana를 이용해 테스트 환경을 구축하고 실제로 사용해 봤지만

이 정도 규모의 서비스와 테스트에는

API 서버 → Postman의 API Performance Testing 기능

DB 서버 → pgAdmin4의 Dashboard

를 통해서 모니터링하는 것이 시간/비용적 측면에서 적절하다고 판단해 진행했다.

성능 개선에 가장 중요한 것은 리소스이고, 이를 위한 방법은 크게 두 가지 있다.

비효율적인 프로세스 개선 / 리소스 사용 줄이기
- 낮은 시간 복잡도를 가진 알고리즘을 사용
- 캐시를 사용
- 아키텍처를 개선
- 비동기 처리
- 인덱싱
리소스 업그레이드 / 리소스 용량 늘리기
- 하드웨어 리소스 측면에서는 CPU 코어를 늘리거나 메모리 용량을 늘릴 수 있다.
- 소프트웨어 리소스 측면에서는 락 범위를 최소화해 락을 잡는 시간을 줄이던가, 여러 개로 락을 나눌 수 있다.

현재 우리의 테스트 환경은 아래와 같은데

실제로 배포할 때 환경

API 서버:

총 2개
각각 VM OCPU 1/8개
1GB 메모리
총 디스크 100GB

DB 서버:

총 2개
GCP의 vCPU core 2
메모리 8GB
SSD 10GB (Master - Slave 구조, CUD / R을 나눠서 사용)

테스트할 때 환경

API 서버:

프로세서	Intel(R) Core(TM) Ultra 7 16코어 
설치된 RAM 32.0GB
디스크 1TB

DB 서버:

cloudtype의 vCPU 프리티어(측정 불가 최소 자원), 메모리 512MB, HDD 1GB

사양에 대한 클로드의 평가

두 환경을 비교해 보면 다음과 같은 차이점이 있습니다

API 서버:
실제 배포: 2개의 서버, 각각 1/8 OCPU, 1GB 메모리 (총 1/4 OCPU, 2GB 메모리)
테스트: 16 코어 프로세서, 32GB RAM, 1TB 디스크

DB 서버:실제 배포: 2개의 서버, 각각 2 vCPU, 8GB 메모리, 10GB SSD
테스트: 최소 자원 (vCPU 측정 불가), 512MB 메모리, 1GB HDD

총 성능 비교:
API 서버: 테스트 환경이 압도적으로 우수합니다.
16 코어 프로세서와 32GB RAM은 실제 배포 환경의 1/4 OCPU와 2GB 메모리를 크게 상회합니다.

DB 서버: 실제 배포 환경이 훨씬 우수합니다.
총 4 vCPU, 16GB RAM, 20GB SSD는 테스트 환경의 최소 자원(512MB RAM, 1GB HDD)을 크게 능가합니다.

결론:
총체적인 성능을 고려할 때 실제 배포 환경이 더 우수할 가능성이 높습니다.
데이터베이스 성능이 전체 시스템 성능에 큰 영향을 미치는 경우가 많기 때문입니다.
또한, 실제 배포 환경은 이중화 구성으로 안정성도 더 높습니다.

→ 내 판단과 더불어 클로드가 판단 하에도 DB의 성능이 백엔드 전체 성능을 좌우하는 경우가 많다고 생각하는데

테스트 환경이 실제 배포 환경보다 훨씬 DB 성능이 안 좋기 때문에

더 열악한 환경 속에서 테스트하는 것이라 훨씬 유의미하다고 생각했다.

결론적으로 현재 서비스를 운용할 때 사용할 하드웨어 리소스는 한정되어 있기 때문에
최대한 비효율적인 프로세스 개선을 통해서 리소스 사용을 줄이는 것을 목표로 하였다.

또한 이미 테스트하는 환경이 실제 운용 환경보다 안 좋은 환경으로 예상하기 때문에

하드웨어 리소스는 자연스럽게 개선될 것으로 예상한다.(마지막에 밝혀짐)

오픈소스 기여하기 / Open Source Contribute - Spring AI

겨울단추 — Sun, 8 Sep 2024 23:09:15 +0900

안녕하세요!
이번 주제는 오픈소스에 기여해 보는 경험을 공유하기 위해서 왔습니다.
프로젝트를 진행하면서 어느 정도 기능 개발에 익숙해져서 자신감에 차 있던 저는
오픈소스를 이해하고, 이를 위해서 테스트 코드를 작성하는 과정에서 우매함의 봉우리에 있다는 것을 깨달았습니다.
덕분에 개발에 대해 더욱 진지하고 열심히 해야겠다는 좋은 다짐을 하게 되었는데요.
그 과정을 설명드리겠습니다.

도전하게 된 배경

제가 주로 사용하는 Spring boot, JPA 등등 오픈소스들은 모든 것이 다 소스코드가 공개되어 있기에

저도 언젠가 공부하고 기여해보고 싶다는 생각을 했습니다.

하지만 뭔가 대단한 사람들만 오픈소스를 개발하거나 기여하는 것 같고,

당장 할 일들이 너무 많아서 도전하지 못하고 있던 중에
인제 님의 오픈소스 멘토링 6기 모집 글과 오픈소스 멘토링 컨트리뷰션 아카데미 체험형 2기 모집글을 보게 되었습니다.

그래서 둘 다 지원했고, 감사하게도 합격하여서 오픈소스에 도전할 좋은 기회를 얻었습니다.

그중 오늘은 인제님의 오픈소스 멘토링 6기를 통해 Spring AI의 이슈를 선정하고, 디버깅하고 PR을 올린 얘기입니다.

(추후에 merged 되면 내용을 추가하겠습니다)

오픈소스 결정

우선 도전해보고 싶은 오픈소스를 결정해야 합니다.

보통 자기가 많이 써본 오픈소스를 도전하는 것이 가장 좋다고 하셨습니다만
그냥 관심 많은 오픈소스에 도전하는 것도 좋은 방법인 것 같습니다.

저의 경우 자주 사용하는 Spring-data-JPA와
지인이신 현준 님이 기여하신 글을 통해서 관심 있었던 Spring AI 두 개를 선정하였습니다.

이슈 선정

인제 님의 이슈 선정 가이드에 적혀있듯이 이슈 선정이 오픈소스 기여하는데 가장 중요한 부분입니다.

선정하는 조건을 정리하자면

1. 명확한 동기부여가 있는 오픈소스 이슈

2. 해결해야 할 목표, 제안하는 해결 방법, 예시 코드, 테스트 코드 등 재현 방법이 적혀 있을 것

3. 이슈 라벨을 활용 - waiting-for-triage처럼 메인테이너가 확인하지 않는 건 제외, bug, core,

enhancement와 같이 대표적인 라벨 중에서 메인테이너가 확인한 경우를 선정

4. 댓글이 5~10개 사이

물론 추후에는 단순히 재밌어 보이는 이슈를 선정해서 해도 되겠지만, 저처럼 처음 도전해 보는 경우에는

위와 같은 조건을 참고하여 선정하는 게 merged 될 가능성이 높습니다.

그래서 저는 아래와 같이 2가지 이슈를 선정하여 멘토님과 상의를 했고

단기간 내 해결할 수 있을 것 같은 Spring AI의 1292번 이슈를 선정하였습니다.

1. https://github.com/spring-projects/spring-data-jpa/issues/3144

enhancement, 댓글 3개, 메인테이너가 확인한 사항

2. https://github.com/spring-projects/spring-ai/issues/1292

메인테이너가 확인하고, 상세한 설명

디버깅

이제 선정하였으니 오픈소스 기여의 거의 마무리가 머지않았습니다..!라고 하지만
사실 이때부터 저에게는 고난의 시작이었습니다.

협업을 여러 번 했지만 오픈소스처럼 아예 모르는 누군가의 코드를 이렇게 분석해 본 적이 처음이었고

테스트 코드의 중요성은 익히 알지만 빠르게 개발하다 보니 실제 코드에 api 요청해서 테스트 케이스대로

작동하는지 확인하는 방식으로 테스트했지, 실제 테스트 코드 작성에는 굉장히 미숙한 상황이었습니다.

그래서 이슈를 남겨주신 분이 자세하게 남겨주신 내용과 코드 분석, 그리고 인제님의 조언으로

Spring AI를 이용할 때 MiniMax 모델을 사용하는 경우 표준 형식으로 프롬프팅하고 반환받으면

message 형태로 받는데 web_search 형식으로 프롬프팅 하면

messages 형태로 반환받아서 생기는 문제라는 걸 파악했습니다.

그래도 이를 제대로 검증하기 위해서 test 코드를 작성해서 해야 하는데, 이 부분에서 애를 많이 먹었습니다.

테스트 코드 작성을 제대로 해보는 것은 거의 처음이라 매우 오래 걸렸고

원하는 대로 구현이 안 되는 경우가 많았습니다.

하지만 결국 web_search 방식으로 검색하는 경우 에러가 발생하는 구간을

mocking을 통한 유닛테스트를 통하여 발견하였습니다.

에러 메시지에서 볼 수 있듯이

choice의 message()가 null 값인데 그 이후에 message의 role을 조회해서 생기는 문제입니다.

또한 이슈에 적혀있는 문제는 null 값뿐만 아니라, message와 messages가 아니라 항상 일관된 형식으로

반환해야 한다는 의견이었습니다.

결론적으로

표준 응답은 choice.message()에 정보가 있었지만, web search 응답은 choice.messages()에 정보가 있었습니다.
role 정보 추출 시 null 체크가 불충분했습니다.

이를 바탕으로 디버깅을 시작했습니다.

수정

그래서 이를 위해서 null 체크와 choice.message()를 적절하게 처리하는 방식으로 수정했습니다.

좀 더 정리하자면,

call 메서드를 수정하여 choice.message()와 choice.messages() 모두를 처리할 수 있게 했습니다.
null 체크를 강화하고, content와 role에 대한 기본값을 제공했습니다.
buildGeneration 메서드를 추출하여 책임을 분리하였습니다.

기존 코드

@Override
	public ChatResponse call(Prompt prompt) {
		ChatCompletionRequest request = createRequest(prompt, false);

		ResponseEntity<ChatCompletion> completionEntity = this.retryTemplate
			.execute(ctx -> this.miniMaxApi.chatCompletionEntity(request));

		var chatCompletion = completionEntity.getBody();

		if (chatCompletion == null) {
			logger.warn("No chat completion returned for prompt: {}", prompt);
			return new ChatResponse(List.of());
		}

		List<Choice> choices = chatCompletion.choices();
		if (choices == null) {
			logger.warn("No choices returned for prompt: {}, because: {}}", prompt,
					chatCompletion.baseResponse().message());
			return new ChatResponse(List.of());
		}

		List<Generation> generations = choices.stream().map(choice -> {
			// @formatter:off
			Map<String, Object> metadata = Map.of(
					"id", chatCompletion.id(),
					"role", choice.message().role() != null ? choice.message().role().name() : "",
					"finishReason", choice.finishReason() != null ? choice.finishReason().name() : "");
			// @formatter:on
			return buildGeneration(choice, metadata);
		}).toList();

		ChatResponse chatResponse = new ChatResponse(generations, from(completionEntity.getBody()));

		if (isToolCall(chatResponse,
				Set.of(ChatCompletionFinishReason.TOOL_CALLS.name(), ChatCompletionFinishReason.STOP.name()))) {
			var toolCallConversation = handleToolCalls(prompt, chatResponse);
			// Recursively call the call method with the tool call message
			// conversation that contains the call responses.
			return this.call(new Prompt(toolCallConversation, prompt.getOptions()));
		}

		return chatResponse;
	}

수정된 코드

public class MiniMaxChatModel extends AbstractToolCallSupport implements ChatModel, StreamingChatModel {
    // 기존 코드 유지

    @Override
    public ChatResponse call(Prompt prompt) {
        // 기존 코드 유지

        List<Generation> generations = choices.stream().map(choice -> {
            ChatCompletionMessage message;
            if (choice.message() != null) {
                message = choice.message();
            } else if (choice.messages() != null && !choice.messages().isEmpty()) {
                message = choice.messages().get(0);
            } else {
                logger.warn("No message or messages found in choice: {}", choice);
                return null;
            }

            String content = message.content();
            String role = message.role() != null ? message.role().name() : "";

            Map<String, Object> metadata = Map.of(
                    "id", chatCompletion.id(),
                    "role", role,
                    "finishReason", choice.finishReason() != null ? choice.finishReason().name() : "");

            return buildGeneration(message, metadata);
        }).filter(Objects::nonNull).toList();

        // 나머지 코드 유지
    }

    private static Generation buildGeneration(ChatCompletionMessage message, Map<String, Object> metadata) {
        List<AssistantMessage.ToolCall> toolCalls = message.toolCalls() == null ? List.of()
                : message.toolCalls().stream()
                    .map(toolCall -> new AssistantMessage.ToolCall(toolCall.id(), "function",
                            toolCall.function().name(), toolCall.function().arguments()))
                    .toList();

        var assistantMessage = new AssistantMessage(message.content(), metadata, toolCalls);
        String finishReason = (String) metadata.get("finishReason");
        var generationMetadata = ChatGenerationMetadata.from(finishReason, null);
        return new Generation(assistantMessage, generationMetadata);
    }

    // 나머지 코드 유지
}

테스트

이후 이렇게 제대로 작동하는 것을 볼 수 있습니다.

PR 작성

그리고 이후에

1. 변경 사항의 요약

2. 주요 변경 사항에 대한 상세 설명

3. 테스트 방법 및 검증 단계

4. 관련된 이슈에 대한 언급

순으로 PR을 작성하였습니다.

아래는 PR 링크입니다.

fix: Improve MiniMaxChatModel to handle Web Search responses by jun10920 · Pull Request #1324 · spring-projects/spring-ai

Summary This PR updates the MiniMaxChatModel class to properly handle both standard and web search response formats from the MiniMax API. It also improves overall null safety throughout the respons...

github.com

아래는 좀 더 PR 내용을 이해하기 쉽게, 한글로 번역한 글입니다.

# MiniMaxChatModel의 웹 검색 응답 처리 개선

## 요약
이 PR은 MiniMax API의 표준 및 웹 검색 응답 형식을 모두 적절히 처리하도록 `MiniMaxChatModel` 클래스를 업데이트합니다. 또한 응답 처리 로직 전반에 걸쳐 null 안전성을 개선하고 `MiniMaxApi` 클래스에 설명 주석을 추가합니다.

## 변경 사항
1. `MiniMaxChatModel`의 `call` 메서드를 업데이트하여 `choice.message()`와 `choice.messages()` 모두 처리합니다.
2. 메시지 내용과 역할 정보에 대한 null 체크를 개선했습니다.
3. 다양한 응답 형식을 처리하기 위해 `buildGeneration` 메서드를 리팩터링 했습니다.
4. 유효한 메시지가 없는 경우에 대한 오류 로깅을 강화했습니다.
5. 웹 검색 응답의 `messages` 필드에 관한 설명 주석을 `MiniMaxApi` 클래스에 추가했습니다.

## 상세 설명

### MiniMaxChatModel 변경 사항
`MiniMaxChatModel`의 `call` 메서드가 표준 및 웹 검색 응답 형식을 모두 처리하도록 업데이트되었습니다:

```java
List <Generation> generations = choices.stream(). map(choice -> {
    ChatCompletionMessage message;
    if (choice.message()!= null) {
        message = choice.message();
    } else if (choice.messages()!= null &&! choice.messages(). isEmpty()) {
        message = choice.messages(). get(0);
    } else {
        logger.warn("No message or messages found in choice: {}", choice);
        return null;
    }
    //... 메서드의 나머지 부분
}). filter(Objects::nonNull). toList();
```

이 변경으로 모델은 `message`와 `messages` 필드를 모두 처리할 수 있게 되어, 표준 및 웹 검색 메서드 간의 응답 형식 불일치를 수용합니다.

### MiniMaxApi 변경 사항
`MiniMaxApi` 클래스에 `messages` 필드의 목적을 명확히 하는 설명 주석을 추가했습니다:

```java
/**
* @param messages 모델이 생성한 채팅 완성 메시지 목록. 웹 검색 응답에서 사용됩니다.
*                 이 필드는 표준 메서드와 웹 검색 메소드 간의 응답 형식 불일치를
*                 처리하기 위해 사용됩니다.
*/
```

이러한 주석들은 `MiniMaxApi` 클래스의 관련 부분에 추가되어 코드 이해도와 유지보수성을 향상합니다.

## 테스팅
- `MiniMaxChatModelWebSearchTest`를 업데이트하여 표준 및 웹 검색 응답 형식을 모두 다룹니다.
- null 메시지 시나리오에 대한 테스트 케이스를 추가했습니다.
- 모든 기존 테스트가 새로운 구현으로 통과합니다.

## 테스트 방법
1. `MiniMaxChatModelWebSearchTest` 클래스를 실행합니다.
2. `testStandardResponseHandling()`과 `testWebSearchResponseHandling()` 모두 통과하는지 확인합니다.
3. `MiniMaxChatModelNullSafetyTest`의 null 안전성 테스트가 통과하는지 확인합니다.

## 관련 이슈
#1292 해결

## 추가 참고 사항
1. 이 PR은 MiniMax API의 다양한 응답 형식 처리의 불일치를 해결합니다. 잠재적인 NullPointerException을 해결하고 다양한 응답 유형에 대해 더 일관된 동작을 제공합니다.
2. 웹 검색 응답의 `messages` 필드에 대한 정보를 공식 MiniMax API 문서에 포함시킬 것을 제안합니다. 이는 다른 개발자들이 다양한 응답 형식을 이해하고 올바르게 처리하는 데 도움이 될 것입니다.
3. 공식 문서에 다음 내용을 추가하는 것을 고려해 주세요:
   "웹 검색 기능을 사용할 때, API는 `message` 필드 대신 `messages` 필드로 응답을 반환할 수 있습니다. 완전한 호환성을 위해 클라이언트는 두 형식을 모두 처리할 준비가 되어 있어야 합니다."

## 다음 단계
- 이러한 변경 사항을 반영하고 다양한 응답 형식 처리에 대한 명확한 지침을 제공하도록 공식 MiniMax API 문서를 업데이트합니다.
- 클라이언트 측 처리를 간소화하기 위해 향후 API 버전에서 응답 형식을 표준화하는 것을 고려합니다.

마무리하며

제가 이번 오픈소스 기여 경험을 통해서 느낀 것이 몇 가지 있습니다.

1. 우매함의 봉우리

2. 오픈소스 기여 도전 가능성 & 오픈소스 코드 분석을 통한 공부

3. 테스트 코드의 중요성

4. 서로 공유하고 돕는 개발문화에 대한 감사

1. 우매함의 봉우리

우선, 위에서 말한 것과 같이 오픈소스 분석과 테스트 코드에 매우 미숙한 제 모습을 보면서

최근 프로젝트 진행하면서 기능 개발을 어느 정도 한다는 것에 흐뭇해하던 제가 웃겼습니다.

아직 한참 부족하고 배울 것이 많다는 것을 깨달았고, 적절한 시기에 이런 깨달음을 얻게 되어

정말 좋은 경험을 했다고 생각합니다.

2. 오픈소스 기여 도전 가능성

하지만 오픈소스 기여 자체는 생각한 것만큼..? 개발 분야의 거장들만 하는 것이 아니라 충분히 일반인들도

도전할 수 있다는 것을 알게 되었습니다.

좋은 개발자들의 코드를 읽으면서 좋은 글을 읽어야 좋은 글을 쓸 수 있는 것처럼,

오픈소스를 통해 좋은 코드를 많이 읽고 작성할 수 있는 개발자가 되어야겠다는 생각을 했습니다.

3. 테스트 코드의 중요성

제가 규모가 커지면 커질수록, 실제로 로컬에서 build가 되지 않는 경우도 빈번하고

특정 기능에만 테스트가 필요한 경우 있습니다.

또한 협업을 하다 보면 다른 사람의 코드를 인용해 테스트하는 경우에는 그런 경우가 더 많은데

이번에 현업에서 겪을 법한 일을 간접적으로 경험하면서 테스트 코드의 중요성을 한 번 더 깨닫게 된 것 같습니다.

또한 이번에 도전한 이슈는 Spring AI의 다른 모든 model은 message로 통일되어 있는데,

MiniMax만 messages가 하나 더 있어서 생긴 이슈였습니다.

아마 메인테이너 분들도 이를 정확히 인지하셨다면

이전에 올라왔던 PR을 통해서 반영된 이 내용을 반영하지 않으셨을 텐데

이전 분이 이 내용을 추가하면서 제대로 된 주석이나 공식 문서의 설명 없이 진행하셔서 그대로 반영되었습니다.

에러가 나올 법한 부분들을 테스트 코드를 작성해 검증했다면 이런 상황을 피할 수 있지 않았을까 생각합니다.

오픈소스의 특성상 한 번 merged 되면 다시 되돌릴 수 없기에, 이렇게 철저해야 하는 경우

더욱 테스트 코드를 잘 작성하여 제대로 검증하고 진행하는 것이 중요하겠다는 생각을 했습니다.

4. 서로 공유하고 돕는 개발문화에 대한 감사

마지막으로, 이번 경험을 하게 해 주신 인제님께 감사했습니다.

다른 분야는 본인만의 스킬이나 경험을 숨기고 암암리에 조용히 공유하는 경우가 많습니다.

하지만 개발은 서로가 공유하지 않으면 안 된다는 것을 잘 알기 때문에

굉장히 공유하는 부분에 있어 열려있고 특히 깃허브는 그런 교류의 장이 되고 있습니다.

인제님께서는 오픈소스 경험이 굉장히 많으신 컨트리뷰터이시고, 충분히 주말에는 본인을 위해서

휴식을 가지실만한데도 남는 시간을 할애해 멘토팅을 진행하시면서

한국의 오픈소스 문화 개선을 위해서 기여하시고 계십니다.

덕분에 저를 비롯해 같이 멘토링을 받으신 분들도 오픈소스 이슈 선정 - 디버깅 - PR 작성하는

하나의 흐름을 경험할 수 있게 되었고 오픈소스에 한 발 더 가까워졌습니다.

내수 시장의 한계를 아시고, 한국인들의 오픈소스를 통한 글로벌 시장 진출까지도 생각하시며

멘토링부터 시작해서 많은 것을 준비 중이신 인제님이 정말 대단하시다는 생각이 들었고,

다시 한번 감사하다는 말씀드리고 싶습니다.

저도 바로 테스트 코드 학습과 오픈소스 기여에 바로 도전해 볼 생각입니다!

메인테이너가 확인하고, 논의가 진행되고 merged 되는 때까지 시간이 좀 걸리겠지만
컨트리뷰터가 된다면 내용을 추가하러 오겠습니다!

긴 글 읽어주셔서 감사합니다.,

[Now, Here] 실시간 MBTI 데이터 기반 매칭 알고리즘 최적화: 동적 가중치 조정과 데이터 분석 자동화

겨울단추 — Fri, 6 Sep 2024 00:50:48 +0900

오랜만에 블로그에 글을 씁니다!
요즘 취업 준비로 바쁘게 지내고 있지만, 이전보다 더 개발에 몰입하며 지내서 만족하며 열심히 살고 있습니다.
이번 글에서는 10월에 있을 대학교 축제를 겨냥해 기획하고 개발 중인 매칭 웹앱 플랫폼 "Now, Here"의 백엔드 개발 과정에서
고민했던 내용을 공유하려 합니다.
특히, 이번에는 실시간 매칭 알고리즘과 데이터 기반 의사결정 방식을 도입한 경험을 소개하려고 합니다.
앞으로 3~4개의 Now, Here 관련 글을 올릴 예정이니 많은 관심 부탁드립니다!

Situation

과거에 제가 TrueEcho를 개발하면서 유저들 사이에서 친구를 추천하는 FOF 알고리즘을 구현한 적이 있습니다.
관련 글 링크

당시에는 친구의 친구들을 해시맵 형태로 저장하여 중복되는 친구가 많은 FoF(친구의 친구)가 사용자가 알 확률이 높다고 생각해서 해당 방식을 통해 구현했습니다.

하지만 이번에는 좀 더 실제 유저들의 피드백을 받고, 이를 통해 데이터 기반 알고리즘을 구현하고 싶었습니다.

처음에는 매칭시켜 줄 멤버 추천을 위해 MBTI 선호도를 조사하는 설문조사를 진행했습니다

우선 대학교 축제에서 사용할 목적이라 비슷한 나이대(20대)를 타깃으로 조사했습니다.

감사하게도 총 82명 정도 참여해 주셨지만 각 성별 당 MBTI의 선호도는 총 36가지라
82/36 = 2.28 개 정도의 조사로는 유의미한 결과가 아니라고 판단해 다른 방법을 찾아야 했습니다.

그래서 실시간으로 매칭되는 정보를 가지고 성별 -> MBTI에 따라 유저를 추천하는 가중치를 조정하는 방법을 생각했습니다.

그리고 매일 매칭된 전체 데이터를 분석하여 매칭 성공률을 계산하고,
어제와 오늘의 매칭률을 비교해 얼마나 지표가 개선되었는지 자동으로 파악할 수 있으면 좋겠다고 생각했습니다.

이렇게 한다면 실시간으로 유저들의 실제 활동으로부터 피드백 받아 연인의 MBTI 선호도를 파악 및 반영하고

데이터 수집과 분석까지 자동화할 수 있다는 이점이 예상됐습니다.

Task

이 목표들을 위해서 크게 세 가지 나누어 과제를 정했습니다.

1. 가중치 반영

- 매칭 성공률을 바탕으로 실시간 가중치 조정 로직을 설계

2. 데이터 저장 및 통계 처리

- 가중치를 실시간으로 업데이트하기 위한 저장소와 이 데이터를 분석하기 위한 저장소를 나누어 성능 최적화

- 이를 위해서 매번 가중치를 DB를 통해서 가져오는 것이 아니라 실시간 가중치는 ConcurrentMap을 통해서 저장

- 오늘 하루의 총데이터는 DB에 저장해서 데이터 분석에 사용하고, 데이터의 고가용성을 보장

3. 하루간 데이터 분석을 통한 가중치 반영과 인사이트 도출 자동화

- 하루 단위로 매칭 성공률 데이터를 저장하고 어제와의 증감 추이를 저장하여 인사이트 도출하도록 구현

- 실시간 선호도 반영과 더불어 하루 총데이터의 분석을 통한 MBTI 선호도를 반영하여 실시간 - 장기간 데이터를 모두 반영

Action

가중치 반영 로직 설계

가중치를 반영하는 매칭 알고리즘은 아래와 같이 설계되었습니다.
먼저 잠재적 매칭 후보를 DB에서 가져온 후, 무작위로 정렬한 후보들 중 가중치를 반영한 스코어가 높은 사람을 선택합니다.

@Override
public List<Member> findMembersByMemberIdAndEventIdAndGender(Long memberId, Long eventId, Gender gender) {
  try {
    return em.createQuery("SELECT m FROM Member m " +
                    "WHERE m.event.id = :eventId " +
                    "AND m.gender = :gender " +
                    "AND m.id != :memberId " +
                    "AND NOT EXISTS (" +
                    "   SELECT 1 FROM Matching match " +
                    "   WHERE (match.senderMemberId = :memberId AND match.receiverMemberId = m.id) " +
                    "   OR (match.receiverMemberId = :memberId AND match.senderMemberId = m.id) " +
                    ") " +
                    "AND m.active = true " +
                    "ORDER BY random()", Member.class)  // 무작위 정렬
            .setParameter("memberId", memberId)
            .setParameter("eventId", eventId)
            .setParameter("gender", gender)
            .setMaxResults(10)  // 최대 10명 선택
            .getResultList();
  } catch (Exception e) {
    log.error("Failed to find members by memberId, eventId and gender: {}", e.getMessage());
    throw new RuntimeException("Failed to find members", e);
  }
}

우선 데이터베이스에서 random() 함수를 통해서 무작위로 10명을 데려왔습니다.
이 중에서 가장 가중치를 통해 구한 스코어가 높은 사람을 뽑는 방식으로 구현하였습니다.

// 가중치를 반영한 매칭 결과 계산
List<PreferenceBasedMBTIMatching.MatchResult> matchResults = matcher.findMatches(
        memberMbti,
        member.getGender(),
        potentialMatches.stream()
                .map(PreferenceBasedMBTIMatching.PotentialMatch::new)  // Member 객체를 직접 PotentialMatch로 변환
                .toList()
);

가중치 계산하는 부분은, PreferenceBasedMBTIMatching 클래스를 통해서 구현했습니다.
해당 클래스 안에는 남성과 여성이 각각 mbti 선호도를 저장하기 위해서 ConcurrentHashmap을 사용했습니다.
*멀티스레드 환경에서 동시성 문제에 안전하기 때문에 ConcurrentHashmap 사용

 // 남성과 여성 각각의 MBTI 선호도를 저장하는 ConcurrentHashMap
private final Map<MBTI, Map<MBTI, Double>> malePreferences = new ConcurrentHashMap<>();
private final Map<MBTI, Map<MBTI, Double>> femalePreferences = new ConcurrentHashMap<>();

초기화 시에는 누적식으로 저장되어 있는 각 성별의 각 MBTI 가중치 정보를 가져와 반영합니다.
만약 이전의 데이터가 없는 경우(첫 날인 경우) 모든 케이스의 가중치를 0.5로 초기화합니다.

 // 남성과 여성 각각의 MBTI 선호도를 저장하는 ConcurrentHashMap
@PostConstruct
public void initializeWeights() {
  MBTI[] mbtiTypes = MBTI.values();

  // 어제의 날짜를 구함
  LocalDate yesterday = LocalDate.now().minusDays(1);

  // DB에서 어제 날짜의 가중치만 불러오기
  List<MatchingStatistics> yesterdayStatistics = matchingStatisticsRepository.findByDate(yesterday);

  // 남성과 여성의 가중치 맵 초기화
  for (MBTI mbti : mbtiTypes) {
    malePreferences.putIfAbsent(mbti, new ConcurrentHashMap<>());
    femalePreferences.putIfAbsent(mbti, new ConcurrentHashMap<>());
  }

  // 어제 데이터를 메모리에서 처리하여 남성 및 여성에 대한 가중치 설정
  for (MatchingStatistics stat : yesterdayStatistics) {
    MBTI userMbti = stat.getUserMbti();
    MBTI matchedMbti = stat.getMatchedMbti();
    double weight = stat.getWeight();

    if (stat.getUserGender() == Gender.MALE) {
      malePreferences.get(userMbti).put(matchedMbti, weight);
    } else if (stat.getUserGender() == Gender.FEMALE) {
      femalePreferences.get(userMbti).put(matchedMbti, weight);
    }
  }

  // 없는 경우 기본값으로 0.5를 설정
  for (MBTI mbti : mbtiTypes) {
    for (MBTI otherMbti : mbtiTypes) {
      malePreferences.get(mbti).putIfAbsent(otherMbti, 0.5);
      femalePreferences.get(mbti).putIfAbsent(otherMbti, 0.5);
    }
  }
}

가중치를 업데이트하는 메서드는 동적 조정법을 적용했습니다.

// 매칭 성공 여부에 따라 선호도 가중치를 업데이트하는 메서드
public void updatePreferences(MBTI userMbti, MBTI matchedMbti, Gender gender, boolean success) {
  Map<MBTI, Map<MBTI, Double>> preferences = (gender == Gender.MALE) ? malePreferences : femalePreferences;
  preferences.putIfAbsent(userMbti, new HashMap<>());

  // 동적 조정법 : 가중치가 극단에 갈수록 안정성을 높임
  double baseAdjustment = 0.1;
  double currentWeight = preferences.get(userMbti).getOrDefault(matchedMbti, 0.5);
  double dynamicAdjustment = baseAdjustment * (1 - Math.abs(currentWeight - 0.5));
  double adjustment = success ? dynamicAdjustment : -dynamicAdjustment;

  // 상한선과 하한선 설정 (최소 0.2, 최대 0.8)
  double newWeight = Math.max(0.2, Math.min(0.8, currentWeight + adjustment));
  preferences.get(userMbti).put(matchedMbti, newWeight);
}

이는 가중치가 극단으로 갈수록 변동성을 줄여 안정석을 높이는 조정법입니다.
- 동적 조정법을 통한 매칭 알고리즘에 대해 더 설명하자면
  - 선호도 기반 가중치 알고리즘 중에서 지나치게 가중치가 높아지거나 낮아지는 것을 방지하는 알고리즘입니다.
  - 가중치는 0과 1 사이로 설정하여 0.5에 가까울 때는 빠르게, 0과 1에 가까울수록 천천히 변화시키게 구현했습니다.
  - 기본 조정 값(baseAdjustment):
    - 가중치를 조정하는 기본 값은 0.1입니다.
    - 이는 성공적인 매칭 시 가중치가 얼마나 변할지를 결정합니다.
  - 현재 가중치(currentWeight):
    - 현재 저장된 가중치 값을 불러옵니다.
    - 만약 값이 없다면 기본값인 0.5를 사용합니다.
  - 동적 조정 값(dynamicAdjustment):
    - 가중치가 0.5에 가까울수록 크게, 0이나 1에 가까울수록 작게 변화하도록 설정합니다.
    - 구체적으로는 1 - |currentWeight - 0.5|를 계산하여 가중치가 0.5에서 멀어질수록 조정량이 줄어듭니다.
    - 예를 들어, 현재 가중치가 0.5일 경우 조정량은 0.1 * (1 - 0) = 0.1로, 큰 폭의 변화가 일어납니다.
    - 반면에 가중치가 0.9일 경우 0.1 * (1 - 0.4) = 0.06으로 조정량이 줄어듭니다.
  - 매칭 성공 여부에 따른 조정:
    - 매칭이 성공했을 경우에는 가중치를 증가시키고, 실패했을 경우에는 가중치를 감소합니다.
    - 또한 상한선과 하한선을 0.8과 0.2로 설정하여 극단적으로 선택되거나 선택이 안 되는 경우를 미연에 방지합니다.
    - 그래서 위와 같은 동적 조정법을 통해 가중치를 조정하고 난 이후
      실제로 멤버 추천을 어떻게 하는지 아래에 설명하겠습니다.

public List<MatchResult> findMatches(MBTI userMbti, Gender userGender, List<PotentialMatch> potentialMatches) {
  List<MatchResult> results = new ArrayList<>();

  if (userMbti == null || userGender == null) {
    throw new IllegalArgumentException("User MBTI or gender cannot be null");
  }

  for (PotentialMatch match : potentialMatches) {
    if (match.getMbti() == null || match.getGender() == null) {
      continue;
    }

    double userPref = getPreferenceScore(userMbti, match.getMbti(), userGender);
    double matchPref = getPreferenceScore(match.getMbti(), userMbti, match.getGender());
    double score = Math.min(userPref, matchPref);
    log.info("Matched score: {}", score);
    results.add(new MatchResult(match, score));
  }

  results.sort((a, b) -> Double.compare(b.score, a.score));

  return results.stream().limit(2).collect(Collectors.toList());
}

스크린샷과 같이 잠재적 후보들과 나의 성별/MBTI에 따라서 가중치를 확인합니다.
- 이때 score(매칭 가능성)을 구할 때 Math.min() 함수를 사용합니다.
- 이는 양쪽의 선호도가 모두 높아야 유의미하다고 판단해서, 매칭의 안정성을 보장하기 위함입니다.
  * 단방향이 아니라 양방향으로 선호도가 높을 때 선호한다고 판단하기 때문
- 이런 과정을 통해 구한 Score를 통해서 잠재적 매칭 후보들 중을 정렬하여 상위 두 명의 결과만을 반환합니다.
일간 매칭 가중치와 매칭률 증감 저장
- 서버에 저장했으므로 휘발성 데이터이기 때문에, 데이터의 고가용성과 분석을 통한 인사이트를 위해서 MatchingStatistics 엔티티를 사용해, 각 성별과 MBTI별로 가중치를 기록합니다.

@Scheduled(cron = "0 0 0 * * *") // 매일 자정에 실행
@Transactional  // 데이터베이스 트랜잭션 관리
public void updateMatchingWeights() {
  log.info("Starting weight update process...");

  // 어제 날짜의 매칭 데이터를 가져옴
  List<Matching> matchings = matchingRepository.findMatchingsFromYesterday();
  int totalMatches = matchings.size();
  int acceptedMatches = 0;

  for (Matching matching : matchings) {
    Member sender = matching.getSender();
    Member receiver = matching.getReceiver();

    if (sender != null && receiver != null) {
      // 매칭 성공 여부에 따라 가중치를 업데이트
      boolean accepted = matching.getStatus() == Status.ACCEPTED;
      if (accepted) {
        acceptedMatches++;
      }

      matcher.updatePreferences(sender.getMbti(), receiver.getMbti(), sender.getGender(), accepted);
      matcher.updatePreferences(receiver.getMbti(), sender.getMbti(), receiver.getGender(), accepted);

      // 각 성별과 MBTI별로 가중치 기록
      saveMatchingStatistics(sender, receiver);
    }
  }

DailyMatchingRate 엔티티를 통해 오늘 총 매칭률과 어제와 오늘의 매칭률 증감을 계산했습니다.

 // 전체 매칭률 계산
        double matchRate = (totalMatches > 0) ? ((double) acceptedMatches / totalMatches) * 100 : 0;
        log.info("Today's matching rate: {}%", matchRate);

        // 어제의 매칭률을 가져옴
        double yesterdayMatchRate = dailyMatchingRateRepository.findByDate(LocalDate.now().minusDays(1))
                .map(DailyMatchingRate::getMatchRate)
                .orElse(0.0);

        // 매칭률 증감 계산
        double matchRateChange = matchRate - yesterdayMatchRate;

        // 전체 매칭 성공률을 기록 (하루에 한 번)
        saveDailyMatchRate(matchRate, matchRateChange);

스케줄링을 통한 자동화
- 마지막으로 매일 자정에 오늘 자정부터 어제 자정까지의 매칭 데이터를 분석하고, 가중치와 매칭 성공률을 자동으로 저장하도록 설정했습니다.
- 이를 통해 사람이 개입하지 않아도 시스템이 자동으로 데이터를 처리하고 개선할 수 있게 자동화하였습니다.

Result

매칭 알고리즘을 통해서 실시간으로 가중치를 반영하게 되었습니다.
하루 동안의 매칭 성공률을 자동으로 분석 및 기록하여 데이터 분석과 저장을 가능하게 구현하였습니다.
이 데이터를 바탕으로 향후 매칭 알고리즘을 개선하고, 사용자 경험을 더욱 향상할 수 있는 기반을 마련하였습니다.

마무리하며

기본적으로 많은 곳에서 사용하는 기능들과 다르게

아이디어부터 구현하는 로직들을 새로이 고민해야 했기에 쉽지 않은 개발이었습니다.

하지만 알고리즘을 구현하면서 코딩테스트를 풀 때 시간복잡도와 공간복잡도를 고민하며 개발하는 것처럼

DB를 거치지 않고 가중치를 반영하는 방법은 무엇일까?

고가용성을 위해서 데이터를 잃지 않고 누적하는 방법은 무엇일까?

가중치를 조정할 때 어떤 방식으로 할까?

추가로 어떤 엔티티가 필요하고, 기존 프로젝트의 어느 부분에 영향을 미칠까? 등등

많은 고민과 함께 개발하였고, 성공적으로 해내서 매우 기쁩니다.

트루에코 프로젝트를 구현할 때와 다르게 이제 하나의 클래스, 메서드를 작성하더라도 여러 조건과 임팩트를 같이 고려하며 개발을

어느 정도 할 수 있게 된 것 같아 성장했음을 체감한 순간이었던 것 같습니다.

최근 Now, Here에 몰두하여 많은 시간을 쏟아부었고,
해당 과정을 통해서 경험했던 내용들을 공유하러 금방 다시 오겠습니다.

긴 글 읽어주셔서 감사합니다.

개발 혹한기에 개발 시작한 지 1년 만에 카카오 서류/코테/면접 경험하기(수시채용)

겨울단추 — Tue, 30 Jul 2024 15:12:12 +0900

부제: 아직 부족한 것, 앞으로의 공부 방향

객관적으로, 아직 범용적인 스펙만 있고 엣지 포인트가 없는 저에게 과분한 기회가 왔었습니다.
바로 카카오 채용절차입니다.
이후에 코딩테스트도 합격하여 면접까지 봤었습니다만
해당 공고에 충분하게 핏 하지 않아서 더 이상 절차를 진행하지 못했습니다.
처음으로 경험하게 될 대규모 채용인 하반기 공채 전에 좋은 경험이었다고 생각하고
이에 대한 경험을 나눕니다.
(추가로 카카오 수시채용 관련해서는 정보가 별로 없어서 준비하는데 살짝 어려웠어서 도움이 되고자 글을 작성합니다)
(주황색 또는 파란색 단어는 링크가 삽입되어 있습니다)

서류 합격

1학기가 끝나고 여름방학이 시작됐다.

1년간 휴학하고 준사관 시험을 준비했기에, 친한 지인들은 슬슬 취업을 한 상태이다.

졸업과 동시에 취업을 하기 원하는 나이기에

4학년 여름방학이지만 마음이 그리 여유롭지 않았다.

그래서 회고록에 작성한 것과 같이 넓고 얇은 스펙은 어느 정도 완성되어 있기에

종강한 이후부터 지원할만한 공고가 생기면 대부분 지원했다.

수시채용 기간이라 대략 6~70여 곳 정도 지원을 했고 서류합격률은 5% 정도였다.

++ 합격률은 더 낮을 수도 있다. 웬만큼 많이 지원하고 나서는 지원한 내용을 기록하는 것을 그만두었기 때문이다.

그중에서 하나은행 코딩테스트에서 불합격을 통지받은 날,

카카오에서 서류합격을 했다고 이메일을 받았다.

사실 이미 너무 많은 곳에서 서류 불합격 이메일을 받았기 때문에 카카오에서 이메일이 왔을 때

어차피 불합격이라 생각하고 확인하지 않았다.

그리고 하루 뒤에 코딩테스트 안내 이메일을 받고서야 합격인 것을 확인했다.

코딩테스트

카카오 신입 공채와 달리, 수시채용의 경우에는 해커랭크에서 코딩테스트를 본다(경력과 같음)

인터넷의 후기를 보면 공채보다는 쉽다는 후기가 일반적인데, 사실이었다.

내 코테 실력은 백준을 거의 하지 않아서 프로그래머스 기준으로 lv2는 적당히 잘 풀고, lv3는 시간을 오래 들이면 가능한 수준인데 불합격했던 하나은행 코테보다 카카오 수시채용 코테가 쉽다고 느꼈기 때문이다.

구체적으로 레벨을 예로 들자면, 레벨 lv2정도의 문제를 3문제 주고, 180분 동안 푸는 형식이었다.

카테고리는 어려운 알고리즘은 안 나오고 구현, 그리디, 이진탐색 정도의 알고리즘을 응용하면 풀 수 있는 문제였다.

그래서 난이도에 비해 시간이 넉넉해서 1시간 반정도 안에 다 풀고, 다시 틀린 부분이 있는지 확인해 보고 제출했다.

모든 테스트 케이스를 전부 통과했기 때문에 합격을 예상했고, 합격했다.

면접 준비

코딩테스트는 부트캠프나 이런저런 프로그램을 통해서 여러 번 경험했지만

기술면접은 처음이었다.

화상으로 2대 1로 진행하였고, 이력서를 기반해서 30분에서 1시간 정도 진행한다고 안내받았다.

후기가 별로 없었지만, 화상면접과 관련된 모든 글들을 읽어보니 대면 면접만큼 힘들게 1시간 동안 보는 팀도 있고,

그냥 인적사항만 확인하고 넘기는 팀도 있다고 들었다.

그래서 힘들게 준비하는 팀 기준으로 생각하고, CS(데이터베이스, 네트워크, 운영체제, 자료구조, 알고리즘, 자바)와 프로젝트에 사용한 기술들의 원리(spring boot, jpa 등등), 프로젝트 관련 내용, 자기소개글에서 중요할 법한 내용들을 모두 노션에 정리해서 하나하나 DFS처럼 궁금한 게 생기면 계속 질문을 만들고 답을 달면서 준비했다.

사실 1년 동안 개발을 하면서, 1학년 때부터 개발을 시작한 사람들을 따라잡기 위해 너무 많은 것을 병행했다.

결론적으로 다양한 분야에서 준수한 결과를 얻었지만, 한 분야에 깊이 있는 성취를 이루지는 못했다.

지금도 여러 개를 병행 중이지만 면접을 준비하는 기간에는 '카카오 면접 준비'라는 명목 하에 모든 것을 차치하고 기술 면접만 준비했는데, 면접에서 어느 정도 깊이까지 나올지 몰라서 계속 깊이깊이 탐구하는 과정이 너무 재밌었다.

정말로, 개발을 제대로 시작한 1년 중에서 가장 재밌었던 순간이었다.

또한 면접을 준비하면서 처음에는 '나를 왜 서류에 붙였지?.. '에서 '이런 이유에서 나를 붙였구나' 하는 식으로 이유를 깨달았다.

그리고 면접 날이 되었다.

면접

면접 때는 공지받은 대로 2대 1 면접으로 화상으로 진행했고, 50분간 진행했다.

대략적인 내용은

자기소개 / 지원동기

해당 직무에 대한 지식

해당 직무 관련된 깊이 있는 경험

데이터베이스 관련된 지식

높은 러닝 커브를 증명할 수 있는 경험

등등 여러 가지를 물어보셨다.

면접을 보면서 느낀 것과 정영진 님과 커피챗하면서 느낀 것은 비슷했는데,

그것은 바로 내가 열심히 살고 러닝 커브가 높다는 것은 알겠는데

개발의 어떤 분야에 특화되어 있는지를 모르겠다는 것이었다.

사실 대학교도 졸업하지 못한 쌩신입이, 어떤 분야에 특화될 수 있는지는 의문인지라

CS 기본기가 탄탄하고, 뭐든지 빠르게 배울 수 있는 사람을 원하실 거라고 생각이 들었고,

그래서 거기에 맞춰서 준비했는데

일반적인 백엔드 직무가 아니라 빅데이터 플랫폼 엔지니어링이라는 특수한 직무라 데이터베이스에

특화된 사람을 원하셨던 것 같다.

또한 러닝 커브가 높다는 것을 좀 더 증명해 주길 바라셨던 것 같은데,

이미 내가 회고록에 적은 것과 같이 거기서 뭘 더할 수 없을 정도로 최대치를 한 거기 때문에

만족하실 만큼 증명할 사례를 더 말 못 했던 것 같다.

면접 상에서 CS나 프로젝트 등에서는 대답 못한 게 없었고 분위기도 그렇게 나쁘지는 않았지만

뭔가 애매모호한 분위기를 느꼈고, 결과는 불합격이었다.

아직 부족한 것, 앞으로의 공부 방향

개발자는, 문제를 찾고 해결하는 직업이라고 생각한다.

그래서

올해 초에 계획 세운 것과 같이

프로젝트 / CS / 코딩테스트 / 자격증으로 나눠서 나의 부족한 부분과 해결하기 위해 계획을 세웠다.

부족한 부분

프로젝트 - 백엔드 관련된 프로젝트가 1개뿐, 최소 하나정도는 더 있어야 할 것 같음

CS - CS전공 고학점, 정처기, SQLD 공부를 하면서 전반적인 개념은 있지만 조리 있게 말할 정도로 정리되지 않음

코딩테스트 - 컨디션에 따라 실력 차이가 너무 벌어지고, 파이썬과 자바 사이에서 갈피를 못 잡아서 실력이 더 떨어짐

자격증 - 정처기 실기가 합격이 애매한 상황, 오픽이 IM1이라 더 높이면 좋을 것 같음, 토익은 9월에 만료

계획

프로젝트 - 백엔드 관련돼서 유저를 받아보는 프로젝트 1 ~ 2개

CS - 예상 면접 질문들에 답을 달면서 전 범위를 훑어보며 꼬리물기로 학습

코딩테스트 - 파이썬이냐 자바냐를 확실하게 정하고 매일 최소 2문제 이상 풀기

자격증 - 정처기 실기 불합격 되면 9월 10일에 재신청, 오픽 8월 중순에 시험, 토익은 여유가 생기면 다시 도전

중점

깊이 있게 학습

- 프로젝트도 어느 정도까지 고려해서 진행했는지 기록

- CS도 자바나 내가 사용하는 기술의 어느 깊이까지 파고들면서 사용했는지 기록(결국 cs와 다 연관되어 있음)

마치며

반년 간 많은 변화가 있었던 것처럼, 남은 2024년에도 최선을 다해서 노력해서 많은 변화를 만들고 싶다.

내가 가진 유일한 무기이자 최고의 무기는

꾸준하고, 긍정적인 것이다.

그래서 시간의 차이가 있을 뿐, 열심히 살고 매사에 긍정적인데 절대 실패할 거라고 생각하지 않는다.

앞으로도 우직하고, 긍정적으로 나아가겠다.

긴 글 읽어주셔서 감사합니다.

나만의 AI 만들기 : 프롬프팅으로 GPT 능력 극대화하기 | 추천 GPTS 첨부

겨울단추 — Wed, 24 Jul 2024 14:08:21 +0900

나름대로 GPTS를 이용해서 학습, 취업 준비 등등 많은 부분을 효율적으로 하고 있습니다.
저보다 잘하시는 분들도 많겠지만,
주변의 개발자들과도 비교해서도 잘 쓰는 편인 것 같아 도움이 될 것 같아서
글을 작성합니다!
(유료 사용자만 GPTS를 생성할 수 있는 것으로 알고 있어 참고 바랍니다)
(무료 사용자 분들은 마지막 GPTs 목록만 가져가셔도 좋으실듯..)

글을 쓰게 된 배경

저는 GPT를 원래도 꾸준히 쓰고 있었지만, 작년 말에 커리어해커 알렉스 님의 영상을 보고 나서

GPT를 통한 제 일상의 효율성 자체가 급격히 좋아졌습니다.

해당 영상을 모두 보시고 개인화된 방법을 사용하는 것이 가장 좋을 거라 생각하지만,

나름대로 제가 어떻게 사용하는지 소개해드리겠습니다.

저와 비슷한 상황에 계신 분들은 도움이 될 거라 생각됩니다.

GPTS란?

GPT를 사용하시는 분들 중에서도, GPT가 그냥 똑똑한 AI 정도로만 알지

자세히 모르는 경우가 더 많은 거라고 생각합니다.

저도 기술적인 내용을 깊게는 모르지만 이해하시기 쉽게 간단하게 설명을 드리지만

거대한 데이터를 기반으로 한 역할 놀이라고 하고 싶습니다.

다른 비유를 들자면 감독과 배우라고 생각이 듭니다.

제가 감독이고, GPT가 배우라고 할 때

감독인 제가 아무런 역할(대본)을 배우에게 주지 않으면 배우는
본인의 능력과는 상관없이 능력을 제대로 발휘하지 못합니다.|

그래서 배우에게 '너는 어떤 역할을 맡아서 어떤 식으로 연기하면 돼. 이때 우리의 상황은 무엇이고 앞으로 어떻게 될 거야.'

라고 말해주는 것처럼 GPT에게 역할을 주는 것이 바로 프롬프팅입니다.

GPTS가 나오기 전에도 설정의 ChatGPT 맞춤 설정에서

위에서 설명한 프롬프팅을 할 수 있었습니다.

프롬프팅의 퀄리티에 따라서 GPT의 성능도 천차만별로 달라지기 때문에

이를 돈을 주고 사고 파는 일도 비일비재했습니다.

그런데, 매번 다른 목적을 가지고 GPT를 사용할 때마다 이 프롬프팅을 갈아 끼우는 것이 귀찮으니

아예 각각 다르게 프롬프팅된 GPT를 만든 것이 GPTS 기능입니다.

GPT 만들기

그래서 GPT를 사용할 때 가장 중요한 것은 프롬프팅입니다.

이미 GPTs에도 프롬프팅을 만들기 위한 GPT가 존재합니다.

여러 좋은 GPT들이 있겠지만 저의 경우 영상을 통해 유용한 방법을 알려주신 커리어해커 알렉스 님의 프롬프트 생성기를 주로 사용합니다.

개발 블로그 글을 작성하기 위해 도와주는 파워블로그 GPT를 만들면서 설명을 이어가겠습니다.

제가 링크를 건 사이트에 들어가서 내 프롬프트 만들기를 누릅니다.

그리고 현재 저의 역할을 먼저 설정합니다

현재 예시는 개발 블로그 작성을 위함이므로, 저의 역할을 영감을 주는 콘텐츠 크리에이터로 선택했습니다.

이후에는 GPT의 역할(배우의 역할)을 설정합니다.

저의 경우에는 글을 작성하는 것을 도와주는 GPT를 만들기 위해서 콘텐츠 스크립트 작성을 선택했습니다.

이후에는 아까 말씀드린 것처럼 저 자세한 지침을 배우(GPT)에게 주어야 하는데요.

저의 경우는 아래 사진과 같이 작성했습니다.
(실제로 만들 때는 더 자세하게 작성합니다)

그럼 GPT가 더 높은 성능을 보이는 영어로 프롬프트를 작성해줍니다.

이후에 GPT 사이트로 돌아와

내 GPT 옆의 만들기를 누르시면

이 화면이 나옵니다.

직접 다 작성하는 경우도 있지만

이번에는 프롬프트를 gpt에게 주고, 어울리는 이름과 설명, 그리고 이미지 모두 생성해 달라고 해서 추가했습니다.

완성

그럼 일반 GPT와 방금 만든 DevBlog GPT가 답을 어떻게 다르게 하는지 확인하겠습니다.

(하지만 저는 기본적으로 초반에 설명한 GPT 맞춤 설정을 통해 제가 개발자이고, 어떻게 반응했으면 좋겠는지 기본적인 프롬프팅이 적용된 상태라는 것을 감안하셔야 합니다)

질문은 '내가 데이터베이스에 대해서 글을 작성하고 싶은데 도와줘'입니다.

일반 GPT

DevBlog GPT

기본 GPT도 제 개인 맞춤설정 때문에 좋은 답을 주지만,

보다시피 개발 블로그 전용 GPT인 DevBlog GPT는 주제와 함께 어떻게 블로그 글을 작성하면 좋을지

제안을 아래에도 한참 해주었습니다.

제가 경험한 바로는,

주제를 더 상세하게 알려주거나 블로그 글을 어떻게 쓰고 싶다고 상세하게 알려줄수록 둘의 성능 차이가 더 벌어집니다.

마무리하며

저는 방금 만든 GPT를 제외하고도

이런 식으로 필요에 따라서 그때그때 만들면서 사용합니다.

그리고 현재 채팅 100+ 가 적혀있는 것처럼 사용 횟수에 따라서 추후에 Open AI에서 수익화를 시켜줄 계획이라고 합니다.

그래서 본인의 효율을 늘리면서, 수익화까지 노리실 분들은 적극적으로 활용하시면 좋을 것 같습니다.

++ 프롬프팅 할 때 파일도 업로드가 할 수 있어서 저의 경우 면접 코치와 이력서 코치에는 저의 이력서와 자소서를 모두 입력해서 제가 따로 알려주지 않아도 개인화된 코치를 해주게끔 설정해 놨습니다.

++ 학교에서 수업을 들을 때, 선생님의 모든 수업 내용을 클로바 노트로 녹음하여 해당 자료와 모든 족보를 프롬프팅 해서 OOO선생님 GPT를 만들고, 시험 기간에 새로 배운 내용들을 알려주어 예상 문제를 뽑아서 사용하는 예시를 들은 적도 있습니다.

이처럼 아이디어에 따라서 정말 유용하게 사용할 수 있는 것이 AI인 것 같습니다..

더 좋은 아이디어 있으시면 저한테도 댓글로 공유해 주세요.

제가 만든 GPT 중에서 성능도 좋고, 잘 사용하고 있는 GPT들을 올리면서 마무리하겠습니다

(사용하면서 피드백 주실 부분이 있으시면 언제든 주시면 감사하겠습니다)