고객이 시스템에 원하는 것 vs 고객이 시스템으로 하는 것

The customer tests should capture the essence of what the customer wants the system to do.

이 포스트는 XUnit Design Pattern 중 위 문장을 번역하다 떠 오른거예요(참고로 번역은 "고객 테스트는 고객이 시스템에 원하는 것이 무엇인가에 대한 정수를 담아야 한다" 라고 했지요. ㅎㅎ )

사실 언뜻보면 제목의 두 구절은 비슷하죠.  시스템으로 하는 것이나 원하는 것이나... 그런데 사실 그렇게 보는 관점이 프로젝트 말미에 있는 요구사항 레볼루션 같은 큰 사건을 일으키는 것이 아닌가 해요. 우리는 주로 엔지니어의 입장에서 고객이 시스템으로 하는 것에 주안점을 두지요. 그래서 특정 업무를 구현할 경우 오프라인의 장표를 온라인으로 옮겨오고 시스템에서 관련작업을 처리하게 하는데, 사실 이게 오프라인의 작업이나 절차가 그대로 온라인으로 옮겨온 경우가 많죠. 어떤 경우에는 종이가 화면으로 바뀐것 뿐이지 도대체 뭐가 더 좋아졌는지(종이값 절약?) 사실 잘 모를때도 있었어요. 게다가 특히나 프로젝트 중후반을 지나면서 많이 나타나는건데 요구사항이 막 바뀌는거예요. 추가던 기존것의 변경이던 막 일어나죠.  그리곤 대부분의 프로젝트는 점점 늪으로 빠져들고요. 원래것만 하기도 바쁜데 변경하는거랑 추가된거랑 하려면 이거 뭐 코드의 수준이나 시스템의 보안, 제품의 성능 따위는 2차적인것이 되고 당장 납기 맞추기에만도 전전긍긍하게 되거든요.

번역서 제목으로 '신기술 도입의 함정'이란 책이 있어요. 원 제목은 'Necessary But Not Sufficient' 예요. 아주 환장하고 읽었던 'The Goal'의 골드렛 박사의 또 다른 작품이지요. 기업에 분명히 새로운 기술과 시스템을 도입 했음에도 불구하고 실제적인 비용 감소나 이익 증가가 뚜렷하지 않은 이유는 무엇인가에 대해 고민하고 해결하는게 이 책의 내용이예요(아마도. 읽은지 좀 돼서.. ㅎㅎㅎ)

이게 우리의 상황이랑 비슷한것 같아요. 지들이(!) 하는 것 그대로 구현해 줬는데 군말없이 잘 쓸것이지 왜 난리지? 새로운 시스템, 새로운 기술을 도입해 주었는데!! ㅎㅎ

진짜 솔직한 심정으로.. 제 경력이야 SI 바닥에서 5년 구른 것 뿐이지만 그래도 나름 대기업 다녔다고 이런 저런 큼지막한 것도 좀 봤었거든요. 근데 그때마다 속으로 드는 생각은.. 이거 이렇게 비싼돈 발라서 구축하는데.. 이게 정말 이 회사의 사업이 뻗어 나가는데 도움이 돼? 라는 것이었지요. 기존 시스템이랑(오프라인 작업이던 기존의 온라인 시스템이던) 크게 차이도 없고 단지 구식 시스템이 최신 - 하드웨어와 OS와 각종 서버 프로그램과 언어는 뭐 자바정도, 근래에는 RIA도 심심찮게 들어가는- 시스템으로 바뀐것일 뿐이란 생각이 많이 들었었거든요.

저 책 그림의 아래쪽 굵은 글씨 보이세요? "왜냐하면 규칙이 아무것도 바뀌지 않았기 때문이다" 이거요. 네.. 정말 그래요.. 몇십억씩 쏟아 부어서 새로운 시스템을 구축하지만 기존의 규칙(시스템 외적인)은 별로 변하지 않기때문에 실제적으로 고객이 원했던 효과는 별로 없는거죠. 뭐 '기존에 연결되어있지 않던 시스템들을 하나로 통합 어쩌구 저쩌구...' 이런건 규칙이 바뀐게 아니예요. 그냥 구조가 바뀐거지. 어차피 조금 불편해도 사람들은 기존의 시스템에 자신을 최적화해서 일하고 있었을 것이거든요. 좀 불편했던 부분의 최적화는 대규모로 시스템을 뒤집지 않아도 조금의 돈과 생각만으로도 개선 가능한 것이 대부분이기도 하구요.

이야기가 좀 쓸데없는 방향으로 흘렀네요.. 다시 돌아와서.

앞서 이야기한 요구사항의 대규모 변경등의 참사를 막기 위해서 우리에게 필요한 것은 고객이 진정 원하는 것이 무엇인지 파악하는 능력이라고 생각해요. 기술이나 방법이 중요한 것이 아니예요. 나중에 애자일 프랙티스들과 디자인 패턴을 비유로 해서 글을 쓸 것이지만 기술이나 방법은 어떻게 하느냐가 중요한게 아니라 왜 필요한가 그리고 그게 현 상황에 정말 필요한 것인가 쓴다면 어떻게 적용해 쓸 것인가가 중요한 것이예요. 그저 남들이 했으니깐 좋다고 하니깐 짧은 이터레이션을 돌고 포스트잇이나 칠판등을 이용한 설계등을 해봤자 그건 좀 재미나고 색다른 것일 뿐이지 우리를 악의 구렁텅이에서 빨리 빼주진 않는거죠. 물론 시간이 한참 지나고 여러번 위의 것들을 기계적으로 반복하다보면 궁극의 목표점에 다다를 수 도 있겠죠. 그런데 우리가 그렇게 긴 시간과 자원을 가지고 있는 것도 아니고 그렇게 하라고 위에서 허락해 주는 것도 아니잖아요? (잠깐! 그렇다고 제가 저런 좋은 프랙티스들을 부정하는 것은 아니예요. 오해하지 말아주셨으면 해요). 진정으로 고객이 원하는 것 - 궁극의 목표. 단순히 기존의 작업을 좀 더 쉽게라는 것은 진짜 목표가 아닌 경우가 대부분이죠 - 을 파악하려는 노력과 관찰, 사유, 토론, 연구등의 과정에 앞서의 도구들이 추가될 때 진정한 시너지 효과가 나타난다고 생각해요.

결론을 내자면....

내가 만든 소프트웨어로 고객에게 "그들에게 의미있는" 가치를 전달해 주려면, 항상 "이게 어떻게 도움이 될 것인가", "정말이지 이 시스템을 도입하면서 원했던 것은 무엇일까"를 고민해 보자 정도 일까요? ㅎㅎㅎㅎㅎ