설계의 목적과 검수하는 문화

안녕하세요. yeTi입니다.
오늘은 검수하는 문화와 이로인해 변화한 설계의 목적에 대해 얘기해보고자 합니다.

계기

안영회 대표님의 폭포수 방식 설계는 기술 부채를 남긴다 라는 글을 몇번을 읽었는지 모르겠습니다.

사회 초년생부터 궁금증을 가지고 있었던, 왜 그런 개발 환경을 가지게 됐는지에 대한 궁금증을 해소할 수 있는 기회였다고 생각하고 있었던거 같습니다.
그러는 와중에 궁금증에 대한 답을 할 수 있는 표현을 발견했습니다.

소프트웨어 개발이 아니라 검수를 위한 결과물로 쓰이기에 그들의 표기법은 매력적일 수 있습니다.
검수 단계에서 계약서에 합의한 금액 지불이 적절한가 하는 문제에만 초점을 맞춥니다.

검수

검수 라는 행위는 발주처 입장에서 목표한 제품을 수행 업체가 제공하였는지를 확인하는 절차이고, 만일 제대로 제공하지 않았을 때는 잔금이라는 것을 담보로 협상할 수 있는 발주처의 행위입니다.

검수 단계에서 계약서에 합의한 금액 지불이 적절한가 하는 문제에만 초점을 맞춥니다.

검수를 진행했던 이전 경험을 되세겨 보자면, 추적표 라는 검수에 최적화된 문서를 작성했습니다. 이후 RFP 에 대응하는 요구사항 > 설계 내용 > 테스트 케이스를 맵핑하는 작업을 하여 우리는 요구사항에 준하는 제품을 개발했다. 는 것을 증명했고, 검수관들은 해당 제품이 실제 사용가능한 수준인지에 대한 여부는 중요하지 않은 듯이 보였습니다.

그렇게 검수를 통과하면 납품처는 잔금을 받을 수 있었고, 이후 발생하는 크리티컬 버그는 도의상 지원하는 수순을 밟았습니다.

이렇듯 수행 업체의 입장에서는 검수라는 절차만 완료한다면 잔금을 받고 프로젝트를 인계 후 역할을 종료할 수 있습니다.

이후 운영의 문제와는 상관이 없어집니다. 오히려 난이도가 있는 프로젝트는 운영 프로젝트에 경쟁사가 없어서 추가 수익을 얻을 수도 있습니다.

그렇다면 왜 검수를 문서에 기반하여 수행하게 됐을까요?
Big Design Up Front 방식의 설계와 UML의 유행에 의해서 일까요?
발주처의 떨어지는 전문성을 납품처가 이용하는 것일까요?

이는 이미 사회적 현상이니 다양한 변수에 의해서 만들어졌다는 생각이 듭니다.

설계의 목적

검수라는 절차에서 문서에 기반한 검증이 이뤄지다보니 수행 업체는 자연스럽게, 납품하는 제품의 품질보다는 문서로 증명하는데 노력을 하는 방향으로 진화하지 않았을까 라는 생각을 합니다.

그렇게 설계라는 행위 또한 그럴듯한 표현을 그리는 방식으로 변화 했을 것이라고 추측됩니다.

소프트웨어 개발이 아니라 검수를 위한 결과물로 쓰이기에 그들의 표기법은 매력적일 수 있습니다.

테일러 주의

그렇게 개발 환경도 변화해 갔을 것이라고 생각합니다.

SI 환경에서는 프로젝트 금액과 기간이 정해져 있습니다.
이러한 환경에서 수익을 극대화하기 위해서 인건비를 효율화하는 방식으로 개발자를 활용해야 합니다. (고급 개발자는 가장 바쁠때만 잠시 쓰는 방식으로..)

역할도 정해져 있었습니다.

• 설계하는 인력
• 개발하는 인력
• QA하는 인력

인력별 투입 주기도 달랐습니다.

• 설계 인력 투입 후 산출물 완성 및 인계 후 빠짐
• 개발 인력 투입 후 제품 완성 (M/M의 효율화에 따라 중간중간 인력 변경)
• QA 인력 투입 후 제품 완성

그렇게 효율화 라는 단어속에 좋은 제품을 위한 지속적인 협업보다는 각자 문제를 만들지 않는 방향으로, 유기적으로 움직이는 것처럼 보이는 방향으로, 개발자보다 PM의 능력이 중요해지는 방향으로 개발 환경 이 맞춰져 갔다는 생각을 합니다.

생존 전략

다른 사람을 이해한다는 것은 다른 사람을 배우는 과정

한동안 이러한 환경을 옳고 그름 의 잣대로 평가하던 시절이 있었습니다.

요즘에는 각자의 비즈니스 전략 이라는 생각이 듭니다.

• 어떤 이는 10억 정도되는 외주 사업을 하면서 만족하기도 하고
• 어떤 이는 100억 1000억 정도되는 외주 사업을 하면서 만족하기도 하고
• 어떤 이는 유니콘을 목표로 하기도 하고
• 어떤 이는 그저 만족하기도 하고
• 어떤 이는 알지도 못하는 제품을 납품받고 만족해 하기도 하고

각자 자본 주의 사회에서 돈을 벌기 위한 전략이 다르기 때문에 나타나는 형태도 다르다는 생각을 합니다.

결론

검수라는 절차에 의해 설계의 목적이 달라질 수 있습니다.

하지만 현업에서 개발환경 개선활동을 통해 경험한 것들은 설계문서는 소통을 위한 시각화 수단일 뿐이고 지속적으로 갱신되어야하는 대상이라는 것입니다.

설계 문서가 만족할만큼 나왔다고해서 개발이 이를 투영했다고 볼 수 없고, 개발의 모든 사항을 설계문서로 표현할 수 없다는 점입니다.

예시로 코드 리뷰를 하다보면 협의했던 내용과 다르게 개발되는 것들도 있습니다. 이를 누구의 잘못으로 보기보다는 소통의 오류로 인해 기인한 것들이 존재합니다.

또한 코드는 유기적인 생명체 인데, 이를 항상 표현할 수 있는 문서는 존재하지 않습니다.

따라서 요구사항의 검토는 코드로 이뤄져야 성공적인 서비스를 만들 수 있다고 생각합니다.