설명에 따른 책임을 이겨낼 것인가?

주의

제목은 거창하지만 내용은 그렇지 않을 수 있습니다..

 

최근에 생긴 고민

큐시즘 동아리를 하면서 스터디와 2달 간 진행하는 밋업 프로젝트를 진행하고 있습니다.

여러 활동을 진행하고 다양한 사람들을 만나면서 여러 안목을 쌓고 있는 와중에 고민이 생겼습니다.

 

누군가에게 내가 아는 내용을 알려줄 때, 
그러나 확실하지 않은 내용일 때, (내 주관대로 내용을 정의하였을 때)

1. 내가 아는 선에서 최대한 설명을 해준다. 애매모호함을 곁들인,,
2. 모른다고 한다.

 

위의 고민거리가 대체 무슨 말이지?! 라고 이해 못하실 독자분들도 계실 거 같아 두 가지 예시를 들어 설명하겠습니다.

 

예시 1. MSA에서 다른 도메인의 정보를 어떻게 가져와야할까요?

백엔드 스터디인 "큐백" 에서 스터디를 진행하고 있습니다.

큐백에서는 여러 도메인을 DDD, TDD로 개발하고 MSA를 도입하고자 합니다.

스터디 주제는 "티켓팅을 MSA 구조로 만들어보자" 입니다.

도메인은 크게 인증/인가, 알림, 대기열, 자리선정, 결제 이렇게 있습니다.

 

제가 속한 도메인은 자리선정 및 결제였고, 저희 팀은 대기열에서 대기가 끝난 사용자를 자리 선정을 할 수 있게 하고 결제를 진행하는 플로우를 가지고 구현 중에 있습니다.

 

이때 문제 상황은 다음과 같습니다.

대기열에서 대기가 끝난 사용자 정보를 받아와서 자리 선정과 결제를 해야 하는데 어떤 식으로 받아와야 할까요?

 

저희 팀에서 내놓은 솔루션은 다음과 같습니다.

1. 대기열 도메인에서 우리 도메인으로 API를 통해 보내주는 방식
2. 우리 도메인에서 대기열 도메인에 "자리 선정 및 결제 가능 여부"를 API를 통해 보내주고 대기열 도메인에서 넘겨주는 방식
3. 메시지 큐를 사용해서 대기열 도메인에서 대기가 끝난 사용자를 이벤트로 해서 큐에 넣어주고 우리 도메인에서 큐의 데이터를 소비(사용) 하는 방식

 

자세히 기억은 안나지만 이정도의 솔루션이 나왔던 것으로 기억합니다.

여기서 저는 3번 솔루션에 대해 얘기했었습니다.

 

이때 저는 3번 솔루션을 말하면서, 정보의 확실성을 갖고 말한 것은 아니었습니다.

그냥 제가 어디선가 보거나 들었던 정보, 즉 객관적인 사실보다는 저의 주관적인 생각, 느낌을 말했던 것 같습니다.

 

나 : "어차피 MSA를 할건데 RabbitMQ나 Kafka를 사용해서 대기열 도메인에서 대기가 끝난 사용자들을 큐에 차곡차곡 넣어주고 우리가 큐의 데이터를 받아서 가공해서 사용하면 어떨까요?"

 

팀원 : "대기가 끝난 사용자를 이벤트로 해서 큐로 넣어준다고 하셨는데 대기가 끝났는지 어떻게 알 수 있어요?"

 

나 : "...................................................."

---

예시 2. 엔티티에서 ID의 집합을 저장할 때 JSON으로 저장하는 건 어떨까요?

이 예시는 한 분의 백엔드파트원과 얘기 중에 나왔던 상황입니다.

 

파트원께서 자신이 구현한 코드에 대해 같이 얘기를 나눠보면 좋을 거 같다 하셨고 그 코드를 보던 중에 

 

Example example = exampleRepository.findById(1L);
Set<ExampleId> exampleIds = example.getExampleIds().stream()
                                    .map(Example::getId())
                                    .collect(Collectors.toSet());

 

이런 식으로 엔티티에서 ids를 저장하는데 이 과정에서 ExampleIds를 조회하고 한 번 더 getId()를 통해 Set으로 변환하는 과정을 거쳤습니다.

자세히 기억은 안나지만 exampleId를 저장하는데 테이블 하나를 더 만들어서 저장한다고 들었습니다.

 

저는 "Set<ExampleId> exampleIds" 을 Example 엔티티 내 저장하면 어떨까 말씀드렸습니다.

 

나 : "한 번 더 변환하는 과정보다는 엔티티에서 Set<ExampleId> exampleIds을 필드로 해서 갖고 있으면 어떨까요?"

파트원 : "Set<ExampleId>" 를 db에 어떤 타입으로 저장하시나요?"

 

나 : "저는 JSON 타입으로 넣고 있어요!"

 

파트원 : "저는 1, 2, 3, ... 이런 식으로 컨버터로 쉼표를 넣어서 변환해서 저장했을 때도 잘 되었는데 JSON으로 저장하시는 이유가 있나요?"

 

나 : "JSON 타입으로 저장하는 이유는 중요한 값이 아닌 부수적인 값들은 JSON으로 저장하는게 좋다고 어디서 본 거 같은데,,,?"

 

나 : "...................................................."

 

위 두 예시 말고도 제가 느끼기에 유사한 여러 상황이 있었습니다.

 

이럴 때마다 느꼈던 것은

"내가 너무 아는 척을 하고 있나?"
"모른다고 하는게 더 나았을까?"

 

이 두 가지 생각이 들었습니다.

---

해결책

물론 위의 경우를 해결할 수 있는 방법은 있습니다.

 

지식을 제대로 알고, 그 지식을 설명할 수 있어야 한다.

 

너무 단순하지만 가장 핵심적인 해결책이라 생각합니다.

 

저는 기존에는 무언가 배울 때 WHY 보다는 HOW에 집중했던 것 같습니다.

책을 읽을 때도, 이게 왜 이렇게 되는 거지에 의문을 품기보다는 그냥 순응하고 지나갔던 것 같습니다.

 

그래서 앞으로 공부를 할 때 WHY에 더 집중하고, 그 WHY를 객관적인 정보에서 설명할 수 있을 정도로 깊게 파고드는 공부를 하려고 합니다.

잘 될지는 모르겠지만, 위 상황의 저의 괴리를 해결할 수 있을 것이라 생각합니다.

---

그래서 너는 설명에 따른 책임을 이겨낼 것인가?

해결할 수 있는 방법은 위에서 설명한 대로입니다.

하지만 완벽히 공부를 하지 않은 다른 주제에 질문이 들어오거나 설명을 해야할 때가 있습니다.

 

그때 불확실한 정보를 제 주관의 생각을 더해 설명을 하고 그에 대한 책임을 질지?

아니면 모르겠다고 책임을 저버릴지?

사실 아직까지 고민입니다.

 

지금 드는 생각으로는 전자에 가까운, 즉 책임을 지는 사람이 되고 싶습니다.

하지만 불확실한 정보를 전달하고 끝내는 사람이 아닌, 저 스스로 더 탐구하고 찾아보며 정제된 지식을 다시 전달할 수 있는 사람이 되고 싶습니다. 이 과정에서 책임을 지려고 합니다.

 

다른 분들께서는 이런 생각을 하고 계시는지..

하고 계셨다면 어떻게 해결하는게 좋다고 생각하시는지 궁금합니다..