업무 중 기획자가 기술적으로 무리한 요구를 하는 경우는 의외로 자주 발생합니다. 그럴 때마다 "안 됩니다"라는 단순한 거절만 반복하면 협업은 점점 어려워집니다. 실무에서 개발자가 기획자와 소통할 때, 기술적 한계를 효과적으로 전달하는 방법에 대해 정리합니다.

1. "기술적 한계"가 아니라 "비용 문제"로 설명하기

기술적으로 불가능한 것은 사실상 거의 없습니다. 문제는 '시간'과 '리소스'입니다.
예를 들어, 기획자가 실시간 AI 번역 기능을 원한다고 요청했다면 이렇게 대응합니다:

"가능은 하지만, 이 기능을 구현하려면 외부 API 비용이 많이 들고, 실시간 성능을 확보하려면 추가적인 서버 리소스가 필요합니다. 개발 기간도 2~3주는 소요될 수 있어요."

이렇게 말하면 단순한 거절이 아니라, 기획자가 직접 우선순위를 판단하게 됩니다.

2. 예시와 유사 사례를 동원해 설명하기

기획자는 기술 내부 구조에 익숙하지 않기 때문에, 유사 서비스나 사례를 들어 설명하면 이해도가 높아집니다. 예:

"지금 요청하신 기능은 인스타그램의 리스폰시브 스토리처럼 작동해야 하는데, 그 정도 인터랙션은 보통 34명의 프론트엔드 인력이 붙어서 12개월은 개발하는 수준이에요."

이런 설명은 기술적 무게감을 직관적으로 전달해 줍니다.

3. 기술 용어를 배제하고, 사용자 행동 관점으로 설명하기

기획자가 이해할 수 있도록 기술 용어는 배제합니다. 예를 들어:

• 잘못된 설명:
  "이건 DOM 리렌더링 이슈 때문에 성능이 안 나옵니다."

• 좋은 설명:
  "사용자가 스크롤할 때 화면이 많이 끊길 수 있어서 UX가 안 좋아질 수 있어요."

기술을 설명하기보다, 그로 인해 사용자 경험에 어떤 영향이 생기는지 중심으로 말하는 것이 중요합니다.

4. 대안을 제시하고 선택권을 기획자에게 넘기기

무조건적인 거절은 최악입니다. 기획자 입장에서는 다음 액션이 막히기 때문입니다. 다음처럼 대안을 제시합니다:

"이 기능을 지금 넣는 건 부담스럽지만, 1차 출시에는 단순 버전으로 구현하고, 이후 개선 버전에서 고도화하는 건 어떨까요?"

기획자에게 선택권을 넘기되, 현실적인 가이드를 주는 것이 이상적입니다.

기술자와 기획자의 대화는 '의사결정'을 중심에 두어야 합니다. 단순히 '안 된다'는 입장이 아니라, '되긴 하지만 이러이러한 조건이 붙는다'는 식으로 설명할수록 협업은 매끄러워지고, 신뢰도 쌓이게 됩니다.

기술의 복잡함은 그대로 두되, 설명은 단순하게. 이것이 실무에서 가장 필요한 역량입니다.

#코딩실무노트 #개발자커뮤니케이션 #기획자협업 #기술적한계설명법 #실무팁