분류 전체보기

회사 입사 후 처음으로 외부 파견을 나가게 되었습니다. 프로젝트는 마지막을 향해가고 있었고, QA에서 발견된 다수의 버그 처리와 쿼리 튜닝이 주요 업무였습니다. 사전에 프로젝트 코드를 전달받았는데, 최근 프로젝트임에도 코드 상태가 좋지 않았습니다. QA 단계에서 발견되는 반복적인 버그들의 원인이 코드 간의 높은 결합도와 가독성 저하에 있다고 판단되었습니다. 단순히 현재의 버그를 수정하는 것에 그치지 않고, 서비스 오픈 후 운영 단계에서 발생할 유지보수 비용을 근복적으로 절감하기 위해 리팩토링을 결심했습니다.보안상 결과물과 커버리지 내역을 공유드리지 못하는 점 양해 부탁드리겠습니다. ⭐️ 리팩토링 목표 설정👉🏻 도메인 지식을 먼저 익히기도메인 지식 없이 객체지향 프로그래밍을 하는 것은 불가능하다고 생..

한 달 동안 토스에서 진행하는 러너스하이 2기에 참여했습니다. 멘토링 프로그램이지만 '스스로 문제를 찾고 해결할 수 있는 힘'을 기르는 것이 러너스하이의 핵심이라고 생각됩니다. 직접적인 멘토링 대신 두 번의 세션이 진행되었고, 세션을 통해 성장에 대한 방향성과 토스의 실제 사례들을 간접 체험할 수 있었습니다. 세션 내용은 공개되지 않은 사항으로 자세하게 작성하기는 어렵지만, 제가 느낀 점을 한마디로 정리하자면 '데이터와 임팩트를 중심으로 성장하기'라고 할 수 있을 것 같습니다. 🤷‍♂️ 주제선정하기프로그램을 진행하면서 시간이 제일 많이 소요되고, 정말 많이 고민했던 부분은 주제 선정이었습니다.주제는 제약 없이 사내의 문제점 또는 개선할 수 있는 부분을 직접 찾아 진행하는 것이었기 때문에 사내의 문제점을..

삶에 많은 변화가 일어날 것 같았지만, 많은 일이 일어나기엔 1년은 너무 짧은 시간이었습니다. 2025년은 제가 발버둥 치던 해라고 정리할 수 있을 것 같습니다. ☕️ 커피챗은 처음이지 ?저는 성장에 목말라 있었고, 다른 개발자분들의 이야기를 듣고 싶어서 관심 있는 회사에 근무하는 개발자 몇 분에게 커피챗을 신청했습니다. 모두 흔쾌히 승낙해 주셨고, 학습에 대한 유익한 방법과 자신감을 얻어갈 수 있었습니다. 회사 견학까지 갈 수 있는 기회도 만들어 주셔서 실제 업무 환경과 개발 문화를 직접 보면서 어떤 개발자가 되고 싶은지, 어떤 환경에서 일하고 싶은지 목표가 한층 더 뚜렷해졌습니다.일면식도 없는 저에게 그동안 쌓인 지식과 따뜻한 응원을 나눠주신 것이 큰 힘이 되었고, ‘어떤 개발자가 되고 싶으신가요?’..

NextStep TDD, 클린 코드 with Java 21기 후기를 남겨보려고 합니다!이 과정을 선택한 이유는 수료생들의 후기 덕분이었습니다. 교육을 통해 코드 스타일이 많이 바뀌었다는 내용이 많았고, 20기까지 꾸준히 운영되어 온 만큼 수료생들의 평가가 하나같이 긍정적이었습니다. 하지만 짧은 교육 일정에 비해 강의 비용이 부담스러워 선뜻 신청하지 못하고 고민하던 중, 같은 동아리 회원 중 해당 과정을 수료하신 분의 조언을 들을 수 있었고, 현재에 머물러 있지 않고 한 걸음 더 나아가고 싶어 교육 과정에 신청하게 되었습니다. 🏃‍♂️ 과정을 진행하며과정은 총 4개의 미션으로 이루어져 있으며, 우아한테크코스에서 학습용으로 사용하는 코드를 베이스로 진행되었습니다. 첫 번째와 두 번째 미션은 TDD와 OOP..

동시 접속자가 증가하면, DB에 전달되는 부하 또한 증가하게 됩니다. 아직 심각한 성능 저하를 경험하지는 못했지만, 사내 서비스에 사용자가 점차 늘어나는 상황에서 단일 DB 구조의 잠재적 문제를 미리 파악해 장애를 방지해야겠다고 판단했습니다. Clustering, Replication, Sharding 등 다양한 선택지 중 해당 프로젝트에 가장 적합한 Replication을 선택하게 되었습니다. 선택한 이유와 Replication을 적용하면서 확인한 성능 개선 결과를 공유하겠습니다. 😣 단일 DB의 한계단일 DB는 모든 쓰기/읽기 요청이 한 곳에 집중되어 트래픽이 증가할 경우 성능 저하를 피할 수 없고, 장애 발생 시 전체 서비스가 중단될 수밖에 없습니다.'그럼 성능을 올리면 되잖아?'라고 생각할 수 ..

여느 때처럼 사내 프로젝트를 진행하던 중, 문득 'Redis에 장애가 발생하면 캐싱된 데이터를 요청하는 API는 어떻게 될까?' 라는 생각이 스쳐 지나갔습니다. TimeOut이 발생할지, 즉시 에러를 반환할지, 다른 방식으로 처리될지 궁금해졌습니다. 궁금증을 해소하기 위해 직접 확인해보기로 했습니다. 🚫 Redis 서버에 장애 상황을 연출해보자Redis 서버에 장애 상황을 만들기 위해 직접 Redis 서버를 종료 시키고 API를 호출한 뒤 어떤 일이 발생하는지 직접 확인해봤습니다.결과는 예상대로, TimeOut이 발생했습니다. 매 요청마다 Redis 연결을 시도하고, 연결에 실패하면 설정된 TimeOut 시간만큼 기다린 후 에러를 반환했습니다. 사용자 입장에서는 몇 초간 응답 없이 기다리다 결국 데이..

얼마 전 새벽, 모니터링 시스템의 알림이 발송되어 확인해보니 운영 중인 사내 사이트에 초당 10,000건 이상의 API 요청으로 인해 서버가 다운되는 상황이 발생했습니다. 서비스는 접속이 불가능해졌고, 약 5시간 동안 서비스가 완전히 중단되었습니다. 악의적인 DDoS 공격이었지만, DDoS에 무방비하게 당한 것은 사전에 대비책을 마련하지 않았기 때문이라고 생각합니다. 동일한 상황을 방지하고자 자발적으로 처리율 제한 장치를 구축했고, 이번 글에서는 어떤 알고리즘을 선택했고, 왜 선택했는지에 대해 공유하려고 합니다. 📊 API 호출 횟수 제한 정책처리율 제한 장치를 설계하면서 가장 먼저 고민했던 부분은 임계값이었습니다. 정상 트래픽은 유지하면서, 공격 트래픽을 제한할 수 있는 임계값을 구하기 위해 Goog..

사내에서 6년간 운영해오던 사이트를 전면 리팩토링 작업 후 몇 개월간 큰 문제없이 운영되는 듯 했었는데, 데이터가 쌓이다보니 동료가 작업한 특정 페이지에서 조회 시간이 16초 이상 소요되는 것을 발견했습니다. 회사에서는 크게 문제 삼지 않았지만, 이런 문제들이 쌓이다 보면 분명 더 큰 문제로 다가올 수 있다고 생각했습니다. 그래서 직접 나서서 슬로우 쿼리 문제를 해결하기로 했습니다. 🛠️ 쿼리부터 튜닝하자인덱스 추가, 캐시 등의 작업을 하기 전 쿼리를 효율적으로 수정하기만 해도 성능이 상당히 개선될 수 있기 때문에 우선 쿼리 작업을 수행했습니다. 아래 3가지 작업을 통해 조회 시간 평균 16초에서 약 3초까지 감소시킬 수 있었습니다. 👉🏻 불필요한 Join 제거 및 서브쿼리 개선불필요한 Join을..