[데브코스] Spring Boot 인증·인가(Auth) (14강) - Member에 apiKey 추가 + username/apiKey 유니크 제약

14강에서는 인증 구조가 한 단계 바뀌기 시작한다.
지금까지는 모든 요청에 username/password를 직접 실어서 인증했지만,
이제 API KEY를 인증 정보로 사용하기 위한 준비 단계에 들어간다.

---

1️⃣ 왜 apiKey가 필요해졌을까?

13강에서 정리했던 문제를 다시 보면 이렇다.

• 스프링부트는 요청을 기억하지 못한다
• 그래서 매 요청마다 “누구인지” 알려줘야 한다
• 지금까지는 username/password를 매번 전달했다

하지만 이 방식에는 치명적인 단점이 있다.

❌ 기존 방식의 문제점

• 매 요청마다 비밀번호가 네트워크를 탄다
• 클라이언트 앱이 비밀번호를 저장해야 한다
• 보안적으로 좋지 않다
• 실무에서 거의 사용하지 않는다

👉 그래서 비밀번호 대신 사용할 수 있는 인증 수단이 필요해졌다.
그게 바로 API KEY다.

---

2️⃣ 14강의 핵심 작업 요약

이번 강의에서 한 작업은 딱 두 가지다.

1. Member 엔티티에 apiKey 필드 추가
2. username, apiKey에 유니크 제약(unique) 설정

아직 “어디서 apiKey를 쓰는지”까지는 안 나왔고,
발급하고, 구분 가능하게 만드는 준비 단계라고 보면 된다.

---

3️⃣ Member 엔티티 코드 살펴보기

@Entity
@Getter
@NoArgsConstructor
public class Member extends BaseEntity {

    @Column(unique = true)
    private String username;

    private String password;
    private String nickname;

    @Column(unique = true)
    private String apiKey;

    public Member(String username, String password, String nickname) {
        this.username = username;
        this.password = password;
        this.nickname = nickname;
        this.apiKey = UUID.randomUUID().toString();
    }

    public String getName() {
        return nickname;
    }
}

---

4️⃣ apiKey 필드를 Member에 추가한 이유

✔ apiKey의 역할

• 회원을 식별하기 위한 대체 인증 수단
• 비밀번호처럼 민감한 정보 ❌
• 노출되어도 상대적으로 안전 ⭕

즉, 이후에는 이렇게 바뀌게 된다.

이전: username + password
이후: apiKey

---

5️⃣ apiKey는 왜 UUID로 만들었을까?

this.apiKey = UUID.randomUUID().toString();

이렇게 만든 이유는 명확하다.

• 전 세계적으로 겹칠 확률이 거의 없음
• 사람이 예측할 수 없음
• 서버에서 자동 생성 가능
• 길이가 충분히 길어 보안적으로 유리

👉 “추측 불가능한 식별자”로 쓰기 적합하다.

---

6️⃣ username과 apiKey에 unique 제약을 건 이유

@Column(unique = true)
private String username;

@Column(unique = true)
private String apiKey;

✔ username이 unique여야 하는 이유

• 같은 아이디가 두 명 있으면 안 된다
• 로그인/회원 조회 시 혼란 발생

✔ apiKey가 unique여야 하는 이유

• apiKey는 “신분증” 역할
• 하나의 apiKey는 반드시 한 명의 회원만 가리켜야 한다
• 겹치면 인증 자체가 무너진다

👉 인증에 쓰이는 값은 반드시 유니크해야 한다.

---

7️⃣ 아직 이 단계에서 apiKey로 인증하지 않는 이유

중요한 포인트 하나.

14강에서는
apiKey를 “사용”하지 않고, “준비”만 했다.

• 아직 컨트롤러에서 apiKey를 받지 않는다
• 아직 인증 로직은 username/password 기반이다
• 지금은 데이터 구조를 바꾸는 단계

이렇게 단계별로 가는 이유는:

• 한 번에 바꾸면 흐름이 꼬이기 때문
• 인증 구조를 이해하면서 점진적으로 전환하기 위해서

---

8️⃣ 14강 한 줄 요약

• 비밀번호를 인증 정보로 쓰는 구조의 한계를 확인했다
• 이를 대체하기 위한 인증 수단으로 apiKey를 도입했다
• Member 엔티티에 apiKey 필드를 추가했다
• username과 apiKey 모두 유니크하게 설정했다
• 아직 “인증 방식 변경”은 시작하지 않았다 (준비 단계)

---

🔚 마무리

14강은 눈에 띄는 기능 변화는 없지만,
인증 구조가 바뀌는 첫 출발점이다.

이제부터는:

• “비밀번호로 매번 인증” ❌
• “한 번 발급받은 신분증(apiKey)으로 인증” ⭕

이라는 방향으로 흐름이 이어진다.

이번 강의는 그 흐름을 위한 기초 공사라고 이해했다.