빵똥

이제 와서 고쳐보는 2024 내 코드

2025년도 두 달이나 지나 벌써 3월입니다. 작년 10월 항해 플러스 백엔드 교육을 통해 많은 인사이트를 얻었고 사용하지 않으면 까먹을게 뻔하니 틈틈이 사내 SI용 템플릿을 개발하고 있었습니다. 당연히 학습과는 달리 실무에 적용하며 많은 어려움을 겪고 있어 다시 한 번 이전에 작성한 코드를 보며 또 다른 인사이트를 얻어보려 합니다.과제 선정항해 당시 선택할 수 있었던 과제는 콘서트 예매 사이트와 E-Commerce 사이트가 있었고 비록 팀 미션은 아니지만 상호 피드백을 위해 학습 매니저님과 팀원들과의 논의 끝에 선정했던 과제는 E-Commerce로 진행하게 되었습니다. Spring Boot로 API 서버만 구현했었고 주요 기능으로는 잔액 충전 및 조회 / 상품 조회 / 장바구니 / 주문 및 결제가 있습..

현재 항해에서 진행중인 E-커머스 프로젝트에서 대용량 트래픽 & 데이터 처리를 위해 아래와 같은 작업을 진행하려 합니다. 자주 사용되거나 복잡한 쿼리에 인덱스 적용트랜잭션 범위 대한 이해와 서비스 확장 및 분리시의 트랜잭션의 한계 파악기존 로직에 영향도를 주지 않고 이벤트기반 메시지 발행  쿼리 성능 테스트 현재 제 프로젝트는 아주 간단한 기능만이 구현되어 있어 복잡한 쿼리는 없고 자주 사용되더라도 그 데이터의 양이 적어 의미있는 성능개선 지표를 얻기가 힘든 상태이기에 테스트를 위한 더미 데이터를 삽입하여 진행하겠습니다. 대용량까지는 아니지만 유의미한 성능 측정은 가능한 1건의 더미 상품 정보를 생성하였습니다.DELIMITER //CREATE PROCEDURE insert_products()BEGIN ..

Cache애플리케이션을 개발하다 보면 자주 "쓰지는" 않지만 자주 "읽는" 데이터들이 있습니다. 어차피 변하지 않는 값이니 정적 리소스처럼 DB 조회나 기타 연산을 하지 않고 그냥 갖고 있는 값을 보여주면 안 될까?라는 생각을 한 번씩은 하게 됩니다. 작은 토이 프로젝트라면 몰라도 수많은 사람들이 사용하는 B2C 서비스일수록 서버에 대한 부하 때문에 더 느끼곤 하죠. 이럴 때 캐시는 아주 유용하게 사용할 수 있습니다.  Spring CacheSpring에서는 3.1 버전부터 이 캐시를 쉽게 사용할 수 있도록 캐시 관련 어노테이션을 지원합니다. 해당 어노테이션 붙은 메서드는 Java 메서드에 캐싱을 적용하여 이후 호출에서는 실제 메서드는 실행하지 않고 캐시 된 결과만 반환합니다.  단, 다중 스레드나 다중..

동시성 이슈일반적으로 생각할 수 있는 동시성 이슈는 여러 프로세스나 스레드가 동시에 실행될 때 이를 비즈니스 로직이나 프로그램에서 처리하지 못해 의도하지 않는 결과가 나오는 상황이라고 생각합니다. 간단한 예시로 들어보자면 콘서트장에서 자리를 예약할 때 여러명이 같은 자리 예매에 성공했다면 그 자리는 누가 앉아야할까요? e-커머스 동시성 이슈 발생 시나리오그렇다면 일반적인 e-커머스에서는 어떤 동시성 이슈들이 발생할 수 있는지 살펴볼까요?잔액이 5,000원인 상황에서 5,000원짜리 물품에 대해 구매하기 버튼을 실수로 두 번 눌러버렸다.재고가 하나 남은 상품을 여러명이 동시에 구매했다.물론 실제 e-커머스 시스템들이 겪는 동시성 이슈는 더 많이 있겠지만 제일 중요한 "돈"과 "상품"에 집중해서 위 두 가지..

4주차 WIL 4주차 KPT를 정리합니다.   1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제) 요구사항E-Commerce 시스템 분석 및 설계 자료를 기반으로 기능구현 3주차에 진행한 산출물 베이스로 실제 서버를 구축합니다. 동시성이나 데이터 인덱싱과 같은 고도화는 이후 구현하며각 기능의 완성에 집중합니다. 2. 시도 CQRS 패턴을 적용하려 시도했습니다. 물론 구현 난이도가 있기 때문에 Command DTO의 활용과 Reader, Store를 분리해읽기와 쓰기 Repo를 나눠 사용하였습니다. 물론 단일 DB에서의 효용성은 없겠지만 이후 확장성이나 학습에 목표를 두어 구현을 시도했습니다.  3. 해결 이번 주차에 잘못된 ERD 설계로 Clean한 기능 구현을 하지 못했습니다. 잘못된 E..

3주차 WIL 3주차 KPT를 정리합니다.   1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제) 요구사항E-Commerce 시스템 분석 및 설계시퀀스 다이어그램, ERD, 프로젝트 마일스톤 등 기초 산출물 작성 이번주차부터는 이어지는 과제로 분석 - 설계 - 구현의 순서대로 진행이 되는 것 같습니다. 첫 주차는 앞으로 만들 E-commerce 시스템에 대한 설계 부분으로어떤 기술을 채택하는지, 패키지 구조는 어떻게 가져가는지 등 전반적인 구조를 잡습니다. 시퀀스 다이어그램이나 API 명세 작성을 실무에서는 많이 안해봐서 어려움을 좀 겪었습니다. 2. 시도 일반 워드, 엑셀, PPT로만 산출물을 작성해봤지 readme.md 등에 작성하고공유하기 위한 "실용성있는" 산출물은 작성해보지 못했습..

2주차 WIL 2주차 KPT를 정리합니다.    1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제) 요구사항아키텍처 준수를 위한 애프리케이션 패키지 설계동시성을 고려한 특강 조회 및 신청 API 서버 구현 1주차와 마찬가지로 단순 기능 구현에 대한 어려움은 없었습니다. 하지만 다른 온라인 강의를 통해 보기좋은 패키지 설계에 대해 살짝만 알았을 뿐DIP와 OCP를 준수하기 위한 노력은 하지 안았기에 구조 자체를 잡게 너무 어려웠습니다. 또한 이전엔 애플리케이션단에서의 Lock을 구현했다면, 다중 인스턴스에서의 동시성 제어를 위해DB Lock과 Redis를 사용했는데 둘 다 고민을 크게 하지 않고 사용했던터라 어려움을 많이 겪었습니다. 2. 시도 공개 Q&A에서 힌트를 얻어 다음과 같이 패키지..

1주차 WIL 9월 21일 항해 플러스를 시작으로 1주간의 KPT를 정리합니다.    1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제) PointService를 정상 동작하게 구현하는 Default 과제는 어렵지 않게 해결했습니다. 이후 Step1~Step2인 동시성 제어에서 다뤄본 적이 없었기에 어떠한 방법을 사용해야 하는지전혀 감이 오지 않았습니다. 공개 Q&A 덕분에 ConcurrentHashMap과 Lock에 대한 Keyword를 얻었지만동시성, 순차성 등 용어의 혼선으로 실패만 되는 테스트 케이스에 부딪혔습니다. 2. 시도 처음엔 UserId와 UserPoint 객체를 가지는 ConcurrentHashMap만을 사용하여 로직을 구현하였습니다. 하지만 이는 순차성을 보장할 순 없었..

지금까지의 회고당연히 핑계겠지만 개발에 대한 욕심만 있고 SI 특성상 성장하기 힘든 환경탓만 해왔습니다. 정말 성장하고 싶지만 전공자도 아니고, 주변에 도움을 받을 수 있는 사람도 없기에 항상 "어떻게?"가 저의 발목을 붙잡았고 그 핑계로 일만 열심히 하는 성실한 노예가 되었습니다. 성실한 노예가 된 덕분에 회사에서의 인정과 작은 규모의 기업에서는 드문 파격적인 연봉 인상도 받았습니다. 그렇게 1년이 지난 지금 사내 에이스라는 정말 작은 우물안에 갇혀 폐사 직전의 왕자 개구리가 되었습니다. 항해플러스 참여 계기그러던 와중 우연히 광고 배너를 통해 항해99 알고리즘 스터디에 참여하게 되었고 성장에 대한 방향성을 몰라 그저 제자리에 서있던 저에게 아주 큰 동기부여가 되었고 40일간 TIL 전부 제출, 알고리..

오늘의 과제리트코드 medium으로 분류된 Optimal Partition of String 입니다. 이번 유형은 그리디 입니다.문제https://leetcode.com/problems/optimal-partition-of-string/description/ 먼저 문제 요구사항 요약입니다. 문자열이 주어질 때 각 문자가 하나의 파티션에 최대 한 번씩만 등장하도록 파티션을 나눈 후 파티션의 개수를 반환하는 문제입니다. 먼저 살펴보아야 할 부분은 각 파티션에 문자가 중복되지 않게 어떻게 나누는가? 입니다. 문제의 유형이 그리디인만큼 매번 최선의 선택을 해야 하는데 제약 조건인 "문자가 중복되지 않는다"에 포커스를 맞추면 매우 쉽게 풀 수 있습니다. 문자열이 주어지면 contains를 통해 중복 여부를 확인하..