망한 프로젝트, 되살릴 수 있을까?

사진 @Pixabay

망가진 프로젝트에 소방수로 자주 투입되었다.

분야가 모두 달랐는데 망한 이유는 거의 판박이처럼 닮아 있었다.

몇 번 정리하고 나니 수습능력과 보는 눈이 생겼다.

그걸 정리해 보았다.

망한 프로젝트를 들어가면, 개발자가 다 도망가고 없다.

도망간 개발자를 좇아가서 만나보면 대부분 비슷한 말을 한다.

사람이야기다. 고객과의 갈등, 팀장과의 불화, 살인적인 일정 등등.

말이 안통한다는 거다.

하지만, 사람 이야기는 복잡하다.

그래서 기술 이야기부터 해보자.

01. 화재현장 둘러보기

망한 프로젝트는 현황진단을 사람말로 하지 않는다.

갈등이 섞여 있기 때문이다. 

그래서, 시스템과 코드로 확인해야 한다.

아래 이야기는 코드나 터미널 열어서 확인하는 거다.

진도. 데이터를 본다.

제일 먼저 데이터를 확인한다.

어떤 데이터가 쌓여 있는지 눈으로 본다.

보고 받는 게 아니라 DB 를 눈으로 뒤져본다.

그게 현재를 확인시켜준다.

현재까지 회사가 걸어온 길을 말해준다.

사업담당자보다 훨씬 더 많은 것을 말해준다.

우선 화려함이 없다.

회원수, 거래실적 등을 있는 그대로 보여준다.

아무 훌륭한 사업처럼 이야기해도, 데이터는 거짓말을 하지 않는다.

사람은 거짓말 한다.

하지만, 잘못을 감추는 건 본능이다. 이해한다.

그러나 전략적이라면 갸우뚱하다.

뭔가 나쁜 일이 벌어지고 있는 거다.

단기사업방향. 데이터 구조를 본다.

DB 테이블 구조는 그릇이다.

사업의 큰 틀과 미래방향을 이야기한다.

특히 코드로 만든 것은 가까운 미래를 말한다.

업무확장이 예상되는 걸 코드로 만들기 때문이다.

가장 많이 쌓인 데이터의 코드가 이 회사의 주력이다.

영업이 거창하게 이야기를 해도 데이터는 거창하지 않다.

담백하게 보여준다.

구조는 개발자에 따라 케바케이다.

잘한 것도 있고, 못한 것도 있다.

중요한 건 CRDU(데이터 생성, 삭제 등)가 제대로 되는지 확인하는 거다.

정합성은 결산 문제를 이야기한다.

돈 일수도 있고, 회원수일 수도 있다.

돈은 결산이 잘맞아야 한다.

작게 벌고 많이 쓸 수 있다. 회사 망한다.

정합성은 구조점검에서 출발한다.

여기저기 중복인데 값이 다르다면 이상한거다.

현재 비즈니스가 처음과 많이 달랐다는 뜻이다.

그래서 미래에도 이상하게 흘러갈 가능성이 크다.

안 그랬으면 좋겠지만, 많이 그렇더라.

사업역량. 서버구조를 본다.

DB 하나, 웹서버 하나.

누구나 처음엔 이렇게 시작한다.

전혀 문제가 없다.

하지만 접속자가 많다면 증설을 해야 한다.

증설을 하면 서버 프로그램이 부하를 나누어 받는다.

구조의 문제가 개입된다.

서버 세팅, 프로그램에 증설 구조가 고려되지 않았을 수도 있다.

대형트래픽을 받아본 경험이 없는거다.

오직 하나의 DB만 사용하도록 만든다.

또는 데이터가 중복으로 쌓여서 어느 게 옳은지를 모른다.

말도 안되는데 적지 않게 본다.

서버 구조의 허술함은 사업초기를 짐작케 해준다.

돈을 얼마들고 시작했는지, 주변 개발자 인맥이 어떤지 알 수 있다.

현장 서비스를 키워본 적이 없다면 대부분 이렇게 만든다.

일정이 촉박하다면 그냥 이렇게 만든다.

사업담당과 개발팀의 사이가 좋지 않다면 이렇게 만든다.

다시는 보지 않을 SI 개발자라면 이렇게 만든다.

두 사람 이상의 손길이 느껴진다면 이직이 잦았다.

이직이 잦다는 것은 갈등이 많았다는 거다.

대부분 개발이 사업 요구사항을 못따라 간다.

고수가 와도 마찬가지일 가능성이 크다.

영업이 생산공정에 대해 이해하지 못하는 거다.

생산능력이 월 100 대인데, 1,000대 수주를 해온거다.

그걸 모르거나 사정이 안될 수 있다.

조직문제. 프로그램 설정파일을 본다.

설정파일에는 접속계정이나 디렉토리, url 정보 같은 게 들어있다.

하지만, 가끔 이상한 게 들어가 있다.

개발자가 임시로 만들어 놓거나 우회처리를 해 놓은 거다.

일정이 촉박하거나, 무리한 요구 때문에 임시처리를 해 놓은 거다.

이런 건 눈에 보이지 않는 오류를 만들 가능성이 있다.

눈에 보였다면 진작 수정했을 거니까.

오류를 만들고 있다면 돈 문제일 가능성도 있다.

크지는 않아도 가능성은 있다.

그래서 작아도 꼭 로직부분까지 추적을 한다.

기술역량. 프로그램 구조를 본다.

먼저 어플리케이션 구조부터 확인한다.

Java 라면 도표로 그려주는 툴들이 있다.

node 라면 직접 그려야 한다.

그리곤, 현재의 비즈니스 룰과 비교한다.

사업담당자의 설명을 듣는다.

패키지 구조가 잘못 잡혀 있기도 하다.

개발자가 사업구조를 이해하지 못한 거다.

통계처리가 실시간 서비스와 섞여있을 수도 있다.

통계가 돌 때 앱이 엄청 느려지기도 한다.

개발자가 경험이 없는 거다.

프로그램 구조는 개발자의 경험에 따라 크게 좌우된다.

이론문제보다 경험적 문제가 더 많이 발생한다.

심플하게 잡혀 있다면, 초보자가 개발한 거다.

정교하게 잡혀 있다면, 베테랑이 개발한 거다.

정교한데 이상하다면, SI로 개발한 거다.

SI는 디테일을 일상룰로 정해버리기 때문이다.

자기 서비스가 아니니까 당연한거다.

프로그램 구조는 미래비전이다.

그런데, 사실 사업은 비전대로 실행되지 않는다.

그래서 구조가 엉망일 수 있다.

구조가 엉망이면 간단한 기능구현도 비싸진다.

구조가 많이 엉망이라면 새로 만드는 게 낫다.

하지만 사업은 자체 속도 때문에 배려하지 못한다.

이 시점에 개발은 사업 진행의 제한요소가 된다.

수습이 가능하다면 열어 보지만, 아니라면 조용히 덮게 된다.

개발팀. 프로그램 소스를 본다.

문제없이 돌아간다면 일단은 내버려 둔다.

개판으로 짜여진 경우라면 한숨을 쉬면서 틈틈히 새로 짤 수 있다.

하지만, 단계적 모듈 교체를 고려하게 된다.

다른 기능 개발시 슬쩍 끼워서 재개발한다.

그런데, 대부분 서버 기능은 연관되어 있다.

시간이 지나면 자연스레 모두 뜯어보게 된다.

미래 위험요소는 알아야 하기 때문이다.

새로운 기능을 오픈했는데, 옛날 로직과 충돌날 수도 있다.

간단히 대응하기 힘든 장애다.

그런건 미리 고민해 두어야 한다.

소스품질은 개발팀의 관리수준을 보여준다.

소스품질이 나쁜데 실서비스 중이라면, 개발팀이 처음부터 없었을 가능성이 크다.

소스품질은 좋은데 장애가 발생된다면, 개발팀이 상용서비스를 운영해본 경험이 없는거다.

또는 관계없는 개발자에게 외주를 준 것이다.

외주개발이라면

사업담당자가 말하지 않은 요구사항은 구현되어 있지 않았을 가능성이 크다.

경험상 인터넷 서비스는, 개발자가 알아서 하는 "기타개발" 분량이 40% 정도 된다.

보통 외주개발이라면 그런 건 하나도 없다

심지어 서비스 지표가 없는 경우도 있다.

그래서 오픈했는데, 잘 되고 있는지를 확인할 수 없기도 하다.

다행히 좋은 SI업체라면 그런 것을 미리 견적에 넣는다.

이 경우는 SI 업체를 만나서 사정을 들어보는 것도 좋다.

만날 수 있다면 말이다.

02. 수습계획 세우기

해결책은 케바케다.

조직문제 일수도 있고, 시스템 문제일수도 있다.

시스템 문제라면 비교적 간단하다.

조직문제라면 복잡하다.

두 개가 섞여 있다면 매우 더욱 복잡하다.

IT업종은 사람이 생산설비(?)이다.

매일매일 닦고 조이고 기름쳐야 한다.

술 사주고 밥 사주라는 이야기가 아니다.

문제 시스템을 의뢰받아보면 안타깝게도 코드 몇 줄 고쳐서 해결되는 경우는 없다.

대부분 오랫동안 문제가 방치된 것이다.

찾다찾다 흘러서 온 경우가 대부분이다.

비난할 생각은 없다.

CEO가 너무 바쁘더라.

코드 문제라고 하더라도 그 증상만 잡으면 해결되는 경우도 거의 없다.

대부분 다른 문제로 이전된다.

그래서 아무리 작은 문제도 3~4주를 붙잡고 있게 된다.

적지 않은 부담이다.

사실 해결의 출발점은 사람이다.

좋은 인력들이 남아서 일하게 하는 것.

이건 술사주는 걸로 안된다.

좀 기니까 이건 다음에 이야기하자.

요약하자면

시스템이 말하지 못하는 문제들도 있다.

하지만 그런 것은 시스템 정상화에 문제되지 않는다.

위의 문제만 제대로 진단해도 시스템은 정상화된다.

이후 조직이 더 발전할 수 있는가는 다른 문제이다.

따로 진단해야 한다.

도움을 요청할 땐 솔직한 게 좋다.

물론 처음부터 솔직하긴 어렵다.

하지만 진도가 빠져도 발뺌하면 안된다.

문제를 치유할 준비가 안된거다.

나중에 고맙다는 이야기 못듣는다.

문제가 잡혀도 정상운영될 가능성이 적다.

대가도 제대로 받지 못할 가능성이 높다.

도대체 누가 도와줄 것인가?

수습비용은 그동안 투자 못한 것에 대한 징벌적 사건이다.

마이너스를 제로로 만드는 건 직원들의 희생으로 가능하다.

그러나, 제로를 플러스로 만드는건 남에게 시켜서 되는 일이 아니다.

FIN.