최근 참여한 프로젝트가 얼마 전에 끝났다. 매번 프로젝트가 끝날 때마다 다음 프로젝트는 더 잘하자고 생각하면서도 지난 프로젝트의 교훈을 잘 활용하지 못하는 것 같다. 이번에는 오랜만에 한번 정리해보기로 했다.
프로젝트 성격
일단 프로젝트가 어떤 성격이었는지 알아야 뭘 잘했고 뭘 못했는지 판단하기 좋겠지. 이 프로젝트는 민간업체의 웹사이트 구축 프로젝트로서 일반인에 컨텐트를 제공하는 목적이며 PC웹과 모바일웹을 함께 개발하는 프로젝트였다. HTML5를 기반으로 접근성을 고려해야 하며 컨텐트 사이트이므로 다양한 미디어와 텍스트가 함께 서비스되도록 페이지를 구성해야 했다. 컨텐트는 별도의 CMS를 통해 관리되며 CMS도 리뉴얼을 해야 하고 웹사이트는 이 CMS에서 컨텐트를 끌어와야 한다.
내가 참여한 것은 모바일웹 쪽이었고 계약 입장에서는 을이 아니고 병이었다.
프로젝트의 문제점
기본적으로 프로젝트가 힘들게 진행된 원인은 업무 분량에 있었다. 사업 전에 공고된 예상 기간은 3개월 남짓(겨우!)이었으나 개발팀이 실제 들어가보니 업무 분량이 상당히 많았다. 개발할 기능과 서비스할 컨텐트의 양이 많았기 때문에 다양한 경우를 고려해 페이지와 기능을 구성해야 했다.
또 다른 문제는 업무 분량이 많더라도 관리 조직이 프로젝트를 노련하게 이끌 수 있었다면 납기를 그렇게 많이 지연되게 만들지 않았을 것이고 지연되더라도 프로젝트가 잡음 없이 진행될 수도 있었을 텐데 여러차례 고객업체와 주계약업체간 마찰이 있었다. 프로젝트 진행에 있어 일을 잘하는 것도 중요하지만 고객이 안심하고 함께 갈 수 있는 것도 중요한데 그게 매끄럽지 않았다. 다른 말로 하자면 커뮤니케이션의 문제다.
개인적인 성공과 실패
이제 나의 잘잘못을 복기해보자면… 단, 나 자신에 대해 객관적일 수가 없을 수 있으니 10년 후에 돌아보면 다른 생각일 수도 있겠다.
- 프로젝트 계획 - 내가 맡은 영역에 있어서는 나름 계획을 세워 착실히 진행했지만 프로젝트를 해볼 때마다 느끼는데 착실한 진행이 꼭 정답은 아닌 듯하다. 어떤 부분은 빠르고 어떤 부분은 꼼꼼히 진행하는 완급 조절이 필요하다. 내가 부족한 부분이다. 하지만 속도의 차이는 있지만 챙길 걸 다 챙기고 돌다리를 두들기고 가는 것 자체는 필요한 일이다.
- 범위 관리 - 업무 범위 역시 내 개인적으로는 고객의 요구를 착실히 수용하자가 원칙이었는데 정답이 아닌 듯하다. 어떻게 얘기하자면 프로젝트는 지속적으로 고객과 대화하는 것이라고 볼 수 있고 업무 범위 역시 줄 것은 주고 받을 것은 받을 수 있는 협상력을 키울 필요가 있다. 내가 특히 약한 부분이 아닌가 생각했다.
- 위험 관리 - 위험은 언제 어떻게 찾아올지 모른다는 것 자체가 위험인 것 같다. 생각지 못한 큰 버그나 설계 변경, 개발자의 컨디션 난조 또는 병가, 업무 지연 등은 항상 주의해야 한다. 특히 업무 지연은 야금야금 찾아오므로 더 이상 용납할 수 없는 중요한 시점이라 판단되면 결단이 필요하다. 이 부분은 차츰 내가 잘 컨트롤해나가고 있는 부분인 듯하다.
- 품질 관리 - 품질은 내가 개발자로서 자존심을 둬야 할 부분이라는 생각을 하고 있으므로 난이도가 있는 부분은 직접 코딩하고 챙기는데 이걸 어떻게 하면 나만이 아니라 여러 다른 개발자들과 분담할 것인가가 숙제인 것 같다. 개발자의 품질은 하루 이틀에 되는 게 아니고 또 업무 특성에 따라 끝날 때까지 업무 전수와 품질 확인이 필요하므로 말로만 개발자들과 분담한다고 되는 문제가 아니다. 평상시에 교육을 하고 개발자들의 관심을 환기시키는 노력이 필요한 것 같다.
- 시험 - 품질과 밀접한 관련이 있는 시험. 그러나 얼마나 어떻게 할지는 항상 고민이다. 많이 하다보면 본 업무 진행이 쪼들리게 되고 덜 하다 보면 여기저기 빵꾸가 나소 품질이 떨어진다. 일반적인 개발 패턴에 있어서는 체크리스트를 잘 활용해야 하는데 이번 프로젝트에서는 기간이 짧으니 무조건 앞으로만 나가는 게 장땡이라고 다소 간과하고 넘어간 면이 있었다.
개인적으로 이번 프로젝트의 큰 문제는 밤샘과 야근이었다.
그런데 이번 프로젝트에서 느낀 건데 밤샘하는 게 좀 수월한 프로젝트도 있다. 사무실이 넓직넓직한데다 추운 겨울에도 따뜻하니 밤샘의 고통이 좀 덜했다. 프로젝트에 따라서는 좁은 사무실에서 히터를 켜가며 밤샘해야 하고 마음대로 들락날락하지 못하는 경우도 있다. 그런 면에서는 이번 프로젝트가 나았다. 사무실 바로 옆에는 세면장도 있었고 휴게실에는 수면실과 안마기도 있었다.
하지만 밤샘이 무엇인가. 개발자의 몸과 정신을 갉아먹는 것이 아닌가. 지나고 나서 생각해보니 밤샘을 좀 덜할 수 있지 않았을까 하고 다음과 같은 면에서 아쉬움이 남는다.
- 고객이 원하는 전반적인 내용은 업무 분석, 기획 단계에서 협의가 되긴 했겠지만 개발하면서 발견되는 다양한 뉘앙스의 문제는 결국 개발자와 고객 실무자가 함께 이해도를 높여서 해결해야 한다. 직접 의사소통을 할 경우 개발 시간이 부족해진다는 우려가 있으나 일정 주기에 한번씩 몰아서 회의를 하는 게 필요하다는 생각이 든다. 다른 사람이 의사소통을 대신해주지 않거나 대신해주더라도 비효율적이 되므로 적극성이 필요하다.
- 기술적인 구성이나 아키텍처는 거의 개발 초기에 확정이 돼서 진행되지만 개발하다보면 한참 후에야 비효율적인 방식이나 예상하지 못했던 예외 상황을 만나는 경우가 종종 있다. 문제가 있다는 걸 인식하지 못했던 것은 사실 업무 이해도에 문제가 있었던 것일 수 있다. 당연한 개발 방식이라고 생각될지라도 개발 초기부터 중기까지는 더 좋은 방안이 없는지 검토가 필요하다. 이번 프로젝트에서는 화면의 세부 구성 요소를 "모듈"이라고 불러서 여기저기 다양한 모듈이 공통적으로 사용되는데 그런 구조를 감안하지 않고 개발하다보니 같은 모듈인데도 여기저기서 코딩이 좀 달라서 테스트 시간이나 수정 시간이 많이 낭비됐다. 처음부터 이런 문제를 예상해서 좀더 효율적인 모듈 개발 구조를 생각했어야 했다.
- 지난 번에 모바일 웹브라우저에 대해 언급했었지만 웹킷 브라우저라는 공통 환경만 믿고 브라우저 차이에 의한 문제 발생을 예측하지 못했다. 다양한 문제 현상을 경험했고 여기서 버린 시간도 상당하다. 좀더 경험이 많은 사람을 수배했었거나 기술적인 구성을 좀더 문제가 덜 발생할 방식으로 생각해서 진행했어야 했다.
맺음말
바쁘다는 핑계로 이미 프로젝트 끝난지도 꽤 된 시점에야 이 글을 마무리하게 됐다. 모든 일이 그렇다. 나중으로 미루지 말고 그때그때 생각날 때 바로 해야 한다. 그게 쉽지 않은 것이지! 그래서 그런 말도 있지 않은가.
달리는 말에 올라타라