협력, 책임, 역할

객체지향의 핵심이자 꽃은 협력, 책임, 역할이다.

객체지향은 객체들이 각자의 책임을 가지고 메시지를 주고받으며 협력함으로써 하나의 유기적인 시스템을 이루는 방식이다.

이를 설명하기 위해 책임이라는 개념에서부터 이야기를 시작해보자.
책임은 어떤 객체 혹은 역할이 수행해야 할 일이나 의무를 의미한다.
객체지향 설계는 시스템이 제공해야 할 요구사항을 시스템의 책임으로 바라보는 것에서 출발한다.

예를 들어 ‘치킨을 먹는다’라는 요구사항이 있다고 해보자.
이를 하나의 객체가 아니라 ‘집’이라는 시스템이 가져야 할 책임으로 바라본다.

이 책임을 수행하기 위해 시스템은 ‘치킨을 먹어라’라는 메시지를 정의할 수 있다.
그렇다면 이 메시지를 수행하기에 적합한 객체는 무엇일까?

바로 ‘나’이다.

하지만 내가 치킨을 먹기 위해서는 여러 가지 하위 작업이 필요하다.
- 치킨을 시킨다
- 치킨값을 낸다
- 치킨을 받는다

이 시점에서는 아직 각 작업을 누가 수행할지는 정해지지 않았다.
다만 책임을 수행하기 위해 필요한 메시지들이 식별되었을 뿐이다.

이제 각 메시지를 가장 잘 처리할 수 있는 객체 혹은 역할을 생각해볼 수 있다.
- 치킨을 시키는 책임 → 휴대폰
- 치킨값을 내는 책임 → 통장
- 치킨을 받는 책임 → 문

이렇게 ‘치킨을 먹는다’라는 하나의 큰 책임은 여러 개의 작은 책임으로 분해되고,
각 책임이 적절한 객체(혹은 역할)에 할당되면서 객체들이 메시지를 통해 상호작용하는 협력 관계가 완성된다.

즉, 객체지향 설계에서 중요한 것은 협력을 먼저 떠올리고, 그 협력을 가능하게 하는 책임과 역할을 올바르게 설정하는 것이다. 여기서 협력을 먼저 떠올리라는 말은 마치 위의 말을 부정하는 것처럼 보인다. 하지만, 여기엔 중요한 포인트가 하나있다.

설계를 시작하기 전, 협력의 큰 그림을 한번 그려보는 것이다.
간단한 예시로 이를 이해해보자.

아침에 일어나 출근 준비를 한다고하면, 가장 먼저 떠오르는 생각이 무엇인가?
"일어나자마자 밥 먹고 씻고나서 옷 입고.."와 같이 아침 출근 준비의 흐름을 생각하게 될 것이다.

여기서 "나는 세수, 밥 먹기, 씻기, 옷 입기를 해야지"와 처럼 책임의 나열을 하진 않을 것이다. 
이처럼 아침 준비라는 큰 책임 아래 '흐름' 즉, 협력을 먼저 생각하기에 객체지향 설계 역시 책임을 정의하기 전에, 그 책임이 어떻게 달성될지에 대한 협력의 흐름을 큰 그림으로 그려보고 시작하는 것이 중요하다.

즉, 책임은 설계의 기준이고, 협력은 그 책임을 올바르게 나누기 위한 사고의 틀이다.

그렇다면 여기서 역할은 무엇일까?

역할은 연극의 배역을 생각하면 쉽다. 
연극에서 어떤 배역이 있을 때 항상 한 명의 배우만 배역을 맡지는 않는다. 
어떤 날은 A 배우가 맡을 수도 있고, 어떤 날은 B 배우가 맡을 수도 있다. 이처럼 협력이라는 관계 속에서 같은 책임을 수행할 수 있다면 배우가 누구든 '배역'이라는 하나의 역할로 볼 수 있다.

단지, 연극이라는 협력 아래 주어진 역할을 잘 수행하기만 하면 된다.

이처럼 역할은 추상화를 만들어내는 중요한 요소이다.
위의 연극 예시에서 배역이 아닌 A 배우로 고정한다고 해보자. 만약, A 배우가 아프다면 해당 배우가 나을때까지 연극을 중단해야 할까? 현실 세계에서는 그럴지도 모르지만, 단순하게 생각하면 다른 배우를 투입하면 된다. 해당 배우가 배역을 잘 수행한다면 전혀 문제가 없다.

이처럼 하나의 객체로 보던 것을 역할로서 바라본다면, 해당 역할만 잘 수행하는 객체면 되기에 변경과 확장에 유연해진다. 즉, 역할은 협력 관계에서 구성 요소를 추상화 할 수 있다는 것이다. 그렇기에 협력의 관점에서 추상화의 이점을 얻어갈 수 있다.
하지만, 설계 초기에는 이러한 역할이 잘 보이지 않을 수 있다. 그리고 하나의 객체만 협력 안에서 책임을 수행하는게 명확할 때도 분명있다.

이러한 경우에는 해당 객체를 역할로 보아도 무방하다. 여기서 재밌는 점은 책임이 역할을 결정한다는 사실이다. 그렇기에 객체는 여러 역할을 가질 수 있다. 다만, 하나의 협력에 참여한 객체는 언제나 하나의 역할을 가진다.

결국 객체지향 설계란, 무엇을 해야 하는가(책임) 를 기준으로 어떻게 함께 일할지(협력) 를 그려보고, 누가 그 일을 맡을 수 있는지(역할) 를 유연하게 배치하는 과정이다.

 

이런 관점에서 문득 프로젝트에서 작성한 토큰 검증 과정이 생각났다.

 

public String validateAndGetUserId(SecretKey key) {  
    try {  
        Claims claims = Jwts.parser()  
                .verifyWith(key)  
                .build()  
                .parseSignedClaims(accessToken)  
                .getPayload();  
        return claims.getSubject();  
    } catch (JwtException e) {  
        throw AUTHENTICATION_FAIL.create();  
    }  
}

@Override  
public OauthUserInfo verifyAndGetUserInfo(Provider provider, String idToken) {  
    NimbusOidcIdTokenProcessor processor = processors.get(provider);  
    if (processor == null) throw new IllegalArgumentException("지원하지 않는 provider: " + provider);  
  
    JWTClaimsSet claims = processor.verifyAndGetClaims(idToken);  
    String providerId = claims.getSubject();  
    String email = safeString(claims, "email");  
    String picture = safeString(claims, "picture");  
  
    return new OauthUserInfo(providerId, email, picture);  
}

진행 중인 두 프로젝트에서 가져온 코드인데, 약간의 차이는 있지만 공통적으로 토큰을 검증하고, 토큰 내에 존재하는 유저의 정보를 가져온다.

여기서 해당 메서드는 이론적으로 두 개의 메시지를 처리한다고 볼 수 있을 것 같다.
- 토큰을 검증하라
- 유저 정보를 가져와라

그렇기에 두 개의 메시지를 하나의 메서드가 담당한다고 볼 수 있다. 그렇다면 두 개의 메시지로 분리하여 각 메서드가 처리하도록 만들면 아래와 같은 코드가 될 것이다.

 

public JwtParser validate(SecretKey key) {  
    try {  
        return Jwts.parser()  
                .verifyWith(key)  
                .build();  
    } catch (JwtException e) {  
        throw AUTHENTICATION_FAIL.create();  
    }  
}  
  
public String getUserId(JwtParser parser) {  
    Claims payload = parser  
            .parseSignedClaims(accessToken)  
            .getPayload();  
  
    return payload.getSubject();  
}

@Override  
public JWTClaimsSet verify(Provider provider, String idToken) {  
    NimbusOidcIdTokenProcessor processor = processors.get(provider);  
    if (processor == null) throw new IllegalArgumentException("지원하지 않는 provider: " + provider);  
  
    return processor.verifyAndGetClaims(idToken);  
}  
 
@Override 
public OauthUserInfo getUserInfo(JWTClaimsSet claims) {  
    String providerId = claims.getSubject();  
    String email = safeString(claims, "email");  
    String picture = safeString(claims, "picture");  
  
    return new OauthUserInfo(providerId, email, picture);  
}

이론적으로 보면 토큰을 검증한다와 유저 정보를 가져온다는 서로 다른 메시지이며, 각각 독립된 책임으로 분리할 수 있다. 그리고 이게 개념적으로 깔끔한 모습으로 보인다.

하지만 실제 협력의 관점에서 보면 이 두 행위는 항상 함께 수행되며, 분리된 상태로 사용될 여지가 거의 없다. 

즉, 이 경우 두 책임은 개념적으로는 분리 가능하지만, 협력 안에서는 하나의 의미 있는 행위(인증)로 동작한다.

이런 상황에서 메시지를 인위적으로 분리하면, 오히려 verify 이후 반드시 getUserInfo를 호출해야 한다는 암묵적인 프로토콜을 코드 밖의 맥락에 의존하게 된다.

이는 협력을 코드로 드러내기보다, 협력을 개발자의 기억과 합의에 맡기는 설계가 될 수 있다.

그렇기에 객체지향은 코드의 배치를 배제하고 설계할 수 없으며, 결국 핵심은 책임을 어떻게 설정하느냐에 있다.