빠른 길? 좋은 길? _ CIS 파트1 유동오 이사

요즘 저의 프로젝트 근무지는 분당입니다. 

집에서 분당까지 대중교통으로 시간이 많이 걸려 가끔 자차로 출근을 하곤 합니다. 차를 주차하고 사무실까지 걸어가는 동안 사거리 하나를 지나게 되는데, 사무실이 대각선 방향에 위치해있어 횡단보도를 두 번 건너야 합니다.

며칠 전 주차를 마치고 사거리에 다다른지 얼마 되지 않아 오른쪽 방향의 횡단보도 파란불이 들어와, 서둘러 횡단보도를 건넜습니다. 그 후 다시 사무실 방향의 횡단보도를 건너기까지 꽤 오랜 시간 기다려야 했습니다. 횡단보도를 건넌 뒤 파란불을 기다리면서 생각해보니 사거리의 파란불 순서는 시계방향 순인데, 방금 제가 건넌 건 반대 방향이었던 것입니다.

가장 먼저 신호등이 켜진 곳을 건넜지만 결과적으로 보면 가장 늦게 도착하게 된 셈입니다.

오늘도 지난번처럼 사거리에 도착했을 때 똑같은 상황이 벌어졌습니다. 시계 반대 방향인 우측 횡단보도 불이 파란색으로 먼저 바뀐 것이죠. 하지만 오늘은 잠깐 기다려 좌측의 횡단보도를 건너고, 그다음 바로 연이어 켜진 횡단보도를 건너 사무실에 도착했습니다.

프로젝트에서도 이와 비슷한 일들이 간혹 있습니다. 갑작스러운 상황이 발생하거나 일정에 쫓기는 경우가 종종 생깁니다. 이런 상황에 처할 경우 업무 성격이나 처한 상황들이 조금씩 다르긴 하지만 매번 비슷한 고민을 했던 것 같습니다.

'일단 급하니까, 문서나 설계는 나중에 하지 뭐...'

'이번 이슈는 잠깐 묻어 둬도 별문제는 없겠지...' 등등.

프로젝트 경험을 떠올리면, 데이터 모델링을 진행하면서 속성의 의미를 명확히 하지 않고 용어 표준에 위배되지 않도록 적당히 설계한 뒤 '나중에 수정해야지' 하는 경우도 있고, 데이터 전환 시 매핑 문서를 형식적으로 일단 작성한 뒤 개발을 진행하는 경우도 있습니다. 프로젝트 상황이 다르기 때문에 항상 틀렸다고 단정 지을 수는 없습니다.

하지만 개인적인 경험상으로는 필요한 절차를 생략했을 때, 조금 빠른 것 같지만 항상 크고 작은 문제가 생겼던 것 같습니다. (물론 문제가 있었기 때문에 제 기억 속에 남아 있을 수도 있겠지만...) 그래서 고민하는 것인지도 모릅니다.

프로젝트가 횡단보도처럼 규칙이 단순하다면 판단하는데 오래 걸리지 않고 좋은 결론을 내릴 수 있을지도 모릅니다. 그래도 예전보다는 프로젝트 경험이 쌓여서인지 무턱대고 판단하는 경우보다는 현재 상황과 선택 결과에 따라 어떤 일이 벌어질지 좀 더 고민하고 결정하는 편입니다.

항상 빠른 방법을 찾기도 힘들겠지만, 빠른 것이 최선의 선택은 아닐 것입니다. 여러분의 생각은 어떠신지요?