SOM이 왜 지금까지 없었는지 묻는 사람이 있다. 좋은 질문이다. 제조업은 수십 년 전에 BOM을 만들었다. 사마천은 2000년 전에 기전체를 만들었다. 원리는 단순하다. 단위를 정하고, 번호를 붙이고, 연결하면 된다. 그런데 왜 소프트웨어 업계는 이것을 하지 않았는가.
기술적 이유가 아니다. 기술은 진작에 가능했다.
조직적 이유다.
먹이사슬의 구조 The food chain of software projects
소프트웨어 프로젝트에는 먹이사슬이 있다.
이 구조에서 품질 문제는 아래에서 발생하고, 아래에서 고통받는다.
기획자는 자신이 설계한 것이 제대로 구현됐는지 확인할 언어가 없다. 개발자는 테스트 산출물을 마감 직전에 소급 작성하면서 야근한다. QA는 검증 결과를 커버리지 숫자로 번역해서 올려보내지만 그게 무엇을 의미하는지 위에서는 제대로 읽지 못한다. 운영자는 납품된 시스템의 어느 부분이 어떻게 테스트됐는지 알지 못한 채 장애를 맞는다.
고통은 아래에 집중된다. 그런데 구조를 바꿀 권한은 위에 있다.
왜 구조가 바뀌지 않았는가 Why the structure hasn't changed
관리자 입장에서 현재 구조는 나쁘지 않다.
프로젝트가 납품되면 된다. 감리를 통과하면 된다. 커버리지 숫자가 기준을 넘으면 된다. 그 숫자가 실제로 무엇을 의미하는지, 어떤 기능이 검증됐고 어떤 기능이 구멍인지 — 굳이 알 필요가 없다. 문제가 생기면 아래로 책임이 내려가는 구조니까.
기획자가 테스트 결과를 읽을 수 없어도, 관리자에게 그것은 불편이 아니다. PM이 품질 지표를 해석하지 못해도, 관리자에게 그것은 문제가 아니다. 개발자만 읽을 수 있는 리포트가 올라와도, 관리자는 숫자만 보고 사인한다.
이것이 수십 년 동안 구조가 바뀌지 않은 이유다.
불평등을 아프게 들여다보다 26 years of watching inequality up close
26년을 현장에서 보냈다. 그중 6년은 ITO — IT 아웃소싱 현장이었다.
ITO는 먹이사슬이 더 선명하다. 발주사와 수주사가 있고, 수주사 안에서 또 위계가 있다. 프로젝트 성공의 기준은 발주사 관리자의 사인이다. 그 사인을 받기 위해 아래에 있는 모든 사람이 움직인다.
그 현장에서 반복해서 목격한 것이 있다.
- 산출물 소급 작성. 마감 이틀 전 밤샘 엑셀 작업.
- "이 커버리지 수치가 뭘 의미하는지는 모르겠지만 기준치를 넘었으니 됐다."
- 기획자가 개발 결과를 확인할 방법이 없어서 개발자의 말을 그대로 믿는 상황.
- 납품 후 운영 중 발생하는 장애의 원인을 아무도 추적하지 못하는 상황.
이것이 기술 문제였다면 진작 해결됐을 것이다. 기술은 충분히 있었다.
구조 문제였다. 고통받는 사람이 구조를 바꿀 수 없는 구조.
그것을 아프게 들여다보면서 하나의 질문이 생겼다.
같은 언어로 말할 수 있다면?"
SOM이 하려는 것 What SOM actually does
SOM은 구조를 바꾸지 못한다.
관리자가 품질에 무관심한 것을 바꾸지 못한다. 발주사가 납품 기준으로 숫자만 보는 것을 바꾸지 못한다. 먹이사슬 자체를 없애지 못한다.
그러나 한 가지는 한다. 보이게 만든다.
먹이사슬의 아래에 있는 사람들이 서로 같은 언어로 말할 수 있게 된다.
관리자가 알아채기 어려운 방식으로, 정보의 비대칭이 조금씩 줄어든다.
코드는 평등하다, 그러나 Code is equal, but organizations are not
코드는 평등하다. 기획자가 짠 코드도, 26년차 개발자가 짠 코드도, 같은 컴파일러 앞에서는 동등하다. 잘 작동하거나, 작동하지 않거나. 둘 중 하나다.
그러나 그 코드를 둘러싼 조직은 평등하지 않다. 코드의 품질을 정의하는 것은 컴파일러가 아니라 사람이고, 그 사람들 사이에는 위계가 있다.
소프트웨어 품질 관리가 그토록 오랫동안 개발자의 언어로만 존재했던 것은, 개발자가 특별히 이기적이어서가 아니다. 시스템이 그렇게 설계되어 있었기 때문이다. 위에서 아래로 압력은 내려오지만, 아래에서 위로 정보는 잘 올라가지 않는 구조.
SOM은 그 구조 안에서, 아래에 있는 사람들이 서로 연결되는 방법을 찾은 것이다.
완벽한 해답은 아니다 Not a perfect solution
이것을 쓰면서 조심스러운 것이 있다.
SOM이 조직의 불평등을 해결한다고 말하고 싶지 않다. 그것은 과장이고, 거짓말이다.
다만 이것은 말할 수 있다. 정보가 투명해지면 책임도 투명해진다. 어떤 기능이 검증됐고 어떤 기능이 구멍인지 모두가 읽을 수 있을 때, "몰랐다"는 말은 더 이상 유효하지 않다.
마지막으로 A closing thought
SOM은 실험실에서 태어나지 않았다.
현장에서 태어났다. 마감 전날 밤의 소급 작성, 아무도 읽지 않는 커버리지 리포트, 납품 후 흩어지는 이력들 — 그 고통들을 아프게 들여다보면서 만든 것이다.
이 이론이 언젠가 논문이 되고, 표준이 되고, 도구가 된다면 — 그것은 현장에서 고통받는 사람들에게 돌아가야 한다. 관리자의 리포트를 더 그럴듯하게 만들기 위해서가 아니라, 기획자와 개발자와 QA와 운영자가 같은 언어로 말할 수 있게 되는 그날을 위해.
SOM은 그 방향을 향해 있다.
오늘도 그 현장에 있을 그들에게 바친다...