아키텍트로 가득 찬 팀을 만드는 ‘아키텍처 설계 워크숍’ 

안녕하세요 👋
SmartStudio HomeBuilder의 김훈민입니다.

요즘 저희 팀은 SmartStudio가 가진 웹UI 빌딩 기술을 모듈화 SDK로 열심히 진화시키고 있습니다.

모듈화 SDK를 만드는 일은 높은 수준의 아키텍처 설계 역량을 요구합니다. 크고 복잡한 한 덩어리의 UI 애플리케이션을, 최소한의 의존성을 가진 개별 모듈로 추상화를 해야합니다. 어렵습니다. 그래서 재미있습니다.

몇년 전에도 모듈화 아키텍처를 설계하는 프로젝트를 했던 적이 있습니다. 당시에는 아쉽게도 제가 기대하는 수준의 아키텍처를 만들지 못했습니다. 10명이 넘는 개발자가 하나의 코드 베이스에서 협업하는 애플리케이션을 설계하는 일이란 코드 이상의 것을 보고 만져야 하는 일이었습니다.

그때 제가 만났던 문제는 이랬습니다. 저랑 비슷한 문제 겪어보셨죠…?

• 쏟아지는 요구사항을 모두 만족시키려고 하면서 시스템의 복잡도가 너무 높아 졌다.
• 아키텍처를 논의할 때 내가 아는 설계 지식을 충분히 동료에게 설명하고 설득하지 못했다.
• 반대 의견을 가진 동료와 대립하다가 지쳐서 그때그때 적당히 일관성 없는 합의를 했다.
• 설계 규칙을 효과적으로 공유하지 못하여 규칙을 따르지 않는 코드가 시스템에 빠르게 퍼져 제어할 수 없는 지경에 이르렀다.

요구사항, 설명, 설득, 합의, 공유. 이런 단어가 눈에 들어옵니다.

복사/붙여넣기를 개발한 래리 테슬러는, ‘시스템의 총 복잡도는 항상 동일하다’고 했습니다. 요구사항은 시스템에 가하는 압력입니다. 이 압력을 견뎌야 하는 시스템은 일정 수준 이상의 복잡도를 어떤 식으로든 내부에 품어야만 합니다. 많은 요구사항을 만족시킨다는 건 그만큼의 복잡도를 시스템 안에 두겠다는 뜻입니다.

지금 와서 생각을 해보면 그때 우리가 만들려고 했던 시스템은 대단히 이상적이었습니다. 분명하지 않은 요구사항을 모두 수용하려고 했습니다. 자연스레 시스템의 복잡도가 높아졌습니다. 하지만 이 복잡도를 팀이 유기적으로 협력하여 다스리지 못했습니다. 설명하고, 설득하고, 합의하고, 효과적으로 공유하는 데에 서툴렀거든요.

팀 프로젝트를 할 때는 아키텍처를 한 사람이 독점할 수 없습니다. 공동의 규칙을 모두가 따르지 않으면 설계의 일관성이 쉽게 깨져버립니다. 깨진 일관성 사이로 파편화가 들어옵니다. 프로젝트에 참여하는 구성원이 많아질수록 파편화는 빨리 퍼집니다. 결국은 한 배를 탄 동료와 어떻게든 발을 맞춰야만 합니다.

내가 아는 걸 충분히 동료에게 설명하기는 왜 이렇게 어려울까요? 우선 남들에게 설명할 수 있을 만큼 지식을 쌓기가 쉽지 않습니다. 내가 무언가를 알고 있다해도 반대 의견을 가진 동료를 설득하는 건 또 다른 일입니다. 동료와 대립하고, 대립하다가 지쳐서 적당히 합의 했습니다. 그때의 저는 제 무의식에서 아키텍처 설계를 내가 더 잘 안다는 걸 증명하는 투쟁의 과정 쯤으로 생각했던 것 같습니다.

이번에는 다른 관점으로 접근을 해보기로 했습니다. 아키텍처를, 개인이 아닌 팀이 함께 힘을 모아 설계를 한다면 어떨까요?

이 글의 주제인 아키텍처 설계 워크숍은 이런 고민에서 태어났습니다.

개발자에서 아키텍트로

나 혼자 어찌 할 수 없는 아키텍처 설계라는 건, 구성원이 공동의 규칙을 합의하는 사회적인 활동은 아닐까요? 이런 생각에 꽂혀있던 어느 날, 제 페이스북 타임라인에서 “개발자에서 아키텍트로”라는 책이 눈에 들어왔습니다. 어떤 문제에 꽂히면 유독 꽂힌 문제와 관련된 정보가 눈에 잘 들어오는 때가… 다들 있으시죠? 😝

이 책은 아키텍처의 기술적인 측면에 집중하는 다른 책과는 다르게, 협력적 측면에서 아키텍트의 역할을 정의하고, 쉽게 따라할 수 있는 설계 방법과 커뮤니케이션 도구를 제시하는 게 특이했습니다. 아키텍처 설계가 사회적 활동이라는 제 생각은 책에서 아래의 대목을 읽는 순간 더 강렬해집니다.

“팀원 모두가 아키텍처를 설계할 수 있으면 모두가 하나의 큰 주인의식을 공유하게 됩니다. 이때부터 소프트웨어는 만들고 잊어버리는 시스템이 아니라 ‘우리의 시스템’이 됩니다. 모든 사람이 설계의 의도를 이해하고 설계의 무결성을 유지해야 할 책임감을 가지기 때문에 변경하기도 더 수월해집니다. 재작업 감소, 품질 향상, 더 효율적인 커뮤니케이션 덕분에 개발 속도도 빨라집니다.”

개발자에서 아키텍트로

이후로 저는 제 사전에, 아키텍처를 이렇게 정의하였습니다.

목표를 달성하기 위해,
주어진 환경을 고려하여(환경),
구성원이 시스템에 가하기로 합의한(사회),
기술적 제약(기술)

아키텍처 설계는 환경, 사회, 기술을 모두 다뤄야 하는 어려운 일이라는 결론에 도달했습니다. 아무리 대단한 기술이라 하더라도 다음의 문제를 해결하지 못하는 아키텍처는 잘 동작하기 어렵습니다.

• 나만 알고 있다.
• 알지만 동료에게 충분히 설명할 수 없다.
• 설명할 수는 있지만 동료가 따르게 할 수 없다.
• 따르더라도 문제를 해결하여 목표를 달성할 수 없다.

팀의 관점에서 아키텍처를 바라보고, 팀이 함께 하는 아키텍처 설계 워크플로우를 만들어보고 싶어졌습니다. 그렇게 팀에 제 생각을 공유하고 ‘아키텍처 설계 워크숍’ 설계를 시작했습니다.

‘아키텍처 설계 워크숍’을 설계하기

개발자에서 아키텍트로의 내용을 큰 틀에서 참고하되 세부 사항을 우리 팀의 사정에 맞게 조정하는 걸로 워크숍 설계를 시작했습니다. 책에서는 디자인 스튜디오 워크숍이라고 소개를 하는데, 길면 하루 정도 진행하는 단기 스프린트 성격의 팀 활동입니다. 저희가 진행한 워크숍은 디자인 스튜디오 여러 개를 밀도 높게 묶은 버전입니다.

이런 장시간 워크숍을 진행해 본 적은 저도 처음이라 워크숍을 설계하는 과정은 저한테 꽤나 도전적인 일이었습니다. 워크숍을 준비하는 일은 커뮤니케이션을 퍼실리테이션 하는 것과 같았습니다. 생각이 ‘나’ 보다는 ‘팀’에 머물 때가 많습니다. ‘어떻게 하면 팀이 의사결정을 더 잘할 수 있게 도와줄 수 있을까’를 고민하는 일이었거든요.

워크숍을 준비하면서 다음 네 가지를 고민하고 결정했습니다.

• 참여 범위: 누가 참여를 해야하는가?
• 사용할 예산: 시간을 얼마나 써야 하는가?
• 워크숍 목차: 어떤 프로그램을 하면 좋을까?
• 상세 프로그램: 효과적으로 논의를 이끌려면?

참여 범위

구성원 모두가 참여하는 걸로 제안을 했습니다. 의사결정 속도 보다는 실행의 효과에 집중해야 할 시기라고 판단했습니다. 아키텍처는 구성원이 따라야 하는 규칙인데 일부가 밀실에서 규칙을 만들고 “이제 우리 모두 이걸 따르자!”라고 선언하는 방식은 합의가 제대로 지켜질 가능성을 낮춥니다. 규칙의 의미를 이해하지 못하고 그저 따라가기에 급급하면 변화에 대응하기도 어렵겠죠. 규칙이 있다는 걸 몰라서 따를 수 없다면 그건 더 문제일테고요.

아키텍처는 변하기 마련입니다. 프로젝트 초기에 모든 정보를 다 알 수가 없거든요. 나중에 결정되는 사안도 있고, 환경이 변하기도 하고, 경험을 하면서 몰랐던 것을 알게 되기도 합니다. 프로젝트를 진행하면서 많은 변화를 만나며 아키텍처가 바뀌고 깎이고 변할텐데, 그럴 때 규칙이 존재하는 이유를 구성원들이 어느 정도는 이해하고 있어야 대응하기가 수월하겠죠.

사실 멤버 모두가 참여하는 이런 회의 방식은 효율이 좋지 않습니다. 각자의 지식수준이 달라서 모두가 같은 수준으로 시스템을 이해하고 의견을 제시하기도 어렵습니다. 미팅에 참여하는 인원이 많으면 커뮤니케이션 비용도 높아집니다. 그럼에도 모두가 소중하게 여겨야 할 큰 합의는, ‘함께’ 결정하는 게 효과적일 수 있다고 생각했습니다.

그래서 비효율을 감수하기로 했습니다. 멤버가 8명이라 부담이 조금 덜 했던 건 다행입니다. 인원이 더 많았다면 깊게 고민했을거에요.

사용할 예산

여기에서 예산은 이 워크숍에 ‘투자할 시간’을 뜻합니다. 전체 프로젝트 예상 기간인 5개월의 20%인 1개월을 최대 예산으로 잡았습니다. 이 지점은 ‘개발자에서 아키텍트로’에서 인용한 배리 베임(Barry Boehm)의 논문에 실린 그래프에서 힌트를 얻었습니다.

배리 베임은 자신의 논문 “Architecting: How Much and When?”에서 프로젝트 스케줄을 ‘아키텍처 설계 및 위험 제거 시간’ + ‘개발 시간’ + ‘재작업 시간’의 합으로 정의를 합니다. 그러면서 아키텍처 설계에 들어가는 총량과 재작업 시간이 상관 관계가 있다며 아래의 그래프를 근거로 제시합니다.

이 그래프는, 프로젝트 초기에 아키텍처 설계에 시간을 많이 쓰면 재작업 시간을 줄일 수 있지만, 재작업 시간이 무한정 줄어드는 건 아니며 임계점이 있다는 걸 보여줍니다. 또한 코드량이 많을수록 초기 아키텍처 설계에 투자하는 시간이 효과가 크다고 합니다. 참고로 이 그래프에서 KSLOC는 1,000줄의 코드를 의미합니다. 그래프에서 검은색 원(Sweet Spot)이 최적 지점입니다. KSLOC가 100일 때 최적 지점이 20 ~ 25% 어딘 가에 있습니다. 이걸 참고해서 전체 일정의 20%를 초기 설계 기간으로 잡았습니다.

이 논문의 결론을 얼마나 신뢰해야 할지는 모르겠으나, 제가 더 나은 기준을 제시할 지식도 없으니 ‘완벽한 정답’ 보다는 ‘괜찮아 보이는 제안’을 ‘적당히’ 따르기로 했습니다.

참고로 1개월을 예산으로 잡았는데 실제 논의에 사용한 기간은 3주 정도였고, 워크숍 이후 기술 리서치, 검증 등에 2주 정도를 더 사용했습니다. 계획이 다 그렇죠…?

워크숍 목차

이제 워크숍의 목차를 구성해야 합니다. 제가 TDD를 좋아하는데, 요즘은 일상에 TDD를 접목하는 시도를 해보고 있습니다. 이 워크숍 끝에 우리 팀이 얻기를 바라는 걸 간단히 적어 보았습니다.

• 아키텍처 의사결정을 할 때 판단 기준이 될 일반 설계 원칙
• 레거시에서 개선해야 할 부분에 대한 공감대 형성
• 구성원이 공감하고 헌신할 수 있으며 경계가 분명한 비즈니스 목표
• 아키텍처 설계를 평가할 수 있는 기준
• 개발할 때 참고할 수 있는 아키텍처 시각화 자료

이 기대를 충족시켜 줄 프로그램을 기대 옆에 적었습니다.

• 아키텍처 의사결정을 할 때 판단 기준이 될 일반 설계 원칙 → 팀 설계 원칙 수립
• 레거시에서 개선해야 할 부분에 대한 공감대 형성 → 레거시 회고
• 구성원이 공감하고 헌신할 수 있으며 경계가 분명한 비즈니스 목표 → 핵심 설계 요구사항 정의하기
• 아키텍처 설계를 평가할 수 있는 기준 → 핵심 설계 요구사항 정의하기
• 개발할 때 참고할 수 있는 아키텍처 시각화 자료 → 아키텍처 설계하기(시각화)

추상적인 이야기에서 구체적인 이야기로 나아가게 프로그램을 나열했습니다. 큰 그림을 먼저 맞춰야 각론에서 세부 사항을 조율하기가 좋을테니까요.

여기에 더해서 장시간의 워크숍을 진행하기 전에 몸 풀기 차원에서, 아이스 브레이킹을 추가했습니다. 아이스 브레이킹을 할 때 주제가 없으면 진행을 하기가 쉽지 않습니다. 화상 미팅을 할 때는 사운드가 비면 적막해지는 경우가 많아서 더 세심하게 설계를 해야했습니다. 그래서 우리가 풀어야 할 문제에 대한 기대를 가볍게 이야기하는 걸로 아이스 브레이킹 시간을 구성했습니다. 이렇게 최종 목차가 만들어졌습니다.

• 아이스 브레이킹 – 좋은 SDK란 무엇인가?
• 팀 설계 원칙 수립
• 레거시 회고
• 핵심 설계 요구사항 정의하기
• 아키텍처 설계하기

상세 프로그램

회의는 몸과 마음의 에너지를 뺏어 갑니다. 원격 회의는… 말도 마세요. 다들 에너지 빨려 보셨죠? 빈 방에서 모니터를 보며 혼자 떠드는 게 쉬운 일이 아닙니다. 또한 당시에 팀은 신규 프로젝트 외에 다른 운영 업무를 병행하고 있었습니다. 한 달이라는 시간을 100% 온전히 워크숍에 사용할 수 없는 상황이었습니다. 효과적으로 일정을 관리해야 했습니다.

고민 끝에 회의를 모듈화 하기로 했습니다. 주제별로 회의를 나눠서 일정을 쪼개고, 한 번의 논의는 최대 2시간을 넘지 않으며, 하루에 회의를 최대 4시간 초과로 하지 않도록 일정을 짰습니다.

그리고 일정을 만들면서 사전 회의록을 하나씩 만들었습니다. 처음에는 참석자들에게 필요한 정보를 주고, 회의 중에는 회의록으로 쓰려고 사전 회의록을 만들었습니다. 그런데 회의록을 작성하는 과정에서 제가 더 많은 걸 얻는 재미있는 경험을 했습니다. 인수 조건을 적어보는 것과 비슷한 효과랄까?

저는 사전 회의록을 작성하는 걸 회의를 TDD 한다고 표현합니다. 사전 회의록을 쓰면 회의를 머리 속에서 시뮬레이션 해볼 수 있습니다. 사전 회의록 작성은 회의에 참여할 사람, 논의 주제, 결론에 도달할 방법, 결론에 도달하기 위해 알아야 할 정보 등을 미리 생각해보게 만드는 힘이 있었습니다. 워크숍 이후로 저희 팀은 사전 회의록을 애용하고 있습니다.

회의록을 쓰면서 자연스레 논의를 어떤 포맷으로 진행할지 고민했습니다. 특히 아키텍처를 공동으로 설계하려면 사용할 도구가 있어야 했습니다. 코드가 없는 상황에서 상위 수준의 아키텍처 설계를 이야기 할 때는 추상적인 생각이 오고가곤 합니다. 추상적인 생각은 배경을 잘 모르는 동료에게 쉽게 전달이 안 될 때가 많습니다. 같은 그림을 그렸다고 생각했는데, 돌아서면 서로 다른 생각하고 있는 경우 많이 겪어보셨죠? 재택 근무가 이어지던 상황이었기에 온라인에서 이 문제를 해결해야 했습니다. Miro 같은 동시 편집을 지원하는 시각화 도구를 적극 이용하기로 했습니다.

Miro는 도형과 선을 이용해서 추상적인 생각을 시각적으로 간단하게 표현할 때 쓰기 좋습니다. 잘 나가는 Figma의 동생인 FigJam도 있습니다. 저는 Miro를 선호합니다. 도형을 연결하는 UX를 Miro가 좀 더 잘 푼 것 같아서요.

워크숍 진행하기

모든 준비를 마쳤습니다. 이제 본격적으로 워크숍을 진행한 이야기로 들어갑니다.

아이스 브레이킹 – 좋은 SDK란 무엇일까?

먼저 워크숍 동안에 참석자가 지켜야 할 간단한 회의 규칙을 정하는 걸로 미팅을 시작했습니다. 그리고 돌아가면서 각자가 생각하는 좋은 SDK의 조건을 가볍게 이야기 했습니다. 모두가 한 번씩은 입을 열게 하는 게 목적입니다. 화상 회의는 사운드가 쉽게 겹치기 때문에 사람들이 발언권을 가질 때 눈치를 훨씬 많이 보거든요. 화상 회의는 소극적인 사람을 더 소극적으로 만듭니다.

여기에서 나온 이야기를 종합해보니 우리가 바라보는 좋은 SDK의 조건은 이랬습니다.

1. 우리가 개발하기 편해야 한다.
2. 사용하기 쉽고 커스텀 하기도 쉬워야 한다.
3. 커스텀 할 수 있는 영역과 아닌 영역을 구분하는 정책이 명확해야 한다.
4. 버그가 적고 에러가 발생해도 계속 안정적으로 사용할 수 있어야 한다.
5. 친절하고 예제가 풍부하며 관리가 잘 되는 문서와 API를 제공해야 한다.
6. 고객이 문제가 발생했을때 원인을 쉽게 찾고 해결할 수 있어야 한다.
7. 업데이트 사이클을 안정적으로 운용할 수 있어야 한다.

지금은 도덕책에 나올법한 이야기지만 워크숍이 끝날 무렵에는 구체적이고 실천적인 내용으로 변해있을거에요.

팀 설계 원칙 수립

다음은 설계 논의를 하다가 의견이 대립할 때 우리가 기준으로 삼아야 할 설계 원칙을 만들었습니다. 설계 원칙은 지금 다시 봐도 우리 팀이 지향하는 엔지니어링 문화를 잘 보여줍니다.

개발자는 경험을 쌓으며 자신의 개발 철학을 만들어갑니다. 그리고 철학에 맞춰 선호가 생깁니다 이 말은 개인의 철학과 선호가 상당 부분 개인의 경험에 의존한다는 뜻입니다.

그렇다면 서로 다른 철학과 선호가 모인 팀은 어떤 가치를 지향해야 할까요? 이 시간은 이 문제를 논의하는 자리였습니다. 더군다나 저희는 신생팀이기 때문에 이런 이야기를 한 번 쯤 해보고 싶었습니다. 서로 다른 우리가 팀이라는 울타리 안에서, 어떤 가치를 향해 하나가 되어야 하는지를 토론하고, 합의하고, 문서로 남겼습니다. 이야기를 하는 것만으로도 서로의 생각이 많이 섞이는 느낌을 받을 수 있었습니다.

레거시 회고

앞으로 진행할 프로젝트가 과거를 개선하는 일이기에 과거를 돌아보지 않을 수 없겠죠? 추상적 문제 정의에서 우리가 세운 7가지 가치를 기준으로 레거시를 회고했습니다. 레거시를 회고 할 때는, 레거시에 기여한 동료가 상처를 받지 않도록 섬세해야 합니다. 회고를 하기 전에, 동료에게 이것이 ‘누군가를 질타’하는 과정이 아닌, ‘더 나아지기’ 위한 과정임을 충분히 설명하려고 노력했습니다.

보통 회고 끝에 액션 플랜을 도출하는데, 이 시간에는 액션 플랜을 만들지 않았습니다. 대신에 가져갈 것, 놓을 것, 새로 받아들일 것에 대한 공감대를 만드는 데에만 집중했습니다. 해결책을 만들어야 한다는 압박을 주고 싶지 않았고, 해결책으로 화제가 넘어가버리면 이야기가 너무 길어질 것 같았거든요. 어차피 문제를 개선하는 아키텍처를 함께 설계하는 시간이 뒤에 있기도 했고요.

핵심 설계 요구사항 만들기

이제 아키텍처 설계에 들어가기 전에 핵심 설계 요구사항을 만들 시간입니다. 이 세션은 요구사항과 아키텍처 사이의 연결 고리를 만드는 아주 중요한 의미를 가진 활동입니다. 앞에서 요구사항을 제대로 통제하지 못한 제 과거를 반성했던 걸 기억하실까요? 요구사항이 문제라면 아키텍처는 해결책입니다. 둘은 한 쌍이에요. 그래서 아키텍처 설계는 요구사항을 이해하는 일에서 시작해야 합니다.

프로그램을 문제를 정의한 후에 해결책을 고민하는 흐름으로 자연스럽게 구성 했습니다. ‘핵심 설계 요구사항’이라는 문서의 목차만 미리 적어서 화면에 공유하고, 논의를 하며 내용을 하나씩 채워가는 방식으로 진행하며 실시간으로 문서를 함께 만들었습니다.

1. 아키텍처의 목적과 범위: 해결해야 하는 문제와 범위는 어디까지인가?
2. 사용자 범위: 우리의 고객은 누구인가?
3. 비즈니스 콘텍스트
   • 비즈니스 목표: 이 프로젝트 끝에 우리는 어떤 비즈니스 가치를 만들어야 하는가?
   • 이해 관계자: 이 프로젝트와 누구와 연관되어 있으며 우리가 집중해야 할 대상은 누구인가?
4. 아키텍처 핵심 요구사항
   • 기술적인 제약: 우리가 바꿀 수 없는 기술적인 제약은 무엇인가?
   • 비즈니스 제약: 우리가 바꿀 수 없는 비즈니스 제약은 무엇인가?
   • 품질 속성 요구사항: 아키텍처가 달성해야 할 품질 목표는 무엇이며, 어떤 기준으로 평가할 것인가?

엔지니어만 모인 팀이 비즈니스 콘텍스트를 정리하는 게 어려울 수 있습니다. 저희는 다행히 이 워크숍을 하기 전에 팀 KPI를 정리하는 시간이 있었던터라 이 과정을 수월하게 넘겼습니다.

논의 끝에 만들어진 핵심 설계 요구사항의 ‘품질 속성 요구사항’에는 아래 그림에서 보이는 것처럼 생긴 품질 검증 시나리오가 담겨 있습니다.

각각의 시나리오를 해결하는 설계 아이템을 모으면, 하나의 백로그가 탄생합니다. 이 백로그는 다음 시간에 우리가 풀어야 할, 시스템 디자인 문제 모음입니다.

아키텍처 설계

문제집을 만들었으니 이제 문제를 풀어야겠죠? 앞의 모든 과정은 이 단계를 위해서 존재하는 빌드업입니다. 이 시간은 Miro를 이용해서 아키텍처를 같이 그리며 토의하는 방식으로 진행했습니다.

구성원 사이에 지식 격차가 존재하기 때문에 이런 논의를 할 때는 일부에게 발언권이 집중되는 경우는 흔합니다. 특히 화상 미팅을 할 때는 오디오가 겹치는 걸 피하려다보면 대화 중에 끼어들기가 쉽지 않습니다.

이럴 때 주제를 주고 각자 아키텍처를 설계한 후에 팀에 공유하고 의견을 교환하는 방식을 섞어서 사용하면 좋았습니다. 이 방식은 관점의 차이를 뚜렷하게 보여주는 게 재미있었습니다. 서로의 그림을 비교하면서 내가 놓친 부분을 알 수 있고, 동료가 놓친 부분을 보면서 어느 부분을 우리가 더 학습해야 하는지 파악할 수 있습니다.

워크숍의 끝에 우리 팀은 이런 값진 아키텍처 카탈로그를 얻었습니다.

워크숍 회고

긴 설계 워크숍을 모두 마무리했습니다. 하지만 아키텍처 설계는, 사실 이제 시작입니다. 그림이 코드가 되고, 제품이 되는 건 아니니까요. 개발하면서 설계 가설을 검증하고, 고치고, 다시 검증하기를 반복할 겁니다. 제품이 멈추지 않는 이상 소프트웨어 아키텍처는 완성이 없습니다. 워크숍 이후의 과정도 잘 끌어가야 합니다. 그러려면 워크숍 경험이 어땠는지, 냉정하게 돌아볼 수 있어야겠죠?

워크숍에 참여한 동료를 소규모 그룹(1~2명)으로 만나서 가볍게 스몰토크 형식으로 피드백을 주고 받았습니다. 대화 그룹이 작을 때 좀 더 진솔한 이야기가 나올 것 같아서요. 대체로 아키텍처 설계를, 팀 단위로 해본 경험이 없었기 때문에 프로그램 자체를 즐거워했습니다. 물론 좋기만 하지는 않았겠죠. 몇 가지 다음에 개선하면 좋을 아이디어도 들을 수 있었습니다.

좋았던 점

• 우선 팀과 개인의 목표를 다시 한 번 맞출 수 있었습니다. 개발자가 코드에 몰입하다 보면 비즈니스 목표를 잊어버리고 자신의 기술적 성취만 좇기 쉽습니다. 그러다보면 팀이 자원을 효과적으로 쓰지 못하는 상태에 빠지곤 하는데, 설계 워크숍은 이걸 방지하는 효과가 있었습니다.
• 요구사항에 잘 맞춰진 아키텍처 의사결정 기준은, 의견이 부딪힐 때 합의를 이끌어내는 효과적인 기준으로 작용했습니다.
• 추상적인 아키텍처에 대한 생각을 시각화 할 수 있었습니다. 이후 프로젝트 진행 과정에서 좋은 설계 나침반 역할을 하고 있습니다. 물론 다이어그램을 코드로 변환해가는 과정에서 아키텍처가 과거의 기대와 다른 부분을 만나며 부딪히고 깎이고 있지만, 우리 팀은 아키텍처 카탈로그를 정보 공유 수단으로 잘 활용하고 있습니다.
• 더해서 우리가 ‘함께 했다’는 성취감을 얻었고, 이 과정에서 소속감을 느낄 수 있었습니다. 원격 근무 환경은 개인을 고립시키기 쉽습니다. 우리가 팀으로 시너지를 내려면 어떤 경험에 신경을 써야하는지 힌트를 얻었습니다. 할 수 있다는 자신감을 얻었다는 것도 아주 큰 소득입니다.

아쉬웠던 점

• 이해 수준과 개인 성향 차이 등으로 인해 논의를 할 때 일부에게 발언권이 집중되는 상황은 여전히 해결하고 싶은 문제입니다. 워크숍으로 팀 활동에 자신감을 얻었으니 다음에는 다양한 활동을 도입해서 이 문제를 해결해보면 좋겠습니다.
• 아키텍처를 시각화 하는 수준에서 더 나아가, 불확실성이 큰 아키텍처 제안은 간단하게 프로토타입을 만들며 검증하는 시간을 가지면 더 좋았을 것 같습니다. 논의는 좀 더 길어지겠지만 현실의 리스크를 빨리 찾아내는 것도 중요하니까요.

목표는 달성했을까?

워크숍에서 얻은 핵심 설계 요구사항과 아키텍처 카탈로그를 가지고, 아키텍처를 계속 다듬어가며 진화시켜 나가고 있습니다. 성장하는 요구사항과 함께 아키텍처도 성장합니다. 그럴때마다 우리가 워크숍에서 쌓은 경험과 만든 결과물이 새로운 변화를 소화하는 동력으로 작용한다는 걸 느낍니다.

프로젝트는 순항하고 있습니다. 하지만 순항하고 있다는 걸 ‘성공’이라고 평가할 수는 없겠죠. 8월에는, 워크숍에서 정리한 아키텍처 품질 속성 기준을 가지고 아키텍처를 평가하는 팀 활동을 하려고 합니다. 우리의 위치를 확인할 수 있을 거라 기대합니다.

그때는 또 다른, 좀 더 기술적인 이야기를 공유 드릴 수 있을 것 같네요.

감사합니다.