본문 바로가기

생각하나

데드라인 - 애매모호한 명세서

244

"네, 마찰이요. 시스템을 가지고 이해관계에 있는 사람들이 협상하죠. 사용자, 이해관계자, 개발자, 운영자, 관리자 같은 사람들이요. RGS 처럼 복잡한 시스템 같은 경우, 서로 다른 이해 집단이 아마 12개쯤 됐을 거에요. 가끔 그 사람들은 서로 동의하지 않죠. 마찰이 생기는 거에요. 예를 들자면 RGS에 관해 협상했던 어떤 집단은 시스템 운영자가 직접 초기 변수를 통제했으면 했는데, 다른 어떤 집단은 중앙에서 통제하기를 바란다고 생각해 보세요."
"아, 서로 충돌한 거군요. 그리고 만약에 그것이 해결될 수 있는 것이 아니라면?"
"그 명세서는 애매할 수밖에요. 예를 들어 운영자가 직접 입력할 수 있는 키보드가 있는지조차 명시할 수 없는 거죠. 구성요소조차도 정확히 명시할 수 없을 거에요. 특정 주제에 관한 애매모호하지 않은 문장은 다른 나머지 집단에게는 위험신호가 되겠죠. 왜냐하면 애매모호하지 않다는 것은 서로 상충하는 많은 요구 중에서 어떤 특정 정보를 명시하기로 결정했다는 뜻일 테니까요."
"그 명세서 작성자들은 애매모호하지 않은 명세서를 쓸 수도 있었지만."
"마찰을 일으키는 이쪽이나 저쪽 편을 들어 명세서 작성에 전념을 다해야 했지만 그렇게 되면 반대쪽 사람들이 가만두지 않는 거죠."
"참 우울하군요. 마찰을 해결하는 대신, 애매호호한 걸로 도배하다니."
"그런 일은 항상 일어나요. 그래서 전 불투명한 부분을 발견하게 되면 혹시 마찰이 있었나 하고 캐내고 다니죠. 그리고 항상 찾아내요. 애매모호하지 않는 문장을 만드는 것은 상당히 쉬운 일이라고 확신하게 됐죠. 그렇게 하지 못한다면, 그것은 우리의 표현력을 수정해야 하는 것이 아니라 마찰 해결 능력을 수정해야 하는 거죠."

'생각하나' 카테고리의 다른 글

데드라인 - 역설계와 설계  (0) 2008.02.04
데드라인 - 마찰  (0) 2008.02.04
데드라인 - 설계  (0) 2008.02.04
부의 기원 - 기업의 존재 이유  (0) 2008.02.01
부의 기원 - 적응적 사고 방식  (0) 2008.02.01