네이버 데뷰 세션 필기다. 네이버가 적용하고 있는 애자일 경험을 공유한 자리다.

순서

체크인 10분
부스탐방 이터레이션1,2,3 각20분
회고 10분

프로세스 부스
황상철 수석이랑 누군가가 설명
질문을 먼저.
질문들
“개발을 혼자 다 한다. 애자일을 따를 수 있다고는 하는데, 권장할 만한 체크리스트가 있나”
“조직에서 어떤 저항을 만났고 어떻게 했나”
“서버 클라이언트 등으로 나뉘어 있는데, 누구 땜에 안 되고 안 되고 이런 거 추정하려면 이슈를 뽑아 내야 한다. 일정 추정치랑 플래닝이 다른데”
“사용자 요구사항은 즉각 처리를 해 줘야 하는데, 그걸 스프린트에 넣는 게 힘들다”
“툴은 어떤 거 쓰나. CI도 쓴다고 했는데, 자동화된 빌드까지 하나”

프로젝트에서 애자일 프로세스를잘 따르나요?
QP: Quality Practice – 엔지니어링 프랙티스. TDD 등
반점개: 반복 점진개발 – 스크럼이란 말 안 쓰고 이거 쓴다. 99% 비슷하긴 하다. 저항 때문에 그랬다. 조직 내의 용어를 쓰는 게 안 좋을 수 있다. 근데 이런 용어를 쓰면 새로운 거라고 안 받아들이고 그래서 쉽게 따라오는 경향이 있다.
스크럼은 가벼운 프로세스다. 조금만 배우면 된다. 근데 가벼운 프로세스를 써도 그대로 무거운 내용을 다룬다. 문서도 마찬가지. 문서를 계속 만들면서 스프린트한다고 한다. 우리는 코드에 집중한다.
그러면 문서, 인수인계는 어떻게? 코드랑 완전히 일치하는 문서를 만드는 건 불가능하다. 결국 코드를 보여 주게 된다.
이토레이션 리뷰는 뭔가? 스크럼 하면 이터레이션을 하게 된다. 그게 끝나면 리뷰를 한다. 우리는 데모를 한다. 그냥 화면뿐 아니라 코드, UI 리뷰 다 한다. 뭘 보여 주는가가 큰 차이를 만든다.

추정과 플래닝

초기 추정을 한다. 플래닝 토크. 피보나치 수열로 해서 같이 만든다. 일정 빡빡하고 그러면 안 된다.
추정과 일정은 다르긴 하지만, 구분해서 잘 못 쓴다. 대신 리스크 관리를 한다.
우리는 최대한 잘게 나누게 한다. 최소 피쳐를 2맨데이 이하로만 되게 한다. 피쳐가 균일해지는 장점이 있다. 물론 되게 어렵다. 마이크로 매니지먼트가 리스크를 줄여 주는 효과는 분명히 있다.
작게 나누는 게 어려울 땐 어떻게? 주로 히스토리데이터를 많이 이야기한다. 경험 많은 사람들에게 물어 보고.
추정할 때 빠지기 쉬운 세 오류.
옵티미스트. 낙관주의. 너무 작다.
패스미스트리. 역량을 크게 보는 거.
전문가 추정. 한 사람이 고 하면 그대로 가는 거.
구간 추정을 해야 한다. 관리자들은 정확한 걸 좋아한다. 삼일 뭐 이렇게. 하지만 일이주 이렇게 하는 게 더 안전.
애자일 프로세스를 잘 따르나요?
아뇨. 근데 노력합니다.

이런 노력을 합니다.
노마드 엔지니어, 코칭은? 실제 프로젝트에 들어가서 같이 개발한다. 자기도 애자일 쓰고 남들에게도 전파한다. 나처럼 초반에 들어가서 방법론을 코칭하는 사람도 있다.
툴은 ZIRA를 쓴다. BTS라고 한다. BDS는 SVN 쓴다. 툴 사용 잘 하는 법을 전파하는 조직과 인력도 있다.
근데 중요한 건 이걸 쓰는 사람이다. 여기까진 안 온 것 같다.
“얼마나 됐나?” 1년쯤.
“저렇게 해서 잘 되면 따라올 거 같은데 성과가 있나?”

SI에서 관리자는 장벽이었다. 근데 NHN은 관리자들이 우호적이다. 근데 우리가 제대로 하고 있냐는 질문 되게 많다.
출시일이 다가오면 하기 싫어지지 않나?
관리자가 개발의 일부라고 생각하지 않으면 쪼게 된다. 근데 NHN에서 관리자는 개발의 일부가. 그러면 좀더 낫다.
애자일은 목표가 아니라 의미다. 저희 애자일 잘 적용했어요 하는 거 뽐내는 거 못봤다. 테스트해서 이렇게 오류를 줄였어요. 이런 거는 있다.
성과는, 일을 얼마나 했느냐 이걸 챙기겠죠.

TDD

커버리지 측정 –
긍정적인 측면: 아, 우리가 낮구나. 더 태스트를 만들어야겠다.
부정적인 측면: ㅇㅇㅇㅇ

테스트의 본질- 누가 시켜서 하는 게 아니라 실제 도움이 되야 하는 거다. 위에서 시키기도 하고.

효과는?
현재 큰 효과가 있는 것 같지는 않다. 제도화하기 전부터 혼자 하던 개발자가 있었다. 근데 이런 개발자들이 제도화하니 좀더 힘을 내고 있다.
팀장들에게 테스트코드 짜고 리팩토링해야 한다는 말이 먹힌다.
테스트를 진지하게 대하는 팀이 커버리지가 40% 막 이런다. 테스트에 대해 나이브한 팀은 70-80%까지 커버리지가 되고 한다. 커버리지가 모든 걸 말해 주는 건 아니다.
물론 수치를 박아두진 않는다. 언어별, 프로젝트별로 다른 건 있다.
근데 아예 안 짜는 건 안 된다는 거다.
개발자가 코드 개발하기 쉽고, 디버그하기 쉽다는 걸 느끼면 된다고 본다.
“자바스크립트나 UI테스트는?”
진도 러이브러리 등 쓰긴 한다. 근데 UI 인터페이스 테스트는 투자대비 효과가 안 나오더라. 기대치를 높여 잡으면 안 된다고 본다.
JS는 좋다고 해서 테스트 만들어 봤다. 근데 요새 경향은 ROI 안 나온다는 판단을
해 가는 거 같다.
웹서비스 인터랙션 테스트는, ROI 낮았다. 내가 하는 프로젝트엔 ATDD를 하고 있다. 너무 꼼꼼히 체크하려 한 거 같다. 그래서 굵직한 것 위주로 하고 있다. 현재까진 좋은 거 같은데 아직은 확신 못한다.
UI테스트가 기대만큼 안 되더라. 서버단에서 하는 건 정말 투자대비수익 짱이더라.
TDD 싫어하는 분 있는데, 그 분이 말하길 유틸리티는 진짜 TDD가 짱이라고 한다. 이거부터 시작하면 된다고 본다. 여기서 성공을 거두고 UI테스트로 넘어가면 될 거 같다.
“테스트 커버리지는 어떻게 측정하는가?”
자동화된 테스트를 기준으로 말한다. 전체 코드중 자동화된 테스트가 거쳐간 클래스가 얼마나 되는가 하는 거다.
“리팩토링한다고 했는데, 수치를 갖고 말할 수 있는 문화가 돼 있나”
팀장별로 다르다. 높으신 분은 해야 한다고 말씀한다. 리팩토링을 해서 잘 되면 더 높이 평가해 주는 문화 있다.
커버리지 안 돼 있고 하면 위험도가 높다.
단계적으로 접근했다. 처음엔 나름대로 정하는 걸로 시작했다. 부작용이 좀 있었다. 지금은 전사적으로 50%정도 뭐 이런 게 있다.
“커맨드 커버리지를 따로 측정하나?”
그런 팀은 없다.
코드를 잘 짜서 주석 안 쓰겠다 이런 식으로 생각하기도 한다. 근데 잘 조화를 이루는 게 좋다고 본다.
코드를 다른 사람이 봤을 때 알아보기 쉽게 하라. 근데 코드로 표현하기 힘든 건 있다. 대표적인 게 디자인 의도. 이런 건 주석을 해야 한다.
외부개발자와 함께 쓰는 공용 클래스도 주석이 필수다.

현황

NHN 내에 TDD하는 개발자 비율은 얼말까? 10%쯤 된다. 테스트 퍼스트라는 엄격한 기준을 적용하면 말이다.
대신 TDD에 적극적인 자세를 갖고 있다. 많은 개발자들은 나중에 테스트를 짠다.
제대로 하고 싶은 분들은 요청을 하면 지원하고 있다.
“ROI 측정은?”
그녕 경험으로 판단할 수밖에 없는 거 같다.
항상 스스로 고민이 되는 것 중 하나다. 이게 진짜 ROI가 나오나 하는.
“테스트 짜기 힘든 코드는 어떤 도움?”
FAQ 만들어 공유하고 한다.

CI – 지속적인 통합

도구로 하는 거다. 기계가 할 수 있는 걸 사람이 하는 걸 싫어 한다. 없어서 못한다? 그럼 만든다.
네이버 개발자 센터에 공개한다. 상당수가 CI 관련 도구다. 개발자 센터 자체가 오픈소스로 개발되고 있다. 엔포지라는 걸로 구축.

깨진 창문 효과

깨진 창문을 바로 수리하지 않으면 사람들이 거기 쓰레기를 버리고 막 이러면서 다른 데 영향을 준다는 거다.
소프트웨어도 버그를 발견했을 때 바로 픽스를 해야 한다.
문제가 있는 부분이있으면 바로바로 피드백을 해야 한다.
젠킨스(옛 허드슨)라는 툴을 이용한다.

빌드만 하는가?

테스트 실행/테스트 커버리지
정적 분석
코딩 스타일
복잡도와 중복 코드 체크
소프트웨어 품질 관리라는 책으로 나와 있다.
네이버 뉴스 CI서버.
QP on CI : CI 실행 결과를 한눈에 보여 주는 플러그인을 하나 만들었다.

얼마나 사용하나요?

200대의 서버에서 – 2000개의 프로젝트.
거의 전체 프로젝트가 이렇게 돈다.
10개의 플러그인을 만들었다. 30개의 플러그인을 사용한다.
젠킨스 유저 컨퍼런스 다녀왔는데 전세계에서 최고 사용량이다.
개발자가 볼 때 다 드러나는 느낌이 든다.

반발 vs 대응

내재화가 중요하다. 숫자가 왜 중요하냐.
-> 목적과 목표를 혼동 마라. 목적은 코드 품질이고 목표는 60%다. 목적만 잘 달성하면 목표는 잘 설명하면 된다.

테스트가 불가능한 코드를 만들지 마라. 샘플을 보여 줘라.

코드 품질을 보장하는 다른 수치를 정의해 가져 와라.

탑다운이 왠 말인가? 바텀업을 해야 한다 -> 변화는 모든 방향에서.

관리자가 볼 때

한 눈에 다 보고 싶다. 200대 서버의 결과가 퀄리티 대시보드에 들어온다.
전사적으로 적용했다.
좌절과 극복.
내 빌드 스크립트가 어떻게 도는지 몰라요.
정적 분석, 커버리지, 복잡도가 뭔가요?
망고폰 프로젝트는 어떻게 적용?
난 이런 모양으로 보고서를 보고 싶어요.
-> 3뇬 훈련, 100개의 위키 페이지

결과는?

장애가 50% 줄었다. 코드 테스트 커버리지가 50% 넘는다.
CI TDD Agile 중 뭐 덕분이냐. 모르겠다.
근데 모든 사람들이 CI을 당연히 여긴다. 이게 큰 소득이다. 일단.

성공 원인

Push 조직장의 끝없는 관심.
Direction 친절한 가이드.
Support 끝없는 기술지원.

젠킨스 플러그인 모두 공개 예정임.
공개 세미나도 있다. 11월 10일 2-6시.

PMI 회고

Plus 실제 대규모 적용 사례를 들어 좋았다.
Minus 모자란 시간 ㅠ
Interest 진짜로 이렇게 했다니!