빵똥

일반적으로 좋은 코드는 잘 동작하고, 읽기 쉬우며, 유지 보수가 용이한 지속 가능한 코드를 말하곤 합니다. 그런 지속 가능한 코드를 작성하기 위해서는 개발자 또한 지속 가능한 개발자가 되려면 어떤 방법들로 꾸준한 학습을 이어나가야 할까요? 이제 막 5년차에 접어든 제가 성장하기 위해서 활용했던 방법들을 간단하게 공유하고자 합니다. 환경 설정개발의 시작은 항상 환경 설정으로 시작됩니다. 학습 역시 개인의 의지를 믿지 않고 최대한 학습을 할 수 밖에 없는 환경을 조성하려고 노력하고 있습니다. 저는 스스로 얼마나 의지가 약한 사람인지 매우 잘 알고 있습니다. 이 기술이 좋다던데, 저 기술이 좋다던데 등 생각이나 다짐만 하고 실제 행동으로 옮기질 못하는 사람이죠. 그래서 일종의 강제성을 부여하여 이를 극복하고 ..

1. 트랜잭션의 개념과 특징트랜잭션이란?트랜잭션이란 더 이상 쪼갤 수 없는 하나의 작업 단위를 뜻합니다. 여러 데이터 변경 작업을 하나로 묶어 원자적으로 처리하여, 모든 작업이 성공하면 커밋, 한 작업이라도 실패하면 롤백되어 이전 상태로 복구됩니다. 일상 생활에서는 은행 계좌에서 현금을 인출할 때 현금이 계좌에서 인출되거나, 인출되지 않을 뿐이지 그 중간의 상태는 없는 것과 같습니다. 트랜잭션은 이러한 속성을 ACID 속성인 4가지로 분류하고 있습니다.Atomicity(원자성) : 모든 작업이 완료되거나, 하나라도 실패하면 전체 작업이 취소Consistency(일관성) : 트랜잭션이 끝난 후에도 데이터베이스는 항상 일관된 상태를 유지Isolation(고립성) : 동시에 여러 트랜잭션이 실행되더라도 각각은..

기존 항해 학습간 TDD를 처음 접하게 되었고 사내 전파를 위해 귀찮기만 한, 오히려 작업량이 늘어버리는 이미지를 가진 TDD의 효용성에 대해 설득을 위해 간단한 정리를 해보고자 합니다.  TDD란?개발을 하다 보면 이런 경험 한 번씩 있으실겁니다.코드 다 짰는데 안 돌아가네? ⇒ 디버깅 ⇒ 버그 발견 ⇒ 수정 ⇒ 또 안 됨 ⇒ OTL 이런 지옥의 무한 루프에 빠지지 않기 위해 탄생한 것이 바로 TDD(Test-Driven Development) 즉 테스트 주도 개발입니다. TDD의 핵심 개념은 아주 간단합니다. 코드를 짜기 전에 실패하는 테스트를 먼저 작성하자! 즉, 기능을 만들고 테스트하는 게 아니라 테스트부터 만들고 그걸 통과하는 개발을 진행하는 방식입니다. 쉽게 말하면 시험 문제를 보고 거기에 맞..

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에서 힌트를 얻어 다음과 같이 패키지..