화성에서 온 남자, 금성에서 온 여자

이 글은 개인적인 경험을 바탕으로 한 내용입니다.

서비스 기획자 VS 개발자의 시각에서 바라본 IT 프로세스의 생각정리

 

교보문고(https://product.kyobobook.co.kr/detail/S000001449371)

 

20여 년 전 출간된 화성에서 온 남자, 금성에서 온 여자(존 그레이, 2010년 4월 15일)는 남녀의 사고방식과 관점 차이를 풀어낸 책입니다. 책장 어딘가에 묵혀 있을지도 모르겠네요.

이 책은 남자와 여자가 서로 다르게 생각하는 방식 때문에 오해가 발생하지만, 서로를 이해하고 배려하면 더 좋은 관계를 만들 수 있다는 메시지를 담고 있습니다.

[핵심 요약]

1. 남자는 신뢰와 인정을 원하고, 여자는 공감과 관심을 원한다.
2. 남자는 성취 지향적, 여자는 관계 지향적이다.
3. 남자는 가끔 동굴에 들어가고, 여자는 우물 바닥으로 내려간다 (즉, 각자만의 방식으로 생각을 정리하는 시간이 필요함).

서로의 차이를 이해하고 존중하는 것이 중요합니다.

다름을 틀림으로 규정하지 않고, 함께 조화롭게 살아가기 위해서는 열린 대화가 필요합니다. 서로의 입장을 배려하고 이해하려는 마음이 관계를 더 깊고 건강하게 만들어 줍니다.

이 개념은 기획자와 개발자의 관계에도 적용할 수 있습니다. 서로 다른 언어와 논리를 사용하지만, 결국 목표는 같습니다. 더 나은 협업과 원활한 커뮤니케이션을 위해 서로의 차이를 인정하고 이해하는 것이 필요합니다.

1. 기획자와 개발자

기획자와 개발자는 각기 다른 시각과 역할을 가지고 있으며, 제품을 바라보는 관점이 다릅니다.

일반적인 제품 개발 사이클을 보면 다음과 같습니다.

1. 기획 → 2. 기획 리뷰 (개발 포함) → 3. 개발 진행 → 4. QA → 5. 배포

기획자는 초기 단계에서 제품의 방향을 설정하지만, 개발자는 배포 단계까지 지속적으로 작업합니다. 개발이 이루어져야 QA도 가능하고, 디자인도 의미를 가지며, 고객 반응도 볼 수 있습니다. 모든 과정이 연결되어 있기 때문에 협업이 중요합니다.

애자일 방식의 조직이라면 기획이 처음 한 번 이루어지는 것이 아니라 여러 번 수정될 수도 있습니다. 하지만 기획 문서를 빠르게 만들어도, 개발자들은 바쁜 일정 속에서 세세히 읽지 못하고 직접 질문하는 경우가 많습니다.

이 과정에서 다음과 같은 문제가 발생할 수 있습니다.

개발자: "이 기능 개발을 시작했는데, 구현이 어렵습니다."

기획자: "왜 어렵죠?"

개발자: "... (기술적 제약 설명)"

또한, 개발자들은 기술 용어를 사용하며 커뮤니케이션하는 경향이 있습니다.

예를 들어: "HLS 응답을 받아 API에 token을 추가했는데, 이로 인해 영상 진입 시 광고 버퍼링이 발생하고 seamless 하게 동작하지 않습니다."

이러한 설명은 기획자가 이해하기 어려울 수 있으며, 결국 커뮤니케이션이 원활하지 않게 됩니다. 기획자는 개발의 난이도를 명확히 알기 어렵고, 개발자는 기획자의 요구사항을 완전히 이해하지 못할 수도 있습니다. 따라서 서로의 역할과 관점을 이해하려는 노력이 필요합니다.

2. 커뮤니케이션과 협업의 어려움

기획자가 기획 문서를 작성하면, 개발자는 이를 검토하며 구현 가능 여부를 자주 확인합니다.

기획자: "이거 가능할까요?"

개발자: "어렵습니다. 시간이 많이 걸릴 것 같습니다."

이때, 개발자는 단순히 "어렵다"고만 말하는 것이 아니라, 어떤 부분이 어렵고 대안이 있는지 설명하는 태도가 필요합니다. 기획자 역시 개발자의 입장을 고려하여 현실적인 일정을 조정할 수 있도록 유연한 사고가 필요합니다.

QA기간 중 QA 분께서 이런 말을 했습니다.

“그거 쉬운 거 아닌가요? 금방 수정 안 되는 게 이해가 안 돼요.”

이 말이 틀린 건 아닙니다. 문구 수정 자체는 쉬울 수 있지만, 영향도는 다를 수 있습니다.

개발은 단순한 변경이라도 디펜던시(의존성)와 영향도를 고려해야 합니다. 작은 문구 하나라도 여러 시스템과 연관될 수 있기 때문이죠.

이럴 때 저는 이렇게 질문하겠습니다.

“문구가 틀렸는데, 혹시 QA 기간 중 수정이 가능할까요? 어렵다면 기획팀에 요청해서 크리티컬 한 이슈인지 판단하고, 일정 조정이 필요하면 공유하려 합니다.”

3. Demo Day와 효과적인 커뮤니케이션

지금 교육 중인스타트업 스테이션 교육에서‘데모데이’라는 단어가 자주 나옵니다.

데모데이는 VC(벤처캐피털) 앞에서 창업 아이템을 소개하고, 업계의 문제점을 어떻게 해결할 것인지 비전과 목표를 발표하는 자리입니다.

저는 리더를 하면서, 개발과 QA, 기획 간의 원활한 협업을 위해 내부 데모데이를 진행하는 것이 중요하다고 생각했었습니다.

일반적으로 기획은 프로젝트의 맨 앞에서 진행되고, 개발은 뒤에서 따라가며, 기획서 업데이트는 자주 이루어집니다. 하지만 기획자와 개발자 모두 사람인지라 놓치는 부분이 발생할 수밖에 없습니다. 특히, 대규모 개편이라면 더더욱 그렇습니다.

그래서 저는 QA가 들어가는 일정 전에 기획, 개발자, QA 등을 초대해 ‘내부 데모데이’를 엽니다.

이 자리에서 개발자가 직접 기능을 설명하고, 시연하며, 질문을 주고받는 것입니다.

[내부 데모데이의 장점]

1. 개발자는 QA 진행 시 고려해야 할 사항과 아직 미흡한 부분을 미리 설명할 수 있습니다. 이를 통해 QA가 개발 의도를 이해한 상태에서 테스트를 진행할 수 있습니다.
2. 기획자는 자신의 기획 의도가 실제 구현된 결과물에서 어떻게 반영되었는지 확인할 수 있습니다. 종이에 적힌 기획이 실제 애플리케이션에서 다르게 보일 수도 있기 때문입니다.
3. QA는 기획 문서에는 없지만 꼭 필요한 예외 처리 사항 등을 개발자로부터 직접 들을 수 있습니다. 이를 통해 QA 도중 예기치 못한 상황을 미리 인지하고 대비할 수 있습니다.

demo day 개발자 시연

 

4. 더 좋은 프로덕트를 위한 협업

『화성에서 온 남자, 금성에서 온 여자』라는 책처럼, 서로의 차이를 인정하고 이해하며, 같은 목표와 방향성을 가지는 것이 좋은 프로덕트를 만드는 출발점이 아닐까 생각합니다.

저는 이러한 프로세스를 정립하고, 더 나은 협업 방식을 만들기 위해 계속해서 노력하고 있습니다

긴 글 읽어 주셔서 감사합니다!

 

 

[원문]

 

화성에서 온 남자, 금성에서 온 여자로 본 서비스 기획자 VS 개발자 | Shin Hyun Bung

 

---

숏폼플레이 다운로드 부탁드려요 ^^