New
-
[DB] 트랜잭션 이해하기 (동시성 이슈와 서비스의 경계)
데이터베이스 트랜잭션이란?데이터베이스 트랜잭션은 하나의 논리적 작업단위를 나타내는 작업들의 집합이다.'논리적 작업단위'는 사용자가 DBMS에 처리를 요구하는 기능으로 1개 이상의 작업으로 구성된다.간단한 예시로 이체 기능이 있다. '사용자 A가 사용자 B에게 1만원을 이체한다.' 라는 요구사항을 처리하는 과정은 다음과 같다. 1) 사용자 A의 잔고를 1만원을 차감한다.2) 사용자 B의 잔고에 1만원을 추가한다. 이 두 작업은 반드시 함께 성공하거나 함께 실패해야 하는데, 만약 A의 계좌에서 금액이 차감된 후 시스템 오류로 인해 B의 계좌에 금액이 추가되지 않는다면, 데이터의 일관성이 깨지게 되어 사용자들에게 혼란을 가져올 수 있다.트랜잭션은 이러한 상황을 방지하여 데이터베이스의 무결성을 보장한다. 트..
2025.03.24
-
코드보다 테스트가 먼저 - TDD의 핵심 원리와 실제 구현
"코드를 작성하기 전에 테스트를 먼저 작성한다"위 문장은 작성된 코드가 없는 데 어떻게 테스트를 진행할 수 있는 지 의구심을 만들 수 있다.하지만 테스트 주도 개발(TDD, Test Driven Development)의 시작과 같은 말이며,많은 개발자들이 실제 코드를 작성하기 전에 테스트를 먼저 작성하는 방식으로 개발한다. 개발자들 사이에서 TDD는 왜 떠오르게 되었을까?이 글에서는 TDD가 무엇인지 간단하게 살펴보고 어떻게 적용되는지 확인해보도록 하자. TDD란?TDD는 테스트부터 시작한다. 구현을 먼저 하고 나중에 테스트하는 것이 아니라 먼저 테스트를 하고 그 다음에 구현한다. 구현된 기능이 없는데 어떻게 테스트를 진행할 수 있을까?TDD에서 '테스트를 먼저 한다'는 것의 의미는 기능이 올바르게 동..
2025.03.16
-
패키지 구조 리팩토링 - 도메인 vs 레이어
"2024년, 한 해 동안 작성한 코드 중 변경하고 싶은 코드는 무엇일까?" 위 질문을 던졌을 때, 작년 초에 진행한 사이드 프로젝트의 패키지 구조가 가장 먼저 떠오른다. 도메인 주도개발 (DDD, Domain Driven Development)에 관심을 가진 상태에서 사이드 프로젝트를 진행했기 때문에 도메인 중심으로 패키지 구조를 설계 했다. 사이드 프로젝트는 단순한 기능을 제공하는 소규모 서비스였고 도메인 중심의 패키지 구조는 이런 소규모 서비스에 어울리지 않는다란 느낌을 주었다. 내부적으로 레이어드 아키텍처를 사용했기 때문에 도메인을 기준으로 패키지를 구성한 뒤 내부에 레이어를 위한 별도의 패키지를 구성하는 작업은 비효율적이었기 때문이다. 더 나은 패키지 구조를 적용하기 위해 '도메인 중심의 패..
2025.03.09
-
네트워크의 통신과정 이해하기
네트워크는 컴퓨터 및 디바이스들 사이에서 데이터 전송을 위해 사용하는 연결망이다. 장치들 간의 연결은 단순하게 이루어지지 않고 데이터를 효율적으로 전달하기 위해 여러개의 중간 처리단계를 가지고 있다. 역할 관점에서 데이터를 요청하는 주체를 클라이언트, 데이터를 제공하는 주체를 서버라고하는데 클라이언트에서 서버까지 요청이 전달되는 과정을 살펴본다. 간단하게 생각할 수 있는 네트워크의 모습HTTP Request : “브라우저에서 무언가의 요구(리퀘스트)를 웹서버에 보낸다.”HTTP Response : “웹 서버는 요구에 따라 움직이고 결과(응답)를 브라우저에 돌려보낸다.” 브라우저에서 전송한 요청은 다음의 물리적 흐름을 통해 서버에 도달한다. 웹브라우저 - URL, Request Message프로토콜 스택..
2025.02.23
-
대규모 서비스와 서비스의 규모 확장 전략
대규모 서비스대규모 서비스는 거대한 데이터를 처리할 수 있는 서비스를 의미한다. 거대한 데이터는 여러 상황들( 1. 다수의 등록된 사용자로 인한 대용량 데이터 처리가 필요한 경우 2. 특정 시간대에 사용자 접근이 집중되어 트래픽이 폭증하는 경우 3. 실시간 데이터 처리량이 매우 큰 경우 등)으로 해석된다. 즉, 거대한 데이터는 단순히 저장된 데이터의 크기뿐만 아니라, 처리해야 하는 데이터의 특성과 패턴에 따라 다양한 형태로 나타날 수 있다. 따라서, 이러한 데이터의 특성을 고려하지 않은 개발이 이루어질 경우, 시스템이 비효율적으로 구성되어 서비스 제공속도가 느려지거나 심각한 경우 전체 서비스의 장애로 이어질 수 있다. 소규모 서비스와 대규모 서비스의 차이목표한 기능의 구현에 초점을 맞추는 소규모 서비스..
2025.01.31
-
[Java] JPA 이해하기
JPA란?JPA는 애플리케이션에서 관계형 데이터베이스를 객체지향적으로 사용할 수 있게 해주는 ORM(Object-Relational Mapping) 기술 표준이다. ORM(Object-Relational Mapping)은 객체와 관계형 데이터베이스를 매핑하여 데이터베이스 작업을 객체지향적으로 처리할 수 있게 해주는 기술이다. 데이터베이스의 테이블을 단순한 데이터 집합이 아닌, 하나의 객체 대상(entity)로 바라보고 다룰 수 있게 한다. 즉, 객체를 직접 저장하고 조회할 수 있게 해준다. 반면 MyBatis나 Spring JdbcTemplate과 같은 SQL Mapper는 단순히 SQL 쿼리를 Java 코드와 연결하는 것에 초점을 맞추고 있어 ORM과는 다른 접근 방식을 보여준다. JPA의 장점 J..
2024.12.20
-
[항해 플러스 백엔드] 마지막 회고
11월 30일, 가을의 마지막 토요일에 10주간의 여정이 끝을 맺었다.토요일마다 발제 강의를 듣고 평일에는 발제 내용을 학습하는 게 일상이 되었는 데, 이제는 제출할 과제가 없어 어색하다.매주 피곤하고 힘들어서 빨리 자유가 오길 바랐지만, 막상 끝나고 나니 허탈하기만 하다. 목표를 이루었는가?처음 생각한 목표의 50%를 달성했다. 항해 플러스를 시작할 때, 10주 동안 이루어야 할 3가지 목표를 세웠다.모든 과제 제출하기매주 진행되는 발제 주제 정리하기코치분들의 개발 노하우 배우기 모든 과제 제출하기매주 발제와 함께 과제가 제공되고, 과제 통과율에 따라 배지를 받는다는 안내를 받았을 때부터 블랙배지를 목표로 삼았다.해당 주차의 교육내용을 완전히 이해해야 통과할 수 있다고 생각했기 때문에, 블랙배지는 ..
2024.12.11
-
[항해 플러스 백엔드] 9주차 회고 (WIL)
이번 한 주동안 카프카를 다루었다.새롭게 접한 기술이었기 때문에 사용되는 개념을 학습할 때는 이해가 잘 안되었지만 hello world를 만들고 필요한 기능을 구현하면서 이해도를 높일 수 있었다. 문제카프카의 주요 구성요소(Producer, Broker, Consumer)가 기능하는 프로세스를 이해했지만 공식문서만을 보고 구현하기는 어려웠다. 시도공식문서의 가이드에 따라 hello world를 구성해보았으나 진행과정을 제대로 따라가지 못했다. 가이드 문서에서 실행시키는 파일의 경로를 찾기 어려웠기 때문이다. 해결Youtube의 강의 영상을 찾아 해결할 수 있었다. Kafka를 검색하면 Kafka의 목적이나 기능에 대한 설명 영상 뿐만 아니라 설정 및 사용하는 방법을 다루는 강의 영상이 존재한다. 알게..
2024.11.25
-
[항해 플러스 백엔드] 8주차 회고 (WIL)
DB인덱스와 트랜잭션 분리에 대해 다루었던 지난 한 주도 어느 순간 끝이 났다. 1. 문제서비스가 제공하는 기능에 따라 트랜잭션의 범위는 다르다. 이번 과제는 서비스가 확대되어 서비스를 분리하게 될 경우 예상되는 문제를 어떻게 해결할지 설계하는 것이었다. 트랜잭션의 범위 때문에 서비스를 분리하면 트랜잭션의 문제가 발생하고 이를 해결하기 위해서는 '보상 트랜잭션'이 필요하다. 하지만 '보상 트랜잭션' 개념을 이번에 처음 듣게 되었다. 2. 시도잘 모르는 개념이기 때문에 단순 구글링을 통해 관련 정보를 찾아볼 수 밖에 없었다. 3. 해결보상 트랜잭션을 검색하면 연관해서 MSA 개념을 쉽게 찾을 수 있다. MSA(MicroService Architecture)에서 보장하는 보상 트랜잭션 방법을 참고해서 과제..
2024.11.16
-
[항해 플러스 백엔드] 7주차 회고 (WIL)
7주는 지금까지 항해플러스를 진행하면서 가장 힘든 한 주였다. 과제가 생각보다 어렵기도 했지만 피로가 몸에 지속적으로 누적된 점도 한 몫했다 생각한다. 과제는 챕터2에서 구현한 서버를 캐싱과 레디스를 활용해 고도화하는 작업이었다. 캐싱처리와 레디스를 사용해본 경험이 없었기 때문에 사용법부터 익혀야만 했다. 1. 문제새로운 개념을 익히는 과정은 생각보다 큰 문제가 되지 않았다. 정작 내 발목을 크게 붙잡은 건 챕터2를 진행할 때 작성했던 내 코드들이었다. 과제 제출에 초점을 두어 기능을 동작하게 만들었지만 구조상 기능사이의 결합도가 크게 형성되었다. 2. 시도이번 과제 내용 중 하나는 DB로 구현된 대기열을 Redis로 옮기는 것이었다. 때문에 처음에는 큰 변경 없이 Redis로 옮기려고 했지만 기존 코..
2024.11.09
