Offcanvas

CIO / 개발자 / 리더십|조직관리

정철환 칼럼 | 개발자와 테스터

2024.07.01 정철환  |  CIO KR
필자가 있는 회사와 소프트웨어 개발 사업을 함께하고 있는 베트남의 아웃소싱 개발 전문 파트너사의 한 임원이 지난 달 링크드인에 다음과 같은 글을 올렸다.
 

제목: 한국 고객과의 작업 경험에 대한 공유.

베트남의 오프쇼어 소프트웨어 프로젝트에서는 프로세스가 보통 초기 단계, 계획, 통제 및 모니터링, 실행, 마무리 단계까지 완전하게 따릅니다. 팀은 보통 SM, PM, BA, TL, SA, 디자이너, 개발자, 테스터, QA, 통역사 등으로 구성됩니다. 비율은 개발자가 약 40-50%, 테스터가 약 30-35% 정도입니다. 예를 들어 개발자 5명이 있다면 3명의 테스터가 따라붙어야 하지만, 버그 비율이 꽤 높습니다. 한국 팀은 다릅니다. 개발자가 보통 80%를 차지합니다. 즉, 개발이 끝나면 자체적으로 유닛 테스트를 하고, 최종 테스트(수용 테스트와 같은)에는 테스터 1-2명만 사용합니다. 그들은 개발자가 자신이 한 일에 책임을 져야 한다고 생각하며, 다른 사람에게 넘기는 것은 시간이 걸리고, 그것을 만든 사람만큼 요구사항을 정확히 이해하지 못할 수도 있다고 생각합니다. 그들은 유닛 테스트를 마치 다른 사람을 위해 테스트하는 것처럼 진지하게 수행합니다. 따라서 한국 개발자의 생산성이 베트남 개발자보다 종종 높습니다.

그러면 베트남은 어떻게 개선하여 업무 생산성을 높일 수 있을까요?!


이 글을 읽고 문득 든 생각이 ‘과연 우리나라의 개발자 생산성은 얼마나 될까?’ 였다. 그러고 보니 우리나라에 개발자라는 직업이 본격적으로 생겨나기 시작한 1990년대에는 시스템 개발에 투입된 인력에 대한 세부 구분이 따로 없었다. 그냥 개발자가 프로젝트 초기에 투입되어 고객의 요구사항분석부터 화면설계, 프로그램 개발, DB 설계 등을 자신의 업무 영역에 대해 모두 담당하는 것은 물론, 자신이 개발한 프로그램에 대한 테스트까지 본인이 수행하였다. 유일하게 통합 테스트에서만 여러 사람들이 모여 사전에 정의된 테스트 시나리오에 따라 자신이 개발하지 않은 영역까지 테스트하였다.

당시 SI기업이 도입하기 시작한 개발방법론의 정의에 따르자면 분석, 설계를 담당하는 인원과 프로그램 코딩을 담당하는 인원이 다를 수 있으며 이를 위해 프로그램 사양서를 문서로 작성해야 한다고 되어 있었고 이에 따른 테스트 사양서 역시 단위 테스트/통합 테스트/고객 테스트 등으로 구분되어 정의되어 있기는 했다. 그러나 대부분의 프로젝트에서는 프로젝트 초기에 개발 대상 업무를 각 인원에게 배정하면 최종 프로젝트 마무리까지 동일 인원이 분석부터 테스트까지 모두 담당하는 것이 일반적인 관례였다.

그러한 상황에서 프로그램 사양서나 테스트 사양서는 개발자들이 매우 작성하기 귀찮아 하고 심지어 쓸모없는 작업으로 여기는 개발자들도 있었다. 이러한 상황이 2024년 지금은 많이 달라졌을까? 필자의 편협한 시각일수도 있으나 여전히 많은 개발 프로젝트, 특히 SI 프로젝트에서는 개발자와 단위 테스터의 구분이 없는 경우가 제법 많지 않을까 생각한다.

즉 업무 분석 및 설계 단계에서 분석, 설계 산출물을 근거로 개발에 들어갈 때 다른 개발자가 문서만 보고 이해할 수 있는 수준의 프로그램 사양서를 작성하지 않고 바로 코딩에 들어가고 단위 테스트 역시 잘 정의된 테스트 시나리오 없이 테스트를 진행하는데 문제가 없는 이유가 동일한 개발자가 처음부터 끝까지 진행하는 방식이었기 때문일 것이다. 물론 베트남 개발자의 실력이나 코드 품질 수준이 한국 개발자와 동등하지 않을 가능성도 있으나 그보다는 이런 이유로 앞서 소개한 베트남 IT 기업의 임원이 보기에 한국 개발자의 생산성이 높다고 판단한 배경이 아닌가 추측한다.

그런데 일본의 경우 이미 1990년대부터 시스템을 개발할 때 아주 명확한 테스트 사양서가 문서로 작성되고 개발자가 아닌 별도의 테스터가 프로그램의 단위 테스트를 진행하였다. 때문에 일본의 개발회사에서 당시 많은 수의 한국인들을 채용하여 테스터로 활용하기도 했다. 그때는 한국이 지금의 베트남과 같이 인건비가 저렴하면서 우수한 인력을 공급하는 나라였던 셈이다.

그 당시 일본에 취업했던 분들의 이야기를 들어보면 워낙 테스트 사양서가 잘 정의되어 있어서 일본어를 전혀 모르는 경우에도 일을 하는데 큰 불편이 없었다고 했다. 더구나 테스트 생산성(속도)이 일본인들에 비해 매우 높아서 하루에 테스트할 분량을 반나절이면 다 마치곤 했다는 이야기도 들었다. ‘빨리 빨리’는 우리나라 사람들의 유전자에 각인되어 있는 특성인 듯하다.

그렇다면 왜 일본과 한국의 개발 문화가 차이가 나게 된 것일까? 소프트웨어 개발의 원조라고 할 수 있는 미국은 개발자와 테스터의 역할이 분명하게 정의되어 있으며 이에 따라 개발 조직을 운영했을 것이다. 이를 받아들이면서 일본은 원리 원칙대로 따랐다면 한국은 그렇지 않았기 때문이 아닐까?

그리고 현재 베트남의 개발 아웃소싱 회사들은 한국의 회사들과 일하기 시작한 시기 이전에 먼저 미국이나 일본의 기업으로부터 프로그램 개발을 수주 받아 진행하였기에 자연스럽게 미국이나 일본의 개발 문화를 따라 시스템 개발의 각 단계에 따른 고유의 역할을 수행하는 인원을 구분하여 운영하게 되었을 것으로 생각한다. 물론 베트남의 개발자 시장에서 개발자들이 한 회사에 오래 근무하지 않고 자주 옮기는 성향이 한국보다 훨씬 더 높다는 것을 감안하면 각 단계별로 잘 정의된 문서와 명확한 역할의 정의에 대한 필요성이 더 높을 수도 있다. 이런 이유로 앞서 소개한 글과 같은 견해가 생긴 것이 아닐까?

그렇다면 과연 한국의 개발 문화가 바람직한 것인가? 상대적으로 한국의 개발 문화에 따른 개발자의 생산성이 높게 나타날 것이다. 하지만 개발이 완료된 후 운영 단계로 넘어가면 다른 인력이 인수를 받아 시스템을 유지보수 하게 될 터인데 이 때 제대로 작성되지 않은 개발 산출물을 넘겨받게 되는 경우가 드물지 않다.

결론적으로 필자는 이러한 한국의 개발 문화가 꼭 문제가 있다고 생각하지 않는다. 오히려 최근 개발 방법론의 중심이 되고 있는 애자일 방법론에서는 오히려 개발자와 테스터가 한 사람인 경우가 더 효율적일 수도 있다. 그러나 개발된 시스템과 일치하지 않는 문서 산출물 및 효용가치가 없는 프로그램 사양서 등은 이슈가 될 수 있다. 하지만 지금까지 우리나라 고유의 개발 문화가 나름 잘 정착되었으며 현재의 IT 시장과 산업을 잘 버텨주고 있다고 생각한다. “대한민국 개발자들 모두 화이팅!!”

* 정철환 상무는 삼성SDS, 한양대학교 겸임교수를 거쳐 현재 그룹 IT 계열사의 사업부를 이끌고 있다. 저서로는 <SI 프로젝트 전문가로 가는 길>과 <알아두면 쓸모 있는 IT 상식>이 있으며, 삼성SDS 사보에 1년 동안 원고를 쓴 경력이 있다. 한국IDG가 주관하는 CIO 어워드 2012에서 올해의 CIO로 선정됐다. ciokr@idg.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
Sponsored
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.