brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Mar 02. 2023

XP는 어떤 조직에서나 쓸모가 있다

함께 책 읽고 함께 이야기하기

Kent Beck의 글 <Scaling Extreme Programming: Dependencies> 중 일부를 XP 책을 함께 읽는 UseCase.Dooray 동료들에게 제공하고 토론하고 싶은 마음에 발췌하고 견해를 기록합니다. 참고로 번역은 하지 않습니다. 번역은 DeepL에게 맡기실 수 있습니다.

글은 두 부분으로 나눠집니다. 전반부는 가역성(번복)의 힘을 설명합니다. 여러분이 시행착오를 받아들일 내면의 힘을 기르신다면, 번복의 힘은 학습하는 능력으로 바뀐다고 믿습니다. 후반부는 바로 Kent Beck이 준비한 13가지 무기에 대한 설명입니다.

XP 확장하기

글 제목을 보니 XP 책 내용이 떠오릅니다. Kent Beck의 XP 책(번역서 제목 '익스트림 프로그래밍') 15장의 제목은 'XP 확장'입니다. 기록에 따르면 2021년 11월 함께 책을 읽던 지인들과 함께 XP 확장에 대한 논의를 하려고 책을 읽었습니다. '확장'을 다룰 때 개인적인 경험(다수의 임원 설득하기) 탓에 브런치에서 자주 언급했던 'Lean Budgets'에 대해 공유했더군요.

확장을 설득과 권위 확보로 모두 말할 수 없기 때문에 개인적 편향이 짙게 들어간 듯도 합니다. 분명한 사실은 더 많은 사람들을 위해 도구를 사용할 때는 부가적인 노력이 필요하기 마련입니다.

사실 15년 이상 애자일과 시행착오를 하고 익히는 과정에서 '애자일을 습관으로' 장착한 탓에 평소에 저는 애자일을 사용한다 혹은 사용하지 않는다는 식으로 생각하지 없습니다. 몸에 익어 나도 모르게 일상에서 쓰기 때문입니다.

더불어 제가 속한 조직에서도 애자일을 드러나게 쓰지 않고 자연스럽게 적용합니다. 제가 다른 사람에게 XP를 쓰라고 강요하지는 않지만, 저는 늘 쓰고 있으니까요.

매주 점검하는 순회의 힘

제 얘기는 이 정도에서 끊고 다시 Kent Beck의 기사로 돌아가 보면, 그는 가역성의 힘을 강조합니다.

Promoting reversibility

저는 그의 추가 설명이 있지 않아도 이미 XP의 힘을 믿고 있기에 그를 대신하여 가역성(reversibility)이 얼마나 큰 힘인지 간단하게 설명할 수 있습니다.

XP는 일주일이라는 자연스러운 인류의 주기(달력의 단위)를 채택하고 있습니다. 실수나 시행착오의 여파가 1주일을 넘지 않는다면 우리는 재앙을 겪을 가능성이 낮아집니다. 어쩔 수 없이 기술 부채를 남기며 고통스럽게 마무리하는 차세대 프로젝트의 분위기도 바꿀 수 있습니다.

뻔한 일에 적용하는 효과는 적을 수 있지만, 모호하고 예측하기 어려울수록 그 효과는 크다고 할 수 있습니다. 보험과 같은 것이죠.

Undo 버튼으로 더 강력해지세요

Kent Beck은 프로젝트에 Undo 버튼을 추가한다는 매력적인 비유를 합니다.

Giving you an Undo button for projects.

비유가 정말 멋지네요. 결과에 대해 어떤 평가를 받을까 봐 두려워하지 않을 수 있습니다. 조금 창피한 수준으로 막을 수 있다면 도전적인 일을 더할 수 있을까요? 이 시점에서는 Kent Beck의 대변인을 벗어나 제 의견을 내놓겠습니다.

아래는 Kent Beck 비유만큼이나 저에게 시원한 느낌을 준 만화입니다.

바위나 외계인조차 실수를 한답니다. 긴장을 풀고 시행착오를 하세요. 이 말은 독자님들과 동료들에게 하는 이야기지만 아주 오래전에 수도 없이 제가 스스로에게 했던 말입니다. 머뭇거리고 망설이던 저에게 말이죠. 오래전 일이라 기억이 가물가물한데 마침 배휘동 님이 놀라울 정도로 정교하게 쓰신 <질문하고 부탁할 때 저평가, 거절, 민폐의 두려움 이겨내기>가 있어 소개합니다. 실천가들은 참고하세요.

성취와 좌절은 늘 함께 있다

제가 과거보다 도전적이 된 후에도 저는 스스로에게 앞으로 나아가라고 말했습니다. 타이슨의 유명한 일화도 제가 앞으로 나아가는데 도움을 주었죠. 나중에 커다란 대미지 한 방에 그간 노력한 것을 다 날리지 말고 조금 창피해도 지금 나아가 보자고 스스로 독려할 때 말이죠.

그런 독려가 습관처럼 되자 이제 다른 사람들에게도 자신 있게 말할 수 있게 되었습니다. 그러고 나서 저는 아래 그림의 왼쪽의 이미지를 보며 '예전에 나도 그랬지'라고 바라보고, 오른쪽에 있는 인물의 표정이 도전을 대하는 제 자세와 비슷하다는 사실을 깨닫습니다.

그리고 바로 지난 주말에 저를 닮아 운동신경이 별로(?)인 아들이 자전거 타는 것을 지켜보며 '성취와 좌절이 늘 함께 있다'는 사실을 깨달았습니다. 그래서 시행착오(좌절) 없이 배우려는 어리석음을 피해야 합니다. 과거에 저는 그런 사람들에게 '파랑새를 찾지 마라'라고 말했습니다.

Undo 버튼을 장착하면 여러분은 확실히 더 강력해질 수 있습니다. 이제 Kent Beck의 글로 다시 돌아갈 차례네요.

애자일에 대한 나쁜 경험 지우기

이 글을 읽고 계신 분 중에서 혹시 애자일에 대한 나쁜 선입관을 가진 분이 있다면 다음 그림처럼 가짜 애자일에 속은 분들일 가능성이 높다고 봅니다. 제 주변에도 가짜 애자일에 고생한 분들의 제보가 있었으니까요.

제가 믿는 애자일은 개인 차원에서도 할 수 있는 것입니다. 가짜 애자일은 자기는 하지 않으면서 다른 사람에게 무언가 강요하는 식이 될 가능성이 높습니다.

여러분이 가짜 애자일에서 자유롭다면 Kent Beck이 제시하는 13가지 무기는 매우 유용할 듯합니다. 여러분이 애자일 즉, 난관에 부딪혔을 때 민첩하게 배워서 대응하기 위해서 메모해 두고 써먹을 만하다고 추천할 수 있습니다.

복잡성을 길들이는 13가지 무기

Kent Beck은 복잡성을 드래곤에 비유하며 이에 맞설 무기들을 나열합니다.

Here are 10 things you can do to tame the dependency head of the Complexity Dragon

1. Awareness 복잡성 지도

무엇이 문제인지 모른다면, 다시 말해 팀원들이 서로 다른 생각을 하고 있다면 모여서 지도를 그려보라고 합니다. 각종 캔버스가 등장하고, 정보를 집약하는 칸반 같은 것들이 만들어지는 이유네요. 하지만 중요한 것은 형식이나 도구가 아니고 공동의 비전을 찾는 일입니다. DDD에서 소개하는 개념 중에 Ubiquitous Language는 각종 용어에 대해서 비전과 연계시키려는 야망이 담긴 표현이라고 생각합니다. 그래서 좋아하죠. 같은 맥락으로 복잡한 개념 체계를 다룰 때 쓰이는 BoundedContext는 같은 비전을 추구한다고 할 때, 입장에 맞춰 맥락을 나누는데 쓰이는 도구죠.

2. Team improvement 현재 팀이 적절한지 검토하기

문제가 요청하는 쪽(upstream team)에 있다면 개발 팀이 노력한다고 해결할 수 없으니 팀에 대한 재검토가 필요합니다.

3. Slack 여유 공간

메시징 툴 이름이기도 하지만, 그 뜻은 아니고요. 개발자에게 일정 수준의 여유가 있어야 한다는 말입니다. 경험상으로는 자가 최적화를 위한 잉여 시간이라고 생각합니다. <여유를 만들어, 자신에게 여유를 주라>에 더 긴 설명이 있습니다.

4. Waiting 기다리기

프로젝트 Undo 버튼이 효력을 발휘하기 위해 (재앙이 아니라면) 일주일 동안은 개발자들을 비가역적으로 두고 기다리라는 말입니다. 중국에서 저는 '농부의 마음'이란 비유로 이런 종류의 기다리는 힘을 키웠습니다. 당시 인고의 시간(?)을 부르는 이름이 '개취 인정'이었는데 최근에는 '방법을 알려주기 이전에 활력부터 주어야 한다'라고 전보다 우아하게 표현할 수 있게 되었습니다. 드러커에 따르면 바로 그 '개취 인정'은 경영자의 최소 요건인 듯도 합니다.

5. Slicing. 가장 작지만 효과를 맛보는 일로 자르기

Slicing 이란 한 단어로 묘사하기 어려운 멋진 말이네요. 제가 아주 어렵게 TDD를 배운 직후 프로그래밍을 할 수 없는 처지가 되었던 적이 있습니다. 원하는 일을 하려면 코딩은 팀원에게 맡겨야 했죠. 그때 이 좋은 것(TDD)을 쓸 수 없다는 사실이 억울해서, 관리나 설계 등 제가 할 수 있는 다른 일을 하면서도 응용하는 방법을 찾아내 습관으로 만들었습니다.

저를 아는 사람들은 제가 '아기 발걸음'으로 통칭하는 그 노하우를 보신 적이 있죠.

6. Prioritizing 세밀한 우선순위 활용

우선순위 조정을 해보세요. 뻔한 이야기란 생각이 드신다면, Time-to-market을 위한 출시(Release)나 피드백 수령으로 대체하는 편이 어감을 살리는 길일 듯합니다. 제가 <구독모델과 SaaS 사업>에 썼던 내용을 공유합니다.

출시(Release) 하지 않고 많은 기능을 상상으로 만들면 그런 위험에 노출된다.

7. Duplication 약간의 중복 활용

다른 팀에 의존하고 있는 경우 꼭 필요한 부분만 직접 구현해서 독자적으로 해볼 수 있습니다. 대가는 약간의 중복을 잠시 허용해 보는 것입니다. 제가 <전략적인 마이크로 서비스 채택 방안>에서 소개한 'Strangler Fig Pattern' 패턴도 이 범주에서 넣고 볼 수 있다는 생각도 듭니다.

8. TF 활용

임시로 필요한 재능을 모은 팀인 Task Forces는 널리 쓰이는 방식이죠.

9. Visit. 직접 해보기

방문이라고 하는데, 구문의 의미는 기다리는 대신에 직접 코드를 이용해서 구현해 보라는 말로 느껴집니다. No Code/Low Code 현상을 생각해 보면 개발자가 아니라도 할 수 있는 부분이 있고, 실제로 우리 회사 동료 중에도 데이터만 있으면 SQL로 자신이 원하는 내용을 만들어내는 분이 있습니다.