[데브코스] Spring Boot 인증·인가(Auth) (40강) - 내 정보 API 구현 — 로그인 여부에 따른 응답 처리

zuno·2026년 1월 13일

40강에서는 “내 정보 조회 API” 를 구현한다.
지금까지 정리해온 인증 흐름(Rq)을 실제로 활용하는 단계다.

핵심은 단순하다.

로그인 안 했으면 401,
로그인 했으면 내 정보를 내려준다.


1️⃣ 내 정보 API가 왜 필요한가?

대부분의 서비스에는 반드시 이런 API가 있다.

  • 로그인 상태 확인
  • 현재 사용자 정보 조회
  • 마이페이지, 프로필 화면의 기반 데이터

즉,

“지금 로그인한 사용자가 누구인지”를 서버에서 알려주는 API


2️⃣ API 스펙

요청

GET /api/v1/members/me
  • Authorization 헤더 필요
  • Bearer 토큰(API Key) 기반 인증

응답 시나리오

상황응답
로그인 안 함401 Unauthorized
로그인 함200 OK + 내 정보

3️⃣ 컨트롤러 구현

이번 강의에서 추가된 컨트롤러 코드는 매우 단순하다.

@GetMapping("/me")
public RsData<MemberDto> me() {
    Member actor = rq.getActor();

    return new RsData<>(
            "200-1",
            "%s님의 정보입니다.".formatted(actor.getName()),
            new MemberDto(actor)
    );
}

여기서 중요한 포인트

  • rq.getActor() 호출
    • 로그인 안 했으면 → 예외 발생 (401)
    • 로그인 했으면 → Member 반환
  • 컨트롤러는 권한 판단 로직을 직접 쓰지 않는다

👉 Rq에 인증 책임을 위임한 구조다.


4️⃣ 로그인 안 했을 때 동작

요청

  • Authorization 헤더 없음

흐름

  1. /api/v1/members/me 요청
  2. rq.getActor() 호출
  3. Authorization 헤더 없음
  4. 예외 발생
{
  "resultCode": "401-1",
  "msg": "로그인 후 이용해주세요.",
  "data": null
}

👉 컨트롤러 로직은 실행되지 않는다.


5️⃣ 로그인 했을 때 동작

요청

  • Authorization 헤더에 유효한 API Key 포함
Authorization: Bearer {apiKey}

응답 예시

{
  "resultCode": "200-1",
  "msg": "관리자님의 정보입니다.",
  "data": {
    "id": 2,
    "createDate": "2025-07-07T10:42:47",
    "modifyDate": "2025-07-07T10:42:47",
    "name": "관리자"
  }
}

👉 현재 로그인한 사용자의 정보만 반환된다.


6️⃣ 테스트 코드로 검증하기

40강에서는 내 정보 API 테스트도 함께 추가한다.

@Test
@DisplayName("내 정보")
void t3() throws Exception {
    Member actor = memberService.findByUsername("user1").get();
    String actorApiKey = actor.getApiKey();

    mvc.perform(
            get("/api/v1/members/me")
                    .header("Authorization", "Bearer " + actorApiKey)
    )
    .andExpect(status().isOk())
    .andExpect(jsonPath("$.resultCode").value("200-1"))
    .andExpect(jsonPath("$.data.id").value(actor.getId()))
    .andExpect(jsonPath("$.data.name").value(actor.getName()));
}

이 테스트가 보장하는 것:

  • 인증이 성공하면
  • 항상 본인 정보만 반환
  • 응답 포맷이 깨지지 않음

7️⃣ 지금까지 인증 흐름 정리

40강까지 오면서 인증 흐름은 이렇게 완성됐다.

  1. Rq

    • 인증(Authentication) 담당
    • 로그인 여부 판단
  2. 컨트롤러

    • 요청 흐름만 담당
    • 인증/인가 판단 ❌
  3. 엔티티 (36강)

    • 인가(Authorization) 담당
    • 수정/삭제 권한 판단
  4. 테스트 (37~39강)

    • 실패 케이스를 테스트로 고정

👉 40강은 이 구조를 실제 API로 증명하는 단계다.


8️⃣ 이 강의의 핵심 메시지

40강의 핵심은 이 문장이다.

“인증 로직은 재사용되어야 하고,
내 정보 API는 그 가장 대표적인 예다.”

  • 로그인 여부에 따라 응답이 갈린다
  • Rq 하나로 모든 컨트롤러에서 동일한 인증 흐름을 사용한다

9️⃣ 최종 요약

  • /api/v1/members/me API 구현
  • 로그인 안 하면 401
  • 로그인 하면 내 정보 반환
  • 인증 책임은 Rq에 집중
  • 테스트로 정상 동작을 보장

이제 인증 구조는
“설계 → 구현 → 테스트 → 실제 사용”
까지 한 사이클이 완성됐다.

0개의 댓글