IT 업계는 짧은 기간에 제품을 빨리 개발, 출시, 개선하는 애자일 방법론을 많이 채택하죠. 고객 요구사항을 정확히 파악하고, 이에 맞게 제품을 신속히 개선하며 올바르게 나아가려면 회고가 필요합니다. 회고는 오늘날 IT 업계에서 중요한 문화인데요. 인포그랩도 데일리 체크아웃, 스프린트 회고 등 개인과 그룹 단위로 회고 프로그램을 상시 운영합니다. 방대한 회고 정보 가운데 IT, 스타트업계 엔지니어에게 적합한 회고 방법을 찾는 분이 많은데요. 이 글에서는 엔지니어가 활용할 만한 회고 유형과 인포그랩의 회고 문화, 좋은 회고 요건을 소개하려 합니다.
대표 회고 유형
회고 유형은 KPT 회고, 5F 회고, PMI 회고 등 다양합니다. 이중 엔지니어 개인 선호나 조직 특성, 프로젝트 상황에 따라 적합한 회고 유형을 선택하면 되는데요. 오늘날 조직에서 많이 사 용하고, 엔지니어가 활용할 만한 회고 유형을 알아보겠습니다.
1. KPT 회고
KPT 회고는 Keep, Problem, Try의 약자로 엔지니어 사이에서 인기 있는 회고 유형입니다. 이는 프로젝트의 마무리 단계에서 자기 경험을 되돌아보고, 개선점을 설정할 때 유용한데요. KPT 회고는 다음 세 가지 측면을 회고합니다.
- Keep(유지할 점): 팀이 잘한 일, 성공적이거나 효과적으로 수행한 일을 정리합니다. 이로써 팀이 앞으로 계속 유지하려는 요소를 도출합니다.
- Problem(문제점): 프로젝트나 작업 과정에서 겪은 어려움이나 문제점을 정리합니다. 이는 팀의 현재 작업 방식에서 비효율적인 점을 분석하고 개선할 기회로 활용할 수 있습니다.
- Try(시도할 점): Keep과 Problem을 바탕으로 향후 새롭게 시도하려는 아이디어나 접근 방식을 제시합니다.
2. 5F 회고
5F 회고는 Fact, Feeling, Finding, Future, Feedback의 약어 모음인데요. 이는 개인 회고에 활용해도 좋습니다. 5F 회고는 다음 다섯 가지 측면을 회고합니다.
- Fact(사실): 작업 과정에서 일어난 구체적 사건, 상황을 객관적으로 정리합니다.
- Feeling(느낌): 프로젝트를 수행하며 느낀 감정을 정리합니다. 이는 팀원 간 다양한 시각을 이해하는 데 도움이 됩니다.
- Finding(배운 점): 경험으로 얻은 인사이트를 공유하여 팀 전체의 학습과 성장을 촉진합니다.
- Future(향후 행동): 위 세 가지 F를 바탕으로 개선 방안을 설정하여 공유합니다. 팀이 앞으로 잘 나아가기 위해 개인과 팀이 집중할 일을 정리합니다.
- Feedback(피드백): 피드백 방식은 여러 가지입니다. 하나는 팀원에게 받은 피드백을 정리하여 계획의 실행 가능성을 높이는 방식입니다. 다른 하나는 위 네 가지 F를 수행하고 시간이 지난 뒤, 결과를 공유하는 방식입니다.
3. PMI 회고
PMI 회고는 Plus, Minus, Interesting의 약자로 간단하고 효과적인 회고 방법입니다. 이는 아이디어를 내고, 평가하는 데 사용할 수 있는데요. PMI 회고는 다음 세 가지 측면을 회고합니다.
- Plus(도움이 되거나 좋았던 점): 팀 또는 개인이 성공적으로 수행한 활동을 정리합니다. 긍정적인 요소를 인지하며 팀의 사기를 높일 수 있습니다.
- Minus(해결할 점이나 아쉬웠던 점): 프로젝트 또는 작업 기간에 직면한 문제점이나 어려운 일, 실패한 접근 방식을 정리합니다. 이로써 동일한 실수를 반복하지 않고, 개선 방안을 모색합니다.
- Interesting(흥미롭거나 인상적인 점): 예상하지 못했던 배움 또는 흥미로웠던 사실을 정리합니다.
인포그랩의 회고 문화
인포그랩은 엔지니어를 비롯한 모든 구성원에게 회고를 장려합니다. 인포그랩 회고는 개인, 유닛(그룹) 단위로 이뤄지는데요. 개인별 회고 활동은 ‘데일리 체크아웃’입니다. 이는 구성원이 오늘 하루를 돌아보고, 목표 달성률과 잘된 점, 잘 안된 점, 시도할 일을 회고하는 활동인데요. 매일 퇴근할 때, 슬랙으로 진행합니다.
유닛 회고 활동은 매주 금요일 유닛의 스프린트 미팅에서 이뤄지는데요. 인포그랩은 조직의 목표 달성과 성과 촉진을 위해 유닛을 운영합니다. 유닛은 OKR 방법론에 따라 분기별 목표(Objective)와 핵심 결과(Key Results), 이니셔티브(Initiative)를 세우는데요. 매주 관련 활동을 진행하고, 스프린트 미팅에서 수행 결과를 공유하며 활동을 회고하죠.
개인별 회고는 KPT 방식으로, 유닛 회고는 PMI 방식으로 진행하는데요. 구체적인 회고 방식을 들여다보겠습니다.
1. 개인별 회고 - 데일리 체크아웃
‘데일리 체크아웃’을 설명하기 전에 먼저 ‘데일리 체크인’ 활동을 짚고 가겠습니다. 이는 출 근할 때, 오늘 목표와 활동 계획을 공유하는 활동인데요. 구성원은 오늘 이루고 싶은 목표와 이니셔티브, 더 생산적이고 만족스러운 하루를 보내기 위한 의견과 함께 해보고 싶은 일을 데일리 체크인으로 알립니다.
데일리 체크아웃에서는 퇴근할 때, 데일리 체크인 내용을 기준으로 오늘 활동을 회고하는데요. 출근할 때 세운 목표 달성률과 잘된 일/성공적인 일(Keep), 잘 안된 일/성공을 가로막은 일(Problem), 시도하거나/집중해야 할 일(Try)을 데일리 체크아웃으로 공유하죠.
이는 KPT 방식으로 진행하는데요. 회고 내용을 토대로 ‘다음 날 집중하고 노력해야 할 일’을 미리 챙기는 장점이 있습니다. 인포그랩 구성원은 동료의 회고를 보며 이모지나 스레드로 피드백을 주기도 합니다.
2. 유닛 회고 - 스프린트 회고
유닛 회고는 매주 금요일 스프린트 미팅에서 한 주를 마무리하며 진행합니다. 먼저 구성원이 돌아가면서 각자 한 주간 유닛 활동을 회고합니다. 이때 유닛 활동의 성과와 한계를 정리하는데요. 유닛 전체를 회고할 수도 있고, 유닛 활동을 수행하는 개인을 회고할 수도 있습니다. 여기 서 좋았던 점(Plus), 아쉬웠던 점(Minus), 인상적이었던 점(Interest), 개선하면 좋은 점(Improve)을 공유하죠.
이는 PMI 방식으로 진행하는데요. 인포그랩에서는 ‘개선하면 좋은 점(Improve)’ 항목을 추가하였습니다. 여기서 개인적으로 또는 유닛에서 개선할 점을 공유하고요. 앞으로 작업의 방향성을 제시합니다. 참고로 위 이미지는 ‘GitLab 공식 기술 문서 한글판 by 인포그랩’을 개발한 Copy And Translate 유닛에서 제가 회고한 내용입니다.
유닛 회고를 진행하면 구성원들의 활동 사항과 고충을 이해하는 데 도움이 됩니다. 내 일에만 매몰되지 않고 다른 사람의 입장을 생각해 볼 기회가 생기고, 시야도 넓어지죠. 또 다양한 의견에 귀를 기울이고 포용하는 분위기를 조성할 수 있습니다.
좋은 회고 요건
회고 방법에 정답은 없습니다. 위 방법이 모두에게 적합하지 않을 수도 있고요. 이를 개인과 조직에 맞춰 수정해 새로운 회고 방법을 만들어도 되죠. 회고 방법에 정답은 없으나 회고를 더 잘하는 방법은 있는데요. 저는 이번 글을 준비하며 여러 참고 자료를 읽다가 ‘좋은 회고의 요건’을 다룬 글을 발견했습니다. IT 기업 Sym의 엔지니어링 부 사장 출신인 Nickolas Means가 쓴 글인데요. 그는 좋은 회고의 요건을 아래와 같이 설명합니다.
과거 관찰하기
회고가 효과적이려면, 특정 기간에 일어난 구체적인 일을 검토하는 데 중점을 둬야 한다는데요. 이는 프로젝트 트래커(project tracker)를 열어 ‘그 기간에 수행한 작업을 검토’하는 걸 의미하지 않습니다. 예를 들어, ‘기능 A와 기능 B가 출시되었다’는 사실에 그치지 않고요. ‘기능 A를 출시하는 데 필요한 작업을 30% 줄인, 좋은 이해관계자 논의’나 ‘기능 B가 지연된 원인인 세부 사항을 놓친 일’을 회고하는 게 더 흥미롭고 유용하다고 합니다. 우리가 회고로 배우려는 귀중한 정보는 작업 자체보다 그 작업을 둘러싼 맥락에 있다고 하죠.
안전 문화 구축하기
우리가 회고하는 가장 중요한 이유는 ‘더 효과적이고, 효율적인 작업 패턴을 향해 계속 반복하기 위함’이라는데요. 그러려면 팀은 잘된 일과 잘못된 일을 이야기할 수 있어야 합니다. 모든 팀원이 ‘안전하다’고 느끼지 않으면, 회고는 비난과 방어의 교환으로 빠르게 변질되기 쉽다는데요. 팀에 안전 문화를 구축하지 않은 채 회고를 안전하게 만들기는 어렵다고 하죠. 뭔가 잘못됐을 때, 판단하는 대신 ‘항상 호기심을 갖고 시작하는 게 좋은 출발 점’이라고 하고요. 팀이 ‘문제와 실패는 학습 대상이며, 처벌 대상이 아니’라는 생각을 포용하도록 도우라고 합니다.
감정 포용하기
팀원 개개인의 감정과 팀의 감정은 리더에게 중요한 정보라고 합니다. 엔지니어링 작업은 주기적이며, 모든 팀은 제품을 빠르게 출시하고 기분이 최고로 좋을 때와 프로젝트가 지체되고 다음 단계가 불분명하며 아무것도 제대로 진행되지 않을 때 사이를 오간다고 하죠. 회고에서 이러한 감정을 이야기하면 팀은 공동으로 대처하고, 좋은 시기를 연장하거나, 나쁜 시기에서 벗어나는 단계를 파악하도록 팀을 끌어올 수 있다고 합니다.
맺음말
지금까지 여러 회고 유형과 인포그랩의 회고 문화, 좋은 회고 요건을 살펴보았습니다. 회고는 문제 해결의 실마리를 찾고, 개인과 조직을 발전시키는 데 유익합니다. 엔지니어는 회고로 업무 수행의 어려움을 털어놓을 수 있고요. 이를 듣는 상대방은 조언을 건네고, 도움을 주며 엔지니어 성장을 끌어줄 수 있습니다.
아울러 조직에서는 회고로 프로젝트 이슈나 작업을 돌아보며 잘한 점, 아쉬운 점을 논의하고요. 회고 내용을 문제 개선에 반영해 조직 생산성과 프로젝트 성공률을 높일 수 있습니다. 이는 조직이 구성원과 공통 목표, 가치를 공유하는 데도 도움이 되고요. 그 결과, 강력한 팀워크 기반 을 다지며 모두가 한 방향으로 나아갈 수 있죠.
엔지니어의 바람직한 회고 방법을 제언하고 싶은 분은 아래 댓글에 공유해 주시면 감사하겠습니다.
인포그랩은 GitLab과 DevOps를 맞춤형으로 기술 지원합니다. GitLab(Omnibus/Cloud Native Hybrid) 구축 지원이 필요하시면 문의하기 로 연락해 주십시오.