백엔드 기본 지식

백엔드 개발자는 사용자의 요청을 받아서, 필요한 데이터를 찾고 처리한 뒤, 다시 사용할 수 있는 응답으로 돌려주는 서버 쪽 흐름을 만드는 사람이다.

프론트엔드는 사용자가 보는 화면과 상호작용을 담당하고, 백엔드는 요청을 처리해서 어떤 데이터와 결과를 돌려줄지 결정한다.

서버가 요청을 받는다는 것은 클라이언트가 보낸 HTTP 메시지를 읽고, 그 안의 메서드, 주소, 헤더, 바디를 바탕으로 어떤 일을 할지 결정하는 것이다.

HTTP 요청과 응답은 클라이언트와 서버가 서로 대화하는 기본 형식이며, 백엔드 API는 결국 이 요청을 읽고 적절한 응답을 만드는 코드다.

GET은 데이터를 조회하기 위한 요청이고, POST는 서버에 데이터를 보내 처리하거나 상태를 바꾸기 위한 요청이다.

URI는 자원을 식별하는 문자열이고, URL은 그중 자원의 위치와 접근 방법을 나타내는 주소다. Endpoint는 클라이언트가 요청을 보내는 API 접점으로 이해할 수 있다.

API 문서는 클라이언트와 서버가 어떤 요청과 응답을 주고받을지 정리한 약속 문서다.

JSON은 사람이 읽기 쉽고, 여러 언어에서 다루기 쉬운 데이터 교환 형식이라서 백엔드 API의 요청과 응답에서 자주 사용된다.

HTTP 상태 코드는 서버가 요청을 처리한 결과를 클라이언트에게 알려주는 숫자다.

로그는 서버가 실행되는 동안 어떤 일이 있었는지를 남기는 기록이다.

개발을 처음 배우면 이런 생각이 들 수 있다.내 컴퓨터에서 잘 돌아가는데, 그대로 서버에 올리면 되는 것 아닌가?

환경변수는 DB 주소, 비밀번호, 외부 API 키처럼 환경마다 달라지는 값을 코드 밖에서 주입하기 위해 사용한다.

비밀번호를 설정 파일에 넣지 말라는 것은 단순한 코딩 규칙이 아니다. 비밀번호가 퍼지는 범위를 통제하기 위한 보안 원칙에 가깝다.

새로운 회사에 입사하거나 다른 사람이 만든 프로젝트를 처음 맡으면 가장 먼저 이런 생각이 든다. > “파일이 너무 많은데 어디부터 봐야 하지?”

“Controller에서 요청도 받고, DB도 조회하고, 응답까지 바로 만들면 더 간단하지 않을까?”

DTO는 요청과 응답에 필요한 데이터만 담아 전달하는 객체다. 백엔드 API에서는 DTO를 사용해 외부에 공개되는 요청·응답 형식을 Entity와 내부 구현으로부터 분리할 수 있다.

JPA Entity를 API 응답으로 그대로 반환하면 서버 내부 정보가 노출될 수 있고, Entity 변경이 API 변경으로 이어질 수 있다.

Request DTO는 서버가 받기로 한 입력 계약이고, Response DTO는 서버가 공개하기로 한 출력 계약이다.

백엔드 개발을 하다 보면 한 번쯤 이런 고민을 하게 된다. Validation은 Controller에서 해야 할까? 아니면 Service에서 해야 할까?

백엔드 API를 만들다 보면 성공하는 경우만큼이나 실패하는 경우도 많이 생긴다. 이러할 때 예외 처리를 어떻게 해야할까?

Spring으로 API를 만들다 보면 공통 응답 형식을 자주 보게 된다. 공통 응답 형식은 여러 API의 응답 구조를 일정하게 만들어주는 장점이 있지만, 모든 API에 무조건 적용해야 하는 것은 아니다.

중복 코드는 줄이는 것이 좋다. 하지만 모양이 같다는 이유만으로 합치면, 나중에 변경하기 더 어려운 코드가 될 수 있다.중요한 것은 코드가 똑같이 생겼는지가 아니다.앞으로도 같은 이유로 함께 바뀔 코드인지가 더 중요하다.

코드를 작성하다 보면 생각보다 자주 멈추게 되는 순간이 있다. 바로 메서드 이름을 지을 때다.

코드가 설명할 수 있는 ‘무엇을 하는지’는 코드로 드러내고, 코드만으로 알기 어려운 ‘왜 그렇게 했는지’를 주석으로 보완하자는 뜻이다.

Spring Boot의 패키지 구조에는 하나의 정답이 없다.

“Controller, Service, Repository 폴더만 나누면 레이어드 아키텍처 아닌가?”

의존성 방향을 신경 쓰는 이유는 간단하다. 코드 하나가 바뀌었을 때 그 변경이 불필요한 곳까지 퍼지는 것을 막기 위해서다.

처음에는 “비즈니스 로직은 Service에 둔다”라고 이해해도 괜찮다. 하지만 기능이 복잡해질수록 모든 로직을 Service에 몰아넣기보다는 역할에 따라 나누는 것이 좋다.

Spring 백엔드에서 API 요청 하나가 들어왔을 때 Controller부터 Service, Repository, DB를 거쳐 응답으로 돌아오기까지의 전체 흐름을 주문 생성 예제로 쉽게 정리