[251220] 25년 회고 겸 적는 플랫폼 vs 서비스 (feat. 객체지향, MSA)

정말 오랜만에 쓰는 블로그.

사실상 이제는 정보공유 보다는 내 일기장 같은 느낌으로 쓰는 느낌이다.

 

블로그 글이 뜸했던 데는 이유가 있다.

 

1. 히스토리/정책이 중요 -> 블로그보다는 사내 위키를 주로 활용.

2. 기술은 배우면 된다. 아키텍처 설계, 객체의 책임이 더 중요한 듯.

3. 바빠서.

 

3번은 사실 핑계다.

1번, 2번 이유가 더 큰 듯하다.

예전에는 '기술적으로 뛰어나면, 개발하는 데에 어려움이 없다' 라고 생각했다.

하지만 지금은 아니라고 생각한다. (물론 기술이 중요치 않다고 생각하는 건 아니다.)

 

지금은 '기술은 하나의 도구일 뿐이다. 더 중요한 것은 나만의 가치관을 잘 정리하는 것' 이라고 생각한다.

 

그리고 이에 대한 내 스스로에 대해, 아직도 정답을 잘 모르겠는 상황이다.

가치관에는 여러 가지가 있겠지만, 요즘 가장 생각이 많은 부분을 적어보겠다.

---

플랫폼 vs 서비스

2023년, 2024년에는 전혀 고민하지 않았던 부분이다.

플랫폼. 구글에 쳐보면 '여러 참여자들이 모여 상호작용하고 가치를 거래하는 장 또는 기반' 이라고 뜬다.

플랫폼은 그만큼 여러 요구사항이 오고, 그것들을 처리해야 된다.

 

요구사항 A 뿐만 아니라, B, C, ... ,Z 에 대해서도 처리를 해야될 수 있는 상황.

따라서 플랫폼에서는 해당 요구사항이 플랫폼의 역할에 맞는지 잘 판단해야 한다.

그렇지 않으면 플랫폼적인 성격을 잃어버리고, 특정 요구사항에 치우친 서비스가 되어버리기 때문.

 

 

예를 들겠다.

어떠한 쿠폰 관리 시스템이 있다고 하자.

여기에는 N원 쿠폰, M% 할인쿠폰을 만드는 기능이 있다.

당연히 쿠폰 사용 가능한지에 대한 검증들도 포함이 되어 있다. 사용자는 4,000원을 주문하는데, 쿠폰 할인금액이 5,000원이면 쓸 수 없을테니. (주문금액을 넘는 할인금액이면 0원으로 만들어서 사용가능하게 할 수도 있겠다. 이 예시에선 그냥 이런 정책이라고 가정하자.)

 

이 시스템에 신기능을 추가해야한다. '신규고객일때만 쿠폰을 쓸 수 있게 하는 기능을 추가하고 싶어요!' 라는 요구사항이 추가됐다고 하자.

당연히 이 쿠폰이 사용가능한지 검증을 해야되므로, 해당 쿠폰 사용 시에 신규고객 검증을 해야 한다.

이럴 때 구현 방법은 여러가지가 있다.

 

• 1. 쿠폰시스템에서 고객의 주문이력을 관리 (DB에 저장). 외부 시스템(ex. 회원시스템, 주문시스템 등) 미호출.
• 2. 쿠폰시스템에서 외부 시스템(ex. 회원시스템, 주문시스템 등)을 호출하여 결과값을 받는다. 

 

사람마다 생각이 다르겠지만, 난 2번이 맞다고 본다.

1번의 경우는 쿠폰시스템에서 주문 데이터를 관리하게 된다고 생각한다. 이는 쿠폰시스템의 책임에 맞지 않다.

또, 이렇게 되면 쿠폰시스템에서는 쿠폰의 정책 뿐 아니라 주문의 정책에도 휘둘리게 될 수 있다고 생각한다.

 

만약 추가로 이런 요구사항이 올 수도 있다.

 

'0번 주문한 회원은 신규고객, 3번 이상 주문한 회원은 VIP, 1달 이내 10번 이상 주문한 회원은 VVIP로 관리해서 이때마다 매달 쿠폰을 뿌려주세요.'

 

 

이러한 경우, 주문이력 테이블에 추가로 컬럼을 따거나 별도 테이블을 생성해야될 수 있다.

또한 정책도 추가로 가지게 되고, 히스토리도 많아진다.

따라서 나는 이러한 주문 데이터 및 정책은 주문팀에서, 쿠폰은 쿠폰에만 집중해야된다고 생각한다.

 

어쩌면 내가 플랫폼 도메인에서 근무하고 있어서 그럴수도 있다.

아마 서비스, 예를 들면 전시 도메인에서 근무하는 사람이라면 '플랫폼에서는 왜 매번 안된다는거야?', '신규쿠폰이니까 신규에 대한 데이터는 쿠폰에서 관리해야지' 라고 생각할 수도 있겠다. (실제로 몇번 보기도 했고.)

내가 아직 플랫폼 외의 도메인에서 근무를 안해봐서 그럴수도 있겠다는 생각도 든다.

---

하지만 플랫폼이 무조건 정답은 아니라고 생각이 든다.

플랫폼 특성 상, 플랫폼에 맞는 데이터/정책만을 가지고 있게 된다.

그리고 그 외의 데이터는 가지지 않게 되고, 그 외의 정책은 이해하지 못한다. (옳지 않다는 건 아니다. 관심사가 확실하게 분리된 것이니 오히려 플랫폼적 관점에선 좋다.)

 

따라서 I/O 비용이 커지게 된다. 

원하는 데이터를 가져오기 위해 생각보다 소통 비용이 매우 커진다. 플랫폼이 작게 나눠져 있을수록 더더욱.

아무래도 서로 자기 데이터가 아니라고 할테니 소통비용도 커지고, 데이터를 조합해야되는 케이스라면 호출 i/o를 여러 번 겪어서 api 성능도 느려질 것이다.

유관부서마다 어떠한 데이터를 다 다른 Key값으로 가지고 있어서 컨버팅이 필요할 수도 있다. 그런데 컨버팅하는 책임 조차 R&R을 해야된다. 이 또한 비용이다.

(글을 쉽게 쓰지를 못하겠다. 회사 프로젝트 사정을 그대로 쓰고 싶은데, 보안법에 따라 잡혀갈 것이다 ㅋㅋ. 내 능력부족으로 예시를 들지도 못하겠다.)

 

위의 단점들은 MSA의 단점이라고도 생각이 든다.

규모가 매우 큰 회사가 아니면, 오히려 MSA는 i/o비용만 늘리고 관리가 힘들 수도 있겠단 생각이 많이 든다.

---

위의 장단점이 있다보니 사실 요즘은 뭐가 정답인지 모르겠다.

플랫폼스러운 개발이 정답이라고 생각했는데, 플랫폼이 꼭 정답은 아닌 거 같다. 어렵다.

 

플랫폼은 어쩔 수 없이 '안돼요'무새가 된다.

너무 많은 것을 공통으로 처리하고 있으므로, 어떤 것이 우리의 책임이고 어떤 것이 우리의 책임이 아닌지 판단하는 것이 중요하다. 

그래서 객체지향이 중요한 것인가 싶기도 하다.

해당 플랫폼이라는 객체에, 특정 요구사항이라는 책임이 올바른 책임인지 잘 판단해야 한다.

 

너무 객체의 책임이 작으면, i/o 비용이 커진다. 

너무 객체의 책임이 크면, 내부 코드 및 관리 데이터/정책이 복잡해진다. 

 

중간을 잘 정해야되는 듯한데, 그게 참 어려운 것 같다.

---

개발 외적인 근황

11월 초에 허리디스크가 터졌다.

허리 상태가 나쁜 편은 아니다.

하지만 클라이밍, 러닝을 너무 무리하게 해서 터진 것인 듯하다.

다행히 젊고, 자세가 좋은 편이고, 평소 몸관리를 잘해서 회복력이 빠른 듯하다.

내년에는 허리디스크 터진 것이 회복이 돼서 클라이밍, 러닝 훈련을 다시 잘 하고싶다.