SonarQube 그리고 코드 품질

당연한 것이, 당연하지 않은 것에 대한 고찰

B2C 프로젝트의 PM을 맡다 보니 챙겨야 할 것들이 꽤나 많다. 게다가 분석, 설계 그리고 개발까지 모두 외부 업체에 맡겼기 때문에 자체 개발보다 신경이 더  쓰인다. 이번 글에서는 프로젝트 코드 품질에 대한 기준을 마련하며 느꼈던 점들을 정리해 볼까 한다.

 

 

소프트웨어 코드 품질에 대한 기준은 사람마다 다르기 때문에 “정답”을 제시하기 어렵다. 때문에, 개발 착수 전에 코딩 스타일을 명확히 하고 용어 사전 등을 준비한다. 나아가 프레임워크를 적용하고 개발자들이 사용할 공통모듈을 만드는 등 제각각 일 수 있는 부분을 최소화하기 위해 노력한다. 

 

로직에 대한 자유도는 최대한 보장하되 품질을 저해할 수 있는 요소들은 최소화하는 것이 프로젝트의 생산성을 향상하고 향후 유지보수에서 생길 수 있는 이슈를 줄이는 지름길이다.

 

당연한 이야기를 재미없게 떠들고 있는 이유는 너무나 당연하다고 생각했던 이런 것들이 처해진 환경에 따라 당연하지 않음을 깨닫게 됐기 때문이다.

 

---

 

나의 첫 직장은 SI 업무를 주로 하는 규모가 큰 회사였다. 때문에 팀별 업무의 세분화가 당연했다. PM, PL, AA(Application Architect), TA(Technical Architect), DBA 그리고 분석/설계자, 개발자, QA, 테스터 등 각자 역할에 맞는 일들이 정해져 있었다. 심지어 심각한 이슈에 대한 전문 해결팀도 별도로 있었다.

 

AA 역할을 수행하던 나는, 위에서 언급한 대로 프로젝트 초반에 소프트웨어와 관련된 다양한 기준을 마련했다. 때론 AA와 PL을 병행하면서 프로젝트 종료 시점까지 개발자들을 이끌기도 했지만 업무가 크게 다르진 않았다. 개발 일정 관리와 공통모듈 개발 업무가 조금 더 많아졌을 뿐.

 

그런데, 이직한 회사는 많은 부분이 달랐다.

 

이직 후 팀원들에게 가장 많이 들었던 질문 중 하나가 ‘이전 회사에서 어떤 일을 했는가?’였다. “Application Architect”라고 이야기하고 구체적으로 이런 일을 했다고 설명했지만 다들 반응은 한결같았다.

 

 ‘그게 왜 필요한데?’라는 어리둥절한 표정.

고병우 作

 

 

 

새로운 회사에서 연구소 소속이긴 했지만, 회사의 주 업종이 IT가 아니었기 때문에 대부분의 시스템 개발은 처음부터 끝까지 개인이 알아서 해야 하는 구조였다. 인프라부터 보안 그리고 기획, 분석설계, 개발 심지어 운영에 이르기까지.(가내 수공업 같은 느낌이랄까…)

 

그냥 일당백 해야 하는 상황이니 세분화된 역할을 들었을 때 생소하고 난처하게 들리는 게 당연지사. 사실 그렇게 완벽하게 역할별로 나눠서 진행할 만큼 큰 프로젝트도 많지 않았거니와 설령 그런 프로젝트가 있더라도 거의 외주에서 개발하기 때문에 담당자는 관리하는 수준이었다.

 

---

 

개인적으로는 느낀 점도 많았다. 기존에 스페셜리스트로 성장해 왔던 한계를 많이 느끼고 ‘T’ 자형으로 성장할 수 있는 기회가 됐다.(서.. 성장한 거 맞지?! -_ -) 

 

그렇게 피했던 안드로이드 개발을 오자마자 딱;;; 덕분에 SPA에 대해서 더 많은 이해를 할 수 있었다. 만약 네이티브 개발을 하지 않았더라면, 하이브리드 개발이 아닌 웹 풀 스택 개발만 계속했더라면 반쪽 지식으로 남지 않았을까 하는 생각이다.

 

인프라는 나와 다른 세상이라고 생각했지만 AWS, Azure에서 FaaS 돌리고 있을 줄이야. 인프라를 보니 더 깊게 보이는 소프트웨어.

 

10년 동안 “백엔드 == 자바”로 살았지만 J 싫어하는 팀장님 덕분에 자바 빼고 다 쓰는 것도 나름 PL 수업 같아서 재밌었고… 정말 우물 안 개구리였다는 느낌이 많이 들었던 거 같다. 할 말이 너무 많지만 주제랑 멀어지니, 나중에 다시 한번 정리하는 시간을 가져 보기로 -0-;

 

---

 

아무튼 본인이 개발한 코드는 자신 책임지는 구조다 보니, 정말 이게 맞는지 제대로 하고 있는지에 대한 의구심을 느끼는 팀원들이 많았다. 그나마 걱정하는 팀원들은 다행이고 그냥 실행되고 에러 안 나면 감사한 경우도 다반사. 멘토링을 제대로 받기도 어려우니 결국 코드 품질은 알아서 하는 정답 없는 미지의 영역으로 자리 잡고 있더라.

 

해서, 이번 프로젝트에서는 개발 초기부터 SonarQube를 적용해 보기로 했다. 사전 개발자 교육을 통해 SonarQube 사용 방법을 전파하고 어떻게 흘러가는지 봤다. 프로젝트 초반이지만 한 가지 확실한 건 개발자들이 코드 품질에 대해 생각하고 자신의 코드에 대해 한번 더 고민하고 있다는 사실이다.(무.. 물론 모든 개발자가 그런 건 아니다 -_ -;;)

 

특히, 코드 중복을 해결하면서 이런 부분이 많이 보였는데, 단순하게 함수의 분리, 추출로 시작했지만 깔끔한 코드를 만들어 가며 스스로 패턴을 만드는 모습을 볼 수 있었다. (백날 패턴 책 봐도 이해 안 되는 것들이 본인 코드 리팩토링 하면 피부로 확 와 닿음)

 

무엇보다, 저변이 넓어서 프레임워크나 패턴이 대중화되어있는 컴파일 언어의 코드들 보다 최근 뜨고 있는 인터프리터 언어들의 코드 품질이 눈에 띄게 좋아졌다. 

 

프로젝트가 끝날 때 또 다른 내용들로 정리할 수 있는 기회가 있기를 바라며, 지금까지 느낀 점들을 끄적거리며 마무리한다.

 

• 프로젝트 완료하고 코드 고치려면 비용 커지는 만큼 개발자 짜증지수도 높아진다. 종료된 프로젝트에 SonarQube 적용할 시도도 하지 말아라;;
  
  
• 코드 리팩토링은 가급적 잦은 주기(못해도 하루에 한 번)로 가이드 하자. 마찬가지로 코드 길어지면 Duplicaiton, Complexity 확률 높아진다
  
  
• 개발자들은 리팩토링에만 신경 쓸 수 있도록 분석 동작은 CI를 통해서 최대한 자동화 하자
  
  
• 분석 결과 추이를 개발자들에게 공유해서 게임적인 요소(CI에 그래프 위젯으로 표시 등)를 활용하면 생각보다 개발자들이 재밌어한다.
  
  
• Duplication이나 Complexity 해결한 소스코드 인스펙션 해서 개발자들과 공유하고 해결한 개발자는 칭찬하자. 이거 생각보다 남녀노소 다 뿌듯해한다.(개발 자부심 뿜뿜)
  
  
• IDE Lint Plugin 적용하면 코드 반영하기 전에 고칠 수 있어서 개발자들이 더 선호할 거 같지만, 오히려 IDE 컴파일 에러처럼 보여서 싫어하더라. 그냥 SonarQube 사이트에서 보고 고치면서 뭔가 숫자 줄어드는 희열을 즐기는 분위기랄까 =0=;; (이건 케바케라 믿어 의심치 않는다.)