[백엔드 기초] 프로젝트 경험으로 다시 공부한 Java, DB, HTTP

들어가며

2026년 4월에는 프로젝트 경험을 다시 기초 개념과 연결해서 공부했다.

기능은 구현할 수 있어도, 면접이나 기술 설명에서 “왜 그렇게 만들었는가”를 설명하지 못하면 부족하다고 느꼈다.
그래서 Java, DB, HTTP, JPA, Spring Security 같은 기본 개념을 내가 했던 프로젝트 경험과 연결해보려고 했다.

이번 글은 그때 정리한 백엔드 기본기 기록이다.

Java와 객체지향

Java를 공부할 때 객체지향 개념은 계속 나온다.

캡슐화, 상속, 다형성, 추상화 같은 단어는 많이 들어봤지만, 프로젝트에서 어떻게 연결되는지 설명하는 것은 또 다른 문제였다.

예를 들어 7STARBALL의 Meeting 도메인을 리팩토링하면서 단순히 필드를 가진 Entity가 아니라, 자기 상태와 규칙을 가진 객체로 만들려고 했다.

서비스가 모든 조건을 판단한다

보다

도메인 객체에게 가능한 행동인지 물어본다

가 더 객체지향적인 방향이라고 생각했다.

객체지향은 문법이 아니라 책임을 어디에 둘 것인지 고민하는 방식에 가깝다는 것을 조금씩 느끼게 되었다.

트랜잭션을 다시 생각하기

트랜잭션은 DB 작업을 하나의 단위로 묶는 개념이다.

하지만 프로젝트를 해보기 전에는 @Transactional을 붙이면 되는 것 정도로만 이해했다.

펜션 예약 프로젝트와 Meeting 참여 기능을 경험하면서 트랜잭션이 왜 중요한지 더 분명해졌다.

예약이나 참여 기능은 중간에 실패하면 데이터가 어긋날 수 있다.

• 예약 가능 여부 확인
• 예약 데이터 저장
• 결제 처리
• 상태 변경

이런 흐름이 하나의 작업으로 묶여야 한다.
일부만 성공하고 일부가 실패하면 데이터 정합성이 깨진다.

트랜잭션은 기능이 아니라 신뢰성을 지키는 장치라는 생각이 들었다.

인덱스와 조회 성능

DB 인덱스도 다시 공부했다.

인덱스는 조회를 빠르게 만들 수 있지만, 모든 컬럼에 붙인다고 좋은 것은 아니다.
쓰기 성능과 저장 공간에도 영향을 주기 때문이다.

프로젝트에서는 where 조건이나 정렬 조건에 자주 사용되는 컬럼을 중심으로 인덱스를 고민했다.

예를 들어 사용자 이메일, 게시글 작성자, 모임 상태, 생성일 같은 값은 조회 조건으로 자주 사용될 수 있다.

하지만 인덱스를 추가할 때는 다음을 함께 봐야 한다.

• 이 컬럼으로 얼마나 자주 조회하는가
• 데이터 중복도가 너무 높지는 않은가
• 정렬과 페이징에 사용되는가
• 쓰기 작업이 많은 테이블인가

인덱스는 성능을 위한 도구지만, 근거 없이 붙이면 오히려 비용이 될 수 있다.

HTTP 메서드와 상태 코드

REST API를 구현하면서 HTTP 메서드와 상태 코드도 다시 정리했다.

처음에는 GET, POST, PUT, DELETE 정도만 구분했다.
하지만 실제 API를 만들다 보면 더 세밀한 판단이 필요하다.

메서드	사용 목적
GET	리소스 조회
POST	리소스 생성 또는 명령 실행
PUT	리소스 전체 수정
PATCH	리소스 일부 수정
DELETE	리소스 삭제

상태 코드도 마찬가지다.

상태 코드	의미
200	요청 성공
201	생성 성공
204	응답 본문 없는 성공
400	잘못된 요청
401	인증 필요
403	권한 없음
404	리소스 없음
409	충돌

예를 들어 모임 정원이 초과된 경우는 단순 400보다 409 CONFLICT가 더 의미에 맞을 수 있다.
이런 작은 선택이 API를 사용하는 사람에게 의도를 더 명확하게 전달한다.

JPA 영속성 컨텍스트

JPA에서 가장 중요한 개념 중 하나는 영속성 컨텍스트다.

영속성 컨텍스트는 Entity를 관리하는 공간이다.
트랜잭션 안에서 조회한 Entity는 영속 상태가 되고, 변경 감지를 통해 update 쿼리가 나갈 수 있다.

처음에는 save를 호출해야만 DB에 반영된다고 생각했다.
하지만 JPA에서는 영속 상태의 Entity를 변경하면 트랜잭션 커밋 시점에 변경 감지가 동작할 수 있다.

이 개념을 이해해야 다음 문제도 이해할 수 있다.

• 지연 로딩
• N+1 문제
• Dirty Checking
• 트랜잭션 범위
• Entity와 DTO 분리

JPA는 편리하지만, 내부 동작을 모르면 예상치 못한 쿼리가 발생할 수 있다.

정보처리기사 공부와 프로젝트 경험

정보처리기사 공부를 하면서 이미 프로젝트에서 경험한 개념들이 다시 나왔다.

정규화, 트랜잭션, 인덱스, HTTP, 보안, 테스트 같은 개념들이 책에서는 이론으로 나오지만, 프로젝트에서는 문제로 나타난다.

이론과 실무를 따로 보는 것보다, 내가 겪은 문제에 이론을 붙여보는 방식이 더 기억에 남았다.

예를 들어 N+1 문제를 겪고 나서 JPA 연관관계와 영속성 컨텍스트를 공부하면 훨씬 잘 이해된다.

마무리

4월에 기본기를 다시 보면서 느낀 것은, 기초는 처음에만 공부하는 것이 아니라 프로젝트를 한 뒤에 다시 볼수록 더 잘 보인다는 점이었다.

기능 구현 경험이 쌓인 뒤 이론을 다시 보면, 단어들이 실제 문제와 연결된다.

앞으로도 새로운 기술을 공부할 때는 프로젝트에서 어떤 문제를 해결하기 위한 개념인지 함께 정리하려고 한다.