개발자

글로벌 칼럼 | 만국의 개발자여, ‘코드 품질’ 위해 단결하라

Jeremy Duvall | InfoWorld 2023.03.23
소프트웨어 개발을 하다 보면 코드 품질을 더 높이자고 목소리를 내기 쉽지 않다. 기업에서는 종종, 어떤 경우는 너무 자주 개발 프로젝트의 성과를 속도로만 측정하려 하기 때문이다. 가령 ‘최대한 빨리 코드를 완성하고 귀찮은 테스트는 QA팀에 맡겨라’라는 지침이 오는 식이다. 실제로 많은 기업에서 QA팀은 개발팀과 분리된 별도의 사무실에 있으며, 두 팀 간의 의사소통은 거의 이뤄지지 않고 피상적인 대화만 이뤄지는 경우가 많다. 
 
ⓒ Getty Images Bank 

경영진은 이러한 분리가 제품 개발 과정을 빠르게 만드는데 좋다고 생각할 수 있다. 하지만 결국 이런 분리는 단기적으로는 가독성을, 장기적으로는 확장성을 구현하는데 부정적인 영향을 끼친다. 코드의 가독성과 확장성을 가져가려면 이해관계자 모두가 코드 품질을 신경 써야 한고 특히 개발자가 이를 관리해야 한다. 소프트웨어 엔지니어라면 직접 코드 품질에 대한 우선순위를 높여보자고 제안하고 이에 대한 가치를 알려야 한다. 특히 조직 전체에서 코드 품질에 관심이 없는 경우에 더더욱 그렇다. 

물론 이런 부분은 말은 쉽지만 행동에 옮기는 것은 어렵다. 리더들과 공감대를 형성하며 오랜 시간 투자를 해야 한다. 어떤 기업에서든 수익과 실제 업무 환경에 영향을 주는 일이라면 변화를 주지 않으려고 한다. 그러나 빠른 속도에만 집중하는 것이 코드 품질 하락의 주요 요소로 작동한다. 원하는 결과가 나올 때까지는 어느 정도 시간이 필요하다는 것을 인정해야 한다. 그럼 구체적으로 왜 코드 품질이 중요한지, 어떻게 하면 업무 환경에 부정적인 영향력을 최소화하며 코드 품질을 높일 수 있을지 그 방법에 대해 알아보자.
 

코드 품질이 중요한 이유

이유 #1: 품질은 가치를 만드는 지름길이다
외주 직원이든 내부 개발 직원이든 품질을 내세우는 것은 고객 및 임원진이 비용만큼 충분한 가치를 만들고 있다는 것을 보여줄 수 있다. 코드의 조각이 모여 소프트웨어가 되고, 그렇게 완성된 소프트웨어는 다른 누군가가 사용한다. 버그 또는 충돌로 인해 소프트웨어가 제대로 작동하지 않는다면, 사용자에게 실망감을 안겨줄 것이다. 더 나아가 소프트웨어를 사용할 고객들에게 가치를 제공하지 못하게 된다.

최신 기능이 아무런 문제 없이 개발되고 출시되더라도 품질을 확인하지 않는 프로세스는 많은 기술 부채를 만든다. 이런 경우 제품 또는 팀 모두 발전하기 어렵고, 이후 무엇인가 개선하는 데도 방해가 된다.

이유 #2: 품질은 브랜드 보호 장치이다
코드의 품질은 장기적으로 기업 브랜드 자산을 보호해준다. 형편없는 코드로 유명해지는 것은 비즈니스에 전혀 도움이 되지 않는다. 코드 품질이 낮은 제품을 단 한두번만 출시하더라도 그로 인한 부정적인 평가는 수년간 입소문을 타고 지속될 수 있다.

애플리케이션 테스트 기술 전문 업체 소스랩스의 CIO 존 켈리는 “소스랩스에서 설문조사를 진행한 결과, 형편없는 사용자 경험을 제공하는 기업에서 높은 품질의 제품을 만들 수 있다고 생각하는 응답자는 59%에 불과했다. 예를 들어, 스마트폰 제조업체에서 만든 주문 플랫폼 기술이 형편 없다면, 고객 중 41%는 해당 업체가 만드는 스마트폰 품질도 낮을 것이라고 생각했다. 한 번의 실수가 신뢰를 무너뜨린다”라고 밝혔다.

고객의 신뢰를 잃으면 과거, 현재, 미래에서 발생하는 모든 비즈니스에 영향을 미친다. 브랜드 손상은 그 어떤 프로젝트 예산보다 큰 재정적 피해를 발생시키며, 회복하는데도 피해 금액만큼의 비용이 발생한다.

이유 #3: 품질 유지에서도 전문성이 필요하다
좋은 코드를 작성하는 것은 다른 기술만큼 전문성이 필요한 영역이다. 적어도 그렇게 바라봐야 한다. 소프트웨어 개발자가 하는 일에는 복잡성이 있으며, 그 결과가 미치는 영향도 크다. 이런 점을 고려해서 개발자는 스스로 직접 좋은 결과를 만들 수 있도록 환경과 운영 모델을 만들어 달라고 요청해야 한다. 

자신이 하는 일은 중요하게 여기고 자부심을 느끼는 것은 중요하다. 이런 마음 가짐은 단기적으로 업무 만족감을 줄 뿐만 아니라 장기적으로 커리어 발전을 돕는다. 스스로 생각하기에 이상적이지 않은 일을 하면 심리적으로 부담감을 느끼고, 동기부여를 받기 어려워진다. 옥스포드 대학의 SBS(Saïd Business School)가 2019년 진행한 연구에 따르면, 행복한 근로자는 그렇지 못한 근로자보다 13% 더 생산적이었다. 전문성을 키울 수 있는 일은 궁극적으로 비즈니스에도 좋은 영향을 끼친다. 엔지니어와 고용주 모두 만족할 수 있다. 

이유 #4: 품질을 높이는 것은 옳은 선택이다
소프트웨어는 사회 곳곳에서 중요한 역할을 하고 있다. 정보를 생성하고 처리하며, 재화와 서비스에 접근하고, 즐거움을 누리는 방식에 소프트웨어과 관여돼있다. 거기다 이제 자동차 업체도 소프트웨어 정의 차량을 만들기에 이동 과정도 소프트웨어로 조정되는 시대로 가고 있다. 

소프트웨어에서 다루는 새로운 영역이 많아지다 보니 개발자의 직업 의식과 책임감에 대한 논의도 최근 늘고 있다. 특히 요즘에는 누군가에게 해가 되지 않는 높은 품질의 제품을 만드는 것이 개발자가 지녀야 할 직업 의식으로 여겨지고 있다. 예를 들어, 소프트웨어 개발자의 직업 윤리 및 방향성을 제시한 SECEPP(Software Engineering Code of Ethics and Professional Practice)는 “소프트웨어 엔지니어는 자신의 제품과 관련된 변경사항이 가능한 최고 수준의 직업 기준을 충족하도록 해야 한다”고 규정하고 있다.

윤리적인 문제에는 나름의 찬반 논란이 따르지만 기본적인 품질 기준은 수준은 덜 모호하다. 품질을 높이면 사람들의 신뢰를 더 받을 수 있다는 것은 분명하며, 앞으로 소프트웨어 품질을 높이는 것은 개발자의 의무가 될 확률이 높다. 
 

코드 품질을 높이는 방법

현 시점에서 품질에 대한 사례가 충분히 명확하다고 생각할 수도 있다. 하지만 윗사람들을 설득하는 것은 그리 쉽지 않다. 어떻게 개발팀 내부에서 추가적인 테스트와 품질 확보를 수행하도록 경영진을 설득할 수 있을까?

일단 원칙만 이야기하는 기획안을 올리는 것에 끝나면 안 된다. 장기적으로 대화가 있어야 하고 합의를 도출하기 위해 꾸준하게 소통해야 한다. 어쨌든 합의는 좋은 소프트웨어 엔지니어링의 중요한 구성요소이다. 나쁜 소프트웨어 엔지니어는 솔루션이 문제를 해결하는 것에 대한 유연하지 못한 관점으로 회의에 임한다. 좋은 엔지니어는 중요한 결정을 유도하기 위해 자신의 의견을 공유하고 탄탄한 보편적인 근거를 찾는다.

소프트웨어 엔지니어라면 이미 항상 동료들과 뭔가를 합의하고 있을 것이다. MVP를 위해 이 방향으로 나아갈까? API를 작성하기 위해 이 방향으로 나아갈까? 더욱 신속하게 생산에 투입할 수 있으려면 파이프라인을 어떻게 구성해야 할까? 같은 논의를 할 확률이 높다. 

하지만 실무진과 경영진이 함께 무엇인가 합의를 하는 문화는 사라졌다. 더욱 빠른 결과에 대한 끝없는 기대 속에서 특히 리더들과 대화하는 실무진은 찾기 어렵다. 하지만 끈기, 인내심, 신중하고 전략적인 접근방식을 통해 품질의 중요성에 대한 합의를 도출할 수 있다.
 

합의 도출하기 101

단계 #1: 고객을 위한 우려를 표명하라
경영진과 대화를 하기 위해서는 언어를 사용해야 한다. 경연진에게 있어서 가장 중요한 목표는 무엇일까? 이런 목표들과 명확하게 연계시킬 수 있다면 리더들은 새로운 접근방식을 고려할 유형의 동기를 갖게 될 것이다. 결국, 품질을 더욱 강조하는 것은 프로젝트를 위한 것이며 회사, 고객의 회사, 최종 사용자의 활동의 가치를 높여준다. 높은 품질로 이런 가치를 절대적으로 만들 수 있다.

단계 #2: 리더의 관점에서 보기 위해 노력하라
코드 품질을 이야기하고 나며 부정적인 의견을 보이는 상사가 있을 수 있다. 이런 경우, 품질을 유지하는 게 좀 어려워 수 있다.  대부분 (아마도 배치 속도에 대한) 특정 목표가 있고 개발자의 요청으로 속도를 맞출 수 없다고 생각한다면 더욱 경계할 것이다. 이해가 안될 수 있지만 상사도 돌봐야 할 가정이 있는 사람이다. 이론적으로 동의하더라도 품질 때문에 포기해야 하는 것과 부정적 영향이 상사의 일자리를 날라가게 할 수 있다. 그들 입장에서는 이론과현실 사이에서 균형을 맞춰야 하는 것이다. 이런 상황이라면 다음과 같은 조금 다른 타협을 해야 한다.

단계 #3: 의견보다는 사실을 주로 강조하라
자동화 테스트는 코드 품질 유지에 있어 큰 역할을 한다. 자신만의 단위 테스트를 작성하고 수행함으로써 QA팀이 UAT(User Acceptance Testing)에 더욱 정확하게 집중하도록 할 수 있다. 테스트 자체도 논란을 잠재울 문서의 출처를 형성한다.

예를 들어, QA에서 기술적 버그를 발견했다고 알려왔지만 당신의 관점에서는 그들이 기술 요건을 잘못 해석했거나 오해한 것이다. 코드가 사실 의도한 대로 작동한다는 것을 입증하기 위해 테스트 결과를 근거로 제시하면서 대화를 객관적으로 유지하고 품질을 의견 분쟁이 아니라 하나의 사실로써 각인시킬 수 있다.

단계 #4: 합의하기 위해 협상하고 있음을 기억하라
경영진의 공감은 도움이 되겠지만 모든 것을 달성할 수는 없다. 성공에 대한 현실적인 지표를 확보해야 한다. 협상의 핵심은 주고받는 것이다. 경영진이 중요하게 여기는 프로세스를 파악하고 양질의 코드로 해당 프로세스의 10% 더 이룰 수 있는 경우가 있을 것이다. 다 포기하는 대신에 진행상황을 파악하고 다음 번에 추가적으로 10%를 더 얻을 수 있는 방법이 무엇일지 생각해보자. 장기적인 게임을 하면서 다른 관점에 대해서도 개방적인 자세를 유지하는 것이 중요하다.

품질에 관한 대화에서 좋은 사람들은 일련의 관점을 제시하고 궁극적으로 경영진이 결정을 내릴 가능성이 높다. 타협은 필수불가결하며, 자신의 노력이 실패했다고 생각할 이유가 없다. 하지만 위의 조언을 따랐지만 경영진이 스프린트 속도 지표를 절대로 포기하지 않는다면 어떻게 될까? 물러서야 할까 아니면 다른 방안을 찾아 떠나야 할까?

현실적으로 경영진과의 대화를 포기하고 새로운 일자리를 찾아볼 시기가 올 수 있다. 궁극적으로 자신만이 그 결정을 내릴 수 있다. 하지만 좋은 리더는 경청하며 건전한 문화는 다양한 관점에 대응하고 심지어 포용할 수 있음을 기억하자. 소프트웨어를 더욱 건전한 방식으로 개발하는 방향으로 조금이라도 전환하는 것에 저항하는 조직은 배우고 성장하며 좋은 코드를 작성하기에 최고의 일자리는 아닐 것이다.
 

코드 품질을 높이는 것은 가치 있는 일이다

코드 품질을 높이는 과정은 단순히 테스트 그 이상의 가치를 담고 있다. 일단 직접 테스트해보며 코드 작성 및 자동화를 다루는 능력을 높이며 전문성을 확보할 수 있다. 거기다 의사소통 능력도 좋아지고 새로운 관점을 받아들이고 더 강력한 업무 관계를 구축할 수 있다. 조직 전체에서 가장 좋은 방법으로 품질을 옹호하고 올바른 것을 옹호하며사용자들에게 더 좋은 경험을 제공하며 그들의 삶의 도움을 줄 수 있을 것이다.

*필자 제레미 두발(Jeremy Duvall)은 소프트웨어 품질 관리 솔루션 업체 세븐팩터 소프트웨어(7Factor Software)의 설립자다
ciokr@idg.co.kr
 Tags 코드품질 QA
Sponsored
IDG 설문조사

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

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

Copyright © 2023 International Data Group. All rights reserved.