Chapter07. 은나현

[nan0silver]

🆕 새롭게 알게 된 점

객체지향 설계는 3가지 관점을 동시에 고려하며 설계하는 것이라는 점을 다시금 이해하게 되었습니다.

📖 핵심 내용 요약

• 객체지향 설계 안의 3가지 관점

  3가지는 단계가 아니라, 동시에 바라보는 서로 다른 시선

  1. 개념 관점
     • 도메인 안 개념과 개념 사이의 관계를 표현
     • 커피 주문 시스템에서 손님, 바리스타, 주문서, 커피 같은 단어는 도메인 개념에 해당.
  2. 명세 관점
     • 객체의 인터페이스
     • Barista는 makeCoffee(Order)라는 기능을 제공한다는 명세는 있지만, 어떻게 만드는지는 아직 모른다.
  3. 구현 관점 - 객체의 구현 (코드) - makeCoffee() 내부에서 어떤 레시피로 커피를 만들고, 어떤 방식으로 완료 여부를 체크하는지 구현.

     개념 : 무엇이 존재하는가?
     명세 : 무엇을 할 수 있는가?
     구현 : 어떻게 하는가?

---

👁️‍🗨️ 소셜 로그인 기능을 객체지향 3가지 관점으로 보기

---

✅ 1. 개념 관점 (Conceptual Perspective)

시스템 안에서 존재해야 하는 도메인 개념들과 그 관계를 정의하는 단계

• 등장하는 주요 개념

  • 사용자(User)
  • 소셜 로그인 제공자(OAuthProvider)
  • 인가 코드(Authorization Code)
  • 액세스 토큰(AccessToken)
  • 세션(Session) 또는 JWT

• 개념 간 관계

  • 사용자는 소셜 로그인 제공자를 통해 인증받는다.
  • 로그인 결과로 액세스 토큰을 얻고, 이를 통해 사용자 정보를 가져온다.
  • 사용자 정보로 우리 서비스의 세션 또는 JWT 발급

👉 이 단계에서는 "GoogleLogin", "KakaoLogin" 같은 구체 이름은 등장하지 않음.
대신 "소셜 제공자", "인증 토큰", "사용자 프로필" 등의 역할 중심 개념을 설정

---

✅ 2. 명세 관점 (Specification Perspective)

각 객체가 외부에 제공하는 인터페이스(메시지) 정의

예: OAuthLoginService 인터페이스

• 사용자 관점에서 필요한 동작은 2가지
  1. 로그인 버튼을 누르면 로그인 페이지로 이동해야함

     클라이언트 입장에서 "어떻게 URL을 조립하는지"는 관심 없음

  2. 로그인 완료 후 받은 코드로 사용자 정보를 가져와야 함

     이 안에서 토큰 요청, 유저 정보 요청 등이 일어나지만 외부에선 몰라도 됨

public interface OAuthLoginService {
    String getAuthorizationUrl(); //사용자가 로그인 버튼 눌렀을 때 리다이렉트할 URL
    OAuthUserInfo login(String authorizationCode); //인가 코드를 받아서 액세스 토큰 요청 → 사용자 정보 추출
}

역할 분리 예시

• 우선 OAuth 로그인은 아래 5단계로 진행됩니다.

단계	설명	중요한 개념
1단계	사용자 로그인 버튼 클릭 → 카카오 로그인 페이지로 이동	인가 요청 URL, redirect_uri 포함
2단계	사용자가 카카오에 로그인 → 카카오가 인가 코드 + redirect_uri로 우리 서버에 보냄	인가 코드, 리다이렉트 URL
3단계	우리 서버가 카카오에 인가 코드를 보내서 액세스 토큰 받음	액세스 토큰
4단계	우리 서버가 카카오에 액세스 토큰으로 유저 정보 요청	사용자 정보 API
5단계	사용자 정보를 바탕으로 JWT 발급 → 프론트에 전달	JWT 생성 및 응답

public interface OAuthProvider {
    String requestAccessToken(String code); // 인가 코드를 받아서 엑세스 토큰을 요청하는 역할 (3단계)
    OAuthUserInfo fetchUserInfo(String accessToken); // 엑세스 토큰으로 사용자 정보를 조회하는 역할 (4단계)
}

• 이 인터페이스는 OAuth 인증 플로우에서 하나의 책임을 하나의 메서드로 명확하게 분리하려 표현
  -> 이것이 바로 역할 중심의 명세 설계
• 구현은 Kakao든 Google이든 상관없고, 어떤 방식으로 요청하는지는 몰라도 된다.

클라이언트 코드 (예: Controller)

@PostMapping("/oauth/kakao/callback")
public ResponseEntity<?> login(@RequestParam String code) {
    OAuthUserInfo userInfo = kakaoLoginService.login(code);
    return ResponseEntity.ok(userInfo);
}

• 이 컨트롤러는 내부적으로 OAuthLoginService의 login(code) 메서드에만 의존한다.
• 이 login(code) 메서드가 code를 주면 사용자 정보를 준다는 "기능 약속"을 믿고 호출하고 있다.
  • 즉, 컨트롤러는 이 객체가 어떻게 토큰을 요청하고, 어떻게 유저정보를 얻는지 전혀 모름
  • 오직 login(code)라는 메시지를 보냈을 때, 그 책임을 수행할 것이라는 계약만 알고 있다.

👉 이 단계에서는 "무엇을 할 수 있는가"를 정의.
"어떻게" 토큰 요청하는지는 중요하지 않음.

---

✅ 3. 구현 관점 (Implementation Perspective)

실제 로직, 알고리즘, API 요청 방식, 응답 파싱 등 내부 코드 구현

public class KakaoLoginService implements OAuthLoginService {

    @Override
    public String getAuthorizationUrl() {
        return "https://kauth.kakao.com/oauth/authorize?...";  // URL 조립
    }

    @Override
    public OAuthUserInfo login(String code) {
        String accessToken = requestAccessToken(code);
        return fetchUserInfo(accessToken);
    }

    private String requestAccessToken(String code) {
        // 카카오 서버에 POST 요청
        // 응답으로 access_token 추출
    }

    private OAuthUserInfo fetchUserInfo(String accessToken) {
        // access_token으로 사용자 정보 요청
        // JSON 파싱 후 OAuthUserInfo 객체 생성
    }
}

👉 이 단계에서는 명세 관점에서 정의한 기능을 실제 HTTP 요청/응답, 파싱 등의 코드로 실현함.

---

❓ 어려웠거나 이해가 부족했던 부분

• 객체 지향을 제대로 이해하고 지키면서 구현을 하는게 어려운 일이라는걸 다시금 깨달았습니다..
  • Spring boot로 로그인을 구현하면서, 비교적 구현 내용이 직관적이고 간단했던 python에서 구현과 달리 복잡하고 어렵다고 느꼈습니다.
    • python에서 로그인 구현은 이 코드면 끝납니다..1차 프로젝트 구글 로그인
  • 이번 장에서 배운 내용으로 실제 코드를 적용해서 공부하니 좀 더 이해가 되는 것 같지만 아직 갈길이 먼 것 같아요..

---

🌟 인상 깊었던 책의 내용

📌 기억에 남는 문장

"인터페이스와 구현을 분리해라!"

---

📚 관련 아티클 & 추가 자료

📌 다른 사람이 이해하는 데 도움이 될 만한 자료 첨부
📌 논문, 블로그, 영상, 실무 사례 등 공유

🔗 추천 자료

• 📄 [관련 논문 또는 공식 문서 링크]
• 🎥 [관련 영상 링크]
• 📝 [관련 블로그 글 링크]