myhousemouse 님의 블로그

PM 회고: 처음 해본 기획, 오래 가져간 프로젝트

myhousemouse — Sat, 20 Jun 2026 23:30:47 +0900

젝트는 기획자, 디자이너, 개발자가 한 팀이 되어 실제 서비스를 만들어보는 IT 사이드 프로젝트 동아리입니다.

아이디어 기획부터 MVP 개발, 사용자 테스트, 마케팅까지 경험할 수 있고, 협업이 처음인 사람도 운영진과 팀원 들의 도움을 받으며

같이 성장해나가는 IT 동아리입니다

[공식 사이트 링크: https://ject.kr]

이 활동은 젝트에서 진행한 프로젝트입니다

처음이라 들어왔고, 끝까지 해보며 배웠다

PM 직무는 이번에 처음 맡아봤다. 처음부터 잘할 수 있을 거라 생각했다기보다는, 직접 해보면서 배우고 싶다는 마음이 컸다.

막상 프로젝트를 시작해보니 PM이 해야 하는 일은 생각보다 넓었다. 문제를 정의하고, 기능을 정하고, 팀원들의 이해를 맞추고, 일정 안에서 계속 선택해야 했다. 특히 하나의 프로젝트를 길게 가져가다 보니 초반 기획이 얼마나 중요한지 체감하게 됐다.

처음 정한 방향이 흐릿하면 뒤로 갈수록 흔들렸다. 그래서 기획은 멋진 아이디어를 많이 내는 일보다, 우리가 무엇을 할지와 무엇을 하지 않을지를 분명히 정하는 일에 가깝다고 느꼈다.

많이 만드는 것보다, 정확히 남기는 것

젝트 안에서도 여러 팀이 방향을 여러 번 바꾸는 것을 보며, 기획자로서 가장 어려운 지점은 ‘탄탄한 기획’과 ‘MVP 설정’ 사이에 있다는 생각이 들었다.

처음에는 좋은 기능을 많이 넣고 싶어진다. 하지만 프로젝트 기간과 팀 리소스는 정해져 있다. 결국 중요한 건 우리가 검증하고 싶은 핵심이 무엇인지, 지금 단계에서 꼭 필요한 기능이 무엇인지 판단하는 일이었다.

우리 팀도 개발을 진행하면서 데이터셋 확보와 정제의 어려움을 마주했다. 원래는 크리에이터와 마케터의 연결고리를 만드는 기능을 주요 페인포인트와 맞닿은 기능으로 보고 있었지만, 데이터셋을 안정적으로 다루기 어렵다고 판단해 후순위로 미뤘다.

그 결정을 하면서 MVP를 정한다는 건 단순히 기능을 줄이는 일이 아니라는 걸 배웠다. 프로젝트의 중심을 남기기 위해, 지금 할 수 없는 것을 인정하는 과정이기도 했다. 다만 그 기능을 어떻게 다시 풀어낼 수 있을지, 보조 기능이나 다른 접근으로 해결할 수 있을지는 앞으로 더 고민해보고 싶은 과제로 남았다.

이번 경험을 통해 PM은 더 많이 만드는 사람이 아니라, 더 정확하게 남기는 사람이어야 한다는 걸 배웠다.

비대면 협업, 저절로 굴러가지 않았다

젝트는 대면 일정이 약 4-5번 정도라 대부분의 협업이 비대면으로 진행됐다. 그래서 마일스톤 관리와 회의 진행이 체계적으로 되어 있어야 프로젝트가 움직인다는 걸 알게 됐다.

비대면에서는 모두가 같은 화면을 보고 있다고 해서 같은 생각을 하고 있는 건 아니었다. 회의 전에 무엇을 결정할지 정리하고, 회의 후에는 결정 사항과 다음 액션을 남겨야 했다. 그 과정이 흐려지면 일정도, 역할도, 우선순위도 함께 흐려졌다.

Jira를 처음 사용해본 것도 기억에 남는다. 비대면으로 프로젝트를 관리해야 하다 보니 티켓 단위로 업무를 나누고 확인하는 방식이 생각보다 유용했다. 회의 중 결정 사항이 계속 바뀌는 상황도 많았는데, 그때마다 메모하고 다시 정리해 전달하는 습관이 생겼다.

이 과정에서 팀장과 PM의 역할이 얼마나 중요한지 크게 느꼈다. 팀이 바쁘고 각자의 속도가 다를수록, 누군가는 현재 위치와 다음 액션을 계속 잡아줘야 했다.

개발자 언어와 디자이너 언어, 그 사이에서

PM으로 일하면서 가장 많이 배운 습관 중 하나는 팀원들의 싱크를 맞추는 일이었다. 단순히 내용을 전달하는 것만으로는 부족했다. 누구에게 전달하느냐에 따라 용어와 설명 방식도 달라져야 했다.

개발자의 말을 디자이너가 이해할 수 있게 풀어주고, 디자이너의 의도를 개발자가 구현 가능한 방식으로 이해할 수 있게 이어주는 일이 필요했다. 때로는 개발자 언어를 번역하는 일처럼 느껴지기도 했다.

그 과정에서 PM은 가운데에서 말을 옮기는 사람이 아니라, 서로 다른 관점을 같은 방향으로 맞추는 사람이라는 생각이 들었다. 같은 내용을 공유하더라도 모두가 같은 방식으로 이해하지 않는다는 점을 계속 의식하게 됐다.

사이드 프로젝트였지만, 협업은 진짜였다

젝트는 대부분 사이드 프로젝트의 성격이 강했다. 협업 프로젝트가 처음인 사람도 있었고, 직장인처럼 다른 일정과 병행하는 사람도 많았다.

그럼에도 이 환경이 좋았던 이유는 혼자 부딪히는 구조가 아니었기 때문이다. 협업이 처음이어도 경험이 있는 팀원들에게 도움을 받을 수 있었고, 운영진분들도 단순히 동아리를 운영하는 데 그치지 않고 각 팀의 멘토처럼 함께 고민해주셨다.

팀원들에게도 많이 배웠다. 프로젝트 중간에 어려움이 생겨도 각자의 책임을 묵묵히 진행해주는 모습이 고마웠다. 잘 모르는 부분을 알려주려 하고, 다른 사람의 의견을 쉽게 깎아내리지 않는 태도도 인상 깊었다. 함께 일하는 방식 자체에서 배운 점이 많았다.

아이디어에서 인스타 운영까지 가봤다

젝트에서 특히 흥미로웠던 점은 자율성이 넓다는 점이었다. 우리 팀은 프로젝트 기간이 늘어났을 때 마케팅 TF팀을 꾸렸고, 한 달 넘게 마케팅만 별도로 진행했다.

나는 그중 인스타그램 운영을 맡았다. 인스타를 잘 아는 편은 아니었지만, 직접 해보니 생각보다 정해야 할 것이 많았다. 아이데이션부터 콘텐츠 레이아웃, 톤앤매너, 업로드 흐름까지 하나씩 잡아야 했다. 어떻게 하면 더 많은 사람에게 닿을 수 있을지, 어떤 메시지가 바이럴될 수 있을지 고민하는 것도 쉽지 않았다.

단순히 4-5주 동안 아이디어를 기획하고 끝내는 것이 아니라, 서비스를 어떻게 알릴지까지 고민해볼 수 있었다는 점이 새로웠다. 실제 프로젝트는 기획에서 끝나는 것이 아니라 사용자에게 닿아야 완성된다는 점을 배웠다.

다들 완벽히 아는 상태에서 시작한 것은 아니었다. 그래도 각자 할 수 있는 만큼 찾아보고, 시도하고, 조율하면서 프로젝트를 끌고 갔다. 그 과정이 힘들기도 했지만, 열정만으로도 팀이 움직일 수 있다는 점이 재미있었다.

실제 사용자를 만나니, 기획이 다시 보였다

UT 세션이 있어 실제 사용자를 만나볼 수 있었던 점도 매력적이었다. 기획자가 상상한 흐름과 사용자가 실제로 쓰는 흐름은 달랐ㅎ

우리 서비스가 정보성 플랫폼이다 보니, 사용자가 너무 많은 정보에 버거워하는 지점도 있었다. 반면 AI 요약 같은 기능에는 긍정적인 반응을 보여주어 조금의 자신감도 생겼다.

이 경험을 통해 기획은 머릿속에서 완성되는 것이 아니라는 걸 느꼈다. 실제 사용자가 어디에서 막히는지, 어떤 기능에 반응하는지 봐야 비로소 다음 방향을 잡을 수 있었다. 사용자 반응을 직접 보는 일은 PM으로서 꼭 필요한 배움이었다.

결국 어려웠던 건 사람과 운영이었다

아쉬운 점도 있었다. 사이드 프로젝트 특성상 젝트에 온전히 집중할 수 있는 사람이 많지는 않았다. 각자의 일과 일정이 있다 보니 참여도와 속도에 차이가 생겼고, 인원 변동도 있었다.

특히 팀장 입장에서는 운영 스트레스가 컸을 것 같다고 느꼈다. 10명이라는 비교적 많은 인원을 이끌어본다는 건 분명 큰 경험이지만, 동시에 쉬운 일이 아니었다.

인원 변동이 있을 때마다 온보딩을 다시 진행해야 했고, 새로 합류한 팀원이 현재 프로젝트 상황에 빠르게 얼라인되도록 돕는 것도 어려웠다. 문서가 있어도 맥락까지 전달하는 데는 시간이 필요했다.

이 경험을 통해 PM에게 필요한 역량은 기획력만이 아니라는 걸 알게 됐다. 일정을 보는 힘, 사람을 살피는 힘, 팀의 맥락을 유지하는 힘도 중요했다.

다음엔 더 탄탄한 기획으로 시작하고 싶다

다음에 다시 PM을 맡는다면 더 탄탄한 기획을 해보고 싶다. 문제의 백그라운드와 사용자 맥락을 더 깊게 이해하고, 페인포인트를 어떤 구조로 풀어갈지 초반에 더 치열하게 고민하고 싶다.

이번에는 처음이라 부딪히며 배운 부분이 많았다. 그래서 앞으로는 기획의 근거를 더 잘 쌓고, 회의 아젠다와 마일스톤, 온보딩 문서도 더 체계적으로 준비해보고 싶다.

기획은 처음에 한 번 정하고 끝나는 문서가 아니었다. 팀이 계속 같은 방향을 볼 수 있도록 업데이트하고, 정리하고, 선택하는 과정이었다.

PM은 팀이 길을 잃지 않게 하는 사람

젝트에서의 경험은 PM이라는 역할을 더 현실적으로 이해하게 해줬다. 좋은 아이디어보다 중요한 건 팀이 실제로 만들 수 있는 방향을 정하는 것. 기능을 많이 넣는 것보다 중요한 건 핵심을 끝까지 지키는 것. 그리고 협업에서 중요한 건 완벽한 사람이 모이는 것이 아니라, 부족해도 계속 맞춰가는 구조를 만드는 것이었다.

처음 PM을 맡으며 많이 헤맸지만, 그만큼 많이 배웠다. 이번 프로젝트를 통해 PM은 프로젝트를 앞에서 끌고 가는 사람인 동시에, 팀이 길을 잃지 않도록 계속 기준을 잡아주는 사람이라는 걸 배웠다.

백엔드 스터디 후기

myhousemouse — Mon, 25 May 2026 19:51:26 +0900

기본 정보

주차/주제: 8주차 - 예외 처리와 데이터 검증

학습 내용 요약

Spring Boot의 기본 예외 처리 방식 조사하기

public Article findById(long id) {
        return blogRepository.findById(id)
                .orElseThrow(() -> new IllegalArgumentException("not found : " + id));
    }

id를 입력받아, 특정 블로그 글을 찾은 다음, IllegalArgumentException 예외로 → not found${id} 에러메시지 보냄

{ 
"timestamp": 2023-04-16T07:28:34. 039+00: 00", # 예외 발생 시간
"status": 500, # HTTP 상태 코드
"error": "Internal Server Error" , # 예외 유형
"path": "/api/articles/123" # 예외가 발생한 요청 경로 
}

예외 발생

컨트롤러나 서비스 레이어에서 예외(런타임 예외, 검증 실패 등) 발생

HandlerExceptionResolver 체인

예외를 처리하는 인터페이스

ExceptionHandlerExceptionResolver (우선순위: 높음)
1. @ExceptionHandler 어노테이션이 달린 메서드를 찾아 실행
2. @ControllerAdvice 클래스 처리
ResponseStatusExceptionResolver (우선순위: 중간)
1. @ResponseStatus 어노테이션이나 ResponseStatusException을 처리
DefaultHandlerExceptionResolver (우선순위: 낮음)
1. Spring MVC 내부에서 발생하는 예외를 적절한 HTTP 상태 코드로 변환
2. 예외 타입에 따라 적절한 HTTP 상태 코드(400, 405 등)를 설정
@ExceptionHandler
1. 컨트롤러 내 특정 예외를 잡아서 처리
2. 이는 전역으로 사용할 수 없다 → @RestControllerAdvice(@ControllerAdvice) 을 사용해야 함
@ControllerAdvice/RestControllerAdvice
1. 애플리케이션 전역에서 예외를 한 곳에서 처리
2. 컨트롤러마다 @ExceptionHandler 쓸 필요 없음
3. @RestControllerAdvice : 에러 응답을 JSON 으로
@ResponseStatus
1. 특정 예외 클래스에 붙여서 그 예외가 발생하면 상태 코드(404, 400 등)를 지정
ResponseStatusException
1. 코드 중간에서 바로 상태 코드와 메시지를 던질 수 있는 예외
2. @ResponseStatus보다 메시지를 동적으로 지정 가능

DefaultErrorAttributes

: 예외 발생 시 에러 정보 수집

무엇을 하는가?
- 예외가 어느 단계에서도 응답으로 커밋(commit)되지 않고,
- 최종적으로 /error로 포워딩되었을 때,
- Map<String,Object> 형태로
  - timestamp, status, error, message, path 등의 공통 속성을 담아 제공합니다
  - 에러 속성을 저장하며 직접 예외를 처리하지는 않는다.
확장 포인트: getErrorAttributes() 메서드 오버라이드를 통해 커스텀 필드 추가 가능

@Component
public class CustomErrorAttributes extends DefaultErrorAttributes {
    @Override
    public Map<String, Object> getErrorAttributes(...) {
        Map<String, Object> attrs = super.getErrorAttributes(...);
        attrs.put("traceId", UUID.randomUUID().toString());
        return attrs;
    }
}

DefaultErrorAttributes가 예외 정보 수집 (getErrorAttributes())

DefaultErrorAttribute - 스프링부트 기본 제공. 에러 "데이터"를 만듬

에러 발생 시, 에러에 대한 다양한 속성(메시지, 상태코드, 예외 등)을 Map 형태로 생성해주는 역할을 합니다.
즉, 에러 응답에 포함될 데이터(에러 정보)를 구성합니다.

ErrorAttribute에 추가 정보를 담아 구현하여 빈으로 등록 → ErrorAttribute에 맞춰 에러메시지 제작

ex) DefaultErrorAttribute → customValue라는 키를 등록

BasicErrorController → 그 데이터를 "응답"으로 만들어 반환

실제로 /error 엔드포인트를 처리하는 컨트롤러
내부적으로 DefaultErrorAttributes를 사용해 에러 정보를 받아와서, JSON 또는 HTML로 응답

BasicErrorController

: 스프링 기본 예외처리 컨트롤러

WAS가 /error 경로 요청 처리 → HTML/JSON 응답 생성

브라우저 → HTML 에러 페이지(Whitelabel)를 보여줌
API → { status:500, error:"Internal Server Error", … } 같은 기본 JSON을 돌려줌

문제점

404(리소스 없음)도 500(서버 에러)로 나옴
에러 메시지·코드가 너무 일반적이라 “무슨 문제가 있었는지” 알기 어려움

@Controller
// 1) Spring 환경 내에 server.error.path 혹은 
// error.pth로 등록된 property의 값을 넣거나 없는 경우에는 /error을 사용한다.
@RequestMapping("${server.error.path:${error.path:/error}}")
public class BasicErrorController extends AbstractErrorController {

    // 2) HTML 형식의 에러 페이지 요청 처리
    @RequestMapping(produces = MediaType.TEXT_HTML_VALUE)
    public ModelAndView errorHtml(HttpServletRequest request,
                                  HttpServletResponse response) {
        // (2-1) 요청에서 HTTP 상태 코드(404, 500 등)를 꺼내고
        HttpStatus status = getStatus(request);

        // (2-2) 에러 정보를 Map 형태로 가져옵니다.
        //      기본적으로 timestamp, status, error, message, path 등이 담겨있음
        Map<String, Object> model = getErrorAttributes(request, false);

        // (2-3) 실제 응답 상태 코드를 설정한 뒤
        response.setStatus(status.value());

        // (2-4) "error"라는 이름의 뷰(HTML)를 렌더링하며,
        //       model에 담긴 에러 정보를 화면에 뿌려줍니다.
        return new ModelAndView("error", model);
    }

    // 3) JSON·API 형식의 에러 응답 처리
    @RequestMapping
    public ResponseEntity<Map<String, Object>> errorApi(HttpServletRequest request) {
        // (3-1) 에러 정보를 Map 형태로 가져옵니다.
        Map<String, Object> body = getErrorAttributes(request, false);

        // (3-2) 상태 코드를 꺼내서
        HttpStatus status = getStatus(request);

        // (3-3) body(Map)를 JSON으로 자동 변환해 리턴
        return new ResponseEntity<>(body, status);
    }
}

getErrorAttributes ← 부모 클래스인 AbstractErrorController

public class BasicErrorContorller extends **AbstractErrorController**

public abstract class AbstractErrorController implements ErrorController {
  private final ErrorAttributes errorAttributes;
    
  protected Map<String, Object> getErrorAttributes(HttpServletRequest request,
    boolean includeStackTrace) {

    WebRequest webRequest = new ServletWebRequest(request);
    return this.errorAttributes.getErrorAttributes(webRequest, includeStackTrace);
  }
}

예외처리 적용

ErrorCode (Enum)

에러 별, Http Status code와 에러 메시지를 정의하는 파일이다.

@Getter
public enum ErrorCode {
    INVALID_INPUT_VALUE(HttpStatus.BAD_REQUEST, "E1", "올바르지 않은 입력값입니다."),
    METHOD_NOT_ALLOWED(HttpStatus.METHOD_NOT_ALLOWED, "E2", "잘못된 HTTP 메서드를 호출했습니다."),
    INTERNAL_SERVER_ERROR(HttpStatus.INTERNAL_SERVER_ERROR, "E3", "서버 에러가 발생했습니다."),
    NOT_FOUND(HttpStatus.NOT_FOUND, "E4", "존재하지 않는 엔티티입니다."),

    ARTICLE_NOT_FOUND(HttpStatus.NOT_FOUND, "A1", "존재하지 않는 아티클입니다.");

    private final String message;

    private final String code;
    private final HttpStatus status;

    ErrorCode(final HttpStatus status, final String code, final String message) {
        this.status = status;
        this.code = code;
        this.message = message;
    }
}

ErrorResponse

클라이언트에게 전달할 에러의 응답 형태를 정의하는 클래스다.

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class ErrorResponse {

    private String message;
    private String code;

    private ErrorResponse(final ErrorCode code) {
        this.message = code.getMessage();
        this.code = code.getCode();
    }

    public ErrorResponse(final ErrorCode code, final String message) {
        this.message = message;
        this.code = code.getCode();
    }

    public static ErrorResponse of(final ErrorCode code) {
        return new ErrorResponse(code);
    }

    public static ErrorResponse of(final ErrorCode code, final String message) {
        return new ErrorResponse(code, message);
    }
}

GlobalExceptionHandler

앞에서 언급한 @RestControllerAdvice, @ExceptionHandler를 사용해 전역 예외 처리를 담당하는 Class이다.

@Slf4j
@ControllerAdvice // 모든 컨트롤러에서 발생하는 예외를 잡아서 처리
public class GlobalExceptionHandler {

    // 지원하지 않은 HTTP method 호출 할 경우 발생
    @ExceptionHandler(HttpRequestMethodNotSupportedException.class) // HttpRequestMethodNotSupportedException 예외를 잡아서 처리
    protected ResponseEntity<ErrorResponse> handle(HttpRequestMethodNotSupportedException e) {
        log.error("HttpRequestMethodNotSupportedException", e);
        return createErrorResponseEntity(ErrorCode.METHOD_NOT_ALLOWED);
    }

    @ExceptionHandler(MethodArgumentNotValidException.class)
    protected ResponseEntity<ErrorResponse> handle(MethodArgumentNotValidException e) {
        log.error("MethodArgumentNotValidException", e);
        return createErrorResponseEntity(ErrorCode.INVALID_INPUT_VALUE);
    }

    @ExceptionHandler(BusinessBaseException.class)
    protected ResponseEntity<ErrorResponse> handle(BusinessBaseException e) {
        log.error("BusinessException", e);
        return createErrorResponseEntity(e.getErrorCode());
    }

    @ExceptionHandler(Exception.class)
    protected ResponseEntity<ErrorResponse> handle(Exception e) {
        e.printStackTrace();
        log.error("Exception", e);
        return createErrorResponseEntity(ErrorCode.INTERNAL_SERVER_ERROR);
    }

    private ResponseEntity<ErrorResponse> createErrorResponseEntity(ErrorCode errorCode) {
        return new ResponseEntity<>(
                ErrorResponse.of(errorCode),
                errorCode.getStatus());
    }
}

public class BusinessBaseException extends RuntimeException {

    private final ErrorCode errorCode;

    public BusinessBaseException(String message, ErrorCode errorCode) {
        super(message);
        this.errorCode = errorCode;
    }

    public BusinessBaseException(ErrorCode errorCode) {
        super(errorCode.getMessage());
        this.errorCode = errorCode;
    }

    public ErrorCode getErrorCode() {
        return errorCode;
    }
}

입력값 검증이 필요한 상황 3가지 생각해오기

입력값 검증 : 사용자가 요청을 보냈을때 올바른 값인지 유효성검사를 하는 과정

1. 사용자 회원가입 정보 검증

검증 요구사항

이메일: 유효한 형식 필수
비밀번호: 8~20자, 영문/숫자/특수문자 조합
나이: 14세 이상 100세 이하
전화번호: 010-XXXX-XXXX 형식

public class SignUpRequest {
    @NotBlank(message = "이메일을 입력해주세요")
    @Email(message = "유효한 이메일 형식이 아닙니다")
    private String email;

    @NotBlank(message = "비밀번호를 입력해주세요")
    @Pattern(regexp = "^(?=.*[A-Za-z])(?=.*\\d)(?=.*[@$!%*#?&])[A-Za-z\\d@$!%*#?&]{8,20}$",
             message = "8~20자 영문/숫자/특수문자 조합 필요")
    private String password;

    @Min(value = 14, message = "14세 이상만 가입 가능합니다")
    @Max(value = 100, message = "유효하지 않은 나이입니다")
    private int age;

    @Pattern(regexp = "^010-\\d{4}-\\d{4}$", 
             message = "010-XXXX-XXXX 형식으로 입력해주세요")
    private String phone;
}

@Valid 어노테이션이 DTO의 검증 규칙을 자동 적용

2. 상품 주문 정보 검증

검증 요구사항

상품명: 필수 입력 항목 (@NotBlank)
가격: 1,000원 ~ 1,000,000원 (@Min, @Max)
수량: 1개 ~ 9,999개 (@Min, @Max)

import javax.validation.constraints.*;

@Data // Lombok 사용 (Getter/Setter 자동 생성)
public class ProductOrderRequest {

    @NotBlank(message = "상품명은 필수 입력 항목입니다")
    @Size(max = 100, message = "상품명은 최대 100자까지 입력 가능합니다")
    private String productName;

    @NotNull(message = "가격은 필수 입력 항목입니다")
    @Min(value = 1000, message = "가격은 최소 {value}원 이상이어야 합니다")
    @Max(value = 1000000, message = "가격은 최대 {value}원 이하여야 합니다")
    private Integer price;

    @NotNull(message = "수량은 필수 입력 항목입니다")
    @Min(value = 1, message = "수량은 최소 {value}개 이상이어야 합니다")
    @Max(value = 9999, message = "수량은 최대 {value}개 이하여야 합니다")
    private Integer quantity;
}

3. 파일 업로드 검증

검증 요구사항

파일 타입: JPG/PNG/PDF만 허용
파일 크기: 최대 5MB
파일명: 특수문자 포함 금지

자바 빈 밸리데이션 (Java Bean Validation)

→ 검증 규칙 간편하게 사용 가능

/**
* 문자열을 다룰 때 사용
*/
@NotNull // null 허용하지 않음
@NotEmpty // null, 빈 문자열(공백) 또는 공백만으로 채워진 문자열 허용하지 않음
@NotBlank // null, 빈 문자열(공백) 허용하지 않음
@Size(min=?, max=?) // 최소 길이, 최대 길이 제한
@Null // null만 가능

/**
* 숫자를 다룰 때 사용
*/
@Positive // 양수만 허용
@PositiveOrZero // 양수와 0만 허용
@Negative // 음수만 허용
@NegativeOrZero // 음수와 0만 허용
@Min(?) // 최솟값 제한
@Max(?) // 최댓값 제한

/**
* 정규식 관련
*/
@Email // 이메일 형식만 허용
@Pattern(regexp="?") // 직접 작성한 정규식에 맞는 문자열만 허용

활용 가능

회원가입 폼 검증
API 입력 파라미터 검증
데이터베이스 저장 전 검증
파일 업로드 메타데이터 검증

새롭게 알게 된 점 & 어려웠던 부분

어려웠던 부분:
- 학습 과정에서 깊이 있는 이해와 실습을 충분히 하지 못한 점이 아쉬움.
- Spring의 기초 개념을 더 공부한 후에 다시 정리하면 더 정확한 이해가 가능할 것 같음.
- 개념 이해에만 시간을 투자하다 보니 실습을 진행하지 못했는데, 향후 실습을 통해 경험을 쌓을 예정
해결 방법:
- 기초 spring 개념 학습 후 재학습
- 실제 실습 프로젝트에서 사용해보고 싶음

과제/실습 결과 (있을 시)

public enum ErrorCode {
    USER_NOT_FOUND(404, "USR_001", "사용자를 찾을 수 없습니다");
    // …생성자·getter 생략
}

// 2) 베이스 예외
public abstract class ApplicationException extends RuntimeException {
    private final ErrorCode code; // 에러코드 Enum 

    public ApplicationException(ErrorCode code) {
        super(code.getMessage());
        this.code = code;          
    }
    public int getStatus() { return code.getStatus(); }
    public String getCode()   { return code.getCode(); }
}

// 3) **커스텀 예외 클래스 (빈칸 채우기)**  => 사용자 찾지 못하는 예외 User_Not_Found 활용
public class UserNotFoundException extends ApplicationException {  
    public UserNotFoundException(Long id) {  // id 형식은 Long -> 
        super(ErrorCode.USER_NOT_FOUND);  
    }  
}

스터디 피드백

면접 CS 질문

커스텀 예외를 만들 때 extends RuntimeException을 권장하는 이유는?

DTO 레벨 검증과 서비스 레벨 검증, 어디에 어떤 검증을 두어야 할까?

입력값 검증만으로 방어할 수 없는 공격(예: SQL Injection, XSS)은? 추가로 어떤 조치를 해야 하나?

-> 각각 질문에 대해서 자신만의 답변 생각해보기.

백엔드 스터디 후기

myhousemouse — Sun, 17 May 2026 21:32:17 +0900

기본 정보

주차/주제: 7주차 - 인증과 보안 기초

학습 내용 요약

1. 인증(Authentication)과 인가(Authorization)의 차이점

A. 인증(Authentication) : 사용자의 신원을 입증하는과정

예시: 사용자가 로그인 화면에서 아이디와 비밀번호를 입력하여 신원을 증명하는 과정

스프링 시큐리티의 예: UsernamePasswordAuthenticationFilter: 사용자가 입력한 아이디와 비밀번호를 통해 인증 과정 처리

B. 인가(Authorization) : 사이트 특정부분에 접근할 수 있는지 파악 (사용자의 권한을 파악)

예시:

관리자 권한이 있는 사용자만 관리자 페이지에 접근 가능, 일반 사용자는 접근할 수 없도록 접근을 제어
파일공유시스템→ 내가 접근가능한 폴더만 사용가능

스프링 시큐리티의 예: FilterSecurityInterceptor: 사용자가 요청한 자원에 접근할 권한이 있는지 검사하여 접근 제어를 처리

인증은 집 현관문을 열 때 "이 집 주인이 맞나요?"라고 물어보는 것
인가는 집 안의 각 방을 들어갈 때 "내가 이 방에 들어갈 수 있나요?"라고 묻는 것과 같음
항상 인증 → 인가 순서로 진행(인증이 완료되지 않으면 인가 로직 자체가 동작하지 않음)

⇒ 스프링 시큐리티로 쉽게 구현 가능

스프링 시큐리티: 보안을 담당하는 하위 프레임워크

CSRF 공격 방지 ( = 봉인스티커)
- CSRF 공격: 사용자의 권한을 가지고 특정 동작을 수행하도록 유도하는 공격
- Spring Security는 모든 POST, PUT, DELETE 요청에 대해 CSRF 토큰을 검증
세션고정 공격 방지 (= 비밀번호 변경 후 새 열쇠 발급)
- 사용자 인증 정보를 탈취하거나, 변조하는 공격
- 공격자가 미리 발급받은 세션 ID(쿠키)를 피해자에게 물고 들어가 로그인 유도
- Spring Security는 로그인 직후 항상 새로운 세션 ID를 발급하도록 기본 설정(SessionAuthenticationStrategy)

Spring Security

필터기반 javax.servlet.Filter로 인증·인가 처리
세션-쿠키 방식
SecurityContextPersistenceFilter :
SecurityContextRepository에서 SecurityContext(접근 주체와 인증에 대한 정보를 담고 있는 객체) 를 가져오거나 저장하는 역할
LogoutFilter:
설정된 로그아웃 URL로 오는 요청을 확인해 해당 사용자를 로그아웃 처리함
UsernamePasswordAuthenticationFilter: 인증관리자
폼 기반 로그인 시 사용되는 필터로 아이디 패스워드 데이터를 파싱하여 인증 요청을 위임인증이 성공하면 AuthenticationSuccessHandler, 실패하면 AuthenticationFailureHandler를 실행
DefaultLoginPageGeneratingFilter:
사용자가 로그인 페이지를 지정하지 않았을 때 기본으로 설정하는 로그인 페이지 관련 필터
BasicAuthenticationFilter:
요청 헤더에 있는 아이디와 패스워드를 파싱해 인증 요청
위임인증이 성공하면 AuthenticationSuccessHandler,
실패하면 AuthenticationFailureHandler를 실행
RequestCacheAwareFilter:
로그인 성공 후, 관련 있는 캐시 요청이 있는지 확인하고 캐시 요청 처리
SecurityContextHolderAwareRequestFilter:
HttpServletRequest 정보를 감싸고, 필터 체인 상의 다음 필터들에게 부가 정보 제공
AnonymousAuthenticationFilter:
필터가 호출되는 시점까지 인증되지 않았다면 익명 사용자 전용 객체인 AnonymousAuthentication을 만들어 SecurityContext에 넣어준다
SessionManagementFilter:
인증된 사용자와 관련된 세션 작업 진행, 세션 변조 방지 전략 설정, 유효하지 않은 세션에 대한 처리, 세션 생성 전략을 세우는 등의 작업을 처리한다
ExceptionTranslationFilter:
요청을 처리하는 중에 발생할 수 있는 예외를 위임하거나 전달
FilterSecurityInterceptor: 접근 결정 관리자
AccessDecisionManager로 권한 부여 처리를 위임함으로써 접근 제어 결정을 쉽게 해준다.이 과정에서 이미 사용자 인증이 되어있으므로 유효한 사용자인지도 알 수 있음. 인가 관련 설정 가능

SecurityContextHolder(금고 열쇠 통)

SecurityContext를 제공하는
static 메소드(getContext)를 지원한다.

SecurityContext (금고)

접근 주체와 인증에 대한 정보를 담고 있는 Context
즉, Authentication 을 담고 있다.

Authentication (보안카드 등록한 프로필)

Principal과 GrantAuthority를 제공한다.인증이 이루어지면 해당 Athentication이저장

Principal (보안카드의 내정보)

유저에 해당하는 정보, 대부분의 경우 Principal로 UserDetails를 반환한다.

GrantAuthority

ROLE_ADMIN, ROLE_USER 등 Principal이 가지고 있는 권한을 나타낸다.

스프링 시큐리티 인증 처리 과정

2. JWT(JSON Web Token)의 기본 구조와 장점 알아보기

기본구조

헤더(Header), 내용(Payload), 서명(Signature) 세 부분으로 구성되며, 각 부분은 마침표(.)로 구분

헤더(Header)

토큰타입 , 해싱 알고리즘 정보 담고 있음.

{ “typ”:”JWT”,  토큰 타입
“alg” : “HS256” } 해싱 알고리즘

내용(Payload)

Payload는 클레임(claim)의 집합으로 → 내용을 한덩어리로
- 클레임: 키 값의 한쌍으로 이루어져 있음 → JWT에 데이터 넣을수있음
- 등록 클레임 (토큰에 대한 정보 ex. 토큰 발급자, 제목, 대상자, 만료시간, 발급 시간 등등)
  - iss, sub, iat, exp 등
- 공개 클레임 : URI로 명명함 (공개되어도 상관 없음)
- 비공개 클레임
  - 애플리케이션 정의 정보
- { "iss": "[ajufresh@gmail.com](mailto:ajufresh@gmail.com)", // 등록된 클레임 "iat": 1622370878, // 등록된 클레임 "exp": 1622372678, // 등록된 클레임 "https://shinsunyoung.com/jwt_claims/is_admin": true, // 공개 클레임 "email": "[ajufresh@gmail.com](mailto:ajufresh@gmail.com)", // 비공개 클레임 "hello": "안녕하세요!" // 비공개 클레임 }
사용자의 인증, 인가 정보가 담김
토큰과 관련된 정보

서명(Signature)

토큰 변조 여부를 확인하는 용도
헤더와 페이로드의 정보를 인코딩한 후, 비밀 키로 서명하여 생성

HMACSHA256(
  base64UrlEncode(Header) + "." + base64UrlEncode(Payload),
  secretKey
)

장단점

JWT 이전의 세션 기반 인증

로그인

사용자 ID/PW 검증 후, 서버가 세션 객체(Map 형태)를 만들고 고유 ID(예: JSESSIONID)를 발급
이 ID를 쿠키로 돌려줌

요청 처리

클라이언트는 매 요청마다 쿠키의 세션 ID를 전송
서버는 이 ID로 DB/인메모리 캐시에 저장된 세션 정보를 조회 → 사용자 정보 로딩

단점

서버 상태 유지(Stateful): 접속자 수만큼 메모리/DB 부하 상승
확장성 문제: 여러 대 서버를 띄울 때 세션 동기화 혹은 Sticky Session 필요
쿠키 의존: 브라우저 설정에 따라 거부될 수 있고, 모바일 앱에서는 관리 불편

JWT 장점

웹 표준 준수 (RFC 7519)
URL-safe: 쿼리 파라미터나 헤더에 안전하게 포함 가능
Self-contained: 사용자 정보나 권한 정보를 토큰에 모두 담아 서버 상태 비저장(Stateless)
- 필요한 모든 정보를 하나의 객체에 담아서 전달하기 때문에 JWT 하나로 인증을 마칠 수 있다
확장성: 서버에 세션 저장소 불필요 → 인프라 비용 절감
설정 가능한 만료/발급 시간: exp, iat를 통해 만료 관리

JWT 단점

토큰 무효화 어려움
- stateless 방식 → 탈취된 토큰은 만료 전까지 유효 → 블랙리스트/키 회전 필요
크기 증가
- Header.Payload.Signature 3부분, 각 파트에 들어가는 정보(클레임)가 많아질수록 길이가 커짐
- HTTP 요청마다 Authorization: Bearer {JWT} 헤더에 수백~수천 바이트의 문자열을 전송해야 함
보안 이슈
- XSS·CSRF 공격에 취약할 수 있어 HTTPS, Secure/Cookie 설정 권장
  - XSS(크로스 사이트 스크립팅) : 악성 스크립트 삽입 → 방문 이용자가 스크립트 실행되도록 함

보완책

리프레시 토큰: 액세스 토큰 만료 시 재발급용으로 사용
- 액세스 토큰이 만료되어 새로운 액세스 토큰을 만들때 사용
블랙리스트 or 키 회전(Key Rotation) 전략
짧은 액세스 토큰 수명 + 안전한 저장소 (예: HttpOnly Cookie)

JWT 적용 방식 HTTP request

Stateless 인증
- 세션 대신 HTTP 헤더 Authorization: Bearer {token} 사용
- 서버가 클레임(Claim) 기반으로 토큰 서명 확인 → 사용자 정보(Subject, 권한) 복원
커스텀 필터 (OncePerRequestFilter 상속)
- 요청마다 JWT 추출 → 유효성 검사 → Authentication 생성 → SecurityContextHolder저장
- 헤더에서 JWT 추출
- 서명·만료일 검사
- 토큰에서 사용자 정보 파싱 → UsernamePasswordAuthenticationToken 생성

“휴대폰 QR 체크인”
QR 체크인 과정 JWT 인증 흐름
1. QR 코드 제시
“한 번만 앱을 켜고 QR 보여주기”
클라이언트가 Authorization: Bearer {JWT} 헤더에 토큰 담아 요청

직원이 스캔하여 확인
“QR 스캔 → 유효 기간·위조 검사→ OK OncePerRequestFilter가 토큰 추출 → 서명·만료일 검증 → Authentication 생성
그 뒤로는 QR만 보여주면 통과“매번 신분증 없이 QR로만 입장 OK” 매 요청마다 토큰 검증 → 상태 비저장(Stateless) 인증 유지
QR 잃어버리거나 훼손 시 입장 불가
“유효 기간 지난 QR 혹은 변조된 QR은 차단” 만료된 토큰(exp) 또는 서명 불일치 시 인증 실패(403)

새롭게 알게 된 점 & 어려웠던 부분

보안과 관련해 처음 배우는 내용이라, 이해하는데 시간이 꽤 걸림.
배울 범위가 방대해 천천히 개념을 잡아가야 할듯..

과제/실습 결과

인증, 인가 실습 -> 스프링 시큐리티
UserDetails 클래스

@RequiredArgsConstructor
@Service
// 스프링 시큐리티에서 사용자 정보를 가져오는 인터페이스
public class UserDetailService implements UserDetailsService {

    private final UserRepository userRepository;

    // 사용자 이름(email)을 통해 사용자 정보를 가져오는 메서드
    @Override
    public User loadUserByUsername(String email) {
        return userRepository.findByEmail(email)
                .orElseThrow(() -> new IllegalArgumentException((email)));
    }
}

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class WebSecurityConfig {
    private final UserDetailService userService;
    // 스프링 시큐리티 비활성화 (모든 기능 사용하지 못하게)
    // 일반적으로 정적 리소스에 인증, 인가 사용
    @Bean
    public WebSecurityCustomizer configure() {
        return (web) -> web.ignoring()
                .requestMatchers(toH2Console())
                .requestMatchers(new AntPathRequestMatcher("/static/**"));
    }
    // 특정 HTTP 요청에 대한 보안 설정
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
                .authorizeHttpRequests(auth -> auth // 인증, 인가 설정
                        .requestMatchers( // 특정 요청과 일치하는 url 액세스
                                new AntPathRequestMatcher("/login"),
                                new AntPathRequestMatcher("/signup"),
                                new AntPathRequestMatcher("/user")
                        ).permitAll() // 모든 사용자에게 허용(로그인, 회원가입은 인증 필요 없음)
                        .anyRequest().authenticated())
                //anyRequest()는 모든 요청을 의미하며,
                // authenticated()는 인증된 사용자만 접근할 수 있도록 설정
                .formLogin(formLogin -> formLogin // 폼 기반 로그인
                        .loginPage("/login") // 로그인 페이지 경로
                        .defaultSuccessUrl("/articles") // 로그인 성공 시 이동할 경로
                )
                .logout(logout -> logout // 로그아웃 설정
                        .logoutSuccessUrl("/login") // 로그아웃 성공 시 이동할 경로
                        .invalidateHttpSession(true) // 세션 무효화
                )
                .csrf(AbstractHttpConfigurer::disable) // CSRF 비활성화 (실습때문에 비활성화)
                .build();
    }
    // 인증 매니저 설정
    @Bean
    public AuthenticationManager authenticationManager(HttpSecurity http, BCryptPasswordEncoder bCryptPasswordEncoder, UserDetailService userDetailService) throws Exception {
        DaoAuthenticationProvider authProvider = new DaoAuthenticationProvider();
        authProvider.setUserDetailsService(userService); // 사용자 정보 서비스 설정
        authProvider.setPasswordEncoder(bCryptPasswordEncoder);
        return new ProviderManager(authProvider);
    }
    // 패스워드 인코더로 사용할 빈 설정
    @Bean
    public BCryptPasswordEncoder bCryptPasswordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

@RequiredArgsConstructor
@Service
public class UserService {
    private final UserRepository userRepository;
    private final BCryptPasswordEncoder bCryptPasswordEncoder;
    public Long save(AddUserRequest dto) {
        return userRepository.save(User.builder()
                .email(dto.getEmail())
                // 비밀번호 암호화
                .password(bCryptPasswordEncoder.encode(dto.getPassword()))
                .build()).getId();
    }
}

# Spring JPA
spring.application.name=springboot-developer
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true
spring.jpa.defer-datasource-initialization=true

# datasource
spring.datasource.url=jdbc:h2:mem:testdb
spring.datasource.username=sa
spring.datasource.password=

# Hibernate DDL
spring.jpa.hibernate.ddl-auto=update

# H2
spring.h2.console.enabled=true

JWT 실습

토큰 생성
올바른 토큰인지 유효성 검사
토큰에서 필요한 정보 가져오기

@RequiredArgsConstructor
@Service
public class TokenProvider {

    private final JwtProperties jwtProperties;
    // 사용자 정보와 만료 기간을 입력받아 JWT를 생성합니다.
    // 만료 시간을 계산한 뒤, makeToken 메서드를 호출합니다.
    public String generateToken(User user, Duration expiredAt) {
        Date now = new Date();
        return makeToken(new Date(now.getTime() + expiredAt.toMillis()), user);
    }
    // JWT 토큰을 생성하는 메서드
    // JWT의 헤더, 페이로드, 서명을 설정합니다.
    // 설정된 정보를 기반으로 JWT 문자열을 생성
    private String makeToken(Date expiry, User user) {
        Date now = new Date();

        return Jwts.builder()
                .setHeaderParam(Header.TYPE, Header.JWT_TYPE) // 헤더 JWT 타입 설정
                // 내용 iss: ajufresh@gmail.com (properties에서 가져옴)
                .setIssuer(jwtProperties.getIssuer())
                .setIssuedAt(now) // 내용 iat : 발급 시간
                .setExpiration(expiry) // 내용 exp : expiry 멤버 변숫값
                .setSubject(user.getEmail()) // 내용 sub : 사용자 이메일
                .claim("id", user.getId()) // 클레임 id : 사용자 id
                //서명: 비밀값과 함께 해시값을 H256 알고리즘으로 암호화
                .signWith(SignatureAlgorithm.HS256, jwtProperties.getSecretKey())
                .compact();
    }
    // JWT 토큰을 유효성 검증하는 메서드
    public boolean validToken(String token) {
        try {
            Jwts.parser()
                    .setSigningKey(jwtProperties.getSecretKey()) //비밀값으로 복호화
                    // Properties에서 가져온 비밀값으로 복호화
                    .parseClaimsJws(token);

            return true;
        } catch (Exception e) {// 복호화 과정에서 에러가 나면 유효하지않은 토큰
            return false;
        }
    }

    // JWT 토큰에서 사용자 인증 정보를 가져오는 메서드
    // 토큰을 받아 인증정보를 담은 Authentication 객체를 생성
    public Authentication getAuthentication(String token) {
        // 1. 토큰 복호화 및 클레임 추출
        Claims claims = getClaims(token); // JWT 토큰을 복호화하고, 클레임(Claims) 정보를 가져옵니다.
        //클레임은 JWT의 페이로드에 포함된 데이터로, 여기서는 사용자 이메일(sub)과 기타 정보를 포함

        // 2. 권한 설정
        Set<SimpleGrantedAuthority> authorities = Collections.singleton(new SimpleGrantedAuthority("ROLE_USER"));
        // Set<SimpleGrantedAuthority>를 사용하여 사용자 권한을 설정합니다. (ROLE_USER라는 권한을 부여)

        // 3. Authentication 객체 생성
        return new UsernamePasswordAuthenticationToken(new org.springframework.security.core.userdetails.User(claims.getSubject
                (), "", authorities), token, authorities);
        //UsernamePasswordAuthenticationToken 객체를 생성하여 반환
        //이 객체는 스프링 시큐리티에서 인증 정보를 담는 데 사용됩니다.
        //첫 번째 인자로 들어가는 User는 스프링 시큐리티에서 제공하는 org.springframework.security.core.userdetails.User 클래스를 사용해야 합니다
    }

    // JWT 토큰에서 사용자 ID를 가져오는 메서드
    public Long getUserId(String token) {
        Claims claims = getClaims(token); // JWT 토큰을 복호화하고, 클레임(Claims) 정보를 가져옵니다.
        // 클레임 정보 반환 -> 클레임에서 id 값 추출
        return claims.get("id", Long.class);
    }

    private Claims getClaims(String token) {
        return Jwts.parser() // 클레임 조회
                .setSigningKey(jwtProperties.getSecretKey())
                .parseClaimsJws(token)
                .getBody();
    }
}

@Setter
@Getter
@Component
@ConfigurationProperties("jwt")
public class JwtProperties {
    private String issuer;
    private String secretKey;
}

스터디 피드백

Q. Refresh Token도 탈취될 경우, Access Token의 보완책으로 나온 의미가 없는데, 이를 어떻게 처리하면 되는가?
A. Refresh Token의 유효기간을 짧게 설정하고, 2중 3중으로 암호화를 하는 방법이 있다.

Q. Access/Refresh Token 전략 설계 -> Access Token만 사용할때?
A. 짧은 유효기간 (15분~1시간)으로 Access Token을 설정하기.

Q. 토큰 저장 위치는 어디로 할까? (쿠키 vs 로컬스토리지)
A. 쿠키 -> XSS 공격 방지, 자동으로 쿠키가 전송되어 편리
로컬스토리지 -> XSS 취약, 자동 전송되지 않으므로 CSRF 공격에 안전, 토큰을 수동으로 추가

보안측면에선 쿠키를 사용하는것이 더 안전.

큐시즘 - SEMOSAN 밋업 프로젝트 중간 회고 | PM

myhousemouse — Sun, 10 May 2026 22:38:10 +0900

세모산 밋업 프로젝트 중간 회고

이번 세모산 밋업 프로젝트를 중간까지 해오면서, PM인 내가 어떤 고민을 했고 무엇을 정리해왔는지 조금 편하게 회고처럼 남겨보려고 한다. 완성된 프로젝트를 돌아보는 회고라기보다는, 중간 시점에서 우리가 어디까지 왔는지, 지금 어떤 걸 배우고 있는지 정리하는 기록에 더 가깝다.

먼저 느낀 점

초반의 세모산은 아이디어 자체는 분명히 매력적이었는데, PM 입장에서는 그 아이디어를 실제 서비스 흐름으로 정리하는 일이 가장 먼저 필요하다고 느꼈다. 누구를 위한 서비스인지, 첫 화면에서 사용자가 뭘 이해해야 하는지, 어떤 기능부터 MVP로 잡아야 하는지가 한 번에 또렷하게 보이지는 않았기 때문이다.

특히 세모산이 초보자용 추천 서비스인지, 등산 기록 서비스인지, 커뮤니티형 서비스인지가 동시에 보이는 순간들이 있었고, 그래서 처음에는 기능이 많아 보이는데도 핵심 메시지가 조금 퍼져 있는 느낌이 있었다. 그걸 정리하는 게 중간까지 내 역할의 핵심이었다고 생각한다.

중간까지 PM으로서 가장 많이 한 일

내가 중간 시점까지 가장 많이 한 일은 새로운 기능을 마구 추가하는 게 아니라, 세모산의 중심 흐름을 계속 정리하고 문서화하는 일이었다.

그래서 우선 세모산의 1차 핵심 흐름을 아래처럼 다시 잡았다.

온보딩
코스 탐색 / 등산 시작
실시간 도우미
기록 아카이빙
기록 공유 또는 커뮤니티 연결

이 흐름이 잡히고 나서야 요구사항 정의서, 기능명세서, 요구사항-기능 매핑표, 운영정책, 심사용 테스트 시나리오 같은 문서들이 하나의 방향으로 연결되기 시작했다. 개인적으로는 이게 중간 시점까지 가장 큰 변화였다.

작업하면서 남겨둔 시안들

아래 이미지는 중간 작업 과정에서 정리한 세모산 홍보물 시안이다. 단순 디자인 결과물이라기보다, 세모산이 어떤 메시지로 보이길 원하는지 정리해가는 과정이기도 했다.

중간까지 오면서 잘했다고 느낀 점

1. 서비스 방향을 계속 초보자 친화적으로 붙잡고 있었던 점

세모산은 결국 등산을 어렵게 느끼는 사람도 시작할 수 있게 만들어주는 서비스여야 한다고 생각했다. 그래서 문서를 쓸 때도 전문 용어보다 생활 언어, 권한 요청 전에 이유 설명, 로그인 없이도 코스 탐색 가능, 추천 결과에 이유를 붙이는 구조 같은 원칙을 계속 놓치지 않으려고 했다.

이 부분은 나중에 디자인이나 홍보 메시지를 정할 때도 꽤 중요한 기준이 됐다. 서비스가 똑똑해 보이는 것보다, 사용자가 "아, 나도 써볼 수 있겠다"고 느끼는 게 더 중요하다고 봤다.

2. 기능 나열보다 사용자 흐름 중심으로 문서를 정리한 점

초반에는 기능 하나하나를 보면 다 중요해 보였는데, 중간쯤 오니까 중요한 건 기능의 개수가 아니라 사용자가 어디서 들어와서 어디까지 가는지를 명확히 보여주는 거라는 걸 더 분명히 느꼈다.

그래서 온보딩, 코스 추천, 기록 저장, 커뮤니티, 심사 대응을 따로따로 보지 않고, 하나의 서비스 경험 안에서 이어지도록 정리하려고 했다. 이 흐름이 잡히면서 팀 안에서 대화할 때도 기준이 조금 더 선명해졌다고 느꼈다.

3. 운영과 심사까지 기획 범위 안으로 끌어온 점

기획하다 보면 보통 정책 문서나 신고/차단, 테스트 계정, 심사 흐름은 뒤로 밀리기 쉽다. 그런데 세모산은 기록 공유와 커뮤니티 요소가 있는 서비스라서, 이런 부분을 나중으로 미루면 결국 마지막에 크게 흔들릴 수밖에 없다고 생각했다.

그래서 개인정보처리방침, 이용약관, 운영정책, 앱 심사용 테스트 시나리오까지 기획 단계 안에서 먼저 다뤄본 건 PM 입장에서 꽤 의미 있었다. 적어도 지금은 출시 직전에 허둥대는 대신, 어떤 게 아직 비어 있는지는 알고 있는 상태가 됐다.

아쉬웠던 점도 분명히 있었다

1. 초반에 MVP 경계가 조금 더 빨리 정리됐으면 좋았겠다는 점

세모산 안에는 좋은 아이디어가 정말 많았는데, 그만큼 PM 입장에서는 "지금 꼭 필요한 것"과 "나중에 해도 되는 것"을 빨리 나눠야 했다. 그걸 중간 시점에 와서야 조금 더 단단하게 정리한 게 아쉽다.

처음부터 더 빠르게 핵심 가치, 후순위 기능, 출시 기준을 나눴다면 문서 작업과 논의가 더 효율적이었을 것 같다.

2. 세부 기능 상상이 전체 흐름보다 앞선 순간들이 있었던 점

온보딩 질문을 어떻게 할지, 커뮤니티 타입을 몇 개로 나눌지, 공동 기록은 어떻게 만들지 같은 세부 기능 고민은 늘 재미있다. 그런데 그런 고민을 하다 보면 전체 서비스 흐름과 연결이 약해질 때가 있었다.

중간 이후에는 문서 구조를 통해 어느 정도 잡아갔지만, 초반부터 같은 기준으로 밀고 갔으면 더 좋았을 것 같다.

3. 역할 분담과 오너십을 더 빨리 선명하게 만들 필요가 있었던 점

회의 기록을 다시 보면 초반에는 PM 내부 역할 분담이나 준비물 오너십이 생각보다 느슨하게 남아 있었다. 누가 어떤 문서를 책임지고, 정책 문서는 누가 쓰고, 심사용 데이터는 누가 챙기는지 조금 더 빨리 선명하게 만들었으면 좋았겠다는 생각이 든다.

이번 프로젝트를 하면서 배운 점

이번 세모산 프로젝트를 하면서 다시 느낀 건, 좋은 아이디어와 좋은 기획 문서는 전혀 다른 일이라는 점이었다. 서비스 방향을 말하는 것만으로는 부족하고, 디자이너와 개발자, 운영 관점이 같은 그림을 볼 수 있게 정리해야 비로소 실행이 가능해진다.

그리고 사용자 경험을 설계할 때는 기능을 설명하는 것보다 다음 행동으로 자연스럽게 이어지게 만드는 것이 훨씬 중요하다는 것도 많이 느꼈다. 세모산도 결국 사용자가 앱을 처음 켰을 때 이해할 수 있어야 하고, 첫 산을 찾고, 기록을 남기고, 다시 돌아오게 만들어야 한다. 그 흐름을 만드는 게 PM 역할이라는 걸 중간 시점에서 더 크게 체감하고 있다.

또 하나는, 출시형 프로젝트에서는 정책과 운영이 절대 부가 업무가 아니라는 점이다. 기록 공개, 신고, 차단, 계정 탈퇴, 심사용 테스트 시나리오는 나중에 붙이는 옵션이 아니라 처음부터 서비스 설계 안에 같이 들어가 있어야 한다는 걸 다시 배웠다.

남은 기간 동안 가장 중요하다고 생각하는 것

지금 이후로는 기능을 계속 넓히기보다, 이미 정리한 흐름을 더 단단하게 만드는 게 중요하다고 생각한다.

내 기준에서 남은 핵심 우선순위는 이렇다.

온보딩 질문과 체력/경험 기반 추천 로직을 더 명확히 정리하기
커뮤니티 MVP 범위를 후기/질문/인증 중심으로 단단하게 고정하기
로그인 전/후 접근 범위와 권한 거절 대체 흐름을 더 선명하게 정리하기
앱 심사 대응 문서와 테스트 데이터 준비 책임을 구체화하기
문서 간 용어와 흐름을 통일해서 팀 전체가 같은 기준으로 이야기할 수 있게 만들기

개인적으로 남기고 싶은 한 줄

중간 시점까지의 세모산은 아직 완성이라기보다 정리의 단계에 더 가깝다. 그래도 처음보다 훨씬 더 누구를 위한 서비스인지, 무엇을 먼저 구현해야 하는지, 어떤 기준으로 출시를 준비해야 하는지는 분명해졌다. 남은 기간에는 이 방향성을 흔들지 않고, 진짜 사용 흐름과 출시 준비까지 연결하는 PM 역할에 더 집중하고 싶다.

백엔드 스터디 후기

myhousemouse — Thu, 30 Apr 2026 11:01:35 +0900

기본 정보

주차/주제: 6주차 - 비즈니스 로직 구현과 서비스 레이어

학습 내용 요약

1. Service 레이어의 역할과 책임 조사하기

Layer는 관심사의 집합

1. Presentation Layer (프레젠테이션 계층)

사용자(UI) 요청 받기: 웹브라우저·앱·윈도우 애플리케이션 등 어디서든 들어오는 요청을 처리
응답(View) 반환: 처리 결과를 HTML 페이지나 JSON 등으로 포장해 사용자에게 돌려줌
입력 검증·예외 처리: URL 잘못 호출, 필수 파라미터 누락 같은 “화면 관점” 오류를 잡아서 사용자에게 친절한 메시지 제공

2. Service Layer (서비스 계층)

순수 비즈니스 로직 구현
트랜잭션 경계 관리 (@Transactional)
- 모두 성공시키거나, 모두 취소(rollback)

계층 간 조율(Orchestration)역할 구분예시성격

비즈니스 로직	이메일 중복 체크, 배송 상태에 따른 취소 여부 판단	도메인 고유의 핵심 규칙
트랜잭션 관리	@Transactional	데이터 일관성 보장 (기술적 처리)
DTO 변환	PostRequestDto → Post 엔티티	계층 간 데이터 이동 구조화
검증(Validation)	비밀번호 길이 검사	입력 무결성(일부는 비즈니스 로직)
캐싱·보안·로깅	@Cacheable, @PreAuthorize, AOP 로깅	애플리케이션 전반 공통 기능
외부 연동	메일·SMS·결제 API 호출	외부 시스템 통합

3. Repository Layer (저장소 계층)

데이터베이스 CRUD 전담
Service 계층과 Controller 계층의 책임 분리 모호함.⇒ 재사용성과 유지보수 때문
ex) 새로 Grapqhql를 도입 하고자 할 때 이미 Controller에 모든 기능을 구현하였다면, Grapqhql API를 구현하는 Controller에 또 다시 구현해야함.

- GqlController를 새로 만들어 Service에 연결
왜 이렇게 분리할까?

어디에 어떤 코드를 두면 좋을까? 에 도움되는 아키텍처 패턴

서비스 레이어 유틸화(Service Layer Utilization)

A서비스가 B, C, D… 여러 도메인을 다 써야 하는 상황
- A서비스 클래스 안에 BService, BRepository, CService, CRepository… 14개 필드가 주입된 상황
필요한 Service Layer의 메서드를 정적(static) 메서드로 → A서비스에는 UtilityClass 하나만 참조 하면 됨
만들어야 하는 Mock 객체 줄어듬
유연하게 대처 가능

ex) A서비스 = “‘책상’, ‘의자’, ‘컴퓨터’, ‘프린터’ … 14가지” 다 갖고 일해야 하는 사람

A서비스 = “사무도우미(UtilityClass) 한 명”만 옆에 두고 필요한 일은 그 사람이 다 해줘서

A서비스는 “프린터 하나만 딱 쓰면” 되는 상황

CQRS (Command and Query Responsibility Segregation)

명령(Command, 쓰기)” 과 “조회(Query, 읽기)” 를 완전히 분리해서 다루는 아키텍처 패턴
- Command : 객체를 변경하는 쓰기 (읽기는 빠른 조회)
- Query : 데이터 조회 기능만을 가진 함수 (쓰기는 정합성, 복잡한 비즈니스 규칙)
전통적인 CRUD

POST /orders   → 주문 생성  
GET  /orders   → 주문 목록 조회  
PUT  /orders/1 → 주문 수정

CQRS 적용
쓰기(Commands)
- POST /orders → OrderWriteService.createOrder(...)
- 내부에서 order_write_table 에 INSERT
읽기(Queries)
- GET /orders → OrderReadService.findAllOrders()
- order_read_table 또는 캐시/검색엔진에서 SELECT

Service 레이어 내부를 쓰기/읽기용 두 클래스로 나눈 예제

// Command 서비스 (트랜잭션, 검증)
@Service
public class OrderWriteService {
    @Transactional
    public Long createOrder(CreateOrderCommand cmd) {
        // 검증, 엔티티 생성, 저장
    }
}

// Query 서비스 (빠른 조회)
@Service
public class OrderReadService {
    public List<OrderViewDto> findAllOrders() {
        // 최적화된 뷰 테이블/캐시에서 가져오기
    }
}

명령(Command) DTO 와 조회(Query) DTO 를 완전히 분리한 예제

// Command DTO
public record CreatePostCmd(String title, String content) { }

// Query DTO
public record PostOverview(Long id, String title, LocalDateTime createdAt) { }

// 쓰기 컨트롤러
@PostMapping
public long create(@RequestBody CreatePostCmd cmd) {
  return postCommandService.create(cmd);
}

// 조회 컨트롤러
@GetMapping("/overview")
public List<PostOverview> overview() {
  return postQueryService.listOverview();
}

ex)

Command 창구: “주문 받기” 전담, 메뉴 옵션 검증·주문표 생성
Query 창구: “주문 현황 조회” 전담, 손님에게 빠르게 현재 대기·조리 상태 제공

2. DTO를 활용한 데이터 전달 패턴 예시 정리하기

DTO / DAO / VO 차이점

DTO(Data Transfer Object)

DAO(Data Access Object)

DB에 접근하는 역할

VO(Value Object)

변경 불가능한 객체
일반적으로 날짜, 통화 또는 수량을 나타내는 데 사용

엔티티와 DTO 차이

DTO(Data Transfer Object) : 클라이언트와 서버 간 데이터 전송을 전송을 위한 객체
Entity : 데이터베이스에 저장되는 데이터 객체로, 데이터베이스와 직접적으로 매핑되는 객체

Request ⇄ Response DTO 분리

Request DTO : 클라이언트가 보내는(요청)
Response DTO : 서버가 돌려주는(응답)

// 글 작성 요청 DTO
@NoArgsConstructor
@AllArgsConstructor
@Getter
public class AddArticleRequest {
    private String title;
    private String content;
    public Article toEntity() {
        return Article.builder()
                .title(title)
                .content(content)
                .build();
    }
}

// 글 작성 응답 DTO
@Getter
public class ArticleResponse {

    private final String title;
    private final String content;

    public ArticleResponse(Article article) {
        this.title = article.getTitle();
        this.content = article.getContent();
    }
}

Mapper/Assembler 분리

Entity ↔ DTO 변환 로직을 한곳에 모아 재사용·테스트 용이

@Component
public class PostMapper {
  public Post toEntity(AddPostRequest req) {
    return Post.builder()
               .title(req.getTitle())
               .content(req.getContent())
               .build();
  }
  public PostDto toDto(Post post) {
    return new PostDto(post.getId(), post.getTitle(), post.getContent());
  }
}

컬렉션 DTO

글 목록 + 전체 개수·페이지 정보 같은 메타데이터를 함께 전달

@Getter
public class ArticleListViewResponse {
    private final Long id;
    private final String title;
    private final String content;

    public ArticleListViewResponse(Article article) {
        this.id = article.getId();
        this.title = article.getTitle();
        this.content = article.getContent();
    }
}

중첩(Nested) DTO

글과 그에 달린 댓글을 한 번에 내려줄 때

화면(View) 전용 DTO (ViewModel)

Thymeleaf 같은 템플릿에서 딱 필요한 데이터만 전달

@Controller //컨트롤러 표시 -> 컴포넌트 스캔을 통해 빈으로 등록
public class ExampleController {
    //컨트롤러 클래스 선언
    @GetMapping("/thymeleaf/example") // 이 URL로 GET 요청이 오면, thymeleafExample() 호출
    public String thymeleafExample(Model model) { //Model 객체를 통해 데이터를 전달 (뷰로 전달)
        Person examplePerson = new Person(); // 컨트롤러 내부 DTO 역할을 할 Person 객체 생성
        examplePerson.setId(1L);
        examplePerson.setName("홍길동");
        examplePerson.setAge(11);
        examplePerson.setHobbies(List.of("운동", "독서"));

        model.addAttribute("person", examplePerson); // 뷰에 Person 객체 전달
        model.addAttribute("today", LocalDate.now()); // today key로 날짜를 뷰에 전달

        return "example"; // example.html로 이동
        // src/main/resources/templates/example.html)을 찾아 렌더링
    }

    @Setter
    @Getter
    class Person { // Person 클래스 정의 == 내부 DTO 역할
        private Long id;
        private String name;
        private int age;
        private List<String> hobbies;
        // 단순 데이터 전달용 -> 엔티티 사용 X
    }
}

Projection 기반 DTO (JPA 인터페이스 프로젝션)

DB 조회 시 특정 컬럼만 바로 뽑아와 SQL/PERFORMANCE 최적화

3. 간단한 비즈니스 로직 구상해오기 (ex: 회원가입, 게시글 작성)

도서 대출 기능

사용자가 대출을 원하는 도서명을 입력한다.
입력된 도서명으로 데이터베이스에서 해당 도서명을 가진 모든 책을 검색한다.
검색된 책 목록을 사용자에게 보여준다.
- 각 책의 ID, 제목, 대출 가능 여부를 포함한다.
사용자가 대출을 원하는 책의 ID를 선택한다.
선택된 책의 대출 가능 여부를 확인한다.
- 대출 가능 여부가 false인 경우, 대출 불가능하다는 메시지를 출력한다.
- 대출 가능 여부가 true인 경우:
  a. 해당 책의 대출 상태를 false로 업데이트한다.
  b. 데이터베이스에 변경 사항을 저장한다.
  c. 대출 성공 메시지를 출력한다.

새롭게 알게 된 점 & 어려웠던 부분

✔️ DTO의 개념을 다시한번 복습하게 됨
✔️ 데이터 전달 패턴이 다양해서, 이해하는데 시간이 걸렸음

과제/실습 결과 (있을 시)

도서 대출 로직

import jakarta.transaction.Transactional;
import lombok.RequiredArgsConstructor;
import me.nam.springbootdeveloper.Domain.Book;
import me.nam.springbootdeveloper.Repository.BookRepository;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class BookService {

    private final BookRepository bookRepository;

    public List<BookResponse> searchBooksByTitle(String title) {
        List<Book> books = bookRepository.findAllByTitle(title);
        return books.stream()
                .map(BookResponse::new)
                .toList();
    }

    @Transactional
    public void borrowingBook(Long id) {
        Book book = bookRepository.findById(id)
                .orElseThrow(() -> new IllegalArgumentException("해당 ID의 책을 찾을 수 없습니다: " + id));

        if (!book.isAvailable()) {
            throw new IllegalStateException("해당 책은 대출이 불가능합니다: " + book.getTitle());
        }

        book.setAvailable(false);
        bookRepository.save(book);
    }
}

스터디 피드백

✔️서비스 로직에 예외 처리를 두는 이유
도메인 규칙(예: 중복 회원 검증)을 처리하는 역할
컨트롤러에서 하면 안 되는 이유
계층 간 역할이 모호,코드 재사용성이 떨어지고, 테스트가 어려워짐

✔️공통 에러 처리: 예외를 한 곳에서 처리
@ControllerAdvice:모든 컨트롤러에서 발생하는 예외를 처리하는 클래스
@ExceptionHandler: 특정 예외를 처리하는 메서드를 정의

✔️스파게티 코드 -> 리팩토링

백엔드 스터디 후기

myhousemouse — Sun, 19 Apr 2026 12:44:02 +0900

기본 정보

주차/주제: 5주차 - 데이터베이스 연동 기초

학습 내용 요약

1. JPA와 Hibernate의 관계 및 주요 개념

JPA(Java Persistence API)

자바 객체와 관계형 데이터베이스를 연결하기 위한 표준 인터페이스(API)
- 주요 기능
  - 엔티티 매핑: 자바 클래스 ↔ DB 테이블
  - 엔티티 관리: 객체 상태(비영속, 영속, 분리, 삭제) 추적 및 CRUD 자동 처리
  - 트랜잭션 관리: 커밋·롤백 처리
  - 쿼리 언어(JPQL): 객체 지향적인 방식으로 데이터베이스에 쿼리를 날릴 수 있도록 해주는 JPQL(Java Persistence Query Language)
Hibernate
- JPA를 구현한 대표적 ORM (Object-Relational Mapping) 프레임워크
- 추가 기능
  - 영속성 컨텍스트
    - 1차 캐시: 조회 시 메모리 캐시 우선 사용
    - 쓰기 지연(Write-Behind): 트랜잭션 커밋 전에 SQL을 모아 한 번에 실행
    - 변경 감지(Dirty Checking): 커밋 시점에 변경된 엔티티를 자동 반영
    - 지연 로딩(Lazy Loading): 실제 사용할 때만 관련 데이터를 조회
  - 자동 생성 SQL: 직접 SQL 작성 없이도 CRUD 가능

JPA는 “무엇을 할지” 규격만 정의하고, Hibernate는 “어떻게 할지” 실제 동작을 구현한 라이브러리

JPA vs Hibernate vs Spring Data JPA

JPA (Java Persistence API)
• 자바 객체와 관계형 DB를 연결하는 ORM 표준 인터페이스
• SQL 지식 없이도 엔티티 객체를 통해 DB 조작 가능
• 비즈니스 로직에 집중, DB 종속성 감소
• 복잡·무거운 쿼리는 어려움

Hibernate
• JPA 인터페이스 대표 구현체
• JDBC API 위에서 동작하는 자바용 ORM 프레임워크
• 영속성 컨텍스트
• 1차 캐시 (조회 시 캐시 활용)
• 쓰기 지연 (트랜잭션 커밋 전 배치 실행)
• 변경 감지 (커밋 시 자동 반영)
• 지연 로딩 (필요 시 쿼리 실행)

Spring Data JPA
• 스프링이 JPA 위에 편리 기능을 추가한 모듈
• PagingAndSortingRepository 상속한 JpaRepository 제공
• 인터페이스 선언만으로 기본 CRUD + 페이징·정렬 기능 자동 제공

public interface MemberRepository extends JpaRepository<Member, Long> {
} // 기본 CRUD 사용 가능

2. Entity·Repository 관련 어노테이션

어노테이션용도

@Entity	클래스가 DB 테이블과 매핑되는 JPA 엔티티임을 선언
@Id	해당 필드를 엔티티의 PK(기본 키)로 지정
@GeneratedValue	PK 값을 자동 생성 전략(IDENTITY, SEQUENCE 등)으로 지정
@Table	엔티티가 매핑될 테이블 이름·스키마 등 커스터마이징
@Column	컬럼 이름·제약조건·길이 등을 커스터마이징
@Repository	해당 클래스를 JPA 데이터 액세스 계층 빈으로 등록, 예외를DataAccessException으로 변환
@Transactional	메서드 또는 클래스 단위로 트랜잭션 시작·커밋·롤백 자동 관리
@PersistenceContext	EntityManager 주입 시 사용 (JPA 표준)
@Autowired	Spring 컨텍스트에서 EntityManager 또는 Repository 빈 주입 시 사용

@Entity : 클래스가 DB 테이블과 매핑되는 JPA 엔티티임을 선언

@Id : 해당 필드를 엔티티의 PK(기본 키)로 지정

@GeneratedValue : PK 값을 자동 생성 전략(IDENTITY, SEQUENCE 등)으로 지정

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;
}

@Repository : 해당 클래스가 JPA 데이터 액세스 계층임을 나타내는

@Repository // @Component와 동일한 역할
public class MemberRepository {
    // 데이터베이스와의 상호작용 구현
}

@Transactional : 메서드 또는 클래스 단위로 트랜잭션 시작·커밋·롤백 자동 관리

@Transactional
public void saveMember(Member member) {
    memberRepository.save(member);
}

@Table

@Entity
@Table(name = "members")// 이 엔티티는 members 테이블에 매핑된다
public class Member {
...
// 컬럼 이름을 username 으로 지정
@Column(name = "username",
// 아무 속성 없이 쓰면, 필드명이 컬럼명이 된다
@Column                       
private String email;

@PersistenceContext

@PersistenceContext
private EntityManager em; // JPA 표준 EntityManager

@Autowired 대신 @PersistenceContext를 써야 영속성 컨텍스트가 올바르게 연결

H2 JDBC URL 모드별 차이

모드URL 예시설명

로컬 파일 모드 (Embedded File)	jdbc:h2:~/test	- 홈 디렉터리(~)에 test.mv.db 파일로 영구 저장- 애플리케이션 프로세스가 꺼져도 데이터 유지
TCP 서버 모드 (Server-TCP)	jdbc:h2:tcp://localhost/~/test	- 별도의 H2 서버 프로세스를 띄워 파일 모드 DB를 TCP로 공유- 다중 애플리케이션에서 같은 DB 접속 가능
인메모리 모드 (In-Memory)	jdbc:h2:mem:testdb	- 메모리 상에만 존재, 애플리케이션이 종료되면 사라짐- 빠른 테스트용, 별도 서버 불필요

http://localhost:8080/h2-console

gradle , 의존성 설정

# (1) datasource URL만으로 드라이버 자동 감지
spring.datasource.url=jdbc:h2:mem:testdb
spring.datasource.username=sa
spring.datasource.password=

# (2) Hibernate Dialect는 JPA 스타터가 자동 선택
spring.application.name=springboot-developer
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true
spring.jpa.defer-datasource-initialization=true

# Hibernate DDL
spring.jpa.hibernate.ddl-auto=update

# H2
spring.h2.console.enabled=true

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-jdbc'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    runtimeOnly 'com.h2database:h2' // 인메모리 데이터베이스
    implementation 'org.projectlombok:lombok:1.18.22'  // Add Lombok dependency
    annotationProcessor 'org.projectlombok:lombok:1.18.22'  // Add annotation processor
}

SQL

CREATE TABLE member (
id   BIGINT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(50)
);
INSERT INTO member(name) VALUES('A'),('B');
SELECT * FROM member;

INSERT INTO article (title, content) VALUES ('제목 1', '내용 1');
INSERT INTO article (title, content) VALUES ('제목 2', '내용 2');
INSERT INTO article (title, content) VALUES ('제목 3', '내용 3');

새롭게 알게 된 점 & 어려웠던 부분

관련 어노테이션을 찾아보면서, 몰랐던 기능과 잘못알고 있던 지식들을 바로 잡을 수 있게 되었다.

스터디 피드백

Spring Data JPA를 사용하며 느꼈던 장단점
장점

@Query 어노테이션사용 → JPQL 간단히 추가 가능
JPARepository 상속으로 기본 CRUD 모두 제공 가능
트랜잭션, 예외처리가 자동 → 깔끔한 코드

단점

복잡한 JOIN쿼리 같은경우 코드가 지저분해 보일 수 있음
연관관계가 복잡할수록 N+1 문제가 쉽게 발생

엔티티 클래스에 비즈니스 로직을 추가하면 어떨까요?
관련 로직이 엔티티 안에 모여 있어 이해,유지보수가 용이하지만,

엔티티 내부 로직이 데이터 접근, 의존하게 되면 단위테스트가 어려울 수 있음

→ 단순 검증, 상태 전환 같은 핵심 비즈니스 로직은 엔티티 메서드로 구현해도 되지만

복잡하거나 외부 호출을 포함하는 비즈니스 로직은 서비스 계층에 두어 책임을 명확히 분리해야하지 않을까 싶음.

이 외에도 다른 팀원분들과의 토론을 진행했습니다.

리트머스 기업 프로젝트 회고 - 대학생이 실제 스타트업이랑 협업해봤습니다(with 큐시즘)

myhousemouse — Tue, 31 Mar 2026 19:00:33 +0900

들어가며

이 글은 스타트업 리트머스(Litmers)라는 IT 컨설팅·개발 스타트업과 기업 연계 프로젝트를 진행하면서 경험한 것들을 정리한 회고글이에요

솔직히 처음엔 그냥 포트폴리오 좀 쌓자는 마음으로 시작했는데, 끝나고 나니까 생각보다 훨씬 많은 걸 배웠고, 동시에 생각보다 훨씬 복잡했다는 걸 느꼈어요.. ㅠㅠ

리트머스는 어떤 회사인가요?

리트머스는 고객사(파트너)의 IT 프로젝트를 기획부터 개발까지 통합으로 진행해주는 스타트업이에요.

현재 리트머스사의 Pain Point는 고객사와 소통할 때 채널(카카오톡, 이메일, 유선 등등)이 분산돼 있어서 히스토리 관리가 어렵다는 문제가 있었고, 우리 팀은 이걸 해결하는 리트머스 파트너 플랫폼을 기획·디자인·개발하는 과제를 받았어요.

https://www.instagram.com/litmers_kr/
https://litmers.com/

리트머스 | 고객의 사업 성공을 함께하는 IT 컨설팅 파트너

리트머스는 기업 규모와 도메인에 무관하게 결과로 증명하는 IT 컨설팅 파트너입니다. 업계 최고 수준 전문가들이 합리적인 비용으로 신뢰할 수 있는 외주개발, 노코드 에이전시, 팀구독 솔루션

litmers.com

우리가 만든 것: 리트머스 파트너 플랫폼

한마디로 설명하면 "고객사와 리트머스 PM이 프로젝트를 함께 관리하는 B2B 협업 툴" 이에요. 기획 단계에서 확정한 핵심 기능들이에요:

홈 대시보드 — 고객사가 로그인하자마자 "지금 내가 뭘 해야 하는지" 바로 파악
문서함 — 리트머스가 올린 산출물을 고객사가 열람하고, 특정 줄에 하이라이트 댓글 달기
문의/요청 — 카카오톡으로 분산되던 요청을 구조화된 양식으로 플랫폼 안으로 흡수
해야할 일 (투두) — PM이 고객사에게 할 일을 명확하게 배정
회의록 — AI 요약 첨부해서 논의 내용 자동 구조화
진행현황 — 기획→디자인→개발→QA 단계를 프로세스 바로 시각화
QA — 고객사가 직접 결과물 검수하는 수정사항 칸반

기술 스택

분류 기술

프론트엔드	Next.js (TypeScript), shadcn/ui, Tailwind CSS, Zustand, TanStack Query
백엔드	Supabase (PostgreSQL + RLS + Storage + Realtime), Prisma ORM
인증	WorkOS (B2B 이메일 초대 기반)
인프라	Vercel + GitHub CI/CD

스프린트별로 내가 한 것들

기획 파트

고객사 대부분이 IT 비전공자임을 감안했고 이를 토대로 사용자리서치를 진행했어요 사용자의 82%가 직관적이고 쉬운용어를 선호함을 알게 되었어요, 전체 화면에서 IT 용어를 전부 일상 언어로 치환하는 작업을 했어요.

QA → 검수, TODO → 해야할 일, 칸반 → 처리 현황판 같은 식으로요

처음엔 "그냥 단어 바꾸는 거잖아?" 싶었는데, 막상 하다 보니까 고객 입장에서 어떤 표현이 더 직관적인지 계속 고민해야 해요!

기능명세서 DB 구축

총 29개 기능 항목을 노션 DB로 정리했어요. 각 항목마다 순번, 기능명, 세부기능, 기능설명, 상세동작, 예외처리, 입출력 로직, 개발 우선순위까지 구체적으로 정의하고 전달하는 업무를 진행했어요. 리트머스에서 사용하는 데이터 구조를 반영하기까지 많은 시간이 소요되어 어려운 경험이었어요 ㅠㅠ

선택과제 — AI 자동화 파이프라인

PM이 반복적으로 하는 작업들(카카오톡 문의 → 노션 정리, 회의 내용 → 회의록 작성 등)을 AI가 어떻게 대체할 수 있는지 설계하는 과제였는데, AX설계하는 역량도 키운것 같아용

기획 → 디자인 → 개발 각 단계마다 AI가 자동으로 다음 파트에 넘길 산출물을 생성하는 구조를 설계했어요. 기획 단계 완료 시 디자이너에게 화면 목록 초안이 자동으로 넘어가고, 디자인 완료 시 개발자에게 API Endpoint 초안이 자동으로 넘어가는 식으로 설계했어용

영상 시연 시나리오

PM 홍길동이라는 가상의 캐릭터를 중심으로 4분 40초짜리 시연 흐름을 설계했어요. "어드민이 아닌 PM 시점에서 어떻게 플랫폼을 쓰는지"를 보여주는 게 핵심이었는데, 씬 구성부터 각 화면에서 강조할 포인트, 더미 데이터 세팅 체크리스트까지 다 작성하여 성공적으로 시연까지 마쳤습니다~

느낀점들

기획은 질문이 나오지 않을 만큼 구체적으로 적어야한다!

처음엔 "기획이야 뭐 생각한 거 적으면 되지" 했는데 실제로 해보니까 전혀 달랐어요. 기능 하나를 정의할 때 고객사 입장, PM 입장, Admin 입장을 전부 고려해야 하고, 예외 케이스를 빠짐없이 잡아야 하고, 개발자가 읽고 바로 이해할 수 있게 써야 해요!

특히 "진행현황에서 단계는 반드시 순서대로 진행되지 않는다"는 설계 주의사항 같은 걸 실제 비즈니스 맥락을 이해해야 나올 수 있는 거거든요. 이런 부분에서 현업 PM의 인터뷰를 추가적으로 요청하고 대표님과의 미팅을 주기적으로 진행하여 맥락을 더 깊이 이해하려고 노력했어요

실제 스타트업 미팅은 학교 팀플과 다르다!

대표님이 미팅에서 "지금 기획이 확정적이지 않아서 방향성을 잡기가 어렵다"고 하셨을 때 좀 당황했어요. 학교 팀플에서는 요구사항이 명확하게 주어지는데, 실제 스타트업에서는 방향 자체가 계속 바뀌거든요.

거기다 민감한 내부 DB에는 접근 불가, AI 워크플로우는 리트머스가 자체 고도화 중이라 보안 문제로 볼 수 없는 것들이 있어서, 이런 제약 안에서 우리가 할 수 있는 걸 찾는 게 생각보다 어려웠어요.

문서화는 모든 협업의 기초!

서비스 기획서, 기능명세서, 영상 시연 시나리오, 선택과제 문서 등 엄청난 양의 문서를 작성했는데, 팀원끼리 커뮤니케이션할 때 문서가 큰 역할을 한 경우가 많았어요 "이 기능이 어떻게 동작한다고 했지?"를 문서 없이 기억에만 의존했으면 중요한 결정을 빠트렸을것 같아요 모든 기록을 노션으로 정리하였고 구두로 진행한 회의도 바로바로 기록하여 아카이빙 했습니다~

현업에서 사용되는 AI는?

미팅에서 대표님이 직접 보여주신 AI 워크플로우가 신선한 충격이었어요. MCP로 디자인 스펙을 자동으로 읽고, 바이브 칸반으로 개발 태스크를 AI 에이전트한테 할당해서 자동으로 PR까지 올라오는 구조를 보여주셨거든요.

AI를 적극적으로 활용하는 회사에서 실제 워크플로우에 적용된 사례를 보며 JD에서 AI 역량을 강조하는 이유를 알게 되었어요.. !! 이번 경험을 계기로 AI 자동화에 대한 큰 관심이 생겼고, 지금도 매일 새로운 기술이 등장하는 만큼 이를 적극적으로 직접 활용해보는 것이 중요하다는 생각이 들었어요. 다양한 영역에서 폭넓게 활용하려고 해요!

아쉬웠던 점

1. 실제 고객사 피드백을 못 받은 것

플랫폼을 만들었는데 실제 고객사가 써보고 "이거 불편해요"라는 피드백을 받았다면 훨씬 더 좋은 서비스가 됐을 것 같아요. 리서치, 큐시즘 내부 UT는 했지만 실제 사용자 테스트까지는 못 갔어요.

2. 기획-개발 간 싱크 맞추기

기획에서 생각한 것과 개발에서 실제로 구현 가능한 것 사이에 갭이 있을 때 조율이 쉽지 않았어요. 기술적 제약에 대한 이해가 기획자한테도 필요하다는 걸 느꼈어요.

3. 변경 사항에 유연하게 대응하는 것

스타트업 특성상 방향이 자주 바뀌는데, 그때마다 문서를 업데이트하고 팀원들이 싱크를 맞추는 게 꽤 힘들었어요.

다음에 이런 프로젝트를 하게 된다면

초반에 기업 쪽 제약 사항을 더 빠르게 파악할 것 - 실제 워크 플로우를 볼 수 있다면, 초반에 보면서 맥락을 이해하는게 중요할것 같아요
짧은 주기로 자주 공유하기 - 기간이 5주밖에 되지않아서, 피드백을 받을 수 있는 시간이 생각보다 짧았어요 많은걸 보여주기보다, 짧게라도 보고하며 진행하는게 더 효율적이었을것 같아요
기술 스택을 기획자도 어느 정도 이해할 것 - 리트머스 사에서 요구하는 개발 스택이 생소했어요.. 이를 어느정도 알고 있었다면, 구체적으로 설명하기 수월했을것 같아요

마무리

이번 프로젝트는 솔직히 처음에 생각했던 것보다 훨씬 어려웠어요. 학교 팀플처럼 요구사항이 딱 주어지고 그걸 만들면 끝나는 게 아니라, 요구사항 자체를 같이 만들어가야 했거든요.

근데 그래서 더 재밌었고, 더 많이 배웠어요!

실제 서비스가 어떻게 기획되고, PM이 어떻게 일하고, AI가 실제 업무 현장에서 어떻게 쓰이는지를 몸으로 느낀 경험이었어요. 이론으로는 절대 배우지 못하는 실제 경험으로 쌓은 소중한 경험이었어요!

백엔드 스터디 후기

myhousemouse — Sun, 22 Mar 2026 16:56:41 +0900

기본 정보

주차/주제: 3주차 - REST API 설계와 구현

학습 내용 요약

API, REST API, RESTful API의 개념 정리하기API는 응용 프로그램(애플리케이션)에서 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻합니다.✅ 기본 개념:
- 애플리케이션이 다른 애플리케이션에 요청을 보내고, 응답을 받을 수 있도록 정해진 규칙(메서드, 데이터 형식 등)을 제공합니다.
- 예를 들어, 카카오톡 앱이 구글 지도 API를 사용해서 지도를 표시하는 것처럼, 다양한 프로그램들이 서로 서로의 기능을 호출하고 결과를 받습니다.✅ REST API(Representational State Transfer) 정의:웹상에서 사용되는 여러 리소스를 HTTP URI로 표현하고, 해당 리소스에 대한 행위를 HTTP Method로 정의하는 방식을 말합니다.
- ✅ 기본 개념:
- REST API는 웹에서 데이터를 주고받기 위해 사용하는 API
- HTTP 프로토콜을 사용하여 데이터를 주고받는 방식을 정의합니다.
- REST API는 URL을 통해 리소스를 지정하고, HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 리소스에 대한 동작을 수행합니다.
- 리소스는 데이터나 객체일 수 있고, 이를 HTTP 메서드로 조회, 생성, 수정, 삭제합니다.
- 구성요소
1. 자원(Resource) : HTTP URI
2. 자원에 대한 행위(Verb) : HTTP Method
3. 자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load, 데이터 형식RESTful API는 REST 아키텍처 스타일을 잘 따르는 APIAPI를 RESTful 하게 만들어서 API의 목적이 무엇인지 명확하게 하기 위해 RESTful 함을 지향 합니다.
4. ✅ 기본 개념:
5. 즉, REST API를 설계할 때 좋은 방식으로 설계된 API를 의미
6. ✅ RESTful API 정의:
- RESTful API는 REST의 원칙과 규칙을 충실히 따르는 API입니다.
  - /(슬래시)는 계층 관계를 나타낼때 사용합니다.
  - URI 마지막 문자에 /(슬래시)를 사용하지 않습니다.
  - URI에 _(underscore)는 사용하지 않도록 합니다. 또한 영어 대문자보다는 소문자를 씁니다.
  - URI에 명사를 사용합니다.
  - URI에 파일의 확장자(예를들어 .json , .JPGE)를 포함 시키지 않습니다.
- 각 리소스는 URL로 고유하게 식별되며, HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 리소스를 조작합니다.
- 상태를 유지하지 않으며, 각 요청은 독립적으로 처리됩니다. 즉, 서버는 각 요청에 대해 필요한 정보만을 처리하고 이전 요청을 기억하지 않습니다.
주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공합니다
✅ API(Application Programming Interface) 정의:

✅ RESTful API 특징:

자원(Resource): 모든 데이터는 자원(리소스)으로 취급됩니다.
- 예: 사용자(users), 게시글(posts), 제품(products)
HTTP 메서드: 각 자원에 대해 GET, POST, PUT, DELETE 메서드를 사용해 읽기, 생성, 수정, 삭제 작업을 수행합니다.

무상태성(Stateless): 각 요청은 독립적이며, 서버는 이전 요청을 기억하지 않습니다.

사용자가 로그인하지 않은 상태에서 GET /users 요청을 보내면, 서버는 사용자 인증 정보를 기억하지 않음. 클라이언트는 매번 인증 정보를 요청에 담아 보내야 합니다.

유연한 응답 형식: JSON이나 XML 형식으로 데이터를 응답받을 수 있습니다.
Uniform Interface (인터페이스 일관성): RESTful API는 일관된 인터페이스를 유지하며, URL 구조나 메서드 사용을 통해 명확한 규칙따름.

리소스 이름은 복수형

Layered System (계층화)

HTTP 메서드(GET, POST, PUT, DELETE)의 용도와 차이점 정리하기HTTPRequestMethod✅ 용도:POST 메서드는 새로운 리소스(데이터)를 서버에 생성할 때 사용됩니다. 즉, 서버에서 새로운 데이터를 추가하거나, 새로운 객체를 생성할 때 쓰는 메서드입니다.✅ 주요 특징:
- 리소스 생성: 클라이언트가 서버에 요청을 보내고, 서버는 새로운 리소스를 생성하여 저장합니다.
- 유일한 ID: 서버에서 새로운 리소스를 생성할 때, 해당 리소스에 고유 ID를 부여하는 경우가 많습니다.
- 본문(body): POST 요청은 데이터를 요청 본문(body)에 담아 보냅니다. 이 데이터는 주로 JSON 형식입니다.
- 멱등성 없음: 같은 요청을 여러 번 보내면 매번 다른 결과를 초래할 수 있습니다. (즉, 중복 생성이 될 수 있음)
- ✅ 장점:
- 서버에 데이터를 추가하는 데 적합합니다.
- 데이터를 요청 본문에 담아 보낼 수 있어 복잡한 데이터도 함께 전송 가능합니다.
- 요청이 서버 상태를 변경하기 때문에, 응답으로 생성된 리소스를 반환하는 것이 일반적입니다.
● POST : 생성, 서버에 자원을 등록

새 유저 추가: /users에 POST 요청을 보내면 새로운 유저가 생성됩니다.

@PostMapping
    public String createUser(@RequestBody User user) {
        service.createUser(user);
        return "사용자가 저장되었습니다.";
    }

POST /users
body : {date : "example"}
Content-Type : "application/json"

● GET: 읽기, 서버 자원을 얻음

✅ 용도:

GET 메서드는 주로 데이터를 조회하는 데 사용됩니다.

즉, 서버에서 데이터를 읽기만 하고, 수정하거나 삭제하지는 않습니다.

✅ 주요 특징:

데이터 조회: 클라이언트가 서버에 요청을 보내고, 서버는 데이터를 응답으로 보내줍니다.
멱등성(Idempotency): 같은 요청을 여러 번 보내도 결과가 변하지 않아요. 예를 들어, /coffees를 여러 번 요청해도, 항상 같은 커피 목록이 응답으로 돌아옵니다.
URL 경로: 조회할 데이터를 경로로 구분해 보냅니다. 예를 들어:
- /coffees → 모든 커피 목록 조회
- /coffees/{id} → 특정 ID의 커피 조회

✅ 장점:

단순하고 직관적: 데이터를 요청하는 방식이 매우 직관적이라서 이해하기 쉽습니다.
캐싱 가능: GET 요청은 서버나 브라우저에서 캐싱될 수 있어, 동일한 요청을 더 빠르게 처리할 수 있습니다.
모든 유저 조회: /users/에 GET 요청을 보내면 유저 목록을 받을 수 있습니다.
특정 유저 조회: /users/{id}에 GET 요청을 보내면, 그 특정 유저 정보를 받을 수 있습니다.

@GetMapping("/")
    public List<User> getAllUsers() {
        return service.getAllUsers();  // 모든 사용자 목록 반환
    }
@GetMapping("/{id}")
    public User getUser(@PathVariable Long id) {
        return service.getUserById(id);
    }

● PUT: 업데이트, 서버 자원을 새로운 자원으로 치환

✅ 용도:

PUT 메서드는 기존 리소스를 수정하거나, 없는 리소스는 새로 생성할 때 사용됩니다.

즉, 서버에 있는 기존 데이터를 업데이트하거나, 존재하지 않으면 새 데이터를 추가할 수 있습니다.

✅ 주요 특징:

기존 리소스 수정: 클라이언트가 요청한 URI에 해당하는 기존 데이터를 수정합니다.
리소스 생성 가능: 만약 해당 리소스가 존재하지 않으면 새로운 리소스를 생성할 수 있습니다.
멱등성(Idempotency): 같은 PUT 요청을 여러 번 보내도 결과가 변하지 않음. 즉, 한 번 수정된 데이터는 같은 PUT 요청을 여러 번 보내도 결과가 동일합니다.
본문(body): PUT 요청은 데이터를 요청 본문(body)에 담아 보내며, 주로 JSON 형식으로 데이터를 보냅니다

✅ 장점:

리소스 수정에 적합합니다.
불필요한 중복 요청을 피할 수 있어, 같은 요청을 여러 번 보내도 데이터는 동일하게 유지됩니다.
데이터 업데이트와 생성을 하나의 메서드로 처리할 수 있어 간편합니다.
유저 정보 수정: /users/{id}에 PUT 요청을 보내면 해당 유저 정보를 수정합니다.
새로운 유저 생성: /users/{id}에 PUT 요청을 보내면, 해당 ID 유저가 없으면 새로 생성합니다.

@PutMapping("/{id}")
    public String updateUser(@PathVariable Long id, @RequestBody User user) {
        user.setId(id);
        service.updateUser(user);
        return "사용자 전체 수정 완료!";
    }

PUT /user/1
body : {date : "update example"}
Content-Type : "application/json"

● PATCH: 업데이트, 서버 자원의 일부만 수정

✅ 용도:

PATCH 메서드는 리소스의 일부만 수정할 때 사용됩니다.

즉, 기존 리소스를 완전히 교체하지 않고 일부 속성만 업데이트할 때 사용해요.

✅ 주요 특징:

부분 수정: 리소스의 전체가 아닌 일부만 수정합니다. 예를 들어, 커피의 이름만 바꾸고 가격은 그대로 두는 식입니다.
멱등성 없음: PATCH 요청은 멱등성을 보장하지 않아요. 즉, 같은 PATCH 요청을 여러 번 보내면 결과가 달라질 수 있습니다. (수정된 값이 여러 번 적용될 수 있음)
본문(body): PATCH 요청은 수정할 데이터만 본문에 담아 보냅니다. 주로 JSON 형식으로 보내며, 수정할 부분만 포함시킵니다.
적용 범위: PUT은 전체 리소스를 대체하지만, PATCH는 부분적인 수정만 진행해요.

✅ 장점:

부분 수정을 통해 불필요한 데이터 변경을 피할 수 있습니다.
데이터의 일부만 변경하고 나머지는 그대로 두고 싶을 때 적합합니다.
사용자의 정보 일부 수정: /users/{id}에 PATCH 요청을 보내면 특정 정보만 업데이트됩니다.

@PatchMapping("/{id}")
    public String partialUpdateUser(@PathVariable Long id, @RequestBody Map<String, Object> updates) {
        service.partialUpdateUser(id, updates);
        return "사용자 일부 수정 완료!";
    }

PUT과 PATCH의 차이점과 멱등성

✅ PUT의 멱등성

PUT은 리소스 전체를 대체하는 방식

첫 번째 요청 이후에 같은 데이터를 다시 보내면 결과가 변하지 않음

✅ PATCH의 멱등성

PATCH는 부분 수정을 하는 메서드

PATCH 요청이 들어올 때마다 부분적인 값이 계속 수정될 수 있음

PUT은 리소스 전체를 대체하고, 결과가 항상 같게 유지되므로 멱등성이 보장됨.

PATCH는 부분만 수정하기 때문에, 같은 요청을 여러 번 보낼 경우 결과가 달라질 수 있어 멱등성이 보장되지 않음.

● DELETE: 삭제, 서버 자원을 삭제

✅ 용도:

DELETE 메서드는 리소스를 삭제할 때 사용됩니다.

즉, 서버에서 특정 데이터를 삭제하는 요청을 처리합니다.

✅ 주요 특징:

리소스 삭제: 클라이언트가 서버에 요청을 보내면, 서버는 특정 리소스를 삭제합니다.
멱등성(Idempotency): DELETE는 멱등성을 보장합니다. 즉, 같은 DELETE 요청을 여러 번 보내도, 결과가 같고 삭제된 리소스는 다시 복구되지 않습니다.
URI 경로: DELETE 요청은 보통 삭제할 리소스의 URI를 지정해 보내며, 리소스를 찾아서 삭제합니다.
응답 상태 코드: 삭제가 성공하면 204 No Content 응답을 보낼 수 있고, 리소스가 없으면 404 Not Found를 보낼 수 있습니다.

✅ 장점:

리소스 삭제를 간단하고 명확하게 처리할 수 있습니다.
멱등성이 보장되므로 여러 번 삭제 요청을 보내도 결과가 동일합니다.
사용자 삭제: /users/{id}에 DELETE 요청을 보내면, 해당 사용자를 삭제합니다.

@DeleteMapping("/{id}")
    public String deleteUser(@PathVariable Long id) {
        service.deleteUser(id);
        return "사용자 삭제 완료!";
    }

● OPTIONS: 통신옵션 조회 (리소스가 지원하고 있는 메소드의 취득)
● HEAD: 응답헤더 조회(메타 데이터의 취득)

간단한 API 기능 2개 구상해오기 (ex: 사용자 조회, 게시글 작성 등)
1. 도서 추가 (POST /books)

POST /books
{
    "title": "자바의 정석",
    "author": "남궁성",
    "price": 25000,
    "category": "Programming"
}

2. 도서 목록 조회 (GET /books)

GET /books?category=Programming&price_max=30000
[
    {
        "id": 1,
        "title": "자바의 정석",
        "author": "남궁성",
        "price": 25000,
        "category": "Programming"
    },
    {
        "id": 2,
        "title": "파이썬 완벽 가이드",
        "author": "홍길동",
        "price": 20000,
        "category": "Programming"
    }
]

새롭게 알게 된 점 & 어려웠던 부분

새롭게 알게된 점: API 개념을 다시 정확하게 알게 되었고, HTTP 메서드와 API 기능에 대해 더 깊게 탐구하고 싶어졌습니다.
어려웠던 부분: HTTP 메서드와 API 기능을 더 깊게 이해하는 부분이 어려웠습니다.
해결 방법: HTTP 메서드와 API 기능에 대해 더 많은 예제와 실습을 통해 이해를 돕고, 구체적인 동작 방식을 연구해볼 계획입니다.

과제/실습 결과

- Spring Boot
- Gradle
- Jsp templeate
- H2 데이터베이스
- JDK 17

###  ️설정

    plugins {
        id 'java'
        id 'org.springframework.boot' version '3.4.4'
        id 'io.spring.dependency-management' version '1.1.7'
    }
    
    group = 'com.example'
    version = '0.0.1-SNAPSHOT'
    
    java {
        toolchain {
            languageVersion = JavaLanguageVersion.of(17)
        }
    }
    
    repositories {
        mavenCentral()
    }
    
    dependencies {
        implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
        implementation 'org.springframework.boot:spring-boot-starter-web'
        runtimeOnly 'com.h2database:h2'
        testImplementation 'org.springframework.boot:spring-boot-starter-test'
        testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
    }
    
    test {
        useJUnitPlatform()
    }

# H2 메모리 데이터베이스 설정
spring.datasource.url=jdbc:h2:mem:testdb
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.username=sa
spring.datasource.password=

# H2 콘솔 사용 설정
spring.h2.console.enabled=true
spring.h2.console.path=/h2-console

# 초기 SQL 실행
spring.sql.init.mode=always

schema 설정

CREATE TABLE users (
                       id BIGINT AUTO_INCREMENT PRIMARY KEY,
                       name VARCHAR(100),
                       email VARCHAR(100)
);

CREATE TABLE posts (
                       id BIGINT AUTO_INCREMENT PRIMARY KEY,
                       title VARCHAR(200),
                       content TEXT,
                       user_id BIGINT,
                       FOREIGN KEY (user_id) REFERENCES users(id)
);

사용자조회 기능

1. Model

package com.example.userapi.model;
public class User {
    private Long id;
    private String name;
    private String email;

    public User() {} // Spring이 객체를 만들 때 기본 생성자를 사용

    public User(Long id, String name, String email) {
        this.id = id;
        this.name = name;
        this.email = email;
    }

    // Getter / Setter
    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

id
name
email

2. Controller

package com.example.userapi.controller;

import com.example.userapi.model.User;
import com.example.userapi.service.UserService;
import org.springframework.web.bind.annotation.*;

import java.util.List;
import java.util.Map;

@RestController
@RequestMapping("/users")
public class UserController {

    private final UserService service;

    public UserController(UserService service) {
        this.service = service;
    }

    @GetMapping("/")
    public List<User> getAllUsers() {
        return service.getAllUsers();  // 모든 사용자 목록 반환
    }

    @GetMapping("/{id}")
    public User getUser(@PathVariable Long id) {
        return service.getUserById(id);
    }

    @PostMapping
    public String createUser(@RequestBody User user) {
        service.createUser(user);
        return "사용자가 저장되었습니다.";
    }

    @PutMapping("/{id}")
    public String updateUser(@PathVariable Long id, @RequestBody User user) {
        user.setId(id);
        service.updateUser(user);
        return "사용자 전체 수정 완료!";
    }

    @PatchMapping("/{id}")
    public String partialUpdateUser(@PathVariable Long id, @RequestBody Map<String, Object> updates) {
        service.partialUpdateUser(id, updates);
        return "사용자 일부 수정 완료!";
    }

    @DeleteMapping("/{id}")
    public String deleteUser(@PathVariable Long id) {
        service.deleteUser(id);
        return "사용자 삭제 완료!";
    }
}

3. Service

package com.example.userapi.service;
import com.example.userapi.model.User;
import com.example.userapi.repository.UserRepository;
import org.springframework.stereotype.Service;

import java.util.List;
import java.util.Map;
import java.util.Optional;

@Service
public class UserService {

    private final UserRepository repo;

    public UserService(UserRepository repo) {
        this.repo = repo;
    }

    public void createUser(User user) {
        repo.save(user);
    }

    public List<User> getAllUsers() {
        return repo.findAll();  // 모든 사용자 목록 반환
    }

    public User getUserById(Long id) {
        return repo.findById(id)
                .orElseThrow(() -> new RuntimeException("사용자를 찾을 수 없습니다."));
    }

    public void updateUser(User user) {
        repo.update(user);
    }

    public void partialUpdateUser(Long id, Map<String, Object> updates) {
        User user = getUserById(id);
        if (updates.containsKey("name")) {
            user.setName((String) updates.get("name"));
        }
        if (updates.containsKey("email")) {
            user.setEmail((String) updates.get("email"));
        }
        repo.update(user);
    }

    public void deleteUser(Long id) {
        repo.deleteById(id);
    }
}

4. Repository

package com.example.userapi.repository;
import com.example.userapi.model.User;

import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.core.RowMapper;
import org.springframework.stereotype.Repository;

import java.util.List;
import java.util.Optional;

@Repository
public class UserRepository {

    private final JdbcTemplate jdbc;

    public UserRepository(JdbcTemplate jdbc) {
        this.jdbc = jdbc;
    }

    public void save(User user) {
        jdbc.update("INSERT INTO users (name, email) VALUES (?, ?)",
                user.getName(), user.getEmail());
    }

    public List<User> findAll() {
        return jdbc.query("SELECT * FROM users", userRowMapper());
    }

    public Optional<User> findById(Long id) {
        // jdbc.query()를 통해 결과를 리스트로 받고, 그 리스트에서 첫 번째 값을 Optional로 반환
        List<User> result = jdbc.query("SELECT * FROM users WHERE id = ?",
                new Object[]{id},
                userRowMapper());
        return result.stream().findAny();  // 결과가 있으면 첫 번째 항목을 Optional로 반환
    }

    public void update(User user) {
        jdbc.update("UPDATE users SET name = ?, email = ? WHERE id = ?",
                user.getName(), user.getEmail(), user.getId());
    }

    public void deleteById(Long id) {
        jdbc.update("DELETE FROM users WHERE id = ?", id);
    }

    private RowMapper<User> userRowMapper() {
        return (rs, rowNum) -> new User(
                rs.getLong("id"),
                rs.getString("name"),
                rs.getString("email")
        );
    }
}

게시글 게시 기능

1. Model

package com.example.userapi.model;

public class Post {
    private Long id;
    private String title;
    private String content;
    private Long userId;  // 작성자 ID

    public Post() {}

    public Post(Long id, String title, String content, Long userId) {
        this.id = id;
        this.title = title;
        this.content = content;
        this.userId = userId;
    }

    // Getter/Setter
    public Long getId() { return id; }
    public void setId(Long id) { this.id = id; }

    public String getTitle() { return title; }
    public void setTitle(String title) { this.title = title; }

    public String getContent() { return content; }
    public void setContent(String content) { this.content = content; }

    public Long getUserId() { return userId; }
    public void setUserId(Long userId) { this.userId = userId; }
}

id
title
content
userId

2. Controller

package com.example.userapi.controller;
import com.example.userapi.model.Post;
import com.example.userapi.service.PostService;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/posts")
public class PostController {

    private final PostService service;

    public PostController(PostService service) {
        this.service = service;
    }

    @PostMapping
    public String createPost(@RequestBody Post post) {
        service.createPost(post);
        return "게시글이 저장되었습니다.";
    }

    @GetMapping("/{id}")
    public Post getPost(@PathVariable Long id) {
        return service.getPost(id);
    }
}

3. Service

package com.example.userapi.service;
import com.example.userapi.model.Post;
import com.example.userapi.repository.PostRepository;
import com.example.userapi.repository.UserRepository;
import org.springframework.stereotype.Service;

@Service
public class PostService {

    private final PostRepository postRepo;
    private final UserRepository userRepo;

    public PostService(PostRepository postRepo, UserRepository userRepo) {
        this.postRepo = postRepo;
        this.userRepo = userRepo;
    }

    public void createPost(Post post) {
        // 작성자 존재 여부 확인 (옵션)
        userRepo.findById(post.getUserId())
                .orElseThrow(() -> new RuntimeException("작성자(User)를 찾을 수 없습니다."));
        postRepo.save(post);
    }

    public Post getPost(Long id) {
        return postRepo.findById(id)
                .orElseThrow(() -> new RuntimeException("게시글을 찾을 수 없습니다."));
    }
}

4. Repository

package com.example.userapi.repository;

import com.example.userapi.model.Post;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Repository;

import java.util.Optional;

@Repository
public class PostRepository {

    private final JdbcTemplate jdbc;

    public PostRepository(JdbcTemplate jdbc) {
        this.jdbc = jdbc;
    }

    public void save(Post post) {
        jdbc.update("INSERT INTO posts (title, content, user_id) VALUES (?, ?, ?)",
                post.getTitle(), post.getContent(), post.getUserId());
    }

    public Optional<Post> findById(Long id) {
        return jdbc.query("SELECT * FROM posts WHERE id = ?",
                new Object[]{id},
                rs -> {
                    if (rs.next()) {
                        return Optional.of(new Post(
                                rs.getLong("id"),
                                rs.getString("title"),
                                rs.getString("content"),
                                rs.getLong("user_id")
                        ));
                    } else {
                        return Optional.empty();
                    }
                });
    }
}

<사용자 조회, 게시글 플로우차트>

스터디 피드백

받은 피드백:

REST API 설계에서 가장 중요한 원칙은 무엇인가요?
일관성이 가장 중요하며, URL, 메서드, 응답 형식 등을 일관되게 설계하면 개발자들이 API를 쉽게 사용할 수 있습니다.
HTTP 상태 코드의 의미와 중요성
상태 코드는 요청 결과를 나타내며, 404 Not Found, 500 Internal Server Error 등의 코드가 오류를 파악하고 디버깅에 중요합니다. 각 코드의 숫자는 상태를 쉽게 파악할 수 있기 때문입니다.
API 성능 최적화 방법
캐싱과 상태 코드 출력을 통해 응답 속도를 높이고, 쿼리 최적화를 통해 성능을 개선할 수 있습니다.

백엔드 스터디 후기

myhousemouse — Sun, 8 Mar 2026 14:16:19 +0900

주차/주제: 2주차 - 프로젝트 구조와 아키텍처 이해

학습 내용 요약

MVC 구조

MVC는 애플리케이션을 세 가지 주요 구성 요소로 분리한 디자인 패턴

서로 독립적으로 동작

UI와 관련된 로직 분리를 목표

Model (모델)

데이터와 관련된 로직을 담당
DB와 연결되어 데이터를 저장하거나 가져오고, 가공하는 등의 역할
스프링부트에선 보통 Entity, DTO, Repository, Service 이런 것들이 모델 영역

package hello.hello_spring.domain;

public class Member {
    private Long id;  // 회원 ID
    private String name;  // 회원 이름

    // id getter()
    public Long getId() {
        return id;
    }

    // id setter ()
    public void setId(Long id) {
        this.id = id; 
    }

    // name getter
    public String getName() {
        return name;
    }

    // name setter
    public void setName(String name) {
        this.name = name;
    }
}

Getter 메서드 : 객체의 속성(필드)의 값을 반환 (외부에서 읽을 수 있게)

주로 get시작
필드 이름 그대로 사용

Setter 메서드 : 객체의 속성(필드)의 값을 설정 (외부에서 수정할 수 있게)

주로 set시작
필드 이름 그대로 사용

View (뷰)

사용자에게 보여지는 화면 (UI 해당)
HTML, Thymeleaf, JSON 등 사용자에게 결과를 보여주는 부분
스프링부트에선 Thymeleaf, Mustache 같은 템플릿 엔진이나, REST API라면 JSON 응답이 이에 해당
- Thymeleaf - 복잡한 화면
- Mustache - 가볍게 사용

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <title>Hello View</title>
</head>
<body>
<h1 th:text="${data}">Default Text</h1>
</body>
</html>

Controller (컨트롤러)

클라이언트의 요청을 받아 적절한 Model 준비하고 View에 전달하는 역할
HTTP 요청을 받고, 필요한 비즈니스 로직(서비스)을 호출하고, 그 결과를 View나 JSON으로 반환

@Controller
public class HelloController {
    @GetMapping("hello") // http://localhost:8080/hello GET 요청을 보낼 때 이 메서드가 실행됨
    public String hello(Model model) { //뷰 이름을 뷰 리졸버(ViewResolver)로 뷰 파일을 찾아서 렌더링
        model.addAttribute("data", "hello!!"); //뷰(View) 가 데이터를 필요로 할 때 이 데이터를 전달
        return "hello";
    } //뷰 이름 반환, resources/templates/hello.html 을 렌더링함 (기본 템플릿이 Thymeleaf)
}

예시 (도서관에서 책을 대출하고 반납하는 과정)

1. Model (모델)

Book 클래스

public class Book {
private String title;
private String author;
private boolean isAvailable;  // 대출 가능 여부

public Book(String title, String author) {
    this.title = title;
    this.author = author;
    this.isAvailable = true;  // 기본적으로 책은 대출 가능
}

// Getter and Setter
public String getTitle() {
    return title;
}

public boolean isAvailable() {
    return isAvailable;
}

public void setAvailable(boolean available) {
    isAvailable = available;
	}
}

Library 클래스

public class Library {
    private List<Book> books;

    public Library() {
        books = new ArrayList<>();
        // 도서 목록 추가
        books.add(new Book("Java Programming", "John Doe"));
        books.add(new Book("Spring Framework", "Jane Doe"));
    }

    public List<Book> getBooks() {
        return books;
    }

    public boolean borrowBook(String title) {
        for (Book book : books) {
            if (book.getTitle().equals(title) && book.isAvailable()) {
                book.setAvailable(false);  // 책 대출 처리
                return true;
            }
        }
        return false;  // 책이 없거나 대출 불가능
    }

    public boolean returnBook(String title) {
        for (Book book : books) {
            if (book.getTitle().equals(title) && !book.isAvailable()) {
                book.setAvailable(true);  // 책 반납 처리
                return true;
            }
        }
        return false;  // 책이 없거나 반납할 수 없는 경우
    }
}

2. View(뷰)

book-list.html : 사용자에게 책 목록을 보여주는 페이지

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <title>도서관</title>
</head>
<body>
    <h1>도서 목록</h1>
    <ul>
        <li th:each="book : ${books}">
            <span th:text="${book.title}"></span> 
            <span th:text="${book.author}"></span> 
            <span th:text="${book.isAvailable ? '대출 가능' : '대출 중'}"></span>
        </li>
    </ul>
</body>
</html>

borrow-book.html: 사용자가 책을 대출할 수 있는 양식을 제공하는 페이지

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <title>책 대출</title>
</head>
<body>
    <h1>책을 대출합니다</h1>
    <form action="/borrow-book" method="post">
        <label for="title">책 제목:</label>
        <input type="text" id="title" name="title" />
        <button type="submit">대출하기</button>
    </form>
</body>
</html>

3. Controller (컨트롤러)

@Controller
public class LibraryController {

    private Library library = new Library();

    @GetMapping("/books")
    public String showBooks(Model model) {
        // 모델에 도서 목록 추가
        model.addAttribute("books", library.getBooks());
        return "book-list";  // book-list.html로 전달
    }

    @GetMapping("/borrow-book")
    public String borrowBookForm() {
        return "borrow-book";  // borrow-book.html로 대출 폼 전달
    }

    @PostMapping("/borrow-book")
    public String borrowBook(@RequestParam("title") String title, Model model) {
        boolean success = library.borrowBook(title);
        if (success) {
            model.addAttribute("message", "책이 대출되었습니다.");
        } else {
            model.addAttribute("message", "책을 대출할 수 없습니다.");
        }
        return "redirect:/books";  // 대출 후 책 목록으로 리다이렉트
    }
}

비즈니스 로직 처리와 데이터 접근을 명확하게 분리
서비스 계층(Service Layer) 중심 비즈니스 로직을 처리
데이터베이스와의 상호작용을 Repository에서 처리

CSR(Controller-Service-Repository) 계층 조사하기

Controller 계층 (Web Layer)

사용자의 HTTP 요청을 처리

사용자로부터 입력 데이터를 받기 (HTTP 요청 파라미터, 폼 데이터 등)
Service 계층을 호출하여 비즈니스 로직 처리를 전달
그 후, 응답을 사용자에게 전달 (뷰 반환 또는 REST API 응답)

Service 계층 (Business Logic Layer)

Controller에서 받은 요청을 바탕으로 실제 비즈니스 로직을 처리

데이터베이스나 외부 API와의 상호작용을 할 때 Repository 계층을 호출

비즈니스 로직 처리: Controller에서 요청받은 데이터를 처리합니다.
Repository 계층 호출: 데이터를 조회하거나 수정할 때 Repository를 호출하여 데이터를 처리합니다.
트랜잭션 처리: 서비스 계층에서 트랜잭션 관리를 담당하는 경우가 많습니다. (@Transactional 어노테이션 사용)

package hello.hello_spring.service;

import hello.hello_spring.domain.Member;
import hello.hello_spring.repository.MemberRepository;
import hello.hello_spring.repository.MemoryMemberRepository;

import java.util.List;
import java.util.Optional;

public class MemberService {
    private final MemberRepository memberRepository = new MemoryMemberRepository();

    public Long join(Member member) {
        // 같은 이름이 있는 중복 회원 X
        validateDuplicateMember(member);
        memberRepository.save(member);
        return member.getId();
    }

    private void validateDuplicateMember(Member member) {
        memberRepository.findByName(member.getName())
                .ifPresent(m -> {
                    throw new IllegalStateException("이미 존재하는 회원");
                });
    }

    public List<Member> findMembers() {
        return memberRepository.findAll();
    }

    public Optional<Member> findOne(Long memberId) {
        return memberRepository.findById(memberId);
    }
}

Repository 계층 (Data Access Layer)

Repository는 데이터베이스와의 상호작용을 담당하는 계층

Spring Data JPA와 같은 ORM(Object-Relational Mapping) 프레임워크를 통해 데이터베이스 쿼리를 수행

데이터베이스 접근: Entity 객체를 데이터베이스에 저장하거나 조회하는 역할
쿼리 메서드 제공: JpaRepository를 상속하여 기본적인 CRUD 작업을 자동으로 제공하고, 맞춤형 쿼리 메서드를 정의

package hello.hello_spring.repository;

import hello.hello_spring.domain.Member;
import java.util.Optional;
import java.util.List;

public interface MemberRepository {
   Member save(Member member); //저장소에 저장
   Optional<Member> findById(Long id); //조회
   Optional<Member> findByName(String name);
   List<Member> findAll();
}

회원 정보 저장
회원정보 id 찾기
회원정보 이름 찾기
전체 회원 찾기

package hello.hello_spring.repository;
import hello.hello_spring.domain.Member;
import java.util.*;

// MemberRepository를 구현한 MemoryMemberRepository
public class MemoryMemberRepository implements MemberRepository {

    // 메모리 저장소 (Long: id, Member: Member 객체)
    private static Map<Long, Member> store = new HashMap<>();

    // 회원 id에 대한 자동 증가 값
    private static long sequence = 0L;

    // 회원을 저장하는 메서드
    @Override
    public Member save(Member member) {
        member.setId(++sequence);  // 자동으로 증가하는 id 설정
        store.put(member.getId(), member);  // store에 회원 저장
        return member;  // 저장된 회원 객체 반환
    }

    // id로 회원을 찾는 메서드
    @Override
    public Optional<Member> findById(Long id) {
        return Optional.ofNullable(store.get(id));  // id로 찾은 값을 Optional로 감싸서 반환
    }

    // 모든 회원을 반환하는 메서드
    @Override
    public List<Member> findAll() {
        return new ArrayList<>(store.values());  // store의 값을 리스트로 반환
    }

    // 이름으로 회원을 찾는 메서드
    @Override
    public Optional<Member> findByName(String name) {
        return store.values().stream()  // 저장된 모든 회원들에 대해
                .filter(member -> member.getName().equals(name))  // 이름이 일치하는 회원을 필터링
                .findAny();  // 일치하는 첫 번째 회원 반환 (없으면 Optional.empty() 반환)
    }

    public void clearStore() {
        store.clear();
    }
}

DTO(Data Transfer Object)의 필요성과 예시 정리하기

객체간 네트워크를 통한 데이터 전송을 목적

비즈니스 로직 포함 X

태그는 웹 브라우저에서 서버로 데이터를 전송할때 사용

ex. 게시판에 글 쓰고 전송 버튼 → 글이 서버로 전송

태그에 컨트롤러가 객체에 담아 받음 → 이 객체가 DTO → DB에 저장

→ DTO를 엔티티로 변환

데이터 전송 최적화: 필요한 데이터만 선택적으로 전송 (네트워크나 서버 리소스를 절약)
계층 간 데이터 격리: 데이터베이스 모델(엔티티) 클라이언트 모델(뷰) 분리 ,계층 간의 의존성을 줄이고, 변경 사항이 데이터베이스 모델에만 영향을 미치게 할 수 있음
보안과 캡슐화:민감한 데이터를 제외한 정보만을 전송
API 응답 구조 정의:API 설계 시, 데이터 교환 형식을 명확히 정의함. API 응답 구조를 표준화하고, 일관성을 유지
성능 향상: 데이터만 선택적으로 전달함으로써 네트워크 비용과 메모리 사용을 절약(메모리와 CPU 리소스, 데이터 처리 시간를 절약)

public class MemberDTO {
    private Long id;  // 회원 ID
    private String name;  // 회원 이름

    // 기본 생성자
    public MemberDTO() {}

    // 생성자 (필드를 통해 초기화)
    public MemberDTO(Long id, String name) {
        this.id = id;
        this.name = name;
    }

    // Getter & Setter
    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return "MemberDTO{id=" + id + ", name='" + name + "'}";
    }
}

Model과 DTO의 차이점

Model → 비즈니스 객체로서 사용될 가능성 있음
DTO는 데이터만 담고, 어떤 비즈니스 로직을 처리하는 데 사용되지 않아야함.

의존성 주입(DI)의 개념과 Spring에서의 구현 방법 학습하기

DI : Dependency Injection, 외부에서 만들어진 객체를 필요한 곳으로 가져오는 기법

스프링에서 의존성 주입을 컨테이너(IOC Container)를 사용하여 자동으로 관리

IOC((Inversion of Control) 자동으로 관리

객체의 생성
생명주기 관리
의존성 관리

DI 필요성

결합도 낮추기: 객체가 다른 객체에 의존하는 방식을 유연하게 바꿀 수 있음
코드의 유연성 향상:객체를 유연하게 확장
유지보수 용이성: 객체의 변경이나 확장을 자주 수정할 필요 없이 DI 컨테이너만 수정
테스트 용이성: 테스트용 객체(목 Mock)를 주입할 수 있어 단위 테스트가능

DI 종류

생성자 주입 (Constructor Injection): 의존성 객체를 생성자를 통해 주입

public class UserService {

    private final UserRepository userRepository;

    // 생성자에서 의존성 주입
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public void performService() {
        // userRepository를 사용한 비즈니스 로직
    }
}

private final MemberRepository memberRepository = new
 MemoryMemberRepository();
 
 /* 의존성 주입 예시 - 회원가입 서비스 적용 */

private final MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

세터 주입 (Setter Injection): 의존성 객체를 세터 메서드를 통해 주입

public class UserService {

    private UserRepository userRepository;

    // 세터 메서드를 통해 의존성 주입
    public void setUserRepository(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public void performService() {
        // userRepository를 사용한 비즈니스 로직
    }
}

필드 주입 (Field Injection): 의존성 객체를 필드에 직접 주입, @Autowired 어노테이션으로 의존성 주입을 할수있음

public class UserService {

    @Autowired
    private UserRepository userRepository;

    public void performService() {
        // userRepository를 사용한 비즈니스 로직
    }
}

/* 회원 컨트롤러에 의존관계 추가 */ 

@Controller
 public class MemberController {
     private final MemberService memberService;
     @Autowired
     public MemberController(MemberService memberService) {
         this.memberService = memberService;
     }
}

package hello.hello_spring.service;

import org.springframework.stereotype.Service;

@Service
public class MemberService {
    // 서비스 로직 구현
}

새롭게 알게 된 점 & 어려웠던 부분

새롭게 알게된 점:
MVC 구조와 CSR(Controller-Service-Repository) 계층을 통해 각 계층의 역할을 명확히 이해할 수 있게됨.
특히, 서비스에서 예외 처리를 하는 것이 적절하다는 점과 아키텍처의 역할과 책임을 명확히 구분하는 것의 중요성을 알게됨.
또한, 의존성 주입(DI)에 대해 다양한 주입 방법(생성자 주입, 세터 주입, 필드 주입)을 배우고, 각각의 장단점과 언제 적합한지에 대해 실습을 진행함.
어려웠던 부분:
의존성 주입(DI)에 대한 개념을 처음 접할 때 어려움을 느낌.
DI가 다양한 형태로 사용되고, 상황에 따라 적합한 주입 방법을 선택해야 하는 점이 복잡하게 느껴짐.
또한, 서비스와 컨트롤러 간의 책임 구분이 모호할 때가 많아 어떤 위치에서 예외 처리를 해야 할지 고민
해결 방법:
강의와 서적을 참고하면서 실습을 진행함.
생성자 주입, 세터 주입, 필드 주입을 직접 사용해보며 각 방식의 특성을 파악함.
예외 처리에 대해선 서비스 계층에서 처리하는 것이 적합함을 토론을 통해 의논함.
이러한 실습과 정보를 참고하여 점차 개념이 확립되어감.