프로젝트의 쓴맛

SI 업계에 있은지 10여년을 훌쩍 넘겼지만 여전히 매 프로젝트마다 쉽게 넘어가는 프로젝트는 없는 것 같다. 프로젝트마다 난이도가 다르고 수행 여건이 다르기에 각각의 특성은 매번 달라지고 그 때마다 새로운 경험을 하면서 뭔가를 배우게 된다. 왜 경험이 누적되는 데 반해 “프로젝트의 쓴맛”은 여전할까? 달콤상콤한 프로젝트란 나하고 거리가 먼 걸까?

예전에도 프로젝트 종료 후 교훈을 복기했지만 여전히 잘 안되고 있는 것들이 많은데 오늘은 한 가지만 새로 짚어보자. 이름하여 “Technical debt”.

내가 경험하는 관점에서 “기술 부채”란 요구사항에 부합하는 기술적 설계/구성을 프로젝트 초기에 완료할 수는 없기에 부족한 부분이 누적되게 되는데 이게 단순 누적이 아니라 “복리” 개념으로 제 때 해결되지 않으면 시간이 지날수록 눈덩이처럼 불어난다는 것이다. 일견 쉬운 문제를 어렵게 해결하는 건 합리적이지 않아보이니 일단 깔끔하진 않지만 쉽게 해결하는 방법을 선택하지만 그게 빚이 돼서 나중에는 다시 해결해야 하는 문제로 돼서 돌아올 수 있는 것이다. 적절한 비유적 표현이다.

어떤 기능을 구현할 때 프로젝트 전체적인 관점에서 재사용성, 확장성 고려 없이 해당 기능 하나만 잘 만들어 놓으면 되겠지하고 짧은 시간에 만들었다고 하자. 그런데 나중에 보니 다른 곳에서도 같은 방식의 구현이 필요하고 하고 그에 따라 이미 구현된 여러 것들의 구조를 변경해야 한다면? 이 때도 임시 방편으로 다른 것들의 구조를 바꾸지 않고 쉽게 가는 방법을 발견해서 갔는데 나중에 또 가보니 결과적으로는 구조를 바꿔야 하게 된다면?

이번 프로젝트에서 그런 문제를 여러 차례 경험했다. GIS 제품, BI 제품을 도입했으나 고객 요구 사항과는 부합하지 않은 것이 많아져 결국 새로 개발하게 되어 제품 비용은 제품 비용대로 들어가고 인력과 시간은 또 추가 투입되고…

그런데 그게 기술 구조도 그렇지만 인력 구성도 마찬가지다. 프로젝트를 셋업할 때 적합한 인력으로 구성해야 하는데 처음부터 적합한 사람을 투입하기 어렵다보니 일단 눈에 띄는 사람부터 넣고 나중에 찾아서 넣는 계획으로 시간을 벌어보고자 한다. 그러나 그 나중이 프로젝트 초기가 아니라 점점 늘어져 중기가 되고 말기가 되는 경우가 발생한다.

프로젝트 진행에서 대출은 자꾸 늘어가기 때문에 처음부터 원금을 갚는 전략을 취해야 한다. 원금을 갚지 않으면 시간이 흐를 수록 늘어나는 대출에 그 이자를 감당할 수 없다. 당장은 원금부터 갚기 힘들겠지만 쉽고 편한 길만 선택하다보면 프로젝트 전체 관점에서 비용은 훨씬 더 많이 들어가게 된다.

느리지만 거북이 같이 꾸준하게 한 걸음, 한 걸음 나아가도록 해야겠다.

프로젝트의 쓴맛”에 대한 의견

  1. 저도 얼마전 종료한 프로젝트에 대한 회고를 여기다가 덧붙여 작성해봅니다. ^^
    그 프로젝트에 적합한 인력이 투입이 되지 않아서 초반 두달을 버렸답니다. 설계가 제대로 되지 않았고, 기존 멤버들끼리 갈등이 있었는데 제가 엄청 싸웠습니다. (내가 늦게 투입된 상태에서 바라본 상황을 객관적으로 얘기한건데, 기존 멤버들이 머리 끝까지 화가 나서 폭발해버린거지만요) 결국엔 수정사항이나 추가사항이 있을 때마다 다른 프로그램을 개발하면서 동시에 변경하게 되었습니다. 인터페이스쪽 연동 테스트때문에 빌드를 수시로 했죠.

    다들 어떻게 헤쳐나가야할지, 또 누가 제대로 된 인력이고 제대로된 의사결정을 하는지 등등에 대한 혼란이 있었습니다. 저도 일년동안 SI프로젝트 대신 학원에서 아이들을 가르쳐본다던지, 교수님과 같이 쬐끔한 규모의 프로젝트를 해본다던지 하는 딴짓을 하다가 프로젝트에 투입된 거라서 제대로 된 판단이나 방향을 바로 제시할 수가 없었습니다.

    그래도 사람들하고 계속 대화하고 같은 팀원하고도 고민을 나눴고, 변경사항에 대해서 적극적으로 받아들였더니 결국에 내가 뭘 고쳤는지도 생각이 안나는 지경에 이르렀지만 결국에 좋게 마무리 되었답니다.

    어릴 때는 제가 너무 부족해서 갈등이 그저 갈등이고 나는 아무것도 할 수 없다고만 생각했는데, 요즘에는 갈등이 있으면 그 갈등에 다이빙을 해야한다는 (범블비 영화처럼?) 교훈을 얻었습니다. 그리고 그 프로젝트에 1도 도움이 안되는 사람이 있으면 가차없이 아웃시키거나 주요업무에서 배제시키지 않으면 그 사람의 입김에 의해 프로젝트 품질이 다운될 수 있다는 것을 깨달았습니다.

    또 개발리뷰가 중요하단 생각이 들었습니다. 개발리뷰를 안하고 각자 개발해서 돌아가는 것만 테스트결과서를 작성해서 증명하다보니 나중에 다른 사람 소스를 보는데 도대체 무슨 말인지 무슨 로직인지 이해가 안되더군요. 제품을 만드는데 그 안의 로직이 각자 스타일대로 가면 운영할 때 너무 힘듭니다. 표준이 디테일하게 잡히지 않은 상태여서 더더욱 그랬습니다.

    개발용어도 표준이 지켜지지 않아서 처음에 서로의 모듈을 쓰는데 이거 맞냐고 물어보러 다니고, 나중에는 뭐 그거 다 통일하라고 해서 수정하고~
    그러니까 말 잘통하고, 잘 들어주고, 성실한 개발리더가 있어야했는데 그 프로젝트에는 존재하지 않았어요.

    의사결정하는 리더도 두명이나 되어서 (피엠과 피엘) 둘이 역할이 불분명해서 팀원들이 두명의 의사결정에 휘둘려서 일을 이중으로 했었어야했는데 그것때문에 나중에 한번 폭발해서 뭐라고 했습니다.

    그리고 리더가 말을 너무 막했어요. 어린 사원들한테 돼지들아~!! 라고 소리를 질러대면서 모멸감주는 말을 너무 많이 해대서 프로젝트 폭파 직전이었는데, 제가 사장님한테 왜 이러냐고 따진적도 있고, 뭐 이런 저런 저항이 있고나서는 그분이 조용해졌습니다.

    그러니까 제가 얻은 교훈은 정리해보면 다음과 같습니다.

    1. 설계 단계를 프로토타입 개발하듯 디테일하게 완성해야했다.
    2. 리더는 한명이어야하고, 커뮤니케이션 통로는 병렬이 아닌 하나로 통일해야했다. (리더 -> 서브리더 -> 팀원)
    3. 공통 표준을 디테일하게 완성해야했다.
    4. 해당 업무에 부족한 역량을 가진 팀원은 배제해야한다. (현실상 불가능함. 그렇다면 스스로가 부족하다는 것을 인정하고 해당 업무를 완성하기 위한 지원을 받아야한다.)
    5. 서로 신뢰관계가 돈독해야한다. (현실상 불가능함. 그렇지만 신뢰가 없으면 프로젝트가 산으로 가고, 제품 품질이 저하됨. 제품개발에 일관성이 없어지거나, 누군가 일을 제대로 안하기 때문)
    6. 테크니컬 아키텍처의 역할이 중요하다. (단순히 경력이 많은 사람이 아니라 최신 기술에 대해서 잘 아는 전문가가 프로젝트내에 꼭 필요하다. 혹은 소스 품질에 대해서 조언해줄 수 있는 자문가가 필요하다.)

    저보다 나이가 어린 친구와 술마시면서 개발이 어떠냐고 물어봤는데, 지겹다면서 if문 for문들로의 연속일 뿐이라고 합니다. 뭐라고 얘기해주고 싶었는데, 맞는 말 같아서 수긍했지만 뭔가 기분이 이상했어요. 세상에는 프로그래밍기술로 인해서 얼마나 많은 것들이 편해지고 좋아졌는데, 그것을 만드는 개발자들은 스스로를 비하하고 더 나아가서는 스스로의 직업을 비하합니다. 제가 봤을 때는 체계성없이 단순노동하듯이 임시성 프로젝트를 반복하기 때문에, 그리고 잘 모르는 기술인데도 경력으로 대충 사람을 끌어모아서 단기간내에 시끄럽게 싸우면서 힘겹게 만들어버리기 때문에 그렇게 되는 것 같습니다..

    1. 임x3님! 새해 들어 이렇게 긴 댓글 주시니 감탄하며 읽었습니다.

      주신 의견은 프로젝트마다 흔히들 발생하는 문제인데 왜 이렇게 반복되는지 모르겠습니다. 혹시 피플웨어라는 책을 읽어보셨는지 모르겠는데 결국 소프트웨어 프로젝트라는 건 사람들이 하는 일이라 기술도 중요하지만 사람들이 시너지를 내고 조화로운 프로세스로 진행할 수 있어야 합니다. 리더의 역할도 중요하고 프로세스도 중요하고 실력도 중요합니다. 프로젝트의 여러 요소는 어느 하나 간과할 수가 없습니다.

      주신 의견에서는 그렇게 오래 이쪽 일을 하시지는 않은 것 같은데 통찰력을 가지고 프로젝트를 진행하신 것으로 보여 그래도 그 프로젝트에서 임x3님이 큰 역할을 하시지 않았나 생각됩니다. 사실상 IT 후진국인 우리나라가 새해에는 좀더 발전적인 소프트웨어 개발을 할 수 있기를 소망해봅니다.

의견 있으시면 냉큼 작성해주세요~