[마소콘 2018] SW품질 프로세스로 보는 SI프로젝트 기술부채 강연내용 후기.

지금 다니고 있는 회사 이전에 다녔던 회사가 통신사 관련 SI 를 하는 회사였고 마지막 프로젝트가 꽤 규모가 있었던거라 이번 파트에 대해선 많은 공감을 하면서 들었다. 허나 강연하신 기술사님이 말씀한 핵심 내용들은 분명 SI 업체에서 일하고 있는 임직원들은 이미 인지한 것이라고 생각한다.

강연내용 정리

SI 란??

나무위키에 자세한 설명이 나와있다..

• https://namu.wiki/w/SI

System Integration(시스템 구축)의 약자. 전산시스템을 필요로 하는 곳으로부터 하청을 받아, 시스템의 기획, 개발, 유지보수, 운영 등을 대신 해주는 업종이다. 아무래도 개인보다는 기업이나 관공서가 주된 고객이다. 고객의 요청에 따라 제안서를 작성하고, PM과 개발자를 투입하여 프로젝트를 수행한 뒤, 소요된 인건비와 솔루션의 단가 등을 수임료로 벌어들이는 형태의 산업이다. 따라서 도급 시스템과 파견 업무를 그 특성으로 한다.

SI 산업은 갑(甲)인 고객이 자신들이 필요로 하는 시스템을 발주하고, 을(乙)인 개발업체가 사업을 수주하여 개발을 진행하는 구조다. 그러나 이것이 갑과 을로만 끝나는 단순한 관계라면 그나마 문제가 덜하겠지만, 갑으로부터 사업을 따낸 을이 영업에만 관여하고 구체적인 개발은 병(丙)에게 맡기고, 심지어 병(丙) 조차도 여건상 스스로는 사업을 감당하지 못해 다시 정(丁)에게 일을 넘기고… 이렇게 해서 단순한 갑을관계가 아니라 갑을병정무… 이런 복잡한 구조가 만들어 지는 것이 많다. 즉 주인과 노예의 피라미드가 구성되면서 진정한 헬게이트를 연다는 게 이 망할 업종의 문제인 것이다.

암튼.. 이와 같은 현실로 인해… 많은 프로젝트들이 개발 중 또는 그 이후에 엄청난 기술부채가 쌓인다.

SI 프로젝트 특성 상 분석설계 할 시간이 없음.. 시간에 쫒김.

1. 분석하고 설계하고 고민하고 그 상태에서 다음 시스템을 생각해야 하나 그럴시간 없음..
2. SI 프로젝트는 대부분 시간을 주지 않음.
3. 개발하면서 계속 바뀌므로…

ex) 성능테스트 할때

• 로드런너, 제이미터
• 하지만 그거에 맞춰서 비즈니스 로직까지 바꿈… 그걸 설계단계까지 바꾸자고함…그럼 분석설계를 다시하자는건데??

SI 일의 구조는?

만약 100억 이상의 프로젝트를 할 경우… (겪어본 바론 진짜 거의 놀라울 정도로 비슷했다..)

1. 커다란 파이의 분할..
2. 모든것을 대화하며 풀기에는 시간이 부족하다. 말을 하면서 할 시간이 없음.
3. 최근엔 PMD나 시큐어프로그램 돌려서 철수하기 직전에 고치게 함.
4. 나갈때 코드를 작성하지 않는 개발자도 있었음 .. 처음에 그 개발자한테 욕을 함.. 하지만 나중에 알게됨. 설계가 없어서 결과물이 나오지 않은 것.
5. 기술부채가 엄청나게 쌓인채로 개발자한테 넘어옴.
6. QA는 막판에 들어와서 개발을 잘합시다~! 설계를 잘합시다~! 잔소리..
7. ……..총체적 난국…………..

기술부채가 초래한 결과

1. 개발단계에서 시작되는 AS-IS 분석.
   • 이 문구를 보고 이전에 했던 프로젝트에서 분석 설계 시 제대로 된 메뉴얼도 없어 결국엔 소스를 깐 경우가 생각났다..
   • 자바 개발자 잔뜩 뽑아놓고 C++ 이나 플랙스로 된 소스 다 까서 분석하는 경우였다.. 이 부분에서 꽤 큰 기술부채가 쌓였다.
2. 개발단계에서 시작되는 TO-BE 설계. (ㄷㄷㄷ 오픈직전에도 그랬다.)
3. AS-IS 소스 재활용. (ㄷㄷㄷㄷㄷㄷㄷㅋㅋㅋㅋㅋㅋ)

SI 쪽은 그래서…

• 너희들은 절대 SI 하지마라.

그럼 어떻게 해야하나?

1. Agile 방법론 vs 기존 방법론&SLDC 에 대한 고민.
2. 산출물의 의미 : 무언가를 이해하고 그려내고 써 내려가는 과정에서의 고민의 결과.
   • 보여주기식 문서가 되면 안됨.
   • 개발하기 전 그림으로 그릴 수 있어야 함.
3. 되도록이면 요구사항이 제대로 정의가 되어 있어야함.
4. 건설쪽은 철저하게 옵션계약을 해서 돈을 더 받아냄 : 계약변경을 계속 할 때마다…
5. 하지만 IT는 그런거 없다. 이런 부분을 자주 얘기를 해서 해결하여야 할 것이다.

기술부채를 제거하기 위해 분석단계에서 해야할 일.

1. 요구명세.. 같이 읽어보고 고민하자.
2. 뭔가 부족한건 없는지 체크하고 같이 얘기하는 시간을 가져보다.
3. agile은 데일리미팅으로 계속 공유를 하자. agile 을 하자는게 아니고 많이 대화를 하여 어려움을 풀어보자.
   • 현재는 많은 프로젝트들이 PL들만 회의에 참석 한다. 밑으로 제대로 내용 전달이 되지 않는다..
4. 모든개발자가 참석할 수 있는 회의실을 잡고 대화를 많이 했으면 좋겠다.

설계단계에서 해야할 일.

• 설계는 설계답게. 고객과의 대화에서 정립한 것을 구체적으로 제대로 설계한다.

개발단계에서 해야할 일.

1. 개발 : 진척률 기반 관리의 맹점 확인.
2. 테스트 : 최대한 고객이 적극참여, 검증데이터의 사전준비.
3. 결함관리 : 결함조치 및 확인 프로세스. 테스트를 통한 재 검증.

결론

1. 모든사람이 하나의 일원으로 같이해야 잘 끝난다.
2. 위와같이만 되도 기술부채는 많이 없어질 것이다.

질문

• 시간이 부족 할 경우 분석설계를 어떤식으로 해야하나?

답변

1. 설계 수준에 대한 난이도를 둬서 우선순위를 둠. (EX : 인터페이스 부분에 대한 것은 우선순위가 높다.)
2. 중요하지 않거나 쉬운 부분에 대해선 설계를 하지 않고 개발단계에서 설계
3. 그럴경우 개발하는 사람들 수준에 맞게 설계를 시킴.
   • 중급 초급: 조회성 단위 화면에 대한 설계를 시킴, 고급 : 어려운것 설계

느낀점

사실 내용 자체는 엄청나게 공감하면서 들었다.
SI 프로젝트를 하면서 많은 생각이 들었던 부분은 고생할게 아닌일을 상당히 수고롭게 일을 한다는 것이었다.
강연하신 기술사님이 말씀하신대로만 진행된다면 많은 SI 프로젝트들이 많은 개선이 될 거라 생각한다.
하지만 사실 명확한 설계가 나오지 않는것은 고객도 사실 뭘 원하는지 모른다는 것이기 때문인 것 같다.
뭔가 개발된 것이 우선 보여져야 생각이 나온다 해야하나 … 사실 그건 PM 이나 개발자들도 마찬가지었었던 걸로..
그리고 제일 문제는 말도 안되는 기간.. SI 업체들의 수익은 얼마나 짧은 시간내에 얼마나 비용을 줄여서 프로젝트를 종료하고 남기는 것이냐로 결정되기 때문에 이런 문제가 나올수 밖에 없을 것 같다는 것이다..

그래도 비록 개발자들이 주로 참석한 컨퍼런스지만 이렇게 문제점들에 대하여 언급해 주신다는 것이 매우 감사한 느낌을 받았다.

그리고… 가능하면 SI는 안하고 싶다..

관련자료

• https://www.imaso.co.kr/archives/4481
• http://it.chosun.com/site/data/html_dir/2018/12/15/2018121501019.html