적절한 질문과 대안 제시하기
멍청한 질문도 더러 있습니다
질문을 어떻게 하느냐에 따라 질문을 듣는 사람은 생각하는 방법이 달라진다. "코끼리를 생각하지 마세요."라고 질문하면 코끼리를 떠올릴 수 밖에 없다. 질문은 소위 생각의 '프레임'을 만든다. 질문하는 방법에 따라 긍정적/부정적 반응을 어느정도 유도할수 있다. 개발자의 전문 역량을 통해 프로젝트 결과물을 만드는 만큼 그들의 긍정적 태도를 이끌어내는 건 필수적이다. 그래서 적절한 질문을 설계해서 생각의 프레임을 원하는 방향으로 만드는 것이 중요하다.
우리가 질문하는 의도는 대개 무언가 해결이 필요한 일이 있기 때문이다. 결국 대안을 마련하는것이 대화의 목적이 된다. 가끔 본인이 생각한 대책은 없으면서 다짜고짜 어떻게든 해결해달라고 떼를 쓰는 경우가 있다. 기술적인 대안을 직접 제안하기는 어려울 수 있지만, 대안을 맡겨놓은 듯 만들어서 가지고 오라는 태도는 관계에 악영향을 준다. 기획자의 입장에서 가능한 해결방안을 생각하고, 적절한 시점에 제시해서 제품의 방향성을 리드해야한다.
질문의 기술 - 언제, 어떻게 물어볼 것인가
잘못된 질문은 어떻게 부정적 영향을 줄까? 첫째, 개발자의 사기를 저하시킨다. "이게 그렇게 오래 걸릴 일인가요?"라는 질문은 개발자의 전문성과 노력을 무시하는 뉘앙스를 담고 있다. 기분이 좋을 수가 없다. 둘째, 문제 해결을 방해한다. "이렇게 하면 안 되나요?"라는 단순한 질문을 받으면 이렇게하면 왜 안되는지 설명해줘야 할 것 같은 기분이 든다. 문제의 본질을 흐리고 문제 해결을 어렵게 만든다. 셋째, 팀 분위기를 해친다. 공개적인 자리에서 공격적인 질문을 하면 전체 팀 분위기를 경직시킨다. 이런 질문들은 결국 시간 낭비를 초래한다. 충분한 사전 조사 없이 던지는 질문은 모두의 시간을 낭비하게 만든다.
질문 전 준비는 매우 중요하다. 기존 자료를 확인하고, 이메일이나 메신저에서 전에 논의된 내용을 반드시 파악해야 한다. 개발자들은 같은 질문을 반복해서 받을 때 큰 스트레스를 받는다. 질문하기 전에 팀 위키, 이슈 트래커, 메신저 히스토리 등을 먼저 확인하는 습관을 들이자. "이미 논의된 내용인데 또 물어보네"라는 인상을 주지 않으려면 이 과정이 필수다.
질문의 시급성을 파악하는 것도 중요하다. 모든 질문이 즉각적인 답변이 필요한 것은 아니다. 팀 전체업무를 막고있는 문제인지, 단순히 알면 좋은 것을 물어보고 있는 것인지 구분해야 한다. 전자에 해당한다면 "이 문제가 해결되지 않으면 다음 단계로 진행할 수 없어서 우선순위가 높습니다"라고 명시하는 것이 좋다. 반면 단순 정보 수집이라면 "급하지 않으니 편하실 때 알려주세요"라고 덧붙이거나 나중에 물어보는 것이 개발자의 몰입을 방해하지 않는 방법이다.
질문 유형을 이해하고 상황에 맞게 활용하는 것도 중요하다. 열린 질문은 다양한 아이디어와 가능성을 탐색할 때 유용하다. "이 기능을 어떻게 개선할 수 있을까요?"와 같은 질문은 개발자의 창의성을 자극한다. 반면 닫힌 질문은 명확한 결정이나 확인이 필요할 때 사용한다. "이 방식으로 진행해도 기술적으로 문제가 없나요?"와 같은 질문은 명확한 Yes/No 답변을 얻을 수 있다.
탐색적 질문은 복잡한 이슈를 탐색할 때 유용하다. "이 이슈가 발생한 근본 원인은 무엇인가요?"와 같은 질문은 깊이 있는 분석을 이끌어낸다. 다만 질문자가 답변을 어느정도 이해할 수 있어야 하고, 가짜 관심이 아니라는 전제가 필요하다.
재확인하는 질문은 정보 확인과 이해도 점검에 활용된다. "제가 이해한 바로는 A, B, C 순서로 진행된다는 것인데, 맞나요?"와 같은 질문은 오해를 줄이는 데 도움이 된다.
개발자의 몰입 시간을 존중하는 것도 중요하다. 누군가 말을 걸면 그 대화에서 다시 하던 업무로 돌아오기까지 전환 시간이 필요하다. 잦은 전환시간은 생산성 저하를 일으키고 결과적으로 프로젝트에 악영향을 준다. 따라서 물어볼 타이밍을 잘 선택해야 한다. 가능하면 정해진 미팅 시간이나 개발자가 명시적으로 소통 가능하다고 표시한 시간에 질문하는 것이 좋다. 긴급하지 않은 질문은 비동기 채널(이메일, 메신저 등)을 적극 활용하는 것이 좋다.
효과적인 질문 구성법
효과적인 질문을 구성하려면 몇 가지 원칙을 지켜야 한다. 첫째, 그냥 “안녕하세요"만 보내는 메신저 스타터를 지양해야 한다. 상대의 시간을 존중한다면 핵심으로 바로 들어가는 것이 좋다. "안녕하세요, 잠시 시간 되세요?"라고 시작하는 대신 "안녕하세요, 로그인 기능 관련해서 질문이 있습니다"처럼 주제를 명확히 하는 것이 좋다. 이렇게 하면 개발자가 질문의 맥락을 빠르게 파악하고 더 효율적으로 대응할 수 있다.
질문을 구조화하는 것도 중요하다. 이미 알고 있는 내용을 정리하고, 시도해본 해결책을 공유한 후, 명확하고 간결한 질문을 제시한다. 예를 들어 "저는 A, B, C까지 확인했고, D 방식으로 해결해보려 했으나 E 오류가 발생했습니다. 이 문제를 어떻게 해결할 수 있을까요?"와 같이 구성하면 개발자가 문제 상황을 빠르게 이해하고 불필요한 반복 작업을 줄일 수 있다.
퍼널 질문 기법도 효과적이다. 일반적인 질문에서 시작해 점차 구체적인 질문으로 좁혀가는 방식이다. 예를 들어 "사용자 인증 시스템에 대해 이야기해 볼 수 있을까요?" "이 부분에서 시간이 오래걸려서 사용자 이탈이 일어나는데 시간이 더 걸리는 이유가 무엇인가요?" "이 프로세스에서 속도를 개선하기 위한 효과적인 방법은 어떤게 있을까요?"와 같이 진행할 수 있다. 이 방식은 복잡한 주제를 체계적으로 탐색하는 데 유용하다.
질문할 때 개발자의 전문성을 존중하는 태도도 중요하다. "이렇게 하면 안 되나요?"라는 질문보다 "이 접근 방식에 대한 의견을 듣고 싶습니다"와 같이 개발자의 전문성을 인정하는 방식으로 질문하면 더 긍정적인 반응을 얻을 수 있다. 개발자는 자신의 전문 영역에서 인정받고 싶어하는 욕구가 있다는 점을 기억하자.
대안 제시의 기술
대안을 효과적으로 제시하는 몇 가지 접근법이 있다. 첫째, 대안 제시 전에 문제를 다양한 관점에서 재정의해본다. 같은 문제도 어떻게 바라보느냐에 따라 해결책이 달라질 수 있다. 예를 들어 "로그인 속도가 느리다"는 문제는 "사용자 경험 저하" 관점에서 볼 수도 있고, "서버 부하 증가" 관점에서 볼 수도 있다. 각 관점에 따라 해결책이 달라질 수 있으므로, 다양한 시각에서 문제를 정의해보는 것이 중요하다.
이상적인 상황을 고려한 후 현실적 제약을 적용하는 방식도 유용하다. "만약 시간과 자원의 제약이 없다면 어떤 해결책이 가장 이상적일까요?"라고 먼저 생각한 후, 현실적인 제약 조건을 고려하여 실현 가능한 대안을 도출하는 방식이다. 이렇게 하면 창의적인 해결책과 현실적인 구현 사이의 균형을 찾을 수 있다.
효과적인 대안 제시 방법으로는 이점 중심으로 설명하는 것이 있다. 기술적 세부사항보다는 해당 대안이 가져올 이점에 초점을 맞추는 것이다. "이 방식을 사용하면 개발 시간을 30% 단축하고, 유지보수가 더 쉬워질 것입니다"와 같이 구체적인 이점을 강조하면 개발자의 관심과 동의를 얻기 쉽다.
선택권을 제공하는 것도 중요하다. 하나의 해결책만 고집하기보다는 여러 옵션을 제시하고 각각의 장단점을 설명하는 것이 좋다. "A 방식은 구현이 빠르지만 확장성이 제한적이고, B 방식은 초기 개발에 시간이 더 걸리지만 장기적으로 유지보수가 쉽습니다. 어떤 방향이 더 적합할까요?"와 같이 접근하면 개발자가 의사결정에 참여한다는 느낌을 줄 수 있다.
정중한 표현을 사용하는 것도 중요하다. "이렇게 해야 합니다"보다는 "이 방식을 고려해 봤는데 어떠신가요?", "좋은 의견 있으신가요?"와 같은 표현이 더 효과적이다. 명령이 아닌 제안의 형태로 대안을 제시하면 개발자의 자율성을 존중하는 동시에 협력적인 분위기를 조성할 수 있다.
대안 탐색을 위한 실용적 접근법으로는 동료 및 네트워크를 통해 조사해보는 것이 있다. 비슷한 문제를 겪었던 다른 팀이나 회사의 사례를 수집하고, 그들이 어떻게 해결했는지 참고하는 것이다. "A 회사에서는 이 문제를 B 방식으로 해결했다고 합니다. 우리 상황에도 적용 가능할까요?"와 같이 접근하면 실제 검증된 해결책을 기반으로 논의할 수 있다.
사례 연구 활용도 효과적이다. 유사 상황에서의 해결책을 참조하여 대안을 제시하는 것이다. 특히 성공 사례와 실패 사례를 모두 분석하면 더 균형 잡힌 시각을 가질 수 있다. "C 프로젝트에서는 이 방식을 시도했다가 D 문제가 발생했습니다. 우리는 어떻게 이 문제를 피할 수 있을까요?"와 같이 실패 사례에서 배운 교훈을 활용하는 것도 좋은 방법이다.
대안을 제시할 때는 개발자의 기술적 제약과 선호도를 고려하는 것도 중요하다. 아무리 좋은 대안이라도 현재 팀의 기술 스택이나 역량과 맞지 않으면 실현하기 어렵다. 따라서 "현재 우리 팀의 기술 환경에서 가장 효율적으로 구현할 수 있는 방법은 무엇일까요?"와 같이 현실적인 맥락을 고려한 대안을 모색하는 것이 중요하다.
상황별 질문과 대안 제시 사례
질문과 대안 제시는 상황에 따라 다르게 접근해야 한다. 몇 가지 대표적인 상황별 사례를 살펴보자.
첫째, 기능 구현 가능성을 탐색할 때다. 새로운 기능을 제안하기 전에 기술적 실현 가능성을 확인하는 것은 중요하다. “이 기능을 저희도 똑같이 구현하고 싶은데 얼마나 걸릴까요?“라고 물어보는 것보다 “이런 기능을 기획하는데, 현재 우리 시스템에서 제약이 될 만 한게 있을까요? 어떻게 접근하는 것이 가장 효율적일까요?“라고 묻는 것이 더 낫다. 전자는 단순히 가능/불가능을 묻는 반면, 후자는 개발자의 전문성을 인정하고 창의적인 해결책을 모색하도록 유도한다.
둘째, 일정 지연이 예상될 때다. 개발 일정이 지연되는 상황은 프로젝트에서 자주 발생한다. 이때 “왜 아직도 안됐어요?“라고 직접적으로 물어보면 개발자는 방어적인 태도를 취할 수 있다. 대신 “혹시 저희 시스템에서 구현이 어려운 부분이 발견됐나요?“나 “일정 준수를 위해 범위를 조정할 만한 부분이 있을까요?“와 같이 문제 해결에 초점을 맞춘 질문이 더 생산적이다. 이런 접근은 비난이 아닌 협력의 메시지를 전달한다.
셋째, 버그나 이슈 발생 시다. 사용자가 버그를 보고했거나 시스템에 문제가 발생했을 때, “왜 이런 문제가 생겼나요?“라고 물어보는 것은 상황에 따라 비난처럼 들릴 수 있다. 사실 프로덕트를 관리하는 입장에서 버그가 발생하면 야속하고 비판하고 싶을 수 있지만, 버그 없는 소프트웨어는 없다. 자연스러운 현상임을 받아들이고 비판적인 질문 대신 “이 이슈의 원인을 파악하는 데 도움이 될 만한 정보가 더 필요한가요?“나 “이 문제를 해결하기 위한 접근 방식에는 어떤 것들이 있을까요?“와 같이 해결책 중심의 질문을 하는것이 좋다. 또한 “단기적으로는 어떻게 대응하고, 장기적으로는 어떻게 예방할 수 있을까요?“와 같이 시간 범위를 구분한 질문도 유용하다.
질문과 대안 제시 후 후속 조치
질문을 하고 대안을 제시한 후의 후속 조치도 중요하다. 첫째로, 적극적 경청이 필수다. 개발자의 응답을 주의 깊게 듣고, 중간에 끊지 않으며, 비언어적 신호도 읽어야 한다. 개발자가 설명하는 동안 메모를 하거나, 이해했다는 신호를 보내는 것이 좋다. “네, 이해했습니다”나 “그렇군요”와 같은 간단한 반응도 대화가 진행 중임을 보여준다.
둘째, 후속 질문으로 이해를 심화한다. “그렇다면 이 접근 방식이 사용자 경험에 어떤 영향을 미칠까요?“나 “제가 이해한 것이 맞는지 확인하고 싶은데, 이 문제는 A 때문에 발생하고, B와 C 방식으로 해결할 수 있다는 말씀이신가요?“와 같은 질문은 대화를 더 깊게 만든다. 이는 단순한 정보 교환을 넘어 진정한 이해로 이어진다.
셋째, 피드백에 열린 자세를 유지한다. 자신이 제안한 대안이 거부되더라도 방어적이 되지 않는 것이 중요하다. “그렇군요, 제 제안에 어떤 문제가 있는지 더 자세히 설명해주실 수 있을까요?“와 같이 열린 태도로 대응하면 더 나은 해결책을 함께 모색할 수 있다. 개발자의 의견을 존중하고, 다양한 관점을 인정하는 자세가 중요하다.
넷째, 논의 내용을 문서화하고 공유한다. 중요한 질문과 대안 논의 후에는 합의된 사항, 결정 사항, 다음 단계 등을 명확히 정리하여 관련 이해관계자들과 공유하는 것이 좋다. “오늘 논의한 내용을 정리해보면, A 문제에 대해 B 접근 방식을 시도해보기로 했고, C와 D는 추가 검토가 필요하다는 결론이었습니다. 이 이해가 맞나요?“와 같이 확인하는 과정도 중요하다. 이는 오해를 방지하고 책임 소재를 명확히 한다.
다섯째, 결정 사항을 존중하고 실행한다. 논의 결과로 내려진 결정은 일관되게 존중하고 실행에 옮기는 것이 중요하다. 합의된 사항을 자주 번복하거나 다른 채널에서 재논의하는 것은 신뢰를 해친다. 만약 새로운 정보나 상황 변화로 재검토가 필요하다면, 그 이유를 명확히 설명하고 투명하게 진행해야 한다.
적절한 질문과 대안 제시는 개발자와 기획자 간의 효과적인 협업을 위한 핵심 기술이다. 질문은 단순한 정보 수집 도구가 아니라 생각의 프레임을 만들고 창의적 사고를 자극하는 강력한 도구다. 마찬가지로, 대안 제시는 단순히 해결책을 나열하는 것이 아니라 협력적 문제 해결 과정의 일부다.
효과적인 질문을 위해서는 준비, 타이밍, 구조화, 경청 등 여러 요소를 고려해야 한다. 대안 제시를 위해서는 다양한 관점, 이점 중심 설명, 선택권 제공, 정중한 표현 등이 중요하다. 이러한 기술은 하루아침에 완성되지 않으며, 지속적인 연습과 피드백을 통해 발전시켜 나가야 한다.
무엇보다 중요한 것은 질문과 대안 제시의 궁극적인 목적을 기억하는 것이다. 그것은 비난이나 자기과시가 아니라, 더 나은 제품을 만들기 위한 협력적 문제 해결이다. 개발자의 전문성을 존중하고, 공동의 목표를 향해 함께 나아가는 자세가 중요하다.
적절한 질문과 대안 제시 기술을 통해 개발자와의 관계를 강화하고, 더 효율적인 협업 환경을 조성할 수 있다. 이는 단순히 현재 프로젝트의 성공뿐만 아니라, 장기적인 팀 역량 강화와 조직 문화 발전에도 기여한다. 다음 회의에서 이 글에서 배운 한 가지 기법이라도 시도해보자. 작은 변화가 큰 차이를 만들어낼 수 있다.
하지만 아무리 좋은 질문과 대안 제시 기술을 갖추더라도, 개발자들이 내린 기술적 결정의 배경을 이해하지 못한다면 진정한 협업은 어렵다. 개발자들은 단순한 취향이나 기분으로 기술을 선택하지 않는다. 그 뒤에는 복잡한 트레이드오프와 깊은 고민이 있다. 다음 글에서는 개발자들이 고심해서 내린 기술 결정들을 어떻게 이해하고, 그 결정에 어떻게 효과적으로 기여할 수 있는지 알아보려고 한다. 기술 결정의 배경을 이해하면 더 나은 질문을 할 수 있고, 더 실현 가능한 대안을 제시할 수 있다. 이것이 바로 기획자와 개발자 간의 시너지를 만드는 핵심이다.
