👀 들어가기 전에구름에서 진행한 프로펙트 부트캠프가 종료되고 CS Study를 진행해오면서 사용했던 발표 자료들을 기반으로 배웠던 내용을 다시 한 번 정리해 나가려 합니다. 지금까지 발표했던 내용들을 정리하고, 진행되는 내용들을 추가로 작성해나가며 채워보도록 하겠습니다. 이외에도 진행하는 다른 스터디들과 관련된 내용들도 함께 작성될 예정이니 많관부~!👀 본론들어가기전 퀴즈멀티 스레드 환경에서 스레드를 많이 쓸수록 항상 어플리케이션의 성능이 좋아질까요?- 어플리케이션을 수행하는 관점에서는 어떨까요?- Context Switching 관점에서는 어떨까요? (CPU 코어가 고정이라는 전제를 합니다.)- CPU Bound 와 I/O Bound의 관점에서는 어떨까요?프로젝트를 진행하며 비동기처리를 진행하신 분..

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

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

👀 들어가기 전에얼마 전 우리 팀에서는 드디어 제대로된 새 계정으로의 AWS 이동이 필요해졌다. 여태까지 임시로 쓰고 있던 임시계정이 아닌 제대로된 계정으로 새롭게 구축한 AWS를 대상으로 옮겨가게 되었다.지금까지는 간단한 테스트 벤치용 AWS정도로 가벼운 사용을 하고 있었지만, 이 정도로는 앞으로 있을 트래픽 및 장기 운영을 고려한 안정성 요구로 새로이 회사 팀 계정을 파서 제대로 Cloud를 구축하기로 하게된 것이다.이 과정에서 현재 사용중인 S3와 MySQL DB 서버는 그대로 데이터를 이전해야만 했다. 여기서 이 모든 작업을 내가 맡게 되었다.그래서 이 작업을 진행하면서 느낀점도 많고 배워간 점도 많았기에 이에 대해 정리해보려 한다. 이 글이 1차인 이유는, 지금은 DEV 계정으로 DEV 서버만..

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

👀 들어가기 전에2025년은 정말 많은 일들이 겹겹이 쌓인 해였다. 학교를 다니며 취업을 준비했고, 고민 끝에 다시 부트캠프를 선택했고, 그 과정에서 수없이 흔들리며 조금씩 깨달음을 얻었다. 그리고 운이 좋게도 인턴으로 실무를 경험하기까지 이어졌다. 한 해를 돌아보면 쉬고 있던 시간보다 움직이고 있던 시간이 훨씬 많았던 것 같다. 순간순간 느꼈던 감정도 참 다양했다. 기쁨보다는 슬픔이나 막막함, 버거움이 더 자주 찾아왔던 것도 사실이다. 그럼에도 이 회고를 무겁게 쓰고 싶지는 않았다. 굳이 부정적인 감정을 남겨놓고 싶지 않았기 때문이다. 가능하면 조금 더 차분하게, 그리고 기분 좋고 따뜻하게 정리하고 싶었다. 그 때의 내가 있기에 지금의 내가 있을 수 있는 것이니까. 지난 해의 감정선과 선택들을 그냥 ..

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

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