느슨한 설계시점 결합은 어떻게 구현하나?
MSA 기술과 적용 연구 6
느슨한 설계시점 결합은 어떻게 구현할 수 있을까요? 느슨한 설계시점 결합이란 표현은 잠시 잊고 이글의 모태가 된 Chris Richardson의 글로 가봅니다.
서비스는 빙산의 일각처럼
그의 글에 있는 상징적인 그림을 인용합니다. 제목은 빙하(iceberg)이고 노출을 최소화 하라고 말합니다. API로 노출된 부분은 다른 사람이 사용하기 시작하면 마음대로 고칠 수 없습니다. 그래서 가급적 최소한을 노출해야 합니다. 빙산을 메타포로 사용한 이유가 여기에 있죠.
발행(Published)한 인터페이스 문제에 대해서는 무려 2003년에 Martin Fowler가 설명한 바 있습니다.
두 번째로 그림을 보면 인터페이스와 구현을 분리합니다. 개발자 중에 스프링(Spring) 사용자들은 기계적으로 하는 일이기도 합니다. 흔히 클라이언트가 상세한 내용을 모르고 써도 되도록 인터페이스를 쓴다고 하지만, 다른 시각으로 말하면 클라이언트와 무관하게 내 마음대로 구현하게 해주기도 합니다. 안전한 수정이 가능해집니다. 안전한 수정이란 말은 <소프트웨어 응집력(cohesion)은 무언가?>편을 떠올리며 쓴 글입니다. 여기까지 쓰면서 제가 깨달은 내용을 한 문장으로 써보겠습니다.
소프트웨어의 응집력은 개발자에게 안전한 수정을 가능하게 해줍니다.
여러분의 이해도에 따라 느끼는 바는 다르겠지만, 일단 소프트웨어 응집력이 해주는 효과를 알 수 있습니다. 그것은 우리의 일상에 영향을 줍니다. 여러분이 개발자거나 개발자와 하루를 보내는 사람이라면 여러분의 삶의 질과 소프트웨어의 응집력은 상당한 관계가 있습니다.
반드시 일주일 단위로 개발하기
자, 이제 여러분의 공감을 끌어올리기 위해 제가 경험한 이야기들을 이야기하겠습니다. 제 경험 중에서 Chris Richardson의 글이 공명을 일으키게 한 경험들을 말하겠습니다. 제가 북경에 상주하던 2016년부터 대략 1년 반동안 해온 일을 동료 CTO님이 쓴 글이 있습니다. <Micro Service, Docker로 할 수 밖에 없었던 사연>인데요. 다른 사람이 옆에서 관찰하여 쓴 글이니만큼 객관적 시각이라고 할 수 있죠. 여기에 드러난 사건을 배경으로 제가 어떻게 소프트웨어 응집력을 만들어냈는지 설명해보겠습니다.
당시 저는 역할을 규정하지 않았지만, PO(Product Owner)에 가깝게 일했다고 할 수 있습니다. 제가 개발팀에게 제시한 원칙은 하나뿐 이었습니다. 개발팀은 전체를 한 팀으로 하고, 매주 금요일은 다음 주에 무엇을 개발할지 논의하고 이번 주에 만든 결과를 함께 본다는 것이죠.
그간 자신들의 습성으로 인해서 다양한 방식으로 절충을 하려고 했습니다. 하지만, 저는 원칙을 어길 수 없다고 말했습니다. 한 개발자가 대단히 중요한 문제라는 표정으로 찾아와서 큐(Queue) 제품을 어떤 것을 골라야 하는지 상의하자고 했습니다. 저는 잠시도 망설이지 않고, 그 친구에게 했던 말을 지금도 기억합니다. 제가 생각해도 너무나 멋진 말이었으니까요.
지금 당장 설치할 수 있는 것으로 하세요.
직업 일상에서 소화할 수 있는 방법으로 기술을 선택하라
당시 저는 서울에서 겪은 내상을 마음에 간직하고 있었습니다. 제가 오랫동안 해온 방법으로는 지속가능한 시스템을 만들 수 없다는 것이었죠. 자책일 수도 있지만, 돌아보니 무의식적으로 그 문제를 풀고 있었던 듯합니다. 제가 알고 있는 모든 것을 버리고서라도 풀고 싶은 문제였을까요? 그런지 어떤지 알 수 없습니다.
다만, 그때부터 갖고 있던 문제으식 덕에 당시에는 문구로 표현하지 못했던 아래 문장을 생각하게 되었습니다.
소프트웨어의 응집력은 개발자에게 안전한 수정을 가능하게 해줍니다.
이 말을 내뱉자마자 '아하' 하게 되었습니다. 제가 왜 일주일단위 개발을 중요하게 생각했는지 깨달았습니다. 당시에는 말로 설명할 수는 없었고, 그런 확신만 있었습니다. 6년이나 지난 지금에야 이렇게 문장으로 정의할 수 있습니다.
직업 일상에서 소화할 수 있는 방법으로 기술을 선택하라
아무리 좋은 방법과 기술도 일상에서 써먹을 수 없다면 소용없습니다. 일주일 제약은 결국 새로운 기술에 대한 호기심에 빠져 시간을 허비하는 개발자들의 습관을 바꿔주었습니다. 그리고 우아한 방법 대신에 결과를 낼 수 있는 방법에 초점을 두는 방식으로 모두의 합의를 얻어가는 여정이었습니다. 게다가 꼭 사용하고 싶은 기술이 있다면 일주일 단위가 만들어내는 흐름속에 적용할 수 있도록 개발자들을 자극했습니다.
지속 가능한 삶에서 나오는 지속 가능한 소프트웨어
이쯤되니 난해한 글쓰기로 스스로를 몰아부친 효과가 나오는 듯합니다. 응집력을 프로그래밍 문제로 국한해서 풀려하면 답이 없다는 사실을 이제야 깨닫습니다. 그에 대해서는 다음에 또 다루겠습니다. 하지만, 여기서 강조하고 싶은 것은 소프트웨어 자체의 응집력에 초점을 맞추는 대신에 우리가 일하는 모양을 안전하게 만들면 다시 말해서 지속 가능한 방식으로 일을 하다 보면 응집력을 갖추는 방법은 자연스럽게 찾을 수 있다는 점입니다.
지난 주에 개발 경험이 많지 않은 제 동료 한분도 내보내고(Published) 나니 수정이 너무 어렵더라고 토로한 일이 있습니다. 누구나 해보면 쉽게 감각할 수 있다는 사실이죠. 이론이나 기술이 도움을 주는 부분은 개인의 경험과 직업 일상이 지켜지는 전제 하에서 가능하다 생각합니다.
나아가 제 경험을 객관화 했던 CTO님의 글의 골자를 살펴보겠습니다.
신규 사업에 대한 도전! 그러나 개발 조직은?
설계는 커녕 개발도 어렵다.
어쩔 수 없는 선택
다시 개발하기
애자일이 일상으로
저는 위 내용을 훑어 보며 확신합니다. 어쩔 수 없는 선택은 바로 일주일 단위로 개발하기 위해 해야 했던 선택을 말합니다. 세상이 변하는 것과 우리의 역량이 하루 아침에 늘어나지 않는다는 사실을 모두가 알고 있습니다. 그렇다면 그 일상 안에서 우리가 일하는 방식을 바꿔 살아남을 수 있도록 해야 합니다. 그렇게 하다 보면 다시 개발하고 또 다시 개발해야 합니다. 왜냐하면 우리가 과거에 하던 방식에서 벗어나기 위한 방법을 모르기 때문에 하는 시행착오입니다. 그리고 새롭게 깨달아서 지속할 수 있는 코드로 바꾸기 위해서죠. 결국 인간은 지속 가능한 방법을 찾을 수 있습니다.
서비스는 빙산의 일각처럼
멋진 표현입니다. 그런데 빙산의 사이즈와 최소라는 감각은 어떻게 개발할 수 있을까요? 제 경험을 꺼내 설명하려고 했던 것은 바로 개발자들이 함께 어울려 협업을 하는 가운데에 찾을 수 있다는 점입니다. 서비스라는 것이 자연의 산물이 아니고 인간의 상호작용 가운데 만들어집니다. 그렇기 때문에 실험실 같은 공간에서 정의하는 방식보다는 실제 운영환경에서 협업 과정에서 난제를 풀다 보면 적절한 덩어리가 보입니다. 그리고 부대끼며 갈등하는 지점을 풀기 위해 노력하다보면 최소 노출이라는 의미도 이해할 수 있죠. 물론, 시행착오를 통해 배우는 것이니 마법을 말하는 것은 아닙니다.
MSA 기술과 적용 연구 시리즈
