기술 토론에 참여하는 기획자

기획자..도..들어가야 됩니까..?

나는 기획자가 안 들어가도 되는 회의는 없다고 생각한다. 그런데 일 하다 보면 기획자가 초대받지 못하거나 자연스럽게 빠지게 되는 회의들이 있다. 대부분 기술적 의사결정을 하는 회의들이다. 어떤 기술을 사용할지 정하거나 시스템 설계를 논의하는 자리가 있고 코드리뷰나 특정 버그를 어떻게 해결할지 다루는 회의도 여기 해당한다. 여기 기획자가 들어가지 않는 이유는 첫째, 들어가도 무슨말인지 잘 모르니 참여하기 부담스러워 한다는 이유가 있고, 둘째로 예전에도 안 들어왔으니 관성으로 기술자들이 초대를 안하기 때문이다. 하지만 이런 회의들은 기획자들이 ‘뜻하는 바’를 ’어떻게’ 구현해 낼지에 대해 논의하는 자리다. 작성한 문서를 기반으로 기술자들끼리 상의하겠지만 모호한 부분이 있다면 기획자가 답을 해줘야만 낭비하는시간 없이 회의가 진행 가능하다. 게다가 기술적 제약이 있다며 개발방향이 기획방향과 다르게 전개된다면 기획자가 나서서 바로잡아야 한다. 기술자들끼리 의사결정을 마치고 한참 개발한 뒤에 “이건 기획방향이랑 다른데요!?” 라고 이야기하면 서로 난감해진다.

기획자가 알아듣지 못하는 기술용어들이 난무하는 기술토론에서 소외감을 느끼고 참여하기 싫어 지는 것은 자연스러운 현상이다. 그럼에도 기획자로서 기획한 바를 실현해 내고 싶다면 기술토론에 참여해야 한다.

다양한 기술회의들과 특징

다양한 기술회의들이 있다. 각 회의들은 목적과 특징이 다르지만, 모두 우리 프로덕트를 어떻게 만들어나갈지 다루는 자리라는 면에서 공통점이 있다.

기술 검토 회의

기술 검토 회의는 복잡한 개발 작업이나 기술적 이슈가 발생했을 때 진행된다. 기술적 어려움에 부딪혀서 구현이 어려워졌을때 제일 쉬운 선택은 그부분을 도려내는 것이다. 하지만 그렇게 되면 기획 의도와는 자연스럽게 멀어지게 된다. 기획자는 이 회의에서 요구사항이 어떻게 반영되는지 확인해야 한다. 예를 들어, 발생할 수 있는 성능 문제를 논의할 때, 기획자는 사용자 경험에 미치는 영향을 설명하고 대안을 제시해야 한다.

아키텍처 설계 회의

시스템의 전반적인 구조와 설계 방향을 결정하는 회의다. 이 단계에서 기획자는 시스템의 확장성과 유연성을 고려하여 비즈니스 목표와 사용자 니즈가 어떻게 반영되는지를 확인해야 한다. 또 계약관계나 규제로 인한 제약을 받는다면 이부분도 설계에 포함되는지 꼼꼼히 확인해야 한다. 설계도가 바뀌면 영향이 막대하다. 각도가 틀어진것 같다면 시간이 지나기전에 초반에 바로잡아야 하기때문에 아키텍처 설계 회의에 참여해야 한다.

기술 스택 선정 회의

프로젝트에 사용할 기술과 도구를 결정하는 회의다. 이때 기획자는 기술 스택이 비즈니스 목표와 사용자 니즈에 어떻게 부합하는지를 평가해야 한다. 예를 들어, React와 Angular 중 어떤 프레임워크를 사용할지 결정할 때, 기획자는 각 기술의 장단점을 고려해 사용자 경험에 미치는 영향을 생각해야 한다. 선정하는 모든 기술스택에 대해 학습하는건 어려울 수 있다. 심지어 개발자들도 모든 기술의 장단점에 대해 다 알지 못한다. 하지만 기술스택이 나중에 어떤 영향을 미치는지 생각해보면 공부할 만한 가치가 있다. 새 멤버를 채용할때나 소프트웨어 유지보수 비용에도 영향을 준다는것을 생각하고 기술 스택에 관심을 가질 필요가 있다.

코드 리뷰 미팅

코드 리뷰 미팅은 작성된 코드의 품질, 보안성, 재사용성을 검토하는 회의다. 기획자에게 코드리뷰 미팅은 우리 개발조직이 건강하게 업무하고있는지 점검할 수 있는 좋은 기회다. 가능하다면 기획내용과 부합하는지 코드를 점검하면 좋겠지만, 불가능하다고 해도 참석해서 개발팀의 분위기를 감지하면 좋다.

문제 해결 회의

개발 과정에서 발생한 기술적 장애물이나 성능 이슈를 해결하기 위한 회의다. 이 회의에서 기획자는 대안을 제시하는 역할을 한다. 예를 들어, 성능 문제로 인해 특정 기능을 제한해야 할 때, 기획자는 사용자 경험을 최적화하는 방안을 제안해야 한다. 결코 포기할 수 없는 요소가 있다면 설득해 관철시켜야 한다. 또 내부 코드와 기술에 몰입하고 있어 새로운 가능성을 보지 못하는 개발진에게 외부 경쟁자들은 이를 어떻게 해결했는지 소개하고 새로운 가능성을 제시할 수도 있다.

각 회의마다 기획자는 기술적 결정을 비즈니스 목표와 사용자 니즈와 연결지어 설명하고, 기획 의도가 기술적으로 어떻게 반영되는지를 확인하는 역할을 한다. 기술회의 자리 만큼 효율적으로 의견을 전달할 수 있는 기회가 많지 않다. 적극적으로 활용할 만한 가치가 있다.

기획자가 지켜야 할 핵심가치

기획자가 기술적 토론에 참여할 때 지켜야 할 핵심 가치는 기획 의도의 본질을 지키는 것이다. 기술적 제약이 있을 수 있지만, 이를 통해 기획 의도가 왜곡되지 않도록 하는 것이 중요하다. 예를 들어, 특정 기능 구현 시 성능 문제가 발생할 수 있다는 점이 기술 토론 때 지적되면, 기획자는 사용자 경험을 최적화할 수 있는 방안을 제시해야 한다. 구현하고 싶은 방향을 제시하지 못하면, 작업자는 진행이 어려워진다.

기획자는 또한 “모르는 것”을 인정하는 자세를 가져야 한다. 당연하게도 전문기술을 모두 알 수는 없다. 모른다고 주눅 들 필요는 없다. 다만 모르는 부분을 인정하고 배우려는 자세를 갖추면 충분하다. ‘내가 이것까지 알아야되?‘라는 고압적인 자세를 가진 기획자들 사이에서 배우려는 자세를 가진 기획자는 샛별같은 존재다. 좋은 태도로 개발자와의 신뢰 관계를 구축하고, 더 나은 협업을 이끌어낼 수 있다.

또한 기획자는 사용자 경험과 비즈니스 가치를 수호하는 역할을 해야 한다. 기술적 결정을 내릴 때, 사용자 니즈와 비즈니스 목표가 어떻게 반영되는지를 확인하고, 이를 지속적으로 강조해야 한다.

참여하기 전에 준비할 것

기술적 토론에 참여하기 전에 기획자는 충분한 준비가 필요하다. 먼저, 논의될 주제에 대한 기본 지식을 습득해야 한다. 예를 들어, 특정 기술 스택이나 아키텍처 설계에 대한 이해가 필요하다면, 사전에 관련 자료를 읽고 이해하는 것이 필요하다.

기획자는 기술 토론 전에 핵심 질문을 준비해야 한다. 특히 성능 관련 질문은 중요하다. 예를 들어, "요청이 클라이언트에서 처리되는지, 서버를 거쳐야 하는지, 아니면 외부 API까지 호출해야 하는지?" 와 같이 구체적인 질문을 준비해야 한다. 또한, "이 기술 스택이 사용자 경험에 어떤 영향을 미칠까?", "이 설계가 비즈니스 목표에 부합하는가?" 와 같은 질문을 통해 기술적 결정을 비즈니스 목표와 연결지어 설명할 수 있어야 한다.

개발자의 관점도 이해하는 것이 중요하다. 개발자가 어떤 기술적 제약을 가지고 있는지, 어떤 문제를 해결하려고 하는지를 이해하면, 더 나은 대안을 제시할 수 있다.

적극적 경청과 끼어들기의 균형

기술적 토론에서 기획자가 적극적으로 경청하는 것은 매우 중요하다. 개발자의 설명을 주의 깊게 듣고, 메모를 하며, 이해한 내용을 재확인하는 습관을 들이는 것이 좋다. 이를 통해 기획자는 기술적 결정을 비즈니스 목표와 사용자 니즈와 연결지어 설명할 수 있다.

또 기획자는 적절한 타이밍에 끼어들어 질문을 던질 줄 알아야 한다. “이 방향은 원래 기획 의도와 다르지 않나요?”라고 말하는 것은 기술적 결정을 재검토하게 만드는 좋은 방법이다. 건설적인 대안을 제시하는 것도 중요하다. 예를 들어, “이 방향으로 가면 사용자에게 어떤 영향이 있을까요? 다른 선택지로는 어떤 것이 있을까요?“와 같은 질문을 통해 기술적 결정을 비즈니스 목표와 연결할 수 있다.

기획자가 기술회의를 주재하는 방법

기획자가 기술회의를 주재하는 것은 존재감을 드러내고 회의에 자연스럽게 스며드는데 도움이된다. 기획자가 할 수 있는 기술 회의 안에서 역할들이 있다.

명확한 의제 설정 : 기획자는 회의의 의제를 명확히 설정해 회의 필요여부를 판단한다. 논의할 주제와 해결해야 할 문제를 구체적으로 정의하고, 모든 참석자가 회의 전에 이를 이해할 수 있도록 만들어야 한다.

적절한 참석자 선정 : 회의에 참석할 적절한 인원을 선정해야 한다. 어떤 개발자가 어느부분을 맡고있는지 정확히 파악하고 회의때 의사결정을 해 줄 사람을 회의실에 불러야 한다. 필요한 인원이 오지 않는건 불필요한 인원이 참석하는 것보다 더 치명적이다.

균형 잡힌 토론 유도 : 기획자는 모든 참석자가 의견을 낼 수 있도록 사회자가 되어 토론을 유도해야 합니다. 논의가 핵심 주제에서 벗어나지 않도록 관리하고, 갈등으로 번지는것을 막아야 한다. 개발자들끼리 기술에 대해 토론하는것은 재미있는 수다거리이다. 우리 프로덕트에 필요한 이야기만 할 수 있도록 사회자의 역할을 수행해야 한다.

결정사항 문서화 : 회의에서 내려진 결정사항을 회의록 형태로 문서화하고 공유해 모두의 이해를 한번더 동기화할 필요가 있다. 회의록에는 반드시 책임자와 일정 등을 명시하여 이후 해야 할 일들을 관리해야 한다.

후속 조치 확인 : 결정사항이 실제로 이행되는지 확인하는 것도 중요하다. 후속 조치를 통해 회의때 함께 정한 사항이 올바르게 구현되는지 정기적으로 확인해야 한다.

위 와 같이 기획자가 기술미팅에 참여하고자 마음먹으면 해야하고 할 수 있는 역할은 충분히 있다.

효과적인 질문하기

기획자가 기술적 토론에서 영향력을 발휘하는 방법은 주로 좋은 질문으로 시작된다. 질문은 열린 질문과 닫힌 질문으로 나눌 수 있다. 열린 질문은 더 많은 정보를 얻을 수 있는 방법이다. 예를 들어, “기술 스택 중에서 이부분을 다른거로 바꾸면 사용자 경험에 어떤 영향을 미칠까요?“라는 질문은 개발자에게 더 많은 설명을 유도할 수 있다.

또한 “왜”보다 “어떻게”로 시작하는 질문이 더 효과적이다. “이 기능을 구현하기 위해 어떻게 하면 좋을까요?“라는 질문은 개발자가 구체적인 해결책을 생각하도록 유도한다.

기술적 세부사항과 비즈니스 가치를 연결하는 질문도 중요하다. “이 결정이 저희 목표와 부합하나요?“라는 질문은 참여자들에게 조직의 목표를 상기시키고 지향하는 방향으로 생각하도록 만드는데 도움이 된다.

기술 제약 속에서 창의적 해결책 찾기

기술적 제약이 있을 때 기획자는 창의적으로 해결책을 찾아야 한다. 기술적 제약을 새로운 기회로 바라보고, 개발자와 함께 대안을 모색하는 것이 중요하다. 예를 들어, 성능 문제로 인해 특정 기능을 제한해야 할 때, 기획자는 새로운 방향으로 사용자의 니즈를 충족시킬 방법을 고민하게 된다.

기술적 제약이 오히려 더 나은 사용자 경험으로 이어질 수 있는 사례도 있다. 예를 들어, 전체 목록을 화면에 노출하는 기능을 구현하는데 문제가 있어 이를 포기하고, 관련성이 높은 아이템 하나를 직접 보여주도록 기획을 변경했다고 가정해보자. 어찌보면 이런 기획 변경은 사용자에게 더 간단하고 직관적인 인터페이스가 될 수 있다. 기획자는 기술적 제약을 기회로 생각하고 창의적인 해결책을 생각해 더 나은 결과물을 도출하도록 힘써야 한다.

기술적 토론은 기획 의도를 지키며 해결책을 찾는 과정이다. 기획자는 기술적 결정을 비즈니스 목표와 사용자 니즈와 연결지어 설명하고, 기획 의도가 기술적으로 어떻게 반영되는지를 확인하는 역할을 한다.

기술적 토론에서 기획자가 적극적으로 참여하고, 자신감을 유지하며, 지속적으로 학습하는 것이 중요하다. 이를 통해 더 나은 제품을 개발하고, 개발자와의 신뢰 관계를 구축할 수 있다. 이는 궁극적으로 비즈니스 성공에 기여하는 중요한 요소다. 기술적 토론은 단순히 기술적 결정을 내리는 것이 아니라, 사용자 경험과 비즈니스 가치를 최적화하는 과정임을 기억하고 가능한 꼭 기술 회의에 참여해야 한다.

위에서 알아본 대로 기술 전문가들과 원활히 소통하기 위해서는 그들의 전문성을 인정하고, 적절하게 질문하을 통해 의견을 듣는게 필요하다. 또 방향을 제시하는 기획자의 특성상 적절한 대안을 제시하는것 역시 커뮤니케이션에 핵심이다. 다음 글에서 적절하게 질문하고 대안을 제시하는 방법을 알아보려고 한다.