4866
2015-05-28 23:54:06
5
간단한 작업의 경우에는 뭐 그럭저럭 수정할 수 있을지 모르나 프로젝트 규모가 커지면 커질수록 '작은 수정사항 하나'가 보이는 것처럼 그리 쉬운일이 아닌 경우가 매우 많습니다.
프로그래밍은 건축과 같아요. 초기 설계가 매우 중요하죠. 결과물이 단순히 한층짜리 가건물이라면야 '여기에 창문 하나 더 뚫어주세요'가 그리 어렵잖은 요구사항일 수도 있습니다. 가건물 벽면에 구멍 하나 뚫고 창문 설치하는 걸로 끝날수'도' 있죠.
그러나 초고층 빌딩을 설계하고 건축한 거라면 이야기가 전혀 다르죠. 빌딩 각 층별로 버텨야 할 하중을 고려해 기둥 위치와 굵기, 벽면의 두께, 창문의 위치 등이 각각 있어야 하는 곳에 합당한 이유를 가지고 배치되어 있는 겁니다. 창문이 꼭 필요한 위치가 있었더라면 설계 단계에서 미리 요구를 했었어야죠. 이미 설계 끝나고 한창 건물 올리는 도중에 뒤늦게 '여기 창문 뚫어주세여. 손님들이 여기서 딱 바깥 풍경을 봐야한단 말이에여'하고 '사업논리'로 우겨봤자 안되는건 안되는 겁니다. 그 창문 하나 때문에 건물 전체의 안전이 위협받을 수도 있고, 거기 창문 하나 뚫기위해 그 주변 기둥 위치가 수십 수백층 전 충에 걸쳐 다 옮겨져야 하는(그게 일정+비용 상 가능하느냐의 문제는 차치하더라도) 사태가 날 수도 있으며, 엘레베이터나 에스컬레이터나 계단 같은 것들이 옮겨지는 상황이 날 수도 있고, 결과적으로 그 건물 이용자들의 동선이 초기 설계단계에서 계획한 것과 전혀 다르게 엉망진창으로 꼬일 수도 있습니다.
요구하는 쪽에선 '아니 겨우 창문 하나 더 뚫는건데 그게 뭐 어려워요? 드릴이랑 해머랑 해서 뚝딱뚝딱 구멍 뚫고 섀시 달고 유리 붙이면 끝 아님?'하면서 개발자가 게을러 하기 싫어하는 거라 생각할지 모르지만 그거야말로 뭘 모르는 소리죠. 운좋게 그 자리가 설계상 벽에 구멍 하나 뚫어도 괜찮은 상황에 딱 얻어걸린 케이스라면 모를까, 이거야말로 운이 좋은 경우일 뿐이고 많은 경우 이런 '사소한 수정' 하나가 초기 설계를 다 어그러뜨리고 프로젝트 전체를 사상누각 부실공사로 몰아넣는 원흉이 되고 맙니다.
물론 결국 최종적 목적은 이렇게 만든 것을 팔아먹기 위한 '사업논리'가 우선시 되어야 하는 것은 맞습니다. 또, 오래도록 유지보수 관리해가며 사용되는 프로그램의 경우 초기 제작시에 이런 시장 상황의 변화, 기술의 발전, 새로운 버전업의 필요 등 시대흐름에 따른 새로운 요구를 모두 충족시킨다는게 불가능한 일이구요.
그렇기에 경험많은 개발자의 경우에는 초기 기획단계에 참여해 설계시 부터 향후 어떤 방향으로 기능이 더 추가될 수 있을지 미리미리 확장을 고려한 설계를 하기도 합니다만, 개발자는 점쟁이가 아니고, 기획자/클라의 욕심은 끝이 없고 아무도 상상도 못한 기발한 추가요구사항을 반복하기에 모든 상황에 다 미리 대비한 설계란 건 있을 수가 없습니다.
결국 어느정도의 '마개조'는 필연적인 일이기는 합니다만, 최소한 그런식의 추후 수정이 비용과 일정 상 절대 쉽고 작은 일이 아니라는 점 만은 알고 있어야겠죠.
'여기 창문 하나 더 다는 거 뿐이니까 하루면 되지?' 이런 생각은 하면 안된다는 겁니다ㅠㅠ 구조적으로 그거 하나 고치는데 막대한 추가 수정이 뒤따를 수도 있는 것이고, 운좋게 꼼수 써서 그 요구사항 하나는 빠르게 잘 처리해 넘길 수 있을지 몰라도 그런 짓의 대가를 훗날 더 크게 치룰수도 있기에 어느정도는 시간과 정성을 들여 마무리해 둘 필요가 있을 수도 있습니다.
기획자나 클라이언트가 처음 계획된 일정을 마음대로 앞당기거나, 예정에 없던 추가 요구사항을 끼워넣으면서 일정은 그대로 두고 '이정도는 어려운거 아니니까 금방 되지?'할때면 그 마음이야 물론 이해가 갑니다만 (예를 들면 비슷한 서비스를 비슷한 시기에 오픈하려는 경쟁사보다 하루라도 빨리 오픈해야 한다거나 뭐라도 하나 더 추가해 오픈해야 한다거나 하는 사업논리는 그 자체로는 타당하겠지만) 그럴때면 귓방망이 깎는 노인의 심정이 생각나네요.. 기획단계에서 그거 미리 예측 못한 너네 과실을 왜 공밀레로 커버치려 그러나요?하고요..ㅠㅠ