기본 콘텐츠로 건너뛰기

[스타트업] [Insight] 사운들리 코드 품질 관리 이야기


[스타트업] [Insight] 사운들리 코드 품질 관리 이야기


 안녕하세요 "사운들리"입니다 :)


오늘은 사운들리의 코드 품질 관리에 대해 이야기 해보려 합니다.
몇몇 개발자에게는 지루하고 악몽같은 이야기일 수 있겠네요.
제 경우에는 예전에는 이런 품질이라는 단어를 멀리했지만 결국 제가 작성한 코드에 발목을 많이 잡히다 보니, 자연스레 관심을 갖게 되었습니다.

일단, 어떤 소프트웨어가 좋은 품질의 소프트웨어일까요?

좋은 품질이란?


 책에 나올법한 내용을 보면, 아래와 같은 항목을 토대로 소프트웨어 품질을 판단한다고 합니다.

ISO/IEC 9126 : Software engineering - Product quality

  • Functionality: 명시된 요구사항을 잘 충족했는지
  • Reliability: 명시된 조건과 시간 아래에서 일정 성능을 유지 하는지
  • Usability: 사용하기 위해 어느정도의 노력과 자원이 필요한지
  • Efficiency: 소모 자원과 성능간의 효율
  • Maintainability: 수정하기 위해 어느정도의 노력이 필요한지
  • Portability: 다른 환경에서도 사용 할수 있는지
출처: https://en.wikipedia.org/wiki/ISO/IEC_9126
 뭔가 복잡해 보이지만, 결국 개발자라면 위의 항목은 누구나 추구하게 되는 가치라고 생각 합니다.

그런데 말입니다. 이런 좋은 내용을 마음 속으로만 간직한 채 코드를 작성하면 정말 좋은 소프트웨어를 만들 수 있을까요? 저는 객관적인 방법으로 코드를 평가한다면 좋은 피드백이 될 것이라고 생각합니다. (물론 이 성적표를 남에게 보여주는 것과는 다른 문제에요 ㅎㅎ)

어떻게 품질을 체크하는가


 소프트웨어의 품질을 체크하는 데에 다양한 방법과 툴이 제시되고 있는데요, 저는 크게 두 가지로 분류 해보겠습니다.
  • 유저 입장의 품질: 유저의 요구사항에 맞는 소프트웨어인지 체크
  • 개발자 입장의 품질: 내가 지금 이 코드를 의도한 대로 잘 작성하고 있는지 체크
 유저 입장의 품질은 언급하지 않아도 중요함을 누구나 알고 있습니다. 이 부분이 만족이 되지 않으면 제품이 아니죠! 그래서 저는 개발자 입장에서 스스로 챙길수 있는 품질을 사운들리는 어떻게 챙겨보고 있는 지 이야기 해보도록 하겠습니다. 실은 제가 개발자 입니다 ㅎㅎ


사운들리 개발자의 코드는 아래와 같이 흘러갑니다.



<그림1> 사운들리 코드 개발상의 품질 관리 순서도
간단히 각 항목을 훑어 보겠습니다.

Local Machine
 각자 갖고 있는 맥북으로, 다양한 IDE를 사용해 코딩합니다. 그리고 git 을 이용해 commit 하고, github 에 push 하죠.
 push 된 수정사항은 pull request 를 통해 동료에게 알려집니다. 이후 코드리뷰를 통해 merge 하게 됩니다.
 코드리뷰는 많은 사람들에 의해 그 중요성이 부각되고 있습니다. 사운들리는 같은 모듈을 만드는 개발자끼리, 그리고 다른 모듈에 영향을 주는 코드일 경우에는 해당 모듈의 개발자도 리뷰를 합니다.
 코드리뷰를 통해 다른 사람이 어떤 기능을 작성했는지 보고, 오류도 찾고, 더 좋은 방법이 있으면 공유도 하고, 칭찬도 하고, 훈수도 두고 합니다.
 참고로 사운들리는 git-flow 정책에 따라 git branch를 운영하고 있습니다.

Jenkins 
 Github 에 commit 이 등록되면 Jenkins 는 자동으로 빌드를 시작 합니다. Jenkins 는 단순 빌드 성공 실패를 떠나서, 코드 품질에 대한 몇가지 report 를 발생 시킵니다. 아래에서 좀더 자세히 다뤄보겠습니다.

SonarQube
 Jenkins 에서 빌드하면서 SonarQube 에 포함된 분석 기능을 사용하게 됩니다.


그렇다면, 코드 품질의 지표는 무엇일까요?

Jenkins가 발생시키는 레포트를 통해서 알 수 있는 내용은 아래와 같습니다.
  • 코딩 스타일 체크 결과: 작성된 코드가 미리 정의된 코딩 스타일에 맞게 작성되어 있는지?
  • Unit Test 결과: 유닛 테스트 결과 (당연히 전부 pass 해야겠죠)
  • Test code coverage 결과: 테스트 코드가 전체 코드의 몇 % 를 커버 하고 있는지 (우리의 최종목표는.. 60%.. 덜덜덜)
  • 정적 분석 결과: 코드를 실행하지는 않지만, 코드 그 자체에서 발생할 수 있는 결함을 찾아줍니다.

 이 네 가지 레포트는 객관적 수치를 나타내주기 때문에 일종의 코드 품질 지표로 삼을 수 있습니다. 물론 이 지표만 잘 관리 했다고 해서 좋은 코드를 작성했다고 말할 수는 없습니다. 다만 좋은 코드를 작성하기 위한 기초 중의 기초라고 볼 수 있겠죠 :)



품질 체크를 위한 툴(tool)은 개발 언어에 따라 다를 수 있습니다.

 사운들리에서는 다양한 언어로 소프트웨어가 작성되어 있습니다. 따라서 언어마다 위의 결과를 얻기 위해서 서로 다른 툴을 사용하고 있습니다.


AndroidJavaJavascriptC/C++
코딩 스타일checkstylecheckstyle jshintcppcheck
Unit testjunitjunitmochagoogletest
Code coveragejacococoberturamocha-covgcov
정적 분석sonarqubesonarqube sonarqubecppcheck 

각 개발자는 위의 네 가지 결과를 얻기 위해서 빌드 시스템에 툴을 포함하여 개발하고 있습니다. 제가 주로 개발하고 있는 java 언어에 해당하는 툴들을 좀 더 자세히 살펴보겠습니다.

checkstyle
  • 코딩 스타일을 체크 해줍니다. xml 파일로 미리 정의 되어있고요. 매번 빌드할때마다 스타일이 틀린것을 지적해 줍니다.
  • 코딩 스타일은 중요합니다. 같이 개발하는 개발자와 코딩 스타일이 같다면 마치 내가 작성한 코드처럼 쉽게 읽을 수 있죠.
junit
  • junit 은 자바 유닛 테스트 프레임워크 입니다. 유닛 테스트 코드를 편하게 작성하게 해주고, 쉽게 테스트 결과를 볼 수 있습니다.
  • 유닛 테스트 코드를 작성하면 내가 작성한 모듈을 작은 단위로 테스트 해서, 작은 로직에서 발생하는 시시콜콜한 문제를 방지 할 수 있습니다. 테스트 코드를 작성해서 검증한 부분은 스스로도 신뢰가 갑니다.
  • 기능 수정간에 유닛 테스트에서 fail 이 나는 경우가 발생하는데, 모르는 사이에 다른 모듈에 영향을 준 것을 알게 됩니다. 다른 모듈에 모르고 영향을 주게 되면 뒷처리가 어려워지잖아요~
cobertura
  • code coverage 를 계산해 주는 툴입니다.
  • 유닛 테스트 코드가 실행되면, 작성된 코드의 각 부분을 실행하게 됩니다. cobertura 는 이때 각 코드의 어느부분이 실행되었는지 확인해서 통계를 내줍니다.
  • 주로 line coverage / branch coverage 두 지표를 보는데요, line coverage 는 해당 라인이 한번이라도 실행 되면 check 되고, branch coverage 는 각 라인에 있는 조건문을 다 따로 check 합니다. 당연히 branch coverage 를 달성하는게 어렵겠죠?
sonarqube
  • 소나큐브는 다양한 plug-in 을 통해서 정적 분석을 하고, 시각화를 해주는 툴입니다.
  • 사운들리는 주로 정적 분석 용도로만 소나큐브를 사용하고 있습니다. (지원하는 plug-in 을 보면 젠킨스와 기능이 겹치는 부분이 있습니다.)
  • 정적분석으로 실제 문제가 되는 부분을 찾는 경우도 있고, minor 한 부분에 대한 지적을 하는 경우도 있습니다. 그러나 이런 minor 한 부분도 꼼꼼하게 잘 챙겨야 좋은 개발자가 된다고 믿고 있습니다.

마치며


 여기까지 사운들리의 코드 품질 관리에 대해 이야기 해보았습니다. 품질 관리를 해보신 분은 아시겠지만, 이런 툴을 쓰다보면 항상 행복하게 코드 품질을 관리할 수는 없습니다.


 매달 세워놓은 목표를 달성하기 위해서 뼈를 깎는 노력으로 테스트 코드를 작성해야 되고, 당장 기능 수정해서 배포해야 되는데, 작성해 둔 테스트 케이스가 Fail 되어 말썽을 부릴 수도 있습니다.

 그렇지만 객관적 기준으로 코드 품질을 관리하다보면 어느샌가 큰 노력없이 좋은 코드를 작성하는 개발자가 되지 않을까 생각해 봅니다. 코드 졸면서 막 짜도 style warning 0건/ 정적분석 오류없음 / 테스트 코드 기본 탑재 뭐 이런 개발자 말입니다 ㅎㅎ


다른 개발자분들은 어떻게 자신이 작성한 코드의 품질을 관리하고 있는지 궁금하네요.
알고 계신 좋은 방법이 있다면 언제든지 공유 부탁드리겠습니다~!

오늘의 블로그 포스팅은 여기서 마치겠습니다.
읽어주셔서 감사합니다 :)

현재 사운들리에서는 웹 / 안드로이드 / 서버 개발자를 채용하고 있습니다. 관심 있으신 분들은 언제든지 사운들리의 문을 두드려주세요! 감사합니다 :) -> 채용 링크 바로 가기

댓글

  1. 실제로 이렇게 해서 코드를 관리하고 계신가요? 배보다 배꼽이 더 커진거 같은데. 저는 코드 주변 기능보다 코드 그 자체에 더 집중했으면 합니다. 코드 패턴 같은 것 아니면 코드 리팩토링 등.. 코드를 코드답게 작성할 수 있는 방법이 더 좋은 것 같습니다. 형식적인 것이 아닌 실질적인 코드관리를..

    답글삭제
    답글
    1. 툴을 사용해 코드 품질을 관리하는 건 호불호가 있다고 생각합니다. (불호가 많은걸로 생각합니다 ㅎㅎ)
      주로 부장님께 툴을 이용한 객관적 수치를 보고하고 매주 쪼임을 받는 환경에서 일하면 그렇게 된다고 생각합니다.
      다행히 사운들리에는 코드 커버리지가 떨어졌다고 점심을 굶기는 극악무도한 부장님은 없습니다 ㄷㄷ

      그리고, 이렇게 관리하는게 생각보다 오버헤드가 많지는 않습니다. 하루 이틀정도 환경 셋팅하면, 그 다음부터는 알아서 report 해주니까, 결과 보고 고칠거만 고치면 됩니다.
      말씀하신 '코드를 코드답게 작성하는 방법'은 제가 포스팅한 내용과는 좀 주제가 다르죠? 저 역시 말씀하신 부분에는 100% 공감합니다.
      다만 이 포스트에서 말하고자 하는건 툴을 이용해서 '기본적인' 품질에 대한 객관적인 관리를 하는 방법이 있고, 이러저러한 방법이다 뭐 이런거였습니다 ㅎㅎ
      저도 내공이 높아져서 코드 패턴이나 리팩토링같은 주제로 다른 분들이 편하게 읽을 수 있는 글을 쓸 날이 오겠죠 ㅎㅎ

      삭제
  2. 포스트처럼 관리하는 것에 저는 찬성하는 편입니다.

    Junit과 그 Coverage는 테스트케이스와 테스트 코드를 제대로 만들었다면
    얼마나 빈틈없이 코딩했는지. 쓸모 없이 만들어진 코드가 없는지 알려주는 좋은 지표라고 생각합니다.

    단, 테스트 코드를 제대로 만들지 않을 경우에는 필요가 없어질것 같네요.

    정적분석은..일부분은 불필요하지만 일부분은 역시 필요하다고 생각되네요.

    글쓰신분 말처럼 한번 설정하면 다음엔 자동으로 돌리게 되니
    나름 저비용으로 기본적인 품질 관리에 도움이 된다고 동의합니다.

    답글삭제
  3. 안녕하세요,
    코드 품질 관리에 관한 포스팅을 보니 반갑네요.
    저도 코드 품질에 관심 많은 개발자로서 관련 서비스를 개발하고 있어서^^

    개발자들한테 이런 정적 분석 도구의 사용이 꺼려지는 건 사실인 것 같습니다. 특히 위에서 어떤 규칙을 이만큼 지켜라 하고 강제가 되면 더욱요. 개발도 바쁜데, 이런 것까지 어떻게 챙기냐는 거죠.
    하지만 전 이런 도구의 사용이 코드 리뷰와 마찬가지로 지금 시간이 조금 걸리더라도 나중에 보상을 준다고 생각합니다. 기능을 확장하거나 다른 사람이 유지보수를 하거나 미래의 내가 코드를 볼 때도요. 그리고 도구에 내재된 best practice로부터 개발자의 잘못된 습관 등을 고칠 수도 있고요.

    특히 정적 분석을 개발 막바지에 검수 용도로 사용하는 경우가 많다 보니 그간 쌓인 코드에 비례해서 알람이 많이 나오고 그만큼 개발자는 부담을 더 느끼는 것 같습니다.
    최초 개발 단계부터 CI 등을 통해 분석 도구를 항시 사용하면 고쳐야 할 양도 많지 않고 방금 작성한 코드이니 컨텍스트가 유지된 상태에서 알람을 보게 되므로 보다 유용할 것이라고 생각되네요.

    JavaScript 코드 품질을 체크하는 정적 분석 엔진과 관련 서비스를 개발하면서 저는 다음과 같이 쓰고 있습니다. 이를 위해 자체 분석 엔진을 사용하는 에디터와 SonarQube 플러그인도 각각 개발했었고요.
    * 에디터(Visual Studio Code)의 플러그인을 통해 코드 작성 시 바로 체크
    ** ESLint로 스타일을 체크하고, 자체 개발 엔진으로 코드 이슈 체크
    * SonarQube 플러그인을 통해 CI로 매일 체크

    Java가 아니라 아쉽지만 JavaScript 품질 관리에 관심 있으시다면 여기를 둘러 보셔도 좋을 것 같습니다.
    * https://cimfalab.github.io/deepscan/2017/03/deepscan

    deepscan.io라는 서비스인데, GitHub 리파지토리의 JavaScript 소스를 정적 분석해서 에러나 코드 품질 관련한 코드 이슈를 리포팅해 주거든요.

    계속적인 코드 품질 관리 노력이 성공적인 제품으로 이어지시면 좋겠습니다.
    감사합니다.

    답글삭제

댓글 쓰기

이 블로그의 인기 게시물

[Insight] 안드로이드 백그라운드 서비스 개발시 고려해야 할 사항

[Insight] 안드로이드 백그라운드 서비스 개발시 고려해야 할 사항

지난 시간엔 사운들리 백엔드에 대해 설명을 드렸었죠. 이번 시간엔 사운들리 서비스중 클라이언트에 해당하는 안드로이드 SDK, 그 중에서도 백그라운드 서비스에 초점을 맞추어 설명을 해 볼까 합니다. 안드로이드의 특징 중 하나로 Service를 들 수 있습니다. 이 서비스란 녀석은 백그라운드에서 실행 될 수 있다는 점이 가장 큰 특징인데요. 물론 iOS 에서도 일부 지원은 합니다만 매우 제한적인 경우(음악 재생 등)에만 사용 가능합니다.
제가 생각하는 백그라운드 서비스 개발 시 유의 사항은 아래와 같습니다. 동작 기간 - 상시 동작 해야 하는가, 특정 조건에서 특정 작업을 할때만 동작 해야 하는가글로벌 프로세스 사용 유무 - 서로 다른 어플리케이션에서 접근이 가능 해야 하는가동작 조건 - 특정 시간 혹은 기간마다 동작 해야 하는가, 특정 이벤트 발생시 동작 해야 하는가그 외에도 많은 부분들이 있지만 일단 저 정도만 고려해도 개인적인 생각으로는 충분히 개발 가능하다고 생각 합니다. 그러면 각각에 대해서 좀 더 자세하게 알아 볼까요?
1. 동작 기간동작 기간에 대해서 이야기 하기 전에 먼저 유저 레벨에서 가장 많이 사용하는 Service 와 IntentService 의 차이점에 대하여 짚고 넘어가보겠습니다. Service 를 상속`Context#startService//Context#stopService` 혹은 `Context#bindService(w/BIND_AUTO_CREATE)//Context#unbindService` 를 통해 수명 조절 (Service 내에서 Service#stopSelf 를 호출하는 방법도 있습니다.)Service 시작된 이후에 커뮤니케이션 가능수명 종료 API(stopService or unbindService) 를 호출 하기 전에는 프로세스가 사라지지 않음 (물론 LMK에 의해서 종료 된다던지 등등이 있지만 여기서는 논외로 하겠습니다.)IntentService 를 상속start…

[스타트업] [Insight] 사운들리 방송 송출테스트 이야기

[스타트업] [Insight] 사운들리 방송 송출테스트 이야기
안녕하세요 "사운들리"입니다 :)


 오늘은 사운들리 사운드 비콘을 방송 콘텐츠에 실어 보내어 시청자의 모바일로 유용한 정보를 전달하기 위해 가장 중요하고, 힘들지만 마치고 나면 모든 팀원들이 가장 뿌듯함을 느끼는 방송 송출테스트 이야기를 하려 합니다.


송출 테스트, 사운들리가 그 어려운 걸 또 해냅니다.
<디지털 방송의 송출 경로>
 위 그림은 우리나라 디지털 방송의 송출 경로의 한 예입니다. 실제 방송국이 지상파인지, 종편인지, 기타 케이블 채널인지 등에 따라 세부적인 변화가 더 있을 수 있지만, 위 그림만 보셔도 충분히 복잡해 보이실 것입니다.
 우리나라는 DMB 등 일부 영역을 제외하고 디지털 방송 영역에서 대부분 미국식 표준 ATSC 관련 표준을 따르고 있지만, 유럽 국가와 뉴질랜드 등은 유럽식 표준인 DVB 관련 표준을 따르고 있습니다. 사운들리가 실제 송출테스트를 통해 증명하기 전까지 마주친 수많은 방송 실무자들, 방송 장비 업계 관계자, 학계 연구자들은 다양한 방송 장비에 의해서 사운들리 사운드 비콘이 유실되거나 왜곡되어 서비스가 불가능할 것 이라며 포기하라고 하였습니다.

 하지만 이렇게 복잡하고 다양한 환경에서 사운들리는 대한민국과 터키에서 모두 서비스를 성공(!)함으로써 미국식 디지털 방송의 대표적인 예인 대한민국과 전형적인 유럽식 디지털 방송의 예인 터키 모두에서 서비스 제공이 가능하다는 것을 증명해 냈습니다 :)


방송 송출, 그 험난한 검증의 시간  그렇다면 이렇게 복잡한 방송망을 거치고 나서도 사운들리 사운드 비콘이 시청자의 모바일로 안전하고 완전하게 전달될 수 있다는 것을 테스트하기 위해 어떤 과정을 거치는지 살펴보겠습니다.

 사운들리가 방송 쪽으로 사업 방향을 잡고 나서 가장 힘들고 오랜 시간이 걸린 부분 중 하나가 방송국들에게 기술의 안전성과 안정성, 정확성을 설득하는 것이었습니다.
기술의 안전성: 시청자 또는 반려 동물에게 선진국들의 가장 보수적인 규제 보다…