개념과 실제의 간극을 메우는 기술적 직무
베터코드 인사이트의 시작 21편
황호성 님과 링크드인에서 '재사용'에 대해 댓글을 나눈 것이 대면 논의로 이어지고, 여기서 배운 사항들을 기록으로 남깁니다.
OOAD와 OOP의 간극
황호성 님이 재사용에 대해 관심을 갖게 된 계기는 최근에 인터뷰에서 질문을 받았기 때문이라고 합니다. 링크드인 대화 중에는 몰랐던 배경의 맥락을 알게 되면서 이야기는 다른 방향으로 흘러갑니다. 이렇게 맥락을 잘 잡아야 대화가 의미있는 소통으로 작동한다는 점을 강조하기 위해 <성공적 대화를 돕는 그림>을 소환합니다.
이번 대화에서는 호성 님이 먼저 배경을 공유해 주어서 대화가 수월했습니다. 그렇게 맥락을 맞춘 후에 이어진 대화에서 저는 객체지향 분석 설계(OOAD) 수준의 이야기와 객체지향 프로그래밍(OOP)에서의 '재사용'은 매우 다르다고 주장했습니다.
설계 과정에서는 흔히 '개념' 수준에서 재사용을 논합니다. 반면에 프로그래밍은 궁극적으로 '일대일 대응'이 가능해야 합니다. 실제 컴퓨터에 의해 구동될 수 있어야 하니까요. 그래서, '재사용'이 제한적이고 구체적인 제약을 따른 경우에야 가능합니다. 그런데 많은 사람들은 흔하게 이 둘에 대해 분명하게 정의하지 않고 섞어서 말을 하는 경향이 있음을 제기했던 것입니다.
어떤 상품을 말하는가?
예전에 이커머스 관련 시스템 개선을 할 때, 사람들이 각자 자기 위치에서 '상품'을 말하던 모습을 기억합니다. 예를 들어 '상품'에 어떤 수정이 필요하다고 말하면, 개발자는 정확하게 어떤 변화가 있어야 하는지 자기 업무와 알고 있는 범주에서 느슨하게 추정하고는 합니다. 그러다가 갑자기 질문을 하면, 그 개발자는 당연히 알 것이라고 전제한 배경 지식이 기획자에게 없어서 대화가 이뤄지지 않습니다. 이때, 옆에 있던 누군가가 자기가 아는 범위에서 의견을 내고, 그렇게 되면 서로 이해는 난항으로 빠졌던 일을 자주 목격했습니다.
그도 그럴 것이 그 시스템의 경우 상품 기본 테이블이 150개 칼럼을 갖고 있는데, 실제로 화면에 보여서 '상품'이라고 불리는 개념은 여러 개의 테이블의 칼럼 조합이 섞인 형태로 매우 다양하게 인지됩니다. 사실은 다수의 기획자와 개발자가 서로 구체적으로는 전혀 다른 대상을 지칭하고 싶지만, 실제 이를 표현한 말은 '상품'이라는 지극히 모호한 단어이기 때문에 회의는 늘 의문 속에서 마무리되는 장면을 목도했습니다. 결국 일은 기획자가 기획서에 데이터를 정확하게 명시한 뒤에야 진행이 될 수 있었습니다.
중국에서 일하던 시절 그러한 모호성을 줄이려고 상품이란 말을 조금 더 다양하게 바꾸려고 시도했던 흔적이 있습니다.
서울에 돌아와서도 이러한 뜻을 이어 동료와 협업을 시도한 흔적도 있습니다.
맥락과 입장에 따라 달라지는 대상 정의
'상품'이라는 대상에 대해 바라보는 입장이 여럿 있을 수 있습니다. 이를 정교하게 묘사하기 위한 개념이 있는데, BoundedContext라고 부릅니다.
다시 재사용 이야기로 돌아가서 의도나 입장이 모호한 상태로 개념을 바로 구현으로 이어가려고 한다면 모호함을 만날 수밖에 없습니다. 제가 지적한 OOAD와 OOP 사이의 간극도 그런 요소의 한 가지 예일 뿐이죠.
명시적 메커니즘 규정과 구현
내가 펼친 이야기를 듣다가 호성 님과 과거에 재사용을 화제로 관리자와 소통했던 이야기를 꺼냈습니다. 거기서도 굉장한 모호함이 있을 수밖에 없었을 것이라고 짐작할 수 있었습니다. 호성 님은 그런 부분을 해결하는 방법을 얻고 싶어 노력하는 것이라고 짐작하고, 저는 과거 경험을 꺼내 설명을 시도했습니다.
PIM이나 PSM은 지금은 잘 쓰이지 않는 표현이지만, 모호함을 제거하는 과정을 설명하는데 적합하여 인용하였습니다. 예를 들어, 상품에 관한 어떤 개선 의도를 설명하는 일을 PIM이라고 하겠습니다. 여기서 I는 Independent의 약자인데, 특정 기술에 대해 독립적이라는 뜻입니다. 프로덕트 관리자 혹은 기획자는 기술을 몰라도 이야기를 편하게 할 수 있어야 하니 그런 방법이 허용되어야 하겠죠.
그런데 구현을 하려면 기술과 결부된 판단이 필요합니다. 이를 지칭하는 것을 PSM이라고 합시다. 여기서 S는 Specific의 약자입니다. 즉, 우리 팀에서 수용할 수 있는 기술 선택지에서 PIM을 받아들이기 위해 확인해야 할 사항들이 있을 수 있습니다. 저는 이를 Mechanism(메커니즘)이라고 불러왔습니다. 그리고 비즈니스에 유리한 기술적 니즈를 충족하는 총체를 아키텍처(architecture)라고 한다면, 이러한 아키텍처를 실현할 수 있는 요소들이 메커니즘으로 표현되거나 구현될 수 있습니다. 한동안 저는 그런 일을 실무로 했던 경험이 있죠.
비즈니스 효과를 기준으로 기술적 결정을 내리기
아키텍처와 메커니즘을 다룰 때 익숙해져야 하는 필수 개념이 트레이드오프(상충관계)입니다.
기술 자체만으로는 적합한 구성에 대한 판단을 하기 어렵습니다. 그래서, 프로그래머들만 모여서 결정을 내리다 보면 주관으로 흘러가기 쉽죠. 그래서 릴리즈를 통해 시장을 배우며 진화하도록 시스템을 만들어 가는 일은 매우 중요하다 믿습니다. 여기까지 쓰고 보니 지난주에 올린 <프로덕트 매니저의 가장 어려운 역할>과도 연결이 됩니다.
프로덕트 매니저의 가장 어려운 역할은 시간, 비용, 에너지를 소비할 대상을 결정하는 것이다.
프로덕트의 구성을 기준으로 트레이드오프를 풀면 프로덕트 매니저라는 역할이 됩니다. 반면 제가 호성 님과 대화를 하며 끄집어낸 과거의 제 경험에서는 아키텍트란 표현이 떠오릅니다.
우리가 CTO나 시니어 개발자를 아키텍트라 부를 필요는 없습니다. 소프트웨어 아키텍트라는 말은 아직 충분한 공감대가 형성된 용어는 아닌 듯합니다. 게다가 아키텍트는 몸값을 높이기 위한 욕구 탓에 오염된 히스토리도 있습니다. 여기서 제가 말하는 아키텍트는 결국 기술문제에 있어 상충관계를 포착해 의사소통을 할 수 있는 사람을 뜻합니다. 그런 맥락에서 개발자가 아키텍트가 되기 위한 필요조건은 다양한 관점을 이해하는 것입니다. 사람들을 이해하고, 그들의 욕구와 이해관계 혹은 사회적 지위(역할)에서 오는 임무와 목표에 대해 공감할 수 있어야 하는 것이죠.
연이아 <프로덕트 관리의 역할과 기원은 무엇인가?>에서 인용한 그림을 떠올려 보니 프로덕트 매니저와 아키텍트 정의에 대한 차이를 발견합니다. 프로덕트 관리가 아래와 같은 삼원의 공통집합이라고 보면, 아키텍트는 UX가 빠져 있다고 볼 수 있습니다.
지난 베터코드 인사이트의 시작 연재
3. Funnel을 마케팅 말고 engagement 분석에?
5. 기술 부채는 무엇인가?
8. loosely-coupled: 빠르게 재구성하는 힘
11. 기술은 쓰임새(use case)에 따라 고르고 조합한다
13. 회사 대표가 엔지니어에게 충분한 권한을 주는가?
16. Cloud Native 승자는 집적이 가능한 개발 조직
17. CNCF는 PaaS를 대체한다
19. 다시 보는 웹 앱의 미래
