그런 식으로 남이 말하는 걸 열심히 주워들은 덕분에, 우리는 애자일 방법론을 몸소 체험해보지 못했더라도 애자일 방법론에서 파생된 단어가 낯설지 않다. 담고 있는 의미를 얼추 설명할 수도 있다. 좀 더 자세한 내용을 찾아보기 위해서 책과 아티클을 따로 읽어본 사람이라면 거기서 이야기하는 각종 사례를 바탕으로 애자일 방법론을 도입한 팀의 업무가 어떤 식으로 굴러가는지도 얼추 짐작할 수 있으리라.

바로 그게 문제다. 우리는 ‘얼추’ 설명할 수 있고, ‘얼추’ 짐작할 수 있다. 얼추란 무엇인가? 사전적 의미는 다음과 같다.

얼추

1. 어지간한 정도로 대충.
2. 어떤 기준에 거의 가깝게.

얼추 = 대충

요약하자면 우리는 지금까지 애자일을 ’대충’ 설명할 수 있었고, 애자일을 도입한 조직이 어떤 식으로 업무를 진행할지 ‘대충’ 짐작할 수 있었다. 우리는 명확히 알고 있는 게 하나도 없다. 남이 이야기하는 애자일 방법론을 듣기만 했지 제대로 된 애자일 방법론을 도입해서 업무를 처리하는 조직을 몸소 경험하지 못했기 때문이다.

방법론은 그 자체가 글자로 쓰여진 이론에 불과하기에 조직에 도입하기 전 체계적인 연구가 필요하다. 또한, 조직이 최고의 효율을 보이며 업무를 수행할 수 있게 도와주는 방법론을 결정하는 과정도 빈말로 쉽다고 할 수 없다. 수많은 고민이 필요하고, 그걸 잘 해낼 수 있는 전문가가 필요하다.

대다수 조직은 가만히 앉아서 방법론만 연구하고 있을 리소스가 없다. 눈으로 확인할 수 있는 성과를 내야 하므로 서비스 개발하기 바쁘다. 그래도 업무처리 방식을 정하긴 해야 되니, 타 조직에서 도입한 방법론을 가져다가 우리 조직에 맞춰서 약간 수정하는 과정을 거친다. 물론 수정 작업을 진행한 사람이 방법론 전문가가 아닌 건 당연지사다.

이 과정 끝에 만들어진 업무 처리 방식이 조직 내에 도입되면, 우리가 제대로 된 방법론을 몸소 느껴봤다고 이야기할 수 있을까?

조금만 덜 대충 해보자.

애자일 방법론을 제대로 사용하면서 업무 프로세스를 끌어나가는 조직을 만나는 건 모래사장에서 바늘 찾는 일만큼 어렵다. 현실이 이러므로 경험해보지 못한 게 당신 잘못은 아니다. 경험해본 사람도 그런 당신을 이해해주리라. 다만, 그러한 그들의 태도가 당신이 계속 대충 아는 상태로 남아도 된다는 의미는 아니다. 경험 못 해봤더라도 어쨌든 지금보다 더 자세히 알긴 알아야 한다.

자세히 알기 위해서 가장 좋은 방법은 직접 경험해보는 거지만 이건 당장 실천할 수 없으니 제쳐두자. 두 번째 방법은 시중에 나와 있는 좋은 책을 사서 읽는 건데 현대인의 독서량이 점점 떨어지고 있는 상황이 바로 지금 우리네가 살아가고 있는 현실에서 펼쳐지고 있기에 감히 시도하라고 말하진 않겠다. 어차피 사서 안 읽을 거 아닌가? 아니면 아예 사지도 않거나. 그럴 거면 그 돈으로 맛있는 거나 사서 먹자.

나는 당신에게 앞으로 소개할 세 번째 방법을 추천한다. 직접 경험도 해보고, 관련 책도 찾아서 좀 읽어본 사람이 잘 정리한 글 을 찾아서 읽어라.

잘 정리한 글의 글쓴이는 몸소 애자일한 업무 프로세스를 체험해봐서 그런지 현실과 이상의 차이점을 알고 있다. 글쓴이는 잘 정리한 글을 쓰기 전에 당신이 사지 않은, 혹은 읽지 않은 책을 대신해서 사고, 읽었다. 그렇게 글쓴이는 직접 체험한 경험과 책을 통해 얻은 지식을 자신이 쓴 글 속에 녹였다. 직접 겪은 경험과 직접 얻은 정보를 당신에게 공유하고 전달하기 위함이다.

잘 정리한 글의 글쓴이가 바로 나라고 당당히 소개하고 싶지만, 아직 미숙한 면이 없지 않아서 외침은 삼가겠다. 나보다 먼저 잘 정리한 글을 쓴 사람이 인터넷에 널려있는 게 현실이니까. 그러나, 현실이 그렇다고 내가 잘 정리한 글의 글쓴이가 될 자격과 기회가 없어졌다는 소리는 아니다. 정말로 자격과 기회가 없어졌으면 이 글을 쓰지도 않았다.

잘 정리한 글의 글쓴이 무리에 합류하기 위해서, 당신에게 경험과 지식을 공유하기 위해서 나는 키보드를 두드렸다. 그러니 당신이 이 글을 읽고 난 후, 적어도 스프린트와 KPT 만큼은 조금만 덜 대충 알고 갈 수 있기를 바란다.

추가로, 하필 수많은 애자일 방법론 속 키워드 중에서 스프린트와 KPT 만 이야기하는 이유가 무엇이냐고 묻는다면 나는 이렇게 대답하겠다.

“지금 내가 속한 팀에서 쓰려는 게 저 두 개예요.”

그래도 애자일이 뭔지는 좀 짚고 넘어가자.

우리는 애자일이라는 단어를 지긋지긋하게 들어봤다. 애자일이 도대체 뭘까? 다른 사람은 애자일을 어떻게 설명하고 있을까? 나는 구글에서 검색해봤다.

‘애자일이란?’ with Google

키보드의 엔터키를 누르거나 검색창 우측의 돋보기 모양 버튼을 마우스로 클릭하면, 구글은 웹 브라우저 화면에 애자일이 뭔지 설명하는 수많은 블로그 포스팅 리스트와 위키백과의 사전적 정의를 담은 박스 엘리먼트를 출력한다. 위키백과는 애자일을 다음과 같이 설명한다.

애자일 소프트웨어 개발 혹은 애자일 개발 프로세스는 소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기동안 반복적인 개발을 촉진한다. 출처 : 위키백과

음. 소프트웨어 엔지니어링에서 쓰이는 ‘개념적인 뭔가’ 가 애자일이고, 애자일을 사용하면 프로젝트가 살아있는 동안 반복적인 개발을 촉진한다는 건 알겠다. 그 이상은 모르겠다. 네이버에서 똑같이 검색해보자.

‘애자일이란?’ with NAVER

네이버는 애자일의 정의를 말하는 지식백과 리스트와 동영상, 이미지, 타 웹사이트 링크, 네이버 블로그 포스팅, 지식인 등 수많은 내용을 웹 브라우저 화면에 출력한다. 가장 상단에 위치한 지식백과 리스트 중 첫 번째 아이템은 애자일을 다음과 같이 설명한다.

애자일은 2000년대부터 주목받기 시작한 소프트웨어 개발 방식이다. 계획이나 문서화 작업보다는 프로그래밍 과정에 초점을 두고 있다. 고객의 피드백을 적극적으로 반영… 출처 : 네이버 지식백과 <용어로 보는 IT>

모두가 애자일이라고 부르는 ‘개념적인 뭔가’ 는 반복적인 개발을 촉진시키다 못해, 계획이나 문서화 작업보다 프로그래밍 과정에 초점을 두는 특징을 가지고 있는 거 같다. 고객의 피드백을 적극적으로 프로젝트에 반영함은 물론이다.

어떤가. 좀 더 지식이 확장되었음을 느끼는가? 솔직히 말해서 나는 잘 모르겠어서 옆에 있는 책을 바로 펼쳤다. 애자일을 도대체 뭐라고 설명해야할까? 그런 고민과 함께 책의 페이지를 넘겼다. 참고로 내가 읽은 책은 2020년 12월 4일 초판 1쇄가 발행된 로버트 C. 마틴이 쓴 <클린 애자일Clean Agile>이다.

‘애자일이란?’ with Clean Agile

로버트 C. 마틴은 클린 애자일 책에서 애자일을 다음과 같이 설명한다.

애자일은 프로젝트를 더 작은 반복 주기로 나누는 프로세스다. 각 반복 주기의 결과물을 측정하여 지속적으로 일정을 평가하는 데 사용한다. 기능은 비즈니스 가치 순서대로 구현하므로 가장 중요한 것이 먼저 구현된다. 품질은 가능한 한 높게 유지한다. 일정은 주로 범위를 조절하여 관리한다. 이것이 애자일이다.

오, 이제 뭔가 좀 알겠다. 애자일은 ‘프로젝트를 더 작은 반복 주기로 나누는 소프트웨어 개발 방식’ 인 거 같다. Google과 NAVER에서 찾은 문장까지 합쳐서 정리해보자. 애자일이 ‘더 작은 반복 주기로 개발을 촉진하고, 계획이나 문서화 작업보다 프로그래밍 과점에 초점을 두는’ 특징을 가지고 있다는 걸 확인할 수 있다.

당신은 이제 대충 애자일이 뭔지 감이 잡혔다… 라고 생각할 것이다.

자. 여기서 다시 한 번 대충 이라는 단어가 나왔다. 잠깐 스크롤을 위로 올려보자. 내가 대충 넘어가지 말자고 앞에서 이야기한 문장을 다시 확인할 수 있다. 난 적어도 당신이 덜 대충 알고 갈 수 있게 글을 쓰기로 마음을 먹었다. 그래서 다음 키워드인 스프린트로 넘어가기 전에 애자일을 조금만 더 파고 들어갈 생각이다.

왜 애자일이 등장했을까?

왜 프로젝트를 더 작은 반복 주기로 나누는 프로세스가 필요했을까?

여기에 대한 히스토리를 알게 되면 당신은 애자일을 덜 대충 이해하고 넘어갈 수 있다. <클린 애자일> 속 내용을 좀 더 알아보자.

애자일 덜 대충 이해하기

팀 단위로 협업해본 사람은 안다. 프로젝트 매니저, 즉 관리자가 팀에 대한 데이터를 파악하고 있어야 업무 프로세스가 원활하게 굴러간다. 여기서 데이터는 팀원의 시시콜콜한 정보 따위를 말하는 게 아니다. 관리자가 파악할 데이터는 바로 팀의 업무 속도, 팀의 목표 달성치를 의미한다.

관리자는 어떤 수단을 통해 그 중요한 데이터를 파악하고 있을까? 제 두 눈으로 직접 팀이 일하는 모습을 관찰하면 데이터를 주르륵 뽑을 수 있을까? 아니다. 그런 방법 만으론 팀이 어떤 속도로 움직이고 있는지, 팀이 목표를 달성하기까지 얼마나 남았는지 파악할 수 없다. 관리자는 직접 업무에 발을 담구지 않는 사람이라는 걸 명심하자.

소프트웨어 개발팀은 ‘마감 기한은 바뀌지 않지만, 요구 사항은 끊임없이 바뀌는 프로젝트를 성공적인 결과로 이끌어야 하는’ 세상 속에서 살고 있는데, 프로젝트 매니저가 팀에 대한 데이터를 파악하고 있지 않으면 그 세상은 과연 어떤 식으로 돌아갈까? 어떤 결말을 맞이하게 될까?

1. 우선 회의를 하겠지

두둥.

프로젝트 시작을 알리는 회의가 열렸다. 조직장은 말했다.

“새로운 프로젝트를 수주했습니다. n월 m일에 끝날 예정입니다. 아직 정확한 요구 사항은 모릅니다. 아마 1, 2주 정도 안에 전달될 겁니다. 자, 요구 사항 분석하는 데 얼마나 걸릴까요?”

당신을 포함한 소프트웨어 개발팀에 속한 이들은 쉽게 말을 꺼내지 못하고 눈치만 보고 있다. 당연하다. 쉽게 대답할 수 있는 질문이 아니니까. 침묵이 이어지고 있는 와중에 어느 한 명이 용기를 ‘조금’ 내서 중얼거렸다.

“하지만 아직 요구 사항이 뭔지도 제대로 모르는데요.”

조직장이 소리쳤다.

“요구 사항이 있다 치고 해보자는 거죠! 일이 어떻게 돌아가는지 다 알잖아요. 모두 전문가 아닙니까? 제가 지금 정확한 날짜를 말하라는 게 아닙니다. 러프하게라도 일정을 잡아야 하니까 물어보는 겁니다. 참, 만약 분석 과정에 두 달이 넘게 소요된다고 하면 이 프로젝트는 그냥 접는 게 나아요. 알아 두세요.”

누군가의 입에서 되묻는 것처럼 “두 달?”하고 작게 웅얼대는 소리가 흘러나오자, 조직장은 그걸 냉큼 의견으로 받아들이며 외쳤다.

“좋아요! 제 생각도 그래요. 두 달이면 충분할 거 같습니다. 자, 그러면 설계에는 시간이 얼마나 걸릴까요?”

조직장의 선언이 다시 한번 모두의 뒤통수를 쿵 치고 지나갔다. 충격에 말을 잃었음은 물론이다. 오늘 날짜로부터 n월 m일까지 6개월밖에 남지 않았다는 사실이 조직장을 제외한 팀원의 머릿속을 스치고 지나갔다. 그리고, 조직장이 듣고 싶은 답이 정해져 있음을 깨달았다. 당신은 말했다.

“두 달요?” “좋아! 정확해. 제가 생각한 거랑 똑같네요. 그러면 분석에 두 달, 설계에 두 달을 쓰고 남은 두 달 동안 구현하는 데에 집중해봅시다. 모두 회의하느라 고생 많았어요.”

와, 정말 시간 낭비 그 자체다. 쓸모없는 회의의 대명사라고 위 사례를 소개할 수 있으리라.

소설처럼 사례를 설명한 만큼, 저게 정말 현실에선 일어나지 않는 일이었으면 좋겠다.

안타깝지만 저건 현실이다. 나는 저런 개노답 회의를 종종 겪어봤다. 당신도 마찬가지일 것이다.

2. 어찌 됐든 분석을 하긴 해야 하는데…

자. 요구사항이 1, 2주 걸려서 팀에 떨어지긴 했다. 이제 분석 단계에 들어갈 시간이다.

어… 분석 단계에서 정확히 무슨 일을 하면 좋을까? 요구 사항을 정교하게 다듬는 일? 데이터 모델 및 객체 모델 미리 만드는 일? 목업 컴포넌트 만드는 일? 프로젝트 규모를 추산하는 일? 실현 가능성 검증? 인력 계획? 프로젝트를 마칠 수 있는지에 대한 여부 파악?

이처럼 분석이 도대체 뭔지 정확히 알지도 못하는 상태로 당신은 두 달이라는 시간을 보내야 한다.

뭐, 행복할 거다. 분석을 빌미로 웹 서핑도 좀 하고, 주식 장도 좀 보고, 고객 인터뷰도 하고, 분석한 데이터-뭘 분석한 건지 모르겠지만-를 가지고 차트도 그려볼 테니까.

그렇게 두 달이 지나면 분석은 놀랍게도 알아서 끝난다.

뭐지? 왜 분석이 끝났을까? 사실 위에 나열한 것만 보면 딱히 분석이라고 부를만한 일을 한 것도 없다. 그냥 월급 루팡의 일상에 불과하다. 근데 분석이 끝났다고 다들 손뼉을 치고 조직장은 팀원을 칭찬하고 회식 자리를 만들고 작은 난리를 피운다.

이건 다 분석 단계에 할당된 두 달이라는 시간이 모두 지났기 때문이다. 그냥 단순히 해당 단계를 처리하라고 주어진 시간이 다 지났기 때문에 다음 단계로 넘어가는 거다.

3. 설계할 시간이다. 어, 잠깐만. 분석한 게 없는데?

뭐, 그래도 설계 단계는 얼추 돌아간다. 분석보다는 조금 더 명확하게 해야 할 일이 보이기 때문이다.

소프트웨어 설계란 프로젝트를 모듈별로 나누고, 각 모듈 간의 인터페이스를 구성하는 것을 말한다. 각각의 모듈과 인터페이스를 구성하기 위해 팀을 나누고, 나누어진 팀과 팀은 어떻게 연결할지 고민하는 단계라고 보면 된다. 현실적으로 달성 가능한 구현 계획을 만들기 위한 일정 조정도 보통 이 단계에서 이루어진다.

물론 설계 단계가 순순히 흘러가란 법은 없다. 예상하지 못한 일은 이곳저곳에서 발생한다. 새로운 기능이 추가되고, 기존 기능은 빠지거나 변경된다. 답이 나오질 않아서 요구 사항을 다시 분석해보고 싶지만 앞 단계로 돌아가기엔 시간이 없다. 그러니 적당히 땜빵해서 설계의 구멍을 메꾼다.

와! 그렇게 두 달이 지나니까 알아서 설계가 끝난다! 다시 또 두 달이 지났으니까!

단계를 처리하라고 주어진 두 달의 시간이 전부 어디론가 사라지고 남은 건 구멍 숭숭 뚫려서 답 없는 소프트웨어 설계도뿐인데 설계가 끝났단다.

뭔가 불안한 마음이 싹트는 와중에 다들 손뼉을 치고 조직장은 팀원을 칭찬하고 회식 자리를 만들고 작은 난리를 피운다 2.

뭐, 분석하고 설계는 어쩔 수 없이 이런 식으로 넘어가야 하는 건 맞다. 분명한 완성 기준이 없어서 진짜로 분석이나 설계가 끝났는지 알 방법이 없다.

그러나 구현은 다르다.

4. 구현만이 남아있다. 지옥이 다가온다.

구현은 완성 기준이 명확하다. 완성된 것처럼 꾸밀 방법은 없다. 당연히 해야 할 일은 모호하지 않다.

당신은 코딩한다. 코딩하고, 코딩을 한다.

그 와중에 요구사항은 계속 바뀐다. 새로운 기능이 계속 추가되고, 기존 기능은 계속 빠지거나 변경된다.

으악! 요구사항을 다시 분석하고 설계하고 싶지만 이제 진짜 마감 기한까지 얼마 남지 않았다. 계속 코드를 땜질한다. 땜질, 땜질, 땜방. 걱정할 시간 따위 없다. 야근만이 있을 뿐.

그러다가 마감 기한이 거의 코앞으로 다가왔을 때쯤, 누군가가 말한다.

“저, 이거 마감이 언제죠? 언제까지 완성해야 하죠?”

소프트웨어 개발팀은 주어진 시간이 얼마 남지 않은 상황에서 마감 기한까지 구현 단계를 절대 끝낼 수 없다는 걸 알아차리게 됐다. 동시에, 이해관계자는 프로젝트에 문제가 생겼다는 걸 마감 기한이 얼마 남지 않은 시점에 와서야 처음으로 전해 듣게 될 것이다.

와. 당신은 이해관계자의 불만을 상상할 수 있는가?

“분석 단계에서 우리에게 알려줄 수는 없었습니까? 프로젝트 규모를 산정하고 일정을 맞출 수 있는지 가늠하는 건 분석 단계에서 해야 할 일 아닙니까? 설계 단계에서는요? 요구사항을 모듈별로 나눈 후, 그 모듈을 팀별로 할당하고, 인력 수요를 계산하는 일이 설계 단계에서 해야 할 일 아닙니까? 왜 이제 와서 문제가 생겼다고 말하는 거죠?”

5. 지옥의 끝이 보이지만…

고객은 이미 화가 났고 이해 관계자도 화가 났다. 압박은 심해지고 야근 시간은 급증한다. 그만두는 사람이 하나둘 늘어난다. 지옥이다.

그래도 뭐, 한 3~4개월 시간을 보내고 나니 고객의 초기 요구 사항 중 절반 정도는 그럭저럭 해내는 소프트웨어를 만드는 데 성공했다. 와, 끝났다… 기뻐하긴커녕 상심한 모두는 다짐한다. 다음엔 이렇게 안 한다. 제대로 할 거다. 더 분석하고, 더 설계해야지!

과연…

자, 아주 끔찍한 사례를 하나 살펴봤다. 업무 프로세스에 폭포수 모델을 사용했을 때 발생하는 일이고, 프로젝트 매니저가 팀에 대한 데이터를 제대로 파악하지 않았을 때 펼쳐지는 지옥도다.

뭐, <클린 애자일> 이라는 책 속에 나도는 이야기니 과장도 어느정도 포함되어 있으리라. 실제로 <클린 애자일> 에서 로버트 C. 마틴은 이런 말을 한다.

“이 이야기는 과장일 수 있지만, 한 편으로 사실이기도 하다.”

나는 이 말에 공감한다. 과장같지만, 사실이다. 나도 경험해본 적이 있다. 이 글을 읽는 당신도 아마 경험해본 적이 있을 것이다. 경험자인 우리는 다시금 생각한다.

우리 소프트웨어 개발자는 위와 같이 프로젝트가 진행되는 걸 원하지 않는다.

그래서 애자일이 나왔다.

애자일의 정의를 다시 한 번 살펴보자.

애자일은 프로젝트를 더 작은 반복 주기로 나누는 프로세스다. 각 반복 주기의 결과물을 측정하여 지속적으로 일정을 평가하는 데 사용한다. 기능은 비즈니스 가치 순서대로 구현하므로 가장 중요한 것이 먼저 구현된다. 품질은 가능한 한 높게 유지한다. 일정은 주로 범위를 조절하여 관리한다. 이것이 애자일이다.

위 정의처럼 애자일은 전체 프로젝트를 마감 기한에 맞춰서 일정한 크기로 더 작게 나눈다. 이걸 반복 주기 또는 스프린트라고 부른다.

첫 번째 반복 주기를 반복 주기 0이라고 하는데, 이때 스토리를 만든다. 스토리는 프로젝트에 들어갈 기능 목록, 즉 개발자가 개발해야 하는 기능이라고 생각하면 된다. 반복 주기 0 동안 개발 환경을 준비하고, 스토리의 크기를 추산하고 최초의 계획을 ‘단순하게’ 세운다. 개발자와 기획자, 디자이너는 만들어진 스토리를 바탕으로 프로젝트의 밑그림을 그린다. 프로젝트가 끝날 때까지 이러한 분석과 설계 과정이 끊임없이 반복된다.

어라? 이상하다고 생각한 사람 분명히 있으리라. 왜냐하면 분석과 설계를 반복하는 건 위에 나온 폭포수 모델과 다른 구석이 없어 보이기 때문이다. 분석과 설계를 거치는 크기를 작게 만들었을 뿐, 애자일은 폭포수 모델과 다를 바가 없어 보인다.

하지만 그렇지 않다. 애자일은 반복 주기 전체에 걸쳐서 요구 사항 분석, 아키텍처 수립, 설계, 구현 작업이 끊임없이 일어난다. 설계 단계에서 분석 단계로 다시 회귀할 수 없는, 구현 단계에서 설계 단계로 다시 회귀할 수 없는 폭포수 모델과는 확연히 다르다.

이렇게 분석, 설계, 구현 작업이 특정 주기 동안 끊임없이 일어나면, 자연스럽게 특정 주기 하나 동안 개발팀이 스토리를 얼마나 완료할 수 있는지에 대한 수치를 측정할 수 있다. 관리자는 소프트웨어 개발팀에 대한 데이터를 얻을 수 있고, 데이터를 기반으로 계획을 조정하거나 프로젝트의 종료 일자를 명확히 계산할 수 있다.

물론 오차가 커서 초기에 예상했던 프로젝트 종료 일자보다 훨씬 더 먼 미래의 날짜가 계산될지도 모른다. 그럼 이제 관리자는 개발팀의 희망을 부술 일만 남았다. 관리자가 “개발 어떻게 되어가요?” 라고 물었을 때, “나쁘지 않아요. 괜찮아요.” 라고 대답하는 개발팀이 품은 희망을 부숴야 한다.

애자일은 빠르게 나아가는 게 아니다. 우리가 얼마나 망했는지를 최대한 빨리 아는 것이다. 그래야 망한 상황 속에서도 최선의 결과를 얻을 수 있다.

상황이 망해버리고 나면 이후는 어떻게 흘러갈까? 뻔하지 않겠는가. 일정을 변경해보거나, 인력을 추가하거나, 품질을 포기하거나, 개발 범위를 변경하거나, 비즈니스 가치에 따라 개발 순서를 변경하거나…

프로젝트가 망해도, 얼마나 망했는지 최대한 빨리 알아차린 다음 망한 상황 속에서 최선의 결과를 얻기 위해 발등에 불난 듯 뛰어서 해결책을 마련하는 업무 프로세스.

이게 바로 애자일이다.

애자일 소프트웨어 개발 선언

반복 주기 또는 “스프린트”

애자일을 덜 대충 알 정도로만 설명했는데 글이 어마어마하게 길어졌다. 하지만 걱정하지 않아도 된다. 애자일 설명이 고비였고, 스프린트나 KPT 에 대한 설명은 아주 쉽고 짧게 끝날 예정이다. 예고편이 본편보다 길어진 꼴이 되었지만 애자일이란 게 원래 이런 녀석이다. 어쩌겠는가?

자, 위에서 언뜻 키워드가 나오긴 했지만 한 번 제대로 사전에서 찾아보자. 스프린트를 과연 뭐라고 정의하고 있을까? 네이버 국어사전은 다음과 같이 스프린트를 정의하고 있다.

스프린트(sprint)

1. 체육 육상, 수영, 스피드 스케이트 따위의 단거리 레이스. 또는 단거리를 전력으로 수영하거나 달리는 일.
2. 체육 자전거 경기에서, 트랙을 두 바퀴 또는 세 바퀴 돌아 도착한 순서를 겨루는 경기. 거리는 대략 1,000미터이고, 마지막 200미터에서 전속력을 낸다.

쉽게 말하면 단거리다. 짧은 거리, 짧은 시간 동안 결판을 내는 스포츠의 주기가 바로 스프린트다. 애자일을 스포츠에 비유해보면 더 이해하기 쉬울 것이다.

전체 프로젝트를 마라톤 코스라고 생각하자. 마라톤 코스를 단거리 수준으로 잘게 쪼갠다. 그리고, 쪼갠 만큼 우선 달려본다. 목표 지점에 도착했을 때 처음 생각했던 것보다 선수가 더 지쳤으면 다시 한번 코스를 쪼갠다. 생각보다 선수가 더 잘 달리면 코스를 조금 더 늘린다. 몸 상태와 코스 상태를 분석하고, 목표 지점까지 무사히 달릴 계획을 설계하고, 달린다.

애자일과 비슷하지 않은가? 그래서 스프린트라는 키워드가 애자일에 등장하게 된 것이다.

다만 여기서 하나 다시 한번 짚고 넘어가야 할 게 있다. 스프린트라는 단어만 보면 특정 기간 동안 전력으로 질주해야 할 것처럼 받아들이는데, 애자일은 빠르게 나아가는 게 아니다. 우리가 얼마나 망했는지를 최대한 빨리 알기 위해서 전체 프로젝트를 쪼개고 쪼개는 거다.

쪼갠 작업에 대해 요구사항 분석부터 아키텍쳐 수립, 설계, 구현 작업을 끊임없이 반복하는 하나의 과정 자체를 반복 주기 또는 스프린트라고 부르지만 절대 전력 질주가 아니다. 평균 1~2주의 기간 동안 개발팀이 충분히 해낼 수 있을 정도의 업무를 진행하는 게 목적임을 명심하자.

KPT

애자일은 필승전략이 아니다. 애자일은 그저 방법론일 뿐이고, 방법론을 제안하고 수용하는 사람이 어떤 태도와 능력을 갖추고 있느냐에 따라서 프로젝트는 망할 수도 있고 성공할 수도 있다.

그러므로 프로젝트를 마친 뒤엔 왜 망했는지 반성하고, 다음에 망하지 않으려면 어떻게 해야 하는지 분석할 시간이 필요하다. 왜 성공했는지 되돌아보고, 다음에도 성공하려면 무엇을 이번처럼 해야 하는지 분석할 시간도 필요하다.

우리는 이걸 회고라고 부르고, KPT는 수많은 애자일 회고 방법론 중 하나이다.

What we should keep. Where we are having ongoing problems. What we want to try in the next time period. -Alistair Cockburn (KPT 회고 방법론 초기 제안자)

KPT는 Keep / Problem / Try 의 약자다. KPT 방법론은 회고를 진행하되 내용은 Keep / Problem / Try 세 가지 관점을 기준으로 생각해야 한다. 정해진 시간 순서대로 작성하고 모두와 함께 공유하면서 서로 의견을 나누고 최종적으로 해결책을 찾을 수 있도록 유도하는 간단한 회고 방법론이다.

Keep

• 현재 만족하고 있는 부분
• 계속 이어갔으면 하는 부분

Problem

• 불편하게 느끼는 부분
• 개선이 필요하다고 생각되는 부분

Try

• Problem의 해결책
• 다음 회고 때 판별할 수 있고, 바로 실천 가능한 부분

여기서 중요한 건 Keep 도, Problem 도 아니다. Try 가 가장 중요하다.

Problem 키워드가 나왔다는 건 개선이 필요하다는 의미인데, 대충 좋게 넘어가자고 말만 하고 끝내면 아무것도 해결되지 않는다. 다음 회고를 진행할 때까지 Problem을 확실히 개선할 수 있을 해결책을 Try 로 제안하여 팀 내에 존재하는 불편한 요소를 해소하고자 팀원 모두가 노력해야 한다.

물론, 그러기 위해서는 Problem 을 남몰라라 묻어두지 말고 팀원 모두에게 명확히 공유되어야 하는 게 선행 조건이지만 말이다.

난 이전 회사에서 KPT 회고를 경험했다. 내가 입사하기 전부터 팀원들은 주기적으로 회고를 진행했다고 들었다. 그래서인지 KPT 회고를 하기 위해 회의실로 갔을 때 책상 가운데에 놓인 Keep, Problem, Try 를 격자로 나눈 칸에 적은 하얀색 하드보드지 위에 이미 포스트잇이 덕지덕지 붙어있었다.

본격적인 회고에 들어가기 전, Keep을 잘 이어가고 있는지, Problem은 Try로 개선했는지, Try는 모두가 잘 실천했는지 훑어봤다. 이후 하드보드지 위의 포스트잇을 모두 떼어낸 다음 각자 다양한 색깔의 포스트잇과 유성 매직을 나눠 가졌다.

정해진 시간 동안 Keep과 Problem에 해당하는 회고 내용을 적었다. 정해진 시간이 끝나면 돌아가면서 포스트잇에 적은 내용을 간단하게 설명한 뒤 하드보드지에 붙였다.

그렇게 모든 사람이 한 번씩 이야기하고 나면 진행자는 Problem을 해결할 수 있는 Try 를 고민하는 시간을 준 다음, 포스트잇에 내용을 쓸 수 있도록 유도했다.

오래전 일이라서 흐릿하지만 하나 생생하게 기억나는 Problem 과 Try 가 있다. 그 당시, 우리가 모두 오전 10시에 맞춰서 출근하지 않고 미적미적 지각하기 시작했는데 하나둘 그러다 보니 각자가 회사에 도착하는 시간이 뒤로 계속 늦춰졌다. 자연스럽게 각자의 업무 시간이 어긋나 협업 시 커뮤니케이션에 불편함을 불러일으켜서 Problem으로 해당 내용이 적힌 포스트잇이 붙였다.

우리는 그 문제를 해결하기 위해 출근하자마자 사무실에 있는 화이트보드에 출석명부(..)를 적은 뒤 10시 정각에 캡처해서 슬랙으로 지각자를 공개처형(..) 하기로 Try 를 정했다. 우스꽝스러운 Try라고 생각할 수도 있겠으나, 놀랍게도 성과가 있었다. 지각률이 확연히 줄었다.

어째서냐고? 모든 팀원이 해당 불편 사항을 Problem으로 인지했으며 이대로 가다간 조직 문화에 안 좋은 영향을 끼칠 수 있으니 개선할 필요성이 있다고 분명히 생각했기 때문이다. 더불어 문제점을 개선하기 위한 해결책으로 나온 Try를 진중하게 받아들여 정말 실천으로 옮기고자 모두 노력했기 때문이다.

이처럼 KPT 회고는 단순해 보여도 회고에 참여하는 팀원의 마음가짐이 가장 중요하다. 정말로 문제를 개선하는 게 필요하다고 생각했으며, 개선하기 위한 해결책을 몸소 실천하는 행동력을 보일 정도로 진지하게 회고에 임해야 한다. 직접 경험해본 바가 그렇다.

덜 대충 맺음말을 적어본다.

솔직하게 말하자면 나는 운이 좋다. 첫 회사에서 만난 사람들에게 개발 지식부터 조직 문화, 각종 방법론까지 무수히 많은 것을 배웠다. 그곳에서 본격적으로 총대를 메고 진행해본 적은 없지만 열심히 주워들은 게 많아서 지금까지 알차게 써먹고 있다. 애자일이나 스프린트, KPT 도 첫 회사에서 제대로 배웠고 몸소 경험했다. 물론 학부생 때 소프트웨어 공학 수업에서 배우기야 했지만 그건 정말 탁상공론에 불과한 재미없는 이론이 아니던가.

지금 와서야 이렇게 주저리주저리 글을 쓸 수 있을 정도로 좀 더 공부하게 됐지만, 나도 막 주워듣기 시작했을 땐 딱 당신처럼 대충 알고 있었다. 그래도 되는 줄 알았다. 나는 애자일 마스터가 아니고, 개발자고, 프로젝트 매니저는 어차피 따로 있을 테고 나는 관리 받기만 하면 될 테니까. 참으로 나이브하게 생각했었다.

그러다가대충 알고 있는 걸 대충 알고 있지도 않은 사람에게 알려주려고 하면서 나의 부족함을 깨달았고, 정신 차릴 수 있었다. 그때 다시 내 경험을 되짚어봤다. 생각보다 진짜배기 애자일을 경험해봤더라. 그걸 남에게 알려주지 못하는 게 아까워서 좀 더 전문적인 용어를 확실히 이해하기 위해 유명한 사람(여기선 로버트 C. 마틴)이 쓴 책을 읽었다. 둘을 비교하면서 머릿속에 대충 박혀있던 걸 덜 대충이 될 수 있도록 정리하고, 키보드를 두드리면서 글로 쓰기 시작했다.

생각보다 회사는 애자일을 따르며 일하지 않는다. 허울뿐인 스프린트, 회고 를 진행하는 조직이 파다하다. 제대로 된 애자일을 한 번이라도 겪어본 내가 운이 좋았던 거고, 나처럼 운이 좋지 않은 사람이 대다수임을 안다. 그래서 운이라도 좋았던 내가 경험한 애자일과 내가 이해한 애자일을 좀 더 쉽게 풀어서 이야기하고 싶었다. 알려주고 싶었다.

애자일을 대충 알고 있는 당신을 위해서.

나, dell.mond 는 카카오 엔터프라이즈에 프론트엔드 개발자로 합류한 지 얼마 지나지 않아 조직 개편을 맞이했다. 랜선 회식을 통해 겨우 얼굴을 익히고 친분을 쌓기 시작한 팀원을 뒤로 한 채 파도처럼 밀려오는 낯선 팀원과 마주해야 했지만 당황하진 않았다. 오히려 나에겐 상황이 좋게 흘러갔다.

개편 전에 속해있던 조직은 백엔드 개발자의 비중이 프론트엔드 개발자의 비중보다 컸다. 물론 비교적 최근에는 프론트엔드 개발자를 많이 영입하려는 모습을 보이긴 했으나-나 역시 그 흐름을 타고 카카오 엔터프라이즈에 합류했다.- 조직 내 백엔드 개발자의 수를 넘지는 못했다. 당연히 프론트엔드 관련 지식 아카이빙 및 정책 설립은 부진한 상태였다. 나는 입사 후 그러한 상황을 곧장 목격하게 되었고, 본격적으로 프론트엔드 개발 인력이 이보다 더 늘어나기 전에 각종 정책을 세워야 한다고 주장했다. 같은 조직 내의 다른 프론트엔드 개발자들 역시 그 부분에 있어서 동의 의사를 밝혔다.

우리는 부지런히 미팅을 통해 프론트엔드 개발 정책을 정했고, 문서를 정리했으며, 실무에 곧장 써먹으려고 했지만, 조직 개편이 이루어지고 말았다. 당황감만 가득한 상황일 수도 있으나 나는 그렇게 느끼지 않았다. 위에서 말했지 않은가? 상황은 꽤 좋게 흘러갔다.

내가 새롭게 만난 조직은 이전과 달리 프론트엔드 개발자만 모여있었다. 파도처럼 밀려오는 낯선 동료 무리와 파악해주기를 기다리고 있는 산더미처럼 쌓인 낯선 프로젝트 속 코드가 나를 반겼다. 그러나 나는 그것들에서 시선을 떼고-물론 새롭게 만난 동료와는 즐겁게 인사를 나눴다. 오해 금지.- 당황하지 않은 모습으로 그들에게 물었다. "개편되기 전, 이 팀에서 따르던 코딩 스타일 가이드가 있습니까?" 돌아온 답은 NO였다.

아, 나는 속으로 탄성을 내질렀다. 이전 조직에서 나와 동료가 나눈 정책 논의는 쓸모없지 않았다. 나는 그래서 살짝 제안했다. "개편을 맞이해서 우리 조직의 프론트엔드 개발자가 따를 코딩 스타일 가이드를 정하는 건 어떨까요?" 새롭게 마주한 동료들은 이 제안을 반기고, 기꺼이 받아들였다.

코딩 스타일 가이드, 이름만 들어도 멋진 이 녀석. 하나 있으면 참으로 든든하리라. 그냥 든든하기만 할까? 코딩 스타일 가이드가 생기면 나와 협업자가 작성하는 코드의 구조가 어느 정도 비슷한 모양을 띠게 된다. 그렇게 되면 서로가 작성한 결과물을 이해하는 데에도 이전보다 힘이 덜 들어간다.

조직에 새로운 구성원이 들어오게 되었을 때도 마찬가지다. 새로운 구성원이 보게 될 그 어떤 프로젝트 역시 통일된 코딩 스타일을 가지고 있을 것이다. 프로젝트 속 코드 분석은 더욱더 쉽게 이루어질 것이고, 그들은 이후에 자신이 작성해야 할 코드의 방향성을 더욱 명확하게 파악할 수 있을 것이다.

이처럼 코딩 스타일 가이드, 표준이라고 불리는 체계는 조직 구성원이 결과물을 표현하는 문법을 일관되게 만들고 그들에게 안정감을 가져다준다.

조직 개편을 통해 새로운 모습을 맞이한, 내가 속해있는 카카오 엔터프라이즈 Cloud FE 파트 역시 이러한 코딩 스타일 가이드가 있었다면 낯선 동료와 협업할 일이 생기더라도, 다른 동료가 개발하던 작업물을 갑자기 넘겨받더라도 당황하지 않을 수 있을 것이다. 또한 이후의 결과물에 대해서도 일관성과 안정감을 금방 얻을 수 있을 것이다.

이러한 이유를 바탕으로 나는 총대를 메고 일을 벌였다. 그러나, 본격적으로 코딩 스타일 가이드를 정할 논의의 장을 열기 전 몇 가지의 고민이 나의 머릿속을 채우기 시작했다.

그렇다면 코딩 스타일 가이드는 어떻게 만들어야 하는가? 누가, 아니지. 도대체 무엇부터 시작해야 하는가?

이러한 생각을 우리만 한 게 아닐 텐데, 다른 사람들은 어떻게 이 큰 산을 넘을 생각을 했을까? 그리고 뭘 했길래 결국 그 큰 산을 넘어서 나아갈 수 있었을까?

그래서 나는 이 글에 코딩 스타일 가이드 작성이라는 큰 산을 넘어간 다른 이들의 경험을 조사한 내용을 담기로 했다.

주의 스타일 가이드 라인 : 소스코드의 레이아웃에 초점을 맞춘 코딩 규칙 코딩 규칙 : 프로그래밍 관례와 디렉토리 구조, 주석에 대한 구조까지 포함되어 스타일 가이드 라인보다 더 큰 범위의 규칙

🤷🏻‍♀️ 아니, 왜 이리 종류가 많은 거야?

카카오 엔터프라이즈 Cloud FE 파트는 javascript와 그의 슈퍼셋인 typescript 언어를 주로 사용한다. 사용자 인터페이스를 만들기 위한 라이브러리는 React를 사용한다. 그래서 나는 javascript, typescript, 그리고 React 이 세 가지로 범위를 한정지어서 코딩 스타일 가이드에 관련한 사항을 조사했다.

(이미지 설명 : 우리는 싸울 것이다. 늘 그랬듯이.)

javascript style guide

Google Javascript Style Guide

• Google이 정의한 Javascript Coding Style Guide
• hard-and-fast rules 을 따른다.
• 명확하지 않고 시행 불가능한 조언은 피한다.
• 13 Noteworthy Points from Google’s JavaScript Style Guide
• 13 Noteworthy Points from Google’s JavaScript Style Guide ver.KOR

Airbnb Javascript Style Guide

• Global Standard
  • Why?
  • Airbnb가 최고는 아니다. 그러나 그들은 그 당시에 ES2015를 적용한 javascript style guide를 문서화해서 대중에게 최초로 공개했다.
  • 추가로, eslint plugin도 공개해서 자기네들의 style guide를 편하게 도입할 수 있었다.
  • 그 결과 많은 개발자들이 Airbnb Style Guide에 익숙해졌다.
• Airbnb는 자신들의 Guide를 fork 뜬 후, 각 팀의 Style Guide에 맞게 변경해서 사용하기를 권장한다.

W3S Javascript Style Guide

MDN Javascript Style Guide

• MDN 왈, 매우 간단한 수준으로 작성한 Style Guide
• Airbnb Style Guide와 호환되는 내용이 많으니, 더 자세한 설명이 필요하다면 Airbnb Javascript Style Guide 참고를 권장한다.

jQuery Javascript Style Guide

typescript style guide

Google Typescript Style Guide

• 이 Typescript Style Guide는 Google 내부에서 사용하는 버전을 기반으로 작성되었으나, 더 광범위한 개발자를 위해 일부 조정된 외부용 스타일 가이드에 가깝다.
• Google에 속해있지 않은 다른 개발자가 Style Guide 작성에 기여할 수 있다.

Typescript Style Guide (An unofficial Typescript Style Guide)

• 공식적인 Typescript Style Guide는 아니다.
• 그러나 표준 Javascript Style Guide를 참고하여 작성했다.
• 이외에도 Typescript 개발에 유용한 Tip을 많이 정리해두었다.

react style guide

Airbnb React/JSX Style Guide

• Javascript에서 널리 사용되는 표준을 기반으로 작성한 Style Guide
• 그러나 각 사례 별로 몇몇 Style Guide가 사용될 수도 있고 사용이 금지될 수도 있음을 유념해야 한다. (즉, 케이스 바이 케이스)

그 외

뱅크샐러드 Coding Style Guide

🤔 근데, 다른 사람들은 저런 걸 어떤 과정 끝에 만들었대?

여기 아주 훌륭한 글이 있다.

코딩 스타일에 대해 논쟁하는 이유 원글 : Why We Argue: Style

위 글에서 말하고 있는 내용을 간단하게 정리하면 (적고 보니 간단하지 않았다...) 다음과 같다.

• 스타일 가이드는 있어야 한다.
  • 코드는 쓰는 횟수보다 읽는 횟수가 훨씬 많다.
  • 자연스럽게 개발자는 한정된 리소스를 코드를 읽은 데에 더 많이 소모하게 된다.
  • 그러므로 응용 프로그램의 코드는 가독성이 중요하다.
  • 가독성을 위해 최적화하는 방법은 코드를 같은 스타일로 통일하는 것, 일반적인 스타일에 코드 작성을 맞추는 것이다.
• 최고의 스타일 가이드는?
  • 이 논의가 바로 분열의 시작이다.
  • "내 스타일이 최고다"라고 다들 알게 모르게 생각하고 있다.
  • 개발자 그룹에 특정 Coding Style Guide를 따를 수 있도록 동의를 구하기는 쉽다.
  • 그러나 어떤 Coding Style Guide가 우리 모두 따를 만한, '최고' 의 스타일인지 정하는 건 굉장히 어렵다.
• 왜 항상 의견이 갈라질까?
  • 스타일 전쟁은 표면적으로는 코드 형식의 문제처럼 보인다.
  • 그러나 실제로는 권력 다툼과 다를 바가 없다.
  • 스타일 전쟁은 팀의 긴장감을 부추기고 그들의 생각 비용을 증가시킨다.
  • 솔직하게 말하자면 스타일 전쟁은 팀 사기에 독이 될 뿐이다.
• 자기만의 방식으로 하려고 시도하지 말라.
  • 여기 개노답 삼 형제가 있다.
  • 자신들의 방식만이 옳다고만 믿는 고참 개발자 그룹
    • 지시로 모든 것을 해결한다.
    • 지시가 실패해도 자신들이 원하는 스타일로 그냥 진행한다.
    • 그룹의 합의는 무시해버린다. (혹은 무시해도 된다고 생각한다.)
  • 다른 언어의 경험을 현재 사용 중인 언어에 도입하려는 개발자 그룹
    • 자신이 선택한 스타일(다른 언어의 스타일)이 코드를 알기 쉽게 한다고 생각한다.
    • 그러나 그들의 선택은 다른 개발자에게 혼란만 가져다준다.
    • 그리고 그들은 그 사실을 애써 무시해 버린다.
  • 스타일에 대한 지론이 확실하지 않은 신인 개발자 그룹
    • 모든 스타일을 이것저것 실험하려고 한다.
    • 그래서 코드에 일관성이 없다.
    • 다른 개발자들은 그들의 실험적인 코드를 뒤처리하기 바쁘다.
  • 이렇게 되면 조직 내의 개발자 수만큼 스타일이 만들어진다.
  • "코드 일부분만 보여주고 누가 쓴 건지 알아 맞히기 게임 해볼까요? 우리 할 수 있겠죠?"
  • "당연하죠, 어떻게 그걸 모르겠어요?"
• 어떻게 해야 팀이 합의에 도달할 수 있을까?
  • 조직 내에서 스타일 가이드 협의 과정 중 오랜 시간 충돌만 이어지고 있으면, 스타일 가이드를 외부조달하자.
    • 잘 만들어진 스타일 가이드를 쓰지 않을 이유가 뭔가?
    • 내부에서의 불필요한 분쟁을 피하고 집단지성을 빌릴 수 있다.
    • 이렇게 되면 만족 정도와 아쉬운 정도가 서로 비슷해서 논의하기도 훨씬 더 편하다.
  • 스타일 가이드를 무사히 결정했다면, 모두가 그것을 따르게 만들자.
    • 정적 분석을 통해 코드가 스타일 가이드를 위반했다면 경고하는 절차를 자동화하자.
    • 개발자는 설명서를 하나하나 따져가듯 협업자의 코드 스타일을 검토하지 말자. 이건 잔소리다.
    • 대신 코드의 문제를 해결하기 위해 실질적으로 필요한 정보만을 제공하자.
    • PR의 내용은 코드의 외형보다 코드의 내용, 동작에 관한 것이어야 한다.
    • PR 올리기 전 스타일 위반은 모두 바로 잡자.
• 기존 코드는?
  • 기존 코드의 스타일까지 수정할 필요는 없다.
  • 앞으로 작성할 코드나 잘해라.
  • 오래된 코드는 다른 이유로 건드리게 될 때까지 내버려 둬라.
  • 만질 필요가 없는 코드의 스타일을 일부러 수정하는 것 = 백로그에 쌓여있는 다음 작업을 하는 것보다 오래된 코드의 스타일을 수정하는 것이 비즈니스 가치가 높다고 선언하는 것
  • 이미 안정화가 되어있고 스타일 수정에 비용이 크게 든다면 기존 코드에 손을 대지 않는다.
• 난 새로 정해진 스타일 가이드가 싫어.
  • 꾹 참고 가이드를 따라서 개발해보자.
    • 따르다 보면 생각이 바뀌기도 한다.
    • 낯설어서 그렇지 적응 후엔 새로운 스타일을 좋아하게 된다.
  • 새로운 스타일 가이드를 따르지 않겠다고 아주 단호한 결심을 해라.
    • 현 조직을 떠나 자신과 맞는 스타일을 사용하는 곳을 찾아가라.
    • 새 조직, 새 직장의 스타일 가이드를 따라라.
  • 결국 당신은 어딜 가게 되더라도 특정 스타일 가이드를 따르게 되어있다. 스타일 가이드를 따르지 않는다는 선택지는 없다.
• 교훈은?
  • 코드는 자신들의 방식대로 작성된 것보다 모든 코드가 비슷한 스타일로 되어 있는 것이 훨씬 중요하다.

촌철살인 그 자체다.

사실 카카오 엔터프라이즈 Cloud FE 파트는 Google이나 Airbnb 처럼 본격적인 Coding Style Guide를 작성할 수 없다. Google과 Airbnb는 우리보다 개발 인력도 많다. 또한 그들의 서비스는 어느 정도 완성되어 이미 시장에 선보여지고 있다. 그래서 실 서비스 개발을 하지 않고, 각종 업무 프로세스를 효율적으로 개선하기 위해 연구하는 개발자의 리소스를 아깝지 않게 생각한다. 나는 이것이 바로, 두 회사가 Coding Style Guide를 밑바닥부터 작성해서 세상에 공표할 수 있었던 큰 이유 중 하나라고 생각한다.

카카오 엔터프라이즈는 다르다. 우리는 아직 실 서비스 개발에 초점을 두고 나아갈 때다. 프로세스 개선도 물론 중요하지만 개발보다는 '덜' 중요하다. 그렇지만 아무것도 개선하지 않고, 정립하지 않고, 해당 논의의 필요성을 무시하고 그냥 지나칠 순 없는 상황이다. (당연하다. 개편된 조직 내의 체계와 문화를 잡지 않고 구성원에게 무조건 앞으로 달리라고만 말하면 그들이 제대로 목적지에 도착할 수 있을까? 준비 운동은 어느 과정에서나 꼭 필요하다.)

코딩 스타일에 대해 논쟁하는 이유는 그러한 우리의 상황에 딱 들어 맞는 시의적절한 내용을 담고 있다. 정말 글쓴이에게 찬사를 보내고 싶을 정도로.

📢 결론

굳이 서로 털어놓지 않아도 알 수 있다. 나를 포함한 카카오 엔터프라이즈 Cloud FE 파트원 모두가 Coding Style Guide 논의를 앞둔 상황에서 공감하는 바는 아래와 같을 것이다.

1. Coding Style Guide는 필요하다.
2. 스타일 가이드를 밑바닥부터 하나씩 다 정할 시간은 없다. (우리에겐 사치다.)
3. "최고의" Coding Style Guide를 정하겠다고 논쟁만 길어지는 건 가치 없는 소모전일 뿐이다.
4. 이미 잘 만들어진 걸 가져다 쓰지 않을 이유는 없다.
5. 팀의 확장이 일시적으로 멈춘 지금, 시간을 내서 스타일 가이드 논의를 성공적으로 빠르게 마쳐야 한다.
6. 이후 작성될 코드는 일관된 스타일을 갖추고 있어야 하며, 해당 작업은 빠르게 이루어질수록 좋다.
7. 급작스럽게 조직 개편을 겪은 구성원들의 혼란을 덜어내고 확실한 체계로 안정감을 부여해야 하며, 해당 작업은 빠르게 이루어질수록 좋다.

다행히 리서치는 만족스러운 수준이다. 이번 리서치를 통하여 이미 잘 만들어진 훌륭한 Coding Style Guide를 찾을 수 있었고, 우리와 매우 유사한 상황에 부닥쳤던 이들이 스타일 가이드 논쟁을 이끌어 나가는 과정 또한 찾을 수 있었다. 준비는 끝났고 실천만이 남아있다. 그렇다면 우리가 여기서 더 머뭇거릴 필요가 있을까?

❓ Lighthouse(라이트하우스)란?

Lighthouse는 구글에서 개발한, 웹 페이지의 품질을 개선할 수 있는 오픈 소스 형태의 자동화 도구이다. 어떤 웹 페이지든 (그것이 공개되었든, 인증이 필요하든) 사용할 수 있다.

Lighthouse is an open-source, automated tool for improving the quality of web pages.

📈 Lighthouse로 확인할 수 있는 지표

Lighthouse는 성능을 측정하기 위해서 다음의 메트릭을 사용한다. (이외에도 부가 항목이 존재하지만 자세한 설명은 생략한다. 다음 링크에서 확인할 수 있다.)

1. First Contentful Paint
   • FCP
   • 사용자가 특정 웹 페이지로 이동했을 때, 브라우저가 첫 번째 DOM의 콘텐츠를 렌더링하는 데 걸리는 시간
2. First Meaningful Paint
   • FMP
   • 사용자가 페이지를 불러오기 시작하면서 스크롤을 내리지 않은 채 제일 먼저 볼 수 있는 영역에 존재하는 주요한 콘텐츠를 렌더링하는 데 걸리는 시간
   • Lighthouse 버전 6.0 이후로 사용되지 않는다. (작은 차이에도 매우 민감하게 측정되어 일관성 없는 결과를 초래하였기 때문이다.)
3. Speed Index
   • 웹 페이지를 불러올 때, 콘텐츠가 시각적으로 표시되는 데까지 걸리는 시간
4. First CPU Idle
   • 웹 페이지가 최소한으로 상호작용할 수 있는 상태가 될 때까지 걸리는 시간
   • Lighthouse 버전 6.0 이후로 사용되지 않는다. (Time To Interactive와 측정 기준이 유사했지만 의미 있는 결과값을 보이지 못했다.)
5. Time To Interactive
   • 웹 페이지가 완전히 상호작용할 수 있는 상태가 될 때까지 걸리는 시간
6. Max Potential First Input Delay
   • FID
   • 사용자가 웹 사이트와 처음 상호작용(버튼 클릭)할 때부터 브라우저가 실제로 해당 상호작용에 응답할 수 있을 때까지 걸리는 가장 긴 시간
   • (즉, 최악의 경우를 측정)
7. Total Blocking Time
   • TBT
   • 웹 페이지가 사용자 입력에 응답하지 못하도록 차단된 총 시간
   • = 로딩 중 메인 스레드가 긴 시간동안 중단되어 응답을 받을 수 없을 정도로 걸린 시간
8. Largest Contentful Paint
   • LCP
   • 뷰포트에서 가장 큰 콘텐츠 요소가 화면에 렌더링 될 때까지 걸리는 시간

서술한 건 8개지만 Lighthouse 버전 6.0부터 사용되지 않는 메트릭를 제외하면 총 6개라고 볼 수 있다. 그렇지만 이게 전부가 아니다. 여기에서 하나 더 추가된 지표가 있다. 그건 바로 Cumulative Layout Shift(CLS) 메트릭이다.

9. Cumulative Layout Shift
   • CLS
   • 이미지/광고의 느린 로딩, 비동기 동작, 동적 DOM 변경 등으로 웹 페이지의 레이아웃이 얼마나 변하는 지 측정한 값
   • 사용자가 잘못된 클릭을 하도록 유발하는 시각적 불안정성을 체크하는 지표

💡 Lighthouse 사용법

1. npm

$ npm install -g lighthouse
$ lighthouse https://www.example.com --view

2. Chrome Extension

다운로드 링크

3. Chrome DevTool

2020년 5월 19일 Lighthouse 버전 6.0 배포 이후 Chrome 웹 브라우저 내부의 개발자 도구에서 Lighthouse를 이용할 수 있게 되었다.

Option. Lighthouse-CI

Lighthouse는 CI를 제공하고 있다. CLI로 웹 사이트의 성능을 측정하는 테스트를 실행한다. 또한, 테스트 결과를 업로드할 수 있을 뿐만 아니라 대시보드를 통해 해당 결과 데이터를 시각화해서 보여주는 Node.js 서버를 가동하는 역할을 한다. 자세한 건 아래의 링크를 참조하자. Lighthouse-CI

👀 Lighthouse Report를 살펴보자

// web.dev 살펴보기
$ lighthouse https://web.dev/ --view --preset experimental

// daum 살펴보기
$ lighthouse https://www.daum.net/ --view --preset experimental

🔍 Lighthouse 결과 항목 분석

1. Performance

Lighthouse는 실제 속도가 어떻든 간에, 화면에 콘텐츠가 얼마나 빨리 표시되고 사용자는 얼마나 빠르게 해당 콘텐츠를 인식하는 지에 더욱 초점을 맞추고 있다. 참고 : Lighthouse Performance Scoring

• Lighthouse 6

• Lighthouse 5

2. Accessibility

Lighthouse는 웹 애플리케이션의 접근성을 검사한다. <img> 태그에 alt 속성이 있는지, <html> 태그에 lang 속성이 있는지, 배경색과 전경색의 대비가 충분한지와 같은 항목을 확인한다.

참고 : Lighthouse Accessibility Scoring 참고2 : 접근성이란?

3. Best Practices

Lighthouse는 웹 페이지가 웹에 대한 표준 모범 사례를 따르고 있는지 확인한다. 웹 애플리케이션을 가동할 때 콘솔에 오류가 출력되진 않는지, 더는 사용하지 않는 API를 호출하고 있지 않은지, HTTPS를 통해 해당 페이지에 접근할 수 있는지와 같은 항목을 확인한다.

참고 : Best Practices Audits

4. SEO

Lighthouse는 웹 페이지가 검색 엔진에 대해 최적화된 순위 결과를 가지고 있는지 확인한다. 각 사용자가 자신의 디바이스를 이용하여 웹 페이지에 접근하였을 때 그들이 콘텐츠를 읽는 데에 무리가 없는 글꼴 크기를 사용하는지, 웹 페이지의 robots.txt 파일이 유효한지, 올바른 상태 코드를 사용하는 지와 같은 일부 SEO 모범 사례를 확인한다.

참고 : Webmaster Guidelines

5. Progressive Web App

Lighthouse는 Progressive Web App을 정의하는 일련의 기준에 따라 웹 페이지를 확인한다. 이 검사는 해당 웹 페이지가 항목을 따르고 있는지 측정하여 점수를 부여하는 것이 아니다. 웹이 HTTP를 HTTPS로 리다이렉션하는지, 응답 코드는 명확한지, 3G 네트워크에서도 로딩이 빠르게 이루어지는 지와 같은 여부를 검사하여 합격 또는 실패를 부여한다.

참고 : What makes a good Progressive Web App?

🙏 친절한 Lighthouse

웹 사이트의 성능을 개선하는 데에 관심이 많다면 web.dev를 주기적으로 살펴보자. 급변하는 웹 생태계에 맞춰서 Lighthouse는 웹 사이트의 성능 측정 방법을 수시로 논의하고 개편한다. web.dev는 해당 개편안 뿐만 아니라, 개편안 측정에 활용한 검사 항목, 각 항목 별 비중의 변화까지 문서로 공유한다. 저들이 새롭게 업데이트한 Lighthouse를 사용해서 각 웹 사이트의 성능을 높이는 방법에 대한 지침 역시 제공한다.

그뿐만 아니라, Lighthouse 라는 도구 자체도 굉장히 친절한 구성을 띄고 있다. Report를 보면 바로 알 수 있다. 검사 별로 좋지 않은 성능 값이 측정된 항목에 대해 원인과 수정 방안을 제시한다. Learn more. 을 통해 상세한 설명이 적힌 문서를 확인할 수도 있다.

이토록 편리하고 친절하지만 Chrome 개발자 도구 저 구석에 숨어있는 탓에 Lighthouse는 생각보다 많은 개발자에게 낯설기만 하다. 그래서 나는 바로 오늘, Lighthouse를 사용하는 방법과 Lighthouse로 얻을 수 있는 웹 사이트 성능 측정 보고서를 분석하는 방법을 설명했다.

더는 낯설어하지 말고 위에 서술한 세 가지의 사용 방법 중 가장 쉽고 빠른 걸 선택해서 자신이 개발한 웹 사이트의 성능 점수를 확인해보는 건 어떨까?

물론, 생각보다 결과는 처참할지도 모르지만... (나 역시 그런 경험을 했었다.)

하지만 두려워 말자. 처참한 성능을 가지고 있는 웹 사이트와 함께 그 장소에서 언제까지나 머무르는 게 목적이고 올바른 길이였다면 Lighthouse는 세상에 나오지도 않았을 것이다. 혹여나 해당 도구가 세상에 나왔더라도 내가 여러분에게 Lighthouse를 사용하는 방법을 소개하는 일은 없었을 것이다. (모두에게 불필요한 요소를 굳이 시간 들여 설명하는 건 리소스 낭비에 불과하다.)

우리는 개발할 때 성능이 중요하단 사실을 이미 알고 있다. 사용자에게 고성능 애플리케이션을 제공하는 게 올바른 길이라는 것도 아주 잘 안다. 그러나 성능을 챙기면서 개발하는 건 영 어색하고 어렵다. 아주 세심한 작업이 필요하기 때문이다. 그래서 그동안 머리로는 이해하고 있었지만 손가락은 성능 개선을 위한 코드를 작성하는 걸 회피한 걸지도 모른다.

그렇게 여러 개발자는 성능 개선 앞에서 일자무식이 되었고 고성능을 위한 요소를 하나하나 꼼꼼히 챙기지도 못하게 되어버리고 만다. 그 상황에서 나름대로 침착을 유지하려 안간힘을 쓰는 개발자의 사고에 혼란을 끼얹으면 어떨까? 가령 서비스 개발 마감 기한이 다가온다거나...

시간에 쫓기지 않아도 평범한 사람의 뇌가 프로그램의 성능을 해치게 될 유의사항을 단 한 개도 놓치지 않고 확인한다는 건 불가능에 가까운데, 저렇게 된다면 정말 '성능이고 뭐고 간에 대충 만들어서 돌아가게 해놓고 나중에 고치자' (안 고침) 라는 심리만 남게 되리라.

인간은 도구를 사용하는 동물이다. 그러니 뇌 하나만 쓰려고 애쓰지 말고, 다른 똑똑한 인간이 만들어 놓은 편리하고 친절한 도구를 사용해보자. 막상 개발하다보면 급하게 배포하느라 바빠서 성능을 잘 챙기지 못할 수도 있지만, 최종적으로 production 스테이지에 애플리케이션을 배포하기 전, Lighthouse로 성능 측정 보고서를 받아본 다음 약간의 개선 작업을 진행하는 건 그리 어려운 일도 아니지 않은가. 안 그런가?

불편하겠지만 습관으로 만들자. 낯선 것을 받아들이고 몸이 친숙하게 생각하도록 꾸준히 학습하자. 웹 어셈블리 언어를 사용해 코어 구간을 새롭게 개발하여 성능을 최적화하란 것도 아니지 않은가. 쉬운 것부터 차근차근 성능을 개선해나가자. 그럼 언젠가 성능이라는 녀석을 조금 더 개선하기 위해 욕심을 내서 또 다른 지식을 학습하기 시작하는 자신의 모습을 볼 수 있으리라.