회고를 통한 시너지 만들기
회고 ㄴㄴ, 뒷풀이 YES
개발자가 어떤 사람인지 깊이 알아보고, 기획자는 어떤 일을 해야하는지 또 자세히 알아봤다. 이제 어떻게하면 이 두 직무간의 간극을 줄이고 시너지효과를 낼수 있는지 구체적인 방법을 알아보려고 한다. 첫 번째로 알아볼 수단은 ‘회고‘다. 회고의 사전적 의미는 “지나간 일을 돌이켜 생각하는 것“ 이다. 우리가 써오던 일기가 대표적인 예가 될 수 있다. 회고는 혼자 할 수 도 있지만 프로젝트 구성원들이 함께 할 수 도 있다. 활용하기에 따라 팀이 함께하는 회고는 개발자와 가까워지고 내가 몰랐던 우리 프로덕트의 문제점을 진단할 수 있는 좋은 기회가 된다.
애자일, 스크럼이라는 단어가 낯설던 시절 “회고”를 처음 경험했다. 애자일 프로젝트에선 매 스프린트가 끝날때마다 회고를 진행할것을 권고한다. 구성원 누구도 함께하는 회고를 경험한 적이 없었기 때문에 책에 적힌 대로 ‘좋았던 점’, ‘아쉬웠던 점’, ‘다음에 시도할 것‘으로 나눠서 포스트잇에 적고 붙이면서 이야기를 나눴다. 처음엔 워크샵 하는 기분도 나고 재미도 있었는데, 회를 거듭할 수록 회고가 별로 의미가 없다는 생각이 들었다. 왜냐하면 매번 포스트잇에 적는 내용들이 변화가 없고 앞으로도 바뀔 것 같지 않았기 때문이다. 개발자 입장에서 잘못한점을 계속해서 찾다 보니 팀에 기여하지 못하는 것 같다는기분도 들었다.
시간이 흘러 PM으로서 동료들과 함께 회고를 할 일이 생겼다. 어떻게하면 참여하는 사람들이 회고를 통해 부정적 생각이 아닌 발전적 생각으로 이끌어갈 수 있을지 고민했다. 그래서 회고 모임요청의 제목을 기존 스타일인 “n월 정기배포 회고 모임요청“에서 ”n월 정기배포 뒤풀이”로 바꿨다. 단어 ‘회고‘라는 단어가 줄 수 있는 의미인 실수를 되짚거나 반성하는 느낌을 줄이고 다같이 웃으면서 이야기를 나누는 ‘수고했다 파티’같은 느낌을 주고 싶었다. 포멧은 그대로 유지하되 제목을 바꿈으로서 참여자들이 긍정적인 생각을 하도록 유도했다. 앞으로 우리가 알아볼 회고의 목적은 구성원들과 가까워지고 깊은 대화를 통해 시너지효과를 만들어내는 것이다. 어떻게 하면 생산성있는 회고 모임을 할 수 있을지 알아보자.
회고의 목적과 중요성
회고는 단순히 지난 일을 돌아보는 것이 아니라 미래를 위한 학습 과정이다. 특히 개발자와 기획자 사이의 간극을 줄이고 시너지를 만들어내는 데 중요한 역할을 한다. 회고의 주요 목적은 크게 세 가지로 나눌 수 있다.
첫째, 문제 해결과 개선이다. 회고를 통해 팀은 지난 프로젝트나 스프린트에서 발생한 문제점을 함께 파악하고 해결책을 모색할 수 있다. 예를 들어, “이번 배포에서 가장 큰 어려움은 무엇이었나요?“라는 질문을 통해 개발자와 기획자가 각자의 관점에서 느낀 어려움을 공유하면, 서로의 입장을 이해하고 다음에는 같은 문제가 발생하지 않도록 예방할 수 있다.
둘째, 팀 동기 부여와 사기 증진이다. 회고는 성공 경험을 함께 축하하고 서로의 노력을 인정하는 자리이기도 하다. “이번 프로젝트에서 가장 자랑스러운 순간은 언제였나요?“와 같은 질문은 팀원들이 자신의 기여를 인정받고 성취감을 느끼게 한다. 이런 긍정적인 경험은 팀의 사기를 높이고 다음 프로젝트에 대한 동기를 부여한다.
셋째, 개인 및 팀의 성장이다. 회고는 학습의 장이다. “이번 프로젝트에서 새롭게 배운 것은 무엇인가요?“라는 질문을 통해 팀원들은 자신의 성장을 돌아보고, 다른 팀원들의 경험에서도 배울 수 있다. 개발자는 기획의 관점을, 기획자는 개발의 관점을 이해하게 되면서 서로의 영역에 대한 이해도가 높아진다.
회고가 효과적으로 이루어지려면 심리적 안전감이 보장되어야 한다. 팀원들이 자유롭게 의견을 표현하고, 실수를 인정하며, 비판 없이 서로의 의견을 존중하는 환경이 필요하다. 이런 환경에서 개발자와 기획자는 서로에 대한 이해를 높이고, 더 나은 협업을 위한 기반을 마련할 수 있다.
효과적인 회고 방법론
회고를 효과적으로 진행하기 위해서는 적절한 방법론을 선택하는 것이 중요하다. 다양한 회고 방법론이 있지만, 여기서는 개발자와 기획자 간의 시너지를 높이는 데 특히 유용한 몇 가지 방법을 소개한다.
1. Start, Stop, Continue 가장 기본적이면서도 효과적인 방법 중 하나다. 팀원들에게 “시작해야 할 것”, “중단해야 할 것”, “계속해야 할 것”을 각각 포스트잇에 적어 공유하도록 한다. 이 방법은 단순하면서도 행동 지향적이어서 구체적인 개선 사항을 도출하기 좋다. 예를 들어, 기획자는 “개발자에게 요구사항을 전달할 때 더 명확한 예시 제공하기”를 ‘시작해야 할 것’으로, 개발자는 “기술적 제약사항을 초기에 공유하기”를 ‘계속해야 할 것’으로 제안할 수 있다.
2. 4Ls (Liked, Learned, Lacked, Longed for) 이 방법은 좀 더 다양한 측면에서 프로젝트를 평가할 수 있게 해준다. “좋았던 점”, “배운 점”, “부족했던 점”, “바랐던 점”을 각각 나누어 이야기한다. 특히 “배운 점”을 공유하는 과정에서 개발자와 기획자는 서로의 영역에서 얻은 인사이트를 나눌 수 있다. 기획자는 기술적 제약사항에 대해, 개발자는 사용자 경험의 중요성에 대해 새롭게 배웠다는 점을 공유할 수 있다.
3. 타임라인 회고 프로젝트의 시작부터 끝까지 중요한 사건들을 시간 순으로 나열하고, 각 사건에 대한 감정(긍정/부정)을 표시하는 방법이다. 이 방법은 프로젝트의 흐름을 한눈에 볼 수 있게 해주며, 특히 개발자와 기획자가 같은 사건에 대해 다른 감정을 느꼈던 지점을 발견하는 데 유용하다. 예를 들어, 요구사항 변경이 있었을 때 기획자는 긍정적으로 느꼈지만 개발자는 부정적으로 느꼈다면, 이런 차이를 인식하고 논의할 수 있다.
4. 감사 회고 팀원들이 서로에게 감사한 점을 공유하는 방법이다. 특히 긴 프로젝트가 끝났을 때나 팀 분위기가 침체되었을 때 효과적이다. “이번 프로젝트에서 가장 감사했던 동료와 그 이유는 무엇인가요?“와 같은 질문을 통해 서로의 기여를 인정하고 감사를 표현한다. 이 방법은 개발자와 기획자 사이의 감정적 유대를 강화하는 데 도움이 된다.
회고를 진행할 때는 모든 팀원이 참여할 수 있도록 하고, 비난이 아닌 건설적인 피드백에 초점을 맞추는 것이 중요하다. 또한, 회고에서 나온 개선 사항은 반드시 다음 프로젝트나 스프린트에 반영될 수 있도록 구체적인 액션 아이템으로 정리하고 책임자를 지정해야 한다. 이렇게 하면 회고가 단순한 대화의 자리가 아니라 실질적인 변화를 이끌어내는 원동력이 된다
회고를 통한 시너지 창출하기
회고는 단순히 과거를 돌아보는 행위를 넘어 개발자와 기획자 사이의 시너지를 창출하는 강력한 도구가 된다. 효과적인 회고를 통해 얻을 수 있는 시너지 효과는 다음과 같다.
첫째, 개방적 소통 문화를 형성한다. 회고는 직급이나 역할에 관계없이 모든 팀원이 자유롭게 의견을 나눌 수 있는 안전한 공간을 제공한다. 개발자는 기술적 제약사항이나 어려움을 솔직하게 표현할 수 있고, 기획자는 비즈니스 요구사항이나 사용자 니즈를 명확히 전달할 수 있다. 이런 개방적 소통은 일상적인 업무 환경에서도 이어져, 문제가 발생했을 때 즉시 논의하고 해결하는 문화를 만든다.
예를 들어, 한 프로젝트에서 개발자가 회고 중에 “기획 변경이 너무 자주 있어서 개발 일정을 맞추기 어려웠다”고 솔직하게 말했다. 이에 기획자는 “변경의 이유와 중요성을 충분히 설명하지 못했던 것 같다”고 인정했다. 이 대화를 통해 두 직군은 변경 요청 프로세스를 개선하기로 합의했고, 이후 프로젝트에서는 변경 요청 시 충분한 설명과 함께 개발 영향도를 함께 고려하는 문화가 정착되었다.
둘째, 상호 이해와 존중이 깊어진다. 회고에서 각자의 관점과 경험을 공유하면서 개발자와 기획자는 서로의 업무 특성과 어려움을 이해하게 된다. 개발자는 기획자가 사용자와 비즈니스 요구 사이에서 균형을 맞추기 위해 노력한다는 것을, 기획자는 개발자가 기술적 제약 속에서 최선의 구현을 위해 고민한다는 것을 알게 된다.
한 스타트업의 회고에서 기획자는 “개발팀이 불가능하다고 했던 기능이 왜 중요했는지 충분히 설명하지 못했다”고 말했다. 개발자는 “그 기능이 그렇게 중요한지 몰랐다. 다른 방식으로 구현할 수 있는 대안이 있었을 텐데”라고 응답했다. 이 대화를 계기로 두 팀은 기능의 우선순위와 목적을 함께 논의하는 시간을 정기적으로 갖기 시작했다.
셋째, 공동의 목표 의식이 강화된다. 회고를 통해 팀은 프로젝트의 성공이 개발자나 기획자 어느 한쪽의 성과가 아니라 모두의 협력 결과임을 인식하게 된다. 이는 “우리 vs 그들”이라는 사일로 현상을 줄이고, “우리 모두”라는 팀 정체성을 강화한다.
성공적인 제품 출시 후 진행한 회고에서, 팀은 출시 과정에서 있었던 어려움보다 함께 이룬 성과에 초점을 맞췄다. 개발자는 “기획팀의 명확한 요구사항 덕분에 효율적으로 개발할 수 있었다”고 말했고, 기획자는 “개발팀의 창의적인 기술 솔루션 덕분에 더 나은 사용자 경험을 제공할 수 있었다”고 화답했다. 이런 상호 인정은 다음 프로젝트에 대한 공동의 주인의식을 강화한다.
회고를 통한 시너지 창출은 하루아침에 이루어지지 않는다. 지속적이고 정기적인 회고(뒤풀이)를 통해 팀은 점진적으로 더 강한 협력 관계를 구축하게 된다. 중요한 것은 회고가 형식적인 절차가 아니라 진정한 소통의 장이 되고 개선을 논의 할 수 있는 자리로 여겨져야 한다는 점이다.
회고의 지속적 적용과 발전
회고는 일회성 이벤트가 아니라 팀 문화의 일부로 지속적으로 적용되어야 그 효과를 최대화할 수 있다. 회고를 조직 문화로 정착시키고 발전시키기 위한 방법을 알아보자.
첫째, 정기적인 회고 일정을 수립하고 지키는 것이 중요하다. 정기배포 완료 후, 중요 마일스톤 달성 후, 또는 월 1회 등 팀에 맞는 주기를 정하고 이를 반드시 지켜야 한다. 바쁘다는 이유로 회고를 미루거나 취소하면 그 중요성이 점차 퇴색된다. 우리 프로젝트의 경우 앱 정기 배포 주 수요일 오후 3시를 ‘정기 배포 뒤풀이(회고)시간’으로 정하고, 어떤 상황에서도 반드시 이 시간을 지켰다. 이 규칙성이 조직을 옮기기 전까지 회고를 팀 문화의 일부가 되도록 만들었다.
둘째, 회고에서 도출된 개선 사항을 실제 행동으로 옮겨야 한다. 아무리 좋은 아이디어가 나와도 실행되지 않으면 의미가 퇴색된다. 회고 마지막에는 반드시 구체적인 액션 아이템을 정하고, 담당자와 기한을 명확히 해야 한다. 다음 회고에서는 이전 회고의 액션 아이템 진행 상황을 먼저 점검하는 것이 좋다.
예를 들어 회고에서 “개발자와 기획자 간 용어 이해 차이로 인한 혼란”을 발견했다면, 이에 대한 액션 아이템으로 “공통 용어집 만들기”를 정할 수 있다. 초안을 언제 까지 완성하기로 합의하고 이를 액션아이템으로 선정한다. 다음 회고에서 이 용어집의 진행 상황을 점검하고, 실제 사용 경험을 공유하면서 점점 구체화 해 나갈 수 있다. 이런 구체적인 실행과 점검을 통해 회고는 더 가치있어 진다.
셋째, 다양한 회고 방식을 시도하고 팀에 맞게 조정해야 한다. 같은 방식의 회고를 반복하면 참여도가 떨어지고 새로운 인사이트를 얻기 어렵다. 앞서 소개한 다양한 회고 방법론을 번갈아 시도하거나, 팀 상황에 맞게 변형하는 것이 좋다. 예를 들어, 긴 프로젝트 후에는 타임라인 회고를, 팀 분위기가 침체되었을 때는 감사 회고를 진행하는 식이다.
넷째, 회고 자체에 대한 메타 회고도 필요하다. “우리의 회고 방식은 효과적인가?”, “회고를 통해 실제로 개선되고 있는가?”, “모든 구성원이 편안하게 의견을 나누고 있는가?” 등의 질문을 통해 회고 프로세스 자체를 개선해 나가야 한다. 한 팀은 분기마다 ‘회고에 대한 회고’를 진행하여 회고 방식을 지속적으로 발전시켰다.
회고는 단순한 과거 반성이 아니라 미래를 위한 학습과 성장의 도구다. 지속적이고 진정성 있는 회고를 통해 개발자와 기획자는 서로를 더 깊이 이해하고, 더 효과적으로 협업할 수 있는 기반을 마련할 수 있다. 회고는 시간이 지날수록 그 가치가 더해지는 투자인 셈이다.
회고는 단순히 과거를 돌아보는 행위가 아니라 개발자와 기획자 사이의 간극을 좁히고 시너지를 창출하는 강력한 도구이다. 효과적인 회고를 통해 팀은 개방적 소통 문화를 형성하고, 서로에 대한 이해와 존중을 깊게 하며, 공동의 목표 의식을 강화할 수 있다.
회고의 진정한 가치는 지속적인 적용에서 나온다. 정기적인 회고 일정을 수립하고, 도출된 개선 사항을 실제 행동으로 옮기며, 다양한 회고 방식을 시도하고, 회고 자체를 개선해 나가는 과정을 통해 팀은 점진적으로 더 나은 협업 환경을 만들어갈 수 있다.
특히 회고의 분위기를 ‘반성’이나 ‘비판’이 아닌 ‘축하’와 ‘학습’의 자리로 만드는 것이 중요하다. 앞서 언급한 “회고” 대신 “뒤풀이”라는 표현을 사용한 사례처럼, 회고의 프레임을 긍정적으로 바꾸는 작은 시도가 큰 차이를 만들 수 있다.
개발자와 기획자는 서로 다른 언어를 사용하고, 다른 관점에서 문제를 바라보지만, 결국 같은 목표를 향해 나아간다. 회고는 이 서로 다른 두 세계를 연결하는 다리 역할을 한다. 정기적이고 효과적인 회고를 통해 개발자는 기획의 중요성을, 기획자는 개발의 복잡성을 이해하게 되고, 이는 더 나은 제품과 서비스를 만드는 원동력이 된다.
회고를 팀 문화로 정착시키는 것은 시간과 노력이 필요한 일이지만, 그 투자 대비 효과는 매우 크다. 진정성 있는 회고 문화를 통해 개발자와 기획자는 단순한 협업자를 넘어 서로의 성장을 돕는 동반자가 될 수 있다. 그리고 이러한 관계는 결국 사용자에게 더 나은 가치를 전달하는 것으로 이어진다.
다음 글에서는 개발자와 기획자 모두가 실수를 통해 어떻게 함께 성장할 수 있는지 알아보겠다.
