태헌님의 블로그

[TIL] 고객 및 상품 관리 시스템 프로젝트 (이커머스 백오피스) API 설계

드디어 시작 된 팀 프로젝트...갈길이 멀고 이걸 과연 10일정도밖에 안되는 시간에 적절히 구현할 수 있을 지 의문이 들긴하지만 일단 시작을 하면 팀원들끼리 뭉쳐 어떻게든 되지 않을까 기도해본다. 본격적인 프로젝트 시작 전에 API 명세서를 직접 작성하면서 실제 엔드포인트 설계가 어떻게 이루어지는지 이해하고,사용자 관리라는 도메인에서 CRUD 작업과 상태 관리를 어떻게 API로 표현하는지부터 시작했다.REST API는 자원(resource)을 URL로 표현하고, HTTP 메서드(GET, POST, PATCH, DELETE)로 행동을 정의한다. 사용자 관리 API를 설계할 때는 사용자라는 자원을 중심으로 여러 엔드포인트가 생기는데, 단순한 CRUD만 아니라 역할 변경, 상태 변경처럼 부분적 업데이트가 필..

Spring 과제에서 가장 어려웠던 3가지와 극복 방법Spring CRUD 과제를 진행하면서 가장 막혔던 부분들을 정리했다.1. Controller → Service → Repository 데이터가 왜 이렇게 흐를까Controller:CreateScheduleRequest request를 받음Service한테 보냄Service:Repository를 호출DB에서 받은 Schedule Entity를 DTO로 변환해서 반환Controller:Service에서 받은 DTO를 JSON으로 변환해서 응답알겠다 알겠는데 내손으로 구현이 안된다. 머리속이 뒤죽박죽 섞여서 흐름을 모르겠고 이 행동 다음에 어떤 행동을 해야하지 정형화가 안된다.결국 ai와 강의, 교안의 도움을 많이 아주 많이 받았다. DTO CreateS..

DI는 Dependency Injection의 줄임말이다. 쉽게 말해서 필요한 객체를 자동으로 주입받는 거다.세 가지 어노테이션의 역할:@Bean직접 설정 클래스에서 등록하는 객체다. 메서드 위에 붙여서 "이 객체를 Spring Container에 올려"라고 지시한다.언제 쓰는가: 라이브러리의 객체나 복잡한 설정이 필요한 객체를 등록할 때.@Service비즈니스 로직을 담당하는 객체다. 계산이나 처리 같은 핵심 기능을 여기에 넣는다.@Repository데이터베이스와 대화하는 객체다. DB에서 데이터 가져오기, 저장하기 같은 작업을 한다.실제 흐름:Controller -> @Autowired -> Service -> Repository -> Database1. 컨트롤러가 비즈니스 로직 필요 -> Servi..

DB에 저장된 Entity가 클라이언트에게 응답으로 돌아가는 과정과, DTO를 따로 두는 실제 이유를 이해하기.Memo Entity (DB 저장 완료)CreateMemoResponse (응답 DTO)JSON 문자열1. Service: Entity → CreateMemoResponse 변환저장된 Entity:Memo { id: 1 title: "스프링 공부" contents: "CRUD 흐름 이해하기" createdAt: 2026-07-06 12:00:00 updatedAt: 2026-07-06 12:00:00}이를 응답 DTO로 변환한다.public CreateMemoResponse(Memo memo) { this.id = memo.getId(); this.title = memo.ge..

메모 생성 요청이 JSON으로 들어와서 데이터베이스에 저장되는 과정 추적하기.개념 구조JSON 문자열 ↓ CreateMemoRequest (입력 DTO) ↓ Memo Entity ↓ Database내용 정리1. 클라이언트가 보내는 JSON{ "title": "스프링 공부", "contents": "CRUD 흐름 이해하기"}네트워크를 통해 문자열로 전송된다.2. Controller: JSON → CreateMemoRequest@PostMappingpublic ResponseEntity create(@RequestBody CreateMemoRequest request) { return ResponseEntity.ok(memoService.save(request));}@RequestBody를 통..

본격적인 Spring 주차를 시작하고 처음 겪은 과제 일정 관리 앱 만들기,애초에 조금 시간이 빠듯하기도 했다고 느꼈지만 강의를 빠르게 듣고 일단은 바로 부딪혀보는게 답일 것 같았다.그리고 간신히 당일날에서야 마무리한 이번 과제정말정말정말 많은 에러들과 마주쳤다. 대부분은 작은 오타나 설정 실수였지만, 그 원인을 찾는 과정에서 배운 게 정말 많다.이번 과제 동안 겪었던 주요 문제들과 해결 방법을 정리해본다. 1. 프로젝트 이름과 패키지 이름을 통일하지 못해서 헤맴 처음에 Entity를 설계할 때는 패키지를 com.example.scheduler, 클래스 이름을 Scheduler로 잡기로 했다. 그런데 실제로 IntelliJ에서 폴더를 만들 때는 프로젝트 이름이 schedule였던 영향으로 나도 모르게 c..