1687년, 뉴턴은 사과가 떨어지는 것을 보았다. 청과상 주인도 같은 장면을 보았다. 그는 생각했다. "저 사과는 힘이 없군. 맛도 없을 거야." 뉴턴은 달랐다. 그는 사과가 아니라 왜 떨어지는가를 물었다. 그리고 중력을 발견했다.
→ 중력을 발견한다
→ 열매만 판단한다
대부분의 사람들은 중력을 무시한다. 눈에 보이지 않기 때문이다. 떨어진 사과만 본다. 떨어지게 만든 힘은 보지 못한다.
소프트웨어 품질도 같다. 납품 직전 소급 작성되는 테스트 문서, 아무도 읽지 않는 커버리지 리포트, 운영 중 터지는 장애 — 사람들은 이것들을 보고 판단한다. "개발자가 부족하다. QA가 게으르다. 팀워크가 나쁘다." 그러나 이것들은 열매일 뿐이다. 열매를 떨어뜨리는 중력 — 조직의 구조, 언어의 단절, 추적의 부재 — 은 보이지 않는다.
SOM은 그 중력을 보려는 시도에서 태어났다. 그리고 SOM Tree는, 그 중력을 눈에 보이게 만드는 도구다.
이름이 생기면 형태가 생긴다 A name gives shape
번외편 4에서 이야기했다. 이름 붙이는 순간 존재가 된다고.
SOM ID가 부여되면 LOGIN-001이라는 이름이 생기고, 그 이름 아래 기획·개발·테스트·결함·변경 이력이 모인다. 흩어져 있던 것들이 하나의 좌표로 모인다.
그런데 좌표는 숫자다. 숫자는 읽힌다. 그러나 보이지는 않는다.
SOM Tree는 그 좌표들을 시각적 형태로 피워낸다. 숫자가 나무가 된다. 이름이 열매가 된다. 관계가 가지가 된다. 역사가 뿌리가 된다.
나무라는 언어 The language of trees
왜 나무인가.
나무는 인류가 가장 오래 읽어온 생명의 형태다. 뿌리가 깊을수록 오래된 것이고, 가지가 넓을수록 풍성한 것이고, 열매가 붉을수록 건강한 것이다. 이것을 배운 적 없어도 안다.
🍎 🍎 🍎 🍎 🍎
가지 ─────────────── 가지
줄기 (trunk)
뿌리 (root system)
뿌리는 프로젝트의 기반이다. 오래되고 안정적인 Module일수록 뿌리가 깊다. 줄기는 시스템의 중심축이다. 가지는 Module이다. 그리고 열매 하나하나가 SOM ID — 각각의 Program이다.
이 나무를 한눈에 보면, 설명 없이도 알 수 있다.
열매가 말하는 것들 What the fruit tells you
열매의 색깔은 상태다.
붉은 열매가 많은 가지가 보인다면, 그 Module에 무언가 문제가 있다는 신호다. 초록 열매가 빽빽한 나무는 건강한 시스템이다. 아무도 설명하지 않아도, 나무를 보는 순간 상태가 읽힌다.
열매의 크기는 커버리지다. 큰 열매는 충분히 테스트된 Program이다. 작은 열매는 검증이 부족하다. 열매가 없는 가지는 아직 개발 중이거나 테스트되지 않은 Module이다.
열매의 위치는 우선순위다. 붉은 열매, 문제 있는 열매일수록 나무 위쪽에 배치된다. 나무를 보면 어디에 먼저 손을 써야 하는지가 보인다.
나무는 살아있다 The tree is alive
정적인 그림이 아니다.
나무는 숨을 쉰다. 열매가 맥동한다. 가지가 바람에 흔들린다. 줄기를 따라 에너지가 흐른다.
결함이 발생한 열매는 흔들린다. 진동이 가지를 타고 줄기까지 전달된다. 오래된 안정적인 열매는 느리고 묵직하게 맥동한다. 새로 배포된 열매는 빠르게 깜빡인다. 경고 상태의 열매 주변에는 황금빛 링이 돈다.
이 움직임들이 상태를 말한다. 보고서를 읽지 않아도, 숫자를 해석하지 않아도 — 나무를 보면 느낀다.
기획자도, PM도, 운영자도, 개발자도 — 각자의 언어가 달라도, 같은 나무를 본다. 그것으로 충분한 경우가 많다.
중력이 보이는 나무 A tree that reveals gravity
SOM Tree의 진짜 가치는 여기에 있다.
어떤 가지의 열매가 반복적으로 붉어진다면 — 그것은 개발자의 실수가 아니다. 그 Module에 구조적 문제가 있다는 신호다. 중력이 거기 작용하고 있다.
어떤 열매가 계속 파랗게 남아있다면 — 테스트가 미루어지고 있다는 신호다. 왜 미루어지는가. 일정 압박인가, 우선순위 문제인가, 개발 지연인가. 나무가 질문을 던진다.
뿌리가 얕은 Module이 있다면 — 그 Module은 역사가 짧거나 변경이 잦다는 뜻이다. 안정성이 낮을 가능성이 높다.
SOM Tree를 보는 사람은 왜 그 열매가 거기 있는지를 묻는다.
소프트웨어는 아름다워야 한다 Software should be beautiful
매일 여는 프로그램이 아름다워야 한다는 것은, 당연한 요구다.
우리는 매일 소프트웨어와 함께 산다. 아침에 열고, 하루 종일 들여다보고, 밤에 닫는다. 그 소프트웨어가 기능만 하면 된다는 생각은, 공장에서 살면 미적 감각이 필요 없다는 생각과 같다.
SOM Tree는 관리 도구이기 전에 소프트웨어의 초상화다.
초상화는 대상을 있는 그대로 담는다. 건강한 부분과 아픈 부분을, 깊은 뿌리와 얕은 뿌리를, 풍성한 가지와 빈 가지를. 그리고 좋은 초상화는 — 오래 들여다봐도 질리지 않는다.
오늘 무엇을 해야 하는지를 느끼는 도구. 데이터가 아니라 감각으로.
번외편을 마치며 Closing the bonus series
SOM 이론은 1화에서 질문으로 시작됐다.
"QA는 왜 항상 개발자의 언어인가."
그 질문을 따라가다 BOM을 만났고, 사마천을 만났고, 조직의 불평등을 마주했고, 이름 붙이는 행위의 철학을 발견했다.
그리고 마지막에 나무에 닿았다.
뿌리가 있고, 줄기가 있고, 가지가 있고, 열매가 있는 나무. 그 열매 하나하나가 SOM ID고, 가지 하나하나가 Module이고, 뿌리 전체가 우리가 만들어온 소프트웨어의 역사다.
나무는 설명하지 않는다. 그냥 보인다.
그리고 보이는 것은 — 무시하기 어렵다.
그들도 꿈틀거린다... 권력의 밖에 있는 그들이. 알지는 모르지만...