👀 들어가기 전에출퇴근 시간을 활용해 UnitTesting : 단위 테스트를 완독하였다. 테스트에 대한 내용이라 흥미롭게 읽을 수 있었고, 1차 독후감에 이어 핵심적으로 정리하고 싶은 내용들을 정리해보려 한다. 책을 읽으며 가장 인상 깊었던 부분은 크게 두 가지였다.가치 있는 단위 테스트를 위해 기존 코드를 어떻게 리팩터링 할 것인가?좋은 테스트를 만들기 위해 의존성을 어떻게 처리할 것인가?👀 본론테스트의 본질테스트는 개발자에게 필수적인 도구다. 하지만 테스트 커버리지 자체가 목표가 되어서는 안된다. (1편 참고)테스트의 본질적인 목적은 코드의 안정성 확보, 리팩터링 내성 향상에 있다. 테스트를 작성하다 보면 자연스럽게 강결합, 숨겨진 의존성 문제를 마주하게 되고, 이를 해결하기 위해 코드 구조를 ..

👀 들어가기 전에기존 내가 다운로드한 배경화면 목록에 대한 요구사항은 단순했다.'사용자가 다운로드한 모든 배경화면을 빠짐없이 볼 수 있어야 한다'는 것이었다. 예를 들어, 사용자가 아래와 같은 순서로 배경화면을 다운로드했다고 가정해보자1번 → 2번 → 3번 → 2번 → 2번 → 2번 → 5번 → 2번 이 경우, 가장 최근에 다운로드한 순서대로 목록이 노출되어 아래와 같은 형태로 보여야 했다.2번 → 5번 → 2번 → 2번 → 2번 → 3번 → 2번 → 1번 즉, 다운로드 이력 전체를 시간 순으로 그대로 보여주는 방식이었다. 하지만 이후 새로운 기획 요구사항이 추가되었다. 같은 다운로드 이력이더라도 이번에는 단순한 시간 순 나열이 아니라 중복된 배경화면을 하나로 묶어 정리된 형태로 보여달라는 요구였다.앞..

👀 들어가기 전에이 글은 지금까지 써왔던 현업에서의 고민 시리즈와는 조금 다르게, 따로 공부하거나 책을 읽으면서 느꼈던 생각들을 정리하기 위해 작성하게 되었다. 현업에서 테스트 코드를 작성하다 보면, '이 테스트가 정말 올바르게 작성된 걸까?'라는 의문이 자주 들었다. 또 테스트 주도 개발에서는 어떤 방식으로 테스트를 설계해야 하는지, 그리고 내가 지금까지 고민해왔던 문제들을 다른 개발자들은 어떻게 해결해왔는지도 궁금해졌다.최근 들어 테스트에 대한 관심이 크게 늘면서 이런저런 자료를 찾아보던 중 개발바닥 향로님께서 추천해주신 책이 눈에 들어왔고 그 계기로 이 책을 읽게 되었다. 매번 느끼는 것이지만 책을 한 권 처음부터 끝까지 차분히 읽으며 공부하는 것과 어렴풋이 알고 있는 상태인 것은 확실히 큰 차이..

👀 들어가기 전에 개발을 하다 보면 "기술 스택"이라는 단어를 자연스럽게 쓰게 된다.하지만 어느 순간부터는 이런 궁금증이 생겼었다.우리가 매일 사용하는 이 도구들은 누가 만들었고,어떤 판단의 결과로 지금의 형태가 되었을까? Spring, Swagger, Kafka, Elasticsearch 등등채용 공고에서 흔히 보이는 이 기술들은 대부분은 오픈소스다.막연하게 "언젠가 나도 이런걸 만들어보고 싶다"는 생각만 하다가, 최근 어느 정도 대규모의 코드도 읽히기 시작하면서실제 오픈소스 코드를 보기 시작했다. 그 무렵 운이 좋게도 인제님께서 진행하시는 오픈소스 기여 모임을 발견하게 되었고 바로 참여하였다.아래 링크에서 자세한 정보를 확인하실 수 있습니다!! 오픈소스에 관심있으시다면 강!추! 합니다.https:/..

👀 들어가기 전에이전 글에서 "쿼리 최적화는 이미 어느 정도 진행된 상태"라고 적어놨는데, 정작 그 내용을 따로 정리해둔 글이 없었다.💦결국 다시 돌아가 내가 DB I/O를 어디에서 어떤 논리로 줄여나갔는지에 대한 과정을 적어보려 한다. 성능 최적화는 거창한 알고리즘보다 DB왕복만 줄여도 체감 자체가 크게 변화하는 경우가 많다.이번 글은 그중에서도 쿼리 수를 줄이는 구조적 개선에 집중한 이야기를 다뤄보려한담.👀 본론책임의 분리 : 조회 API 하나가 너무 많은 책임을 지고 있다. MVP 단계에서 코드는 일단 되게 만드는 것을 목표로 빠르게 쌓인다.나도 마찬가지였고 그 결과 하나의 트랜잭션 안에 다음이 한 덩어리로 섞여있었다. (보안 내용으로 예시로 작성한 점 양해부탁드립니답)사용자 검증 / 권한 검..

👀 들어가기 전에얼마 전 프로젝트에 대하여 회고하며 한 번 이런 이야기를 한 적이 있다.Hikari CP는 결국에는 대기열을 늘릴 뿐이다 이 이야기에 대해서 이번에 실무에서 진행한 프로젝트와 연관지어서 이야기해보려 한다. 과연 HikariCP는 진짜 대기열만 늘리는 존재일까?아니면 특정 조건에서는 성능을 드라마틱하게 개선할 수 있는 도구가 될 수 있을까?있다면 언제, 없다면 왜 없는지 그리고 왜 그런 결과가 나오는지를 고민한 내용을 아래에 정리해보려 한다.👀 본론문제 발생 : RPS 20에서 무너진 내 서버 😭이번 프로젝트에서는 DAU 5,000명을 가정했기에, RPS 50~100 수준을 목표로 부하테스트를 진행했다. RPS 50~100을 안정적으로 처리할 수 있다면 충분히 DAU 5,000명을 가..

👀 들어가기 전에처음 회사를 입사하고 일 처리를 하나하나 해나갈 당시 우리 서비스에는 중앙 로그 수집이나 모니터링 체계가 전혀 없었다.서버에서 문제가 발생하면 EC2에 직접 접속해 도커 컨테이너 로그를 하나하나 확인해야 했고, 그마저도 어떤 로그가 에러인지 어떤 로그가 단순 정보인지 구분하기 쉽지 않았다. 실제로 EC2 장애를 한 번 겪고 나서야(이전 포스팅 참고!) 이 문제가 얼마나 치명적인지를 직접적으로 체감하게 되었다.장애 상황임에도 불구하고 지금 무슨 일이 벌어졌는지를 한눈에 파악할 수 없는 상태였기 때문이다.이 경험을 계기로 고민했다. 결국 로그 정책 수립부터 수집 / 시각화 환경 구성까지 전부 직접 제안하고 구축하게 되었고 이 글은 그 과정에서의 고민과 선택들을 정리한 기록이다.👀 본론로..

👀 들어가기 전에드디어 MVP 개발이 끝나고, 테스트 코드 작성까지 완료한 시점에서 이에 대해 회고를 시작해보려한다. 테스트 코드에 대해 주변 개발자들과 이야기를 나눠보면 생각은 정말 가지각색이다.실제로도 아래와 같은 질문들을 수 없이 받아왔다.이거 진짜 꼭 필요해?기능만 잘 돌아가면 되는거 아니야?테스트 하나 실패했다고 빌드가 깨지는게 이게 맞아?어차피 기획 바뀔 건데 왜 이렇게 까지해?(실제로 들었던 이야기다...)마침 진행하던 프로젝트에서 테스트 코드 작성을 마무리한 시점이기도 했고, 그동안 내가 테스트에 대해 어떤 고민을 했고 왜 이렇게까지 테스트가 중요하다고 생각하고 집착(?)하게 되었는지를 한 번 정리해보고 싶어 이 글을 쓰게 되었다.👀 본론테스트 진짜 왜 필요할까?이 질문에 답하려면 사실..