프로젝트 회고 방법
나는 프로젝트가 종료될 때 개인적으로 항상 프로젝트에 대한 회고를 해본다. 어떤 부분이 아쉬웠는지 살펴보고 이를 해결하기 위해 학습할 부분은 무엇인지 생각하기 위해서 많이 하는 것 같다. 프로젝트 회고를 할 때 사용되는 다양한 방법이 있다는 것을 최근에 알게 되었다. 이번 포스팅에서는 다양한 회고 방법들을 정리하고 간단한 프로젝트 회고를 진행할 것이다.
회고란?
회고는 지나간 일을 돌이켜 생각해본다는 의미를 가진 단어이다. 따라서 프로젝트 회고는 프로젝트의 전반적인 진행 상황을 생각해보는 것이다.
이러한 프로젝트 회고는 비단 프로젝트가 종료될 때에만 수행하는 것도 아니고, 개인만 수행하는 것이 아니었다. 프로젝트 중간에 산출된 결과물을 가지고 회고를 할 수도 있고, 개인이 아닌 팀 단위로 회고를 진행할 수도 있다.
왜 회고를 해야하는가?
회고를 진행하는 이유가 모호하면 회고에 대한 동기 부여가 생기지 않을 것이다. 회고를 해야 하는 이유는 과거를 되돌아보고 과거의 사건들을 분류한 다음에 이를 참고삼아 프로젝트 또는 개인을 더더욱 발전시킬 수 있기 때문이다.
회고 시점
그렇다면 어느 시점에 회고를 진행해야 할까? 내가 참고한 글에서는 회고의 시점을 너무 주기적으로 설정하면 저번 회고와 비슷한 이야기가 나올 수 있기 때문에 개발, 런칭과 같은 큰 이벤트가 완료된 시점에 진행하는 것을 추천한다고 한다.
회고 방법
회고에도 다양한 방법이 있다. 대표적으로 KPT, TIL, CSS 등이 있는데 차례로 살펴보도록 하자.
KPT (Keep-Problem-Try)
Keep, Problem, Try의 앞 글자를 따온 회고 방법으로 Keep은 현재 만족하고 있는 부분이나 계속 지켜졌으면 하는 부분, Problem은 업무 중 문제라고 느끼는 부분이나 부족했던 점, Try에는 Problem을 해결하는 방안과 빠른 시일 내에 시도해 볼만한 것들을 작성한다. 이때 Try는 최대한 현실적이고 구체적으로 작성해야 한다.
TIL (Today I Learned)
잘한 점, 개선점, 배운 점을 정리하는 회고이다. 이는 프로젝트를 진행하면서 배운 부분을 정리하는 것을 목표로 한다.
CSS (Continue-Stop-Start)
지속하거나 유지해야 할 것, 그만해야 할 것, 새롭게 시작할 것들을 회고하는 방식이다. 이 회고를 진행할 때는 그만둬야 할 문제점에 대해서도 논의하기 때문에 솔직하게 문제를 이야기 하고, 구체적인 계획을 정리해야 한다.
AAR (After Action Review)
스프린트 종료 후 활용되는 회고 방식이다. 정성적, 정량적 성과와 개선점을 파악할 때 사용하는데, 초기 목표, 현실, 배운 점, 개선점과 목표 등으로 구분할 수 있다.
회고 과정은 다음과 같다.
- 초기 목표 파악을 위해 얻고자 한 것을 리마인드
- 얻고자 한 것에 대해서 실제로 어떤 일이 일어났고 무엇을 얻었는 지 점검
- 계획과 실제 결과의 차이와 원인은 무엇인지와 예기치 않은 성공과 실패는 무엇인지 점검
- 계속해야 할 것과 버려야 할 것은 무엇인지 정의
이러한 회고 방법을 통해 구체적인 현재 상황 파악이 가능하다고 한다.
회고 예시
나는 프로젝트를 진행할 때는 TIL를 작성해나가고, 프로젝트 종료 시 KPT 방식으로 회고를 진행해왔던 것 같다. 내가 진행했던 어느 프로젝트의 KPT 회고를 살펴보도록 하자.
Keep
- Spring Cloud와 Kubernetes 환경에서 서비스 디스커버리·설정 서버·Kafka 기반 비동기 처리 등을 직접 구현하며 대규모 분산 시스템 구조를 이해
- Kafka 이벤트 기반 아키텍처 설계로 서비스 결합도 감소 및 안정적인 푸시 알림 기능 구현
- 메모리 누수 추적·해결 과정을 통한 서버 자원 관리 및 최적화 학습
- STOMP와 Kafka 연계를 통해 백엔드부터 프론트엔드까지 통신 흐름과 UX를 모두 고려한 풀스택 개발 수행
Problem
- 테스트 환경 분리 실패로 인하여 테스트 진행을 하지 못함
- 쿠버네티스에서 서비스 이름 기반 라우팅 대신 각 서비스의 직접 주소를 명시
- 영상 조회 기능에서 사용자 로딩 시간 지연 발생
- 개발 일정으로 미흡한 채팅 기능 (푸시 알림, 읽음 처리 등)
Try
- 테스트 환경을 위한 의존성 학습 및 적용
- 영상 업로드를 청크 단위 또는 스트리밍 방식으로 전환
- 쿠버네티스에 대한 지속적인 학습으로 간단한 msa 배포 및 라우팅 실습
- 스트리밍 서버에 대한 학습 및 실습
- 채팅 서버 구축에 대한 별도 학습
나는 프로젝트를 진행하면서 좋았던 점을 Keep, 아쉬웠던 부분을 Problem, 해당 문제를 해결하기 위해서 Try를 작성해봤다. 이러한 회고를 통해서 앞으로의 학습 방향성을 설정할 수 있다고 생각한다.
또한 Try를 해보고 실제로 해결된 부분은 링크 등으로 해결한 부분을 바로 볼 수 있게 만들 수도 있을 것 같다. 위 회고는 가장 최신 프로젝트에 대한 회고이므로 아쉽게도 아직 해결이 된 부분이 없다.
마지막 프로젝트가 되어서야 회고 방법이 이러한 것들이 있다는 것을 알게 되어 조금 아쉬운 것 같다. 항상 협업을 하다보면 아쉬운 부분이 많이 생기는데, 주요 기능 개발 완료마다 AAR 회고를 진행했다면 더욱 수준높은 프로젝트를 만들 수 있었을까 생각이 든다.
댓글남기기