개발자의 공유 문화 이모저모 (2) 회고 문화

개발자의 공유 문화 이모저모 (2) 회고 문화

기록도 점검도 셀프! 
개발자는 왜 회고를 할까요?

#오픈소스 #기술블로그 #회고문화

바쁘게 일하고 공부하다 보면 시간이 훌쩍 지나있기 마련이죠. 
그렇지만 모든 일을 다 기억할 수는 없는 법, 
문득 ‘작년엔 뭘 했지?’ ‘이번 프로젝트에서 내가 어떤 일을 맡았더라?’ 
고개를 갸웃하게 되는 순간들이 있죠.

더 나은 개발자로 성장하고 싶은 분들, 
더 좋은 제품(Product)을 만들고 싶은 조직이라면 
그동안 겪은 시행착오를 어떻게 기록할지 고민해봤을 텐데요.

이번 주 <주간 인프런> #41에서는 지난 호, 오픈소스 & 기술 블로그 편에 이어 개발 업계의 회고 문화에 대해 이야기합니다.
덧붙여 인프랩 개발 파트의 재미있는 신규 서비스 런칭 회고도 살짝 공개할게요.

더 나은 내일의 나를 위해 고군분투하는 분들께 
개발 업계의 회고 문화가 자그마한 힌트가 될 수 있기를 바랍니다 😊

이번 주간 인프런 #41은 👨‍💻

주간 인프런 #40, #41 <개발자의 공유 문화 이모저모>는 총 2주에 걸쳐 연재됩니다. 이번 호에서는 오픈소스 & 기술 블로그 편에 이어 개발 업계의 회고 문화에 대해 다룹니다 😊

주간 인프런 #41 🌿

개발자는 왜 회고를 할까요? 
효과적인 회고를 위한 추천 템플릿 +
인프랩 팀원들의 생생 회고까지!

회고 없는 성장은 없다?

매해 연말이 되면 개발자들 사이에서 회고 소식이 공유되는 걸 심심치 않게 볼 수 있어요. 작게는 개인 수준의 회고부터, 기업 단위의 프로젝트 회고 내지는 팀 회고까지 다양한 회고가 이루어지고 있죠.

구글에 "개발자 회고"로 검색해 보세요. 수많은 개발자들의 회고를 확인할 수 있어요!

말 그대로 ‘뒤를 돌아본다’는 의미의 회고(Retrospective)가 IT 업계를 중심으로 인기를 얻은 이유는 2000년대 들어 개발 방법론의 대세로 자리잡은 애자일(Agile) 프로세스*와  특히 연관이 깊습니다. 애자일이란 대략 1~4주 정도의 짧은 주기(스프린트) 안에 최소한의 결과물을 구현, 배포한 뒤 고객의 피드백에 따라 빠르게 제품을 개선해나가는 루틴을 반복하는 기법이에요. 

*애자일 프로세스 보충 설명!

애자일 프로세스는 워터폴(Waterfall) 프로세스에 대항하는 방법론입니다. 서비스 배포에 필요한 요구사항 분석 → 설계 → 개발 → 테스트 및 유지보수 각각의 단계를 순차적으로 진행하는 대신, 중간에 새로운 요구 사항을 추가하거나 변경하기 어렵고 배포까지 시간이 오래 걸리는 워터폴과 달리 민첩하고 효율적인 접근 방법을 추구해요.

이 애자일 방법론에서 회고는 상당히 중요합니다. 짧은 주기로 계속되는 개발 과정 안에서 성공 요인이나 문제점을 되돌아볼 수 있게 해주기 때문이죠. 뿐만 아니라 앞으로 업무를 어떻게 개선할 수 있을지 아이디어와 후속 작업을 이끌어내는 역할도 합니다. 문제가 발생했을 때 뒤를 돌아보는 게 아니라, 항상 문제를 인지하고 빠르게 해결할 수 있도록 체계를 갖추는 것이죠.

책 『애자일 회고』. 이 책에서는 회고를 "즐겁게 돌이켜보고, 기민하게 해결하고, 강점을 살려주는 집단 점검의 시간"으로 정의하고 있어요.

Bonus!

개발 분야에 한정된 방법론은 아니지만, 애자일뿐만 아니라 구글이 사용하는 성과 관리 방법론으로 알려져 있는 OKR(Objective & Key Results) 관점에서도 회고가 중요한 역할을 해요. 주기별로 목표 달성에 대한 회고를 반복함으로써 방향을 점검하고 업무를 지속적으로 개선할 수 있도록 이끄는 것이 OKR의 핵심 요소 중 하나이기 때문입니다.


회고를 ‘잘’ 하고 싶다면

회고를 실천하는 방법은 다양합니다. 물론 문제를 돌아보는 것 자체로 충분히 의미있지만, 현상을 명확하게 분석하고 성장의 동력으로 삼기 위해서는 효과적인 회고 방식을 고민하게 되기 마련인데요. 이럴 때 회고 템플릿을 사용하면 회고를 좀더 효율적으로, 명확하게 남기는 데 도움이 됩니다. 많은 사람들에게 사랑받는 대표적인 회고 템플릿 몇 가지를 소개해드려요.

KPT

KPT는 각각 Keep, Problem, Try의 약자입니다. 이름에서 알 수 있듯 3가지 관점에서 업무를 돌아보고, 다음 액션 아이템을 도출해내는 데 도움이 되는 회고 템플릿이에요.

  • Keep (프로젝트에서 만족했고, 앞으로의 업무에서 지속하고 싶은 부분)
  • Problem (프로젝트에서 부정적인 요소로 작용했거나 아쉬웠던 점)
  • Try (Problem에 대한 해결 방식으로 다음 프로젝트에서 시도해볼 점)

무엇보다 KPT에서 중요한 관점은 Try입니다. 이번 프로젝트에서 아쉬웠던 점을 Try를 통해 어떻게 보완할 수 있을지 정리해보면서 구체적인 실천 방안을 세울 수 있다는 장점이 있어요.

인프런 팀에서도 프로젝트 회고에 KPT를 특히 자주 활용하고 있어요.

5F

5F는 다음 다섯 개의 키워드에 따라 순서대로 회고를 진행하는 방식입니다.

  • Fact (사실: 무슨 일이 있었나?)
  • Feeling (느낌: 무슨 느낌이 들었나?)
  • Finding (배운 점: 어떤 인사이트를 얻었나?)
  • Future action (향후 행동: 앞으로 무엇을 해야 할까?)
  • Feedback (피드백: 앞서 정한 향후 행동을 실천해본 뒤, 이에 대해 어떤 피드백을 받았나?)

특히 5F는 개인이 한 활동을 회고하는 데 유용한데요, 어떤 일이 있었고 무엇을 느꼈는지를 시간 순서대로 정리하는 데 도움이 되는 방식이에요. 

4L(4Ls)

4L은 특정 활동에 대해 느낀 생각과 경험을 중심으로 회고를 진행하는 방식입니다.

  • Liked (좋았던 점)
  • Lacked (아쉬웠던 점)
  • Learned (배운 점)
  • Longed for (앞으로 바라는 점)

4L 역시 여러 상황과 여건에 적용해볼 수 있지만, 협업 프로젝트 진행 과정의 특정 지점(마일스톤)에서 구성원들과 중간 점검을 할 때 더욱 편리하게 쓸 수 있을 것 같아요.

협업을 위한 위키 시스템, 컨플루언스(Confluence)에서도 4L 회고 템플릿을 제공하고 있어요. ⓒAttlasian

PMI

아이디어 도출 및 평가를 위해 고안된 PMI 역시 회고 방식으로도 종종 활용되고 있어요.

  • Plus (좋았던 점)
  • Minus (아쉬웠던 점)
  • Interesting (흥미로운 점)

최선의 아이디어를 찾기 위해 고안된 방식이니만큼 새로운 제품을 개발하거나 인사이트를 찾고자 할 때 도입해보면 좋겠습니다.

여러분은 어떤 회고 방식이 마음에 드시나요? 회고 방식은 정말 다양하지만 결국 핵심은 무엇을 생각하고 느꼈는지, 앞으로 무엇을 할 수 있을 것인지를 생각해보는 것 같아요. 
상황과 여건, 그리고 취향에 따라 다양한 회고 방식을 적용해보시길 바랍니다. 😉


회고는 나, 그리고 모두의 힘 

앞서 많은 개발자들이 개인 회고부터 기업이나 팀 차원의 프로젝트 회고까지 다양한 회고를 공개하고 있다고 말씀드렸죠. 다른 많은 사람들과 각자의 경험을 공유함으로써 노하우를 나누고, 의견을 주고받고, 서로의 자극이 되어준다는 점에서 회고는 개발 문화의 중요한 축을 맡고 있다고 할 수 있을 것 같아요. (물론 팀 및 개인 브랜딩에도 도움이 되고요!) 무엇보다 꾸준히 스스로를 돌아봄으로써 성장하는 동력을 만들어나갈 수 있다는 점이 회고의 진면목이 아닌가 싶습니다 😊

인프런을 만드는 인프랩 역시 모든 팀원들의 수습, 연말 회고뿐만 아니라 중요한 피쳐에 대한 프로젝트 회고를 공개하고 있어요. 지난 연말 및 인프랩이 만든 신규 채용 서비스 ‘랠릿’ 런칭 과정에도 어김없이 회고를 작성했습니다. 

인프랩 실Log에서는 팀원들의 수습, 연말 회고 및 프로젝트 후기를 볼 수 있어요. “프로젝트 앤트맨”은 현재 인프런 서비스, “프로젝트 루비콘”은 채용 서비스 랠릿의 코드네임입니다 😆

인프랩 팀원들의 프로젝트 루비콘(랠릿) 회고 한줄 스크랩!
회고 전체가 궁금하다면 >> (클릭)

CTO & Product Owner (향로, 예박, 대니, 개수)

향로 (CTO) 🐻 
“한번은 제대로 프로젝트를 진행해보고, 본인들이 지식으로만 알고 있던 내용들을 실제로 적용해보면서 호된 경험도 해보면서 매번 같은 방식을 쓰던 방식에서 탈피해봐야 한다.”

예박 (Product Owner) 🐨 
“일을 나눠서 할수록 기존 업무는 줄어들었지만 새로운 업무가 더 많이 생겼다. 그 중에서도 커뮤니케이션 방식을 정하는 데에 꽤 많은 시간을 쏟아야 했다. "후 조치 전략" 덕분에, 개발 도중에도 기획 사항을 축소/변경하거나 보완하느라 각 파트간에 의사소통하는 시간이 늘어갔다.”

대니 (Product Owner) 🦷 
“새로운 프로세스, 스택, 협업 방식, 업무 환경등 서비스 출시외에 많은 도전과제들이 있었던 프로젝트였다고 생각한다. 그렇기에 후회와 아쉬움이 드는 부분도 많았지만, 성장할 수 있는 객관적인 모멘텀이 된 것 같아 참여할 수 있었음에 감사함을 느낀다.”

개수 (Product Owner) 🌕 
“지금부터가 중요한 만큼, 진짜 사용자 중심의 서비스를 만들기 위해 초심으로 돌아가보려 합니다. (…) PO, 디자인, 개발 각자의 입장에서 이번 기획에 활용된 문서들의 활용도를 어떻게 보고 있는지 빨리 이야기 해보고 싶습니다.”

Backend Engineer (꾸기, 비스타, 차밍, 인트, 하루)

꾸기 (Backend Engineer) 💡 
“내가 좀 더 NestJS와 타입스크립트를 잘 다뤘으면 어땠을까? 깨끗한 코드를 작성해서 코드 리뷰를 빨리 통과했다면 어땠을까? 시간을 아껴서 검색하고 찾아보고 공부해보고 테스트 해봤으면 어땠을까? (…) 개인적으론 나에겐 이런 프로젝트와 경험이 절실하게 필요하지 않았나 싶다.”

비스타 (Backend Engineer) 🌟 
“지금은 작업 속도도 빨라졌고, PR 생성 후 거의 바로 반영되고 있는데, 이제 작성하는 코드들이 향로가 생각하는 좋은 코드에 조금 더 가까워진 게 아닐까 싶다. (…) 새로운 기술 & 처음부터 투입되는 새로운 프로젝트라서 작업하는 동안 너무 재미있었고, 코드 스타일이나 협업(커뮤니케이션) 관련해서도 많이 성장한 것 같다.”

차밍 (Backend Engineer) 🍀 
“좋은 구조가 무엇인지 알게 되었다. 그리고 유지보수를 하면서 직접 그 장점들을 느낄 수 있었다. 다른 언어와 프레임워크로 된 코드를 봤을 때 우리 프로젝트와 설계가 비슷하다! 라는 생각이 들었다. 그리고 좋은 구조는 비슷하다는 걸 느꼈을 때 내가 성장했음을 체감했다.”

인트 (Backend Engineer) 🔢 
“입사 전에는 데이터베이스를 거치는 로직을 어떻게 테스트하는게 좋을지 감이 잡히지 않았지만 이곳에서 레포지토리 활용과 향로가 알려준 여러 테스트 관련 자료 덕분에 많은 지식을 얻을 수 있었다. 특히 Stub을 사용하는 테스트하는 방법이 마음에 들어 HTTP 요청 로직을 테스트하기 위한 모듈을 만드는 작업을 매우 즐겁게 한 것이 기억이 남는다.”

하루 (Backend Engineer) 🐷 
“한줄평: 메인 딜러가 아닌 최고의 서포터가 되기위해 노력한 프로젝트.”

Frontend Engineer (빠삐코, 준프, 라비, 홍시, 리온, 록, 몰리, 어텀)

빠삐코 (Frontend Engineer) 🍦 
“파트 내부에서 자신의 주장을 강하게 이야기하고, 모든 의견에 소리내어 이야기하는 행동 내면에는, 현재까지의 자신의 걸어온 커리어에 대한 불안과, 회의감을 느낀 나 자신이 있었다. (…) 내가 모른다고 말한다고 해서, 나에게 책임을 묻거나, 나를 원망할 분은 우리 파트에 없다. 나 스스로가 만든 강박에 스스로 목을 조이고 있었다. 이제 조금 편안해지려고 한다. 포기하겠다는 의미는 아니고 더 이상 그럴 필요가 없다는 것을 알게 되었다.”

준프 (Frontend Engineer) 🐶 
“프로젝트 진행이 3분의 2가 지날 때즈음부턴 정신적으로 그리고 체력적으로, 과거 걸어왔던 길에 대한 후회, 관계에 대한 반성 등으로 가득찼다. 사실 개발을 어떻게든 부여잡고 진행한게 대단했구나 싶을 정도였다. 위에선 실패 리스트로 적었지만 사실 앞으로 성공 히스토리가 될 밑밥을 깐 것이다. 모든 내용이 도전적이고 앞으로 계획이다.”

라비 (Frontend Engineer) 🚃 
“논리적으로 무결하면서도 이해하기 쉽고 생산성에 저해되지 않는 보편적인 코드에 대해서 팀원들과 치열한 논의가 있었고 비록 아직까지도 완벽한 답을 찾아낸 것 같지는 않지만 지금까지 고려하지 못했던 다양한 관점에서 소프트웨어를 어떻게 설계하고 관리할지에 대해서 고민해보면서 많이 배우고 성장한 것 같다.”

홍시 (Frontend Engineer) ❄️ 
“개발 기간 내내 프론트엔드 팀의 슬로건은 ‘뒤돌아 보지 않을 각오로 만든다’ 였던 것 같다. 하지만 그렇게 되지 않았는데 (…) 실전에서 FE는 정말 많이 뒤돌아 보아야 했던 것 같다. 다음에 프로젝트를 한다면 이를 염두에 두고 ‘언제 뒤돌아 보아도 병목이 없게’가 슬로건이 될 것 같다.”

리온 (Frontend Engineer) 🍸 
“이번 랠릿 프로젝트는 크게 보면 인프랩에게, 작게 보면 저에게 지도와 나침반을 쥐여준 프로젝트라고 생각합니다. 회사 측면에서는 새로운 서비스를 오픈함으로써, 더 넓은 시야와 데이터를 축적할 수 있게 되었고, 개인적으로는 어느 부분이 부족하고 어느 부분이 강점인지를 파악할 수 있는 프로젝트였습니다.”

록 (Frontend Engineer) 🦌 
“이메일 템플릿을 끝내고 빠삐코가 구축해놨던 어드민쪽에 투입됐다. 맨 처음 설명을 들었을 때, 익숙하지 않은 상태관리 라이브러리로 구성되어 있어서 솔직히 반 정도만 이해했다. 혼자 조금 더 모르는 부분에 대해서 찾아보고 직접 기능을 몇 개 개발해보니 왜 이렇게 설계했는지 이해가 갔다. 구조에 대해서 파악이 되니 기능을 추가하는 작업은 빠르게 작업할 수 있었고, 추후에는 빠삐코의 고민이 담긴 코어모듈이 가져다주는 생산성에 감사함을 느꼈다.”

몰리 (Frontend Engineer) 🐽 
“성장하기 위해서는 많은 방법들이 존재하겠지만 요즘 느끼는 것이 한 가지가 있다. 머리와 말이 아닌 코드로 직접 해보면서 느껴야 된다는 것이다. 말로 설명했을 때와 실제 코드에서는 많은 차이가 있을 수 있다.”

어텀 (Frontend Engineer) 🍁 
“마감을 앞두고 있어서 바쁘게 일하는 팀원들을 옆에서 봐왔기 때문에 질문을 하기가 더 죄송스러웠다. 내가 질문하는 것이 집중을 방해하는 건 아닌지, 시간을 너무 빼앗는 건 아닌지 걱정이 됐다. (…) 질문 ‘잘' 하는 것도 앞으로 계속 가져가야 하는 숙제 같은 거라서 이런저런 시도를 많이 해봐야겠다.”

DevOps Engineer & UX/UI Designer (조슈아, 선비, 스댕, 레슬리, 율무)

조슈아 (DevOps Engineer) 🎪 
“나는 무얼 만드느냐보다 어떻게 만드느냐가 중요하다고 여긴다. 대상에 관계 없이 이 프로덕트를 어떻게 잘 만들어갈지에 집중을 하고 싶다. 물론 대상도 중요하다, 대상이 목표로 한 가치가 좋아야 하니까, 인프런과 랠릿 모두 훌륭한 가치를 추구하고 있기 때문에 문제되진 않는다.”

선비 (DevOps Engineer) 🎢 
“루비콘 프로젝트는 끝났지만 사실 랠릿이라는 서비스가 세상에 공개된 것뿐이지 내가 해야할 일은 지금부터 시작이라고 생각한다. 프로젝트가 끝나고 짧은 시간동안 Go 언어를 공부하고, Terragrunt와 Terratest를 이용한 DRY Terraform 구조를 이해했다. 현재는 기존 인프라를 Terraform으로 이전하고 있고, 그 후에는 하나씩 필요한 인프라를 정교하게 올리기 시작할 것이다.”

스댕 (UX/UI Designer) ➕ 
“#과유불급 - 걱정, 근심, 욕심, 야근, 극단적
#후회막급 - 일정 및 업무 공유의 부족, 의사소통, 느슨해진 긴장감
#개선사항 - 합리적인 선택과 집중, 적당함, 적극적 의사소통
#유지사항 - 꼼꼼함, 베리에이션, 확인”

레슬리 (UX/UI Designer) 🌷 
“수정/추가하는 과정에서 원래의 디자인 의도는 뭐였는지 물어봐주고 고민해주고 함께 해결책을 찾으려 노력해준 팀원들 너무 고맙고 감사하다! 부족했던 부분을 적나라하게 보여준 프로젝트였다. 문제를 알았으니 개선할 일만 남았다.”

율무 (UX/UI Designer) 🌻 
“QA 초반에는 예쁘게 만들어 놓은 디자인 그대로 구현되었으면 하는 마음으로 픽셀 단위로 꼼꼼히 봤던 것 같다. 그리고 여러번 사이클을 돌리면서 점점 사용성이 개선되면 좋을 만한 것들까지 의견을 제시하게 되었다. 처음엔 철저히 제 3자 마냥 랠릿을 보다가 점점 정도 들고 우리 서비스라는 생각이 들어서 그랬던 것 같기도 하고.. 제시한 의견을 진지하게 같이 검토해주는 팀원들이 있어서 더욱 편하게 꺼낼 수 있었다.”


이번 [주간 인프런] 어떠셨나요?
솔직한 의견을 들려주세요!

유익해요 | 아쉬워요

지난 [주간 인프런] 이 궁금하다면? (클릭)

댓글 5

댓글을 작성해보세요.

  • 박상민
    박상민

    기존 자사 회고 템플릿이 아쉬워서 찾아보는 중입니다! 잘 봤습니다!

  • 이시영
    이시영

    좋은 글이네요. 감사합니다.

  • Hyun Yoo
    Hyun Yoo

    회고라.. 해본적 없는데 해보고싶네요!

  • nameunskadms
    nameunskadms

    다들 엄청 솔직한 회고를 하시는 군요! 잘 읽고 갑니다 :)

  • jarchive
    jarchive

    반가운 주간 인프런! 잘 읽고 있습니다. 유익한 내용 감사합니다👍🏻