회의실에서 개발자가 말합니다. “그건 구조상 어렵습니다.” 혹은 “보안 이슈가 있어서요.”

3년차쯤 되면, 이런 말을 들을 때마다 미묘한 긴장감이 생깁니다. 진짜 기술적으로 불가능한 건지, 아니면 다른 이유가 있는 건지. 잘못 물어보면 “기획이 기술을 모른다”는 소리를 들을까 봐 조심스럽고요.

이 글은 그런 순간을 위한 가이드입니다. 개발자와 대화할 때 “기술적으로 어렵다”는 말 뒤에 숨은 진짜 이유를 찾아내는 법을 정리했습니다.

왜 기획자는 기술 용어 앞에서 주눅 드는가

API, 권한 체계, 캐싱, 웹소켓. 회의 중에 이런 단어들이 쏟아지면, 배경지식이 없는 기획자는 순간 멈칫하게 됩니다. “이해 못 했다고 하면 무시당하는 거 아닐까” 하는 불안감이 생기죠.

하지만 문제는 이해 부족이 아닙니다. 맥락의 차이입니다.

개발자는 “기술 구현의 복잡도”를 말하고, 기획자는 “사용자가 경험할 결과”를 묻습니다. 같은 단어를 쓰지만, 서로 다른 층위에서 대화하고 있는 거예요.

예를 들어볼까요. 제가 앱 기획할 때 있었던 일입니다.

기획자(저): “주문 알림이 실시간으로 되나요?” 개발자: “웹소켓 연결 유지하려면 서버 부하가 크고, 모바일에서는 백그라운드 제약도 있어서…”

저는 “주문 후 5초 안에 알림이 왔으면 좋겠다”는 UX를 묻고 싶었는데, 개발자는 실시간 통신 프로토콜의 기술적 난이도를 설명한 겁니다. 서로 다른 걸 말하고 있었던 거죠.

‘기술적으로 어렵다’의 진짜 의미 5가지

개발자가 “어렵다”고 할 때, 실제로는 다음 중 하나를 의미하는 경우가 많습니다.

1. 정말 기술적으로 불가능하다

가장 드문 케이스입니다. 현재 기술 스택으로는 물리적으로 구현할 수 없는 경우죠.

물어볼 질문:

• “우리 서비스에서 안 되는 건가요, 아니면 기술 자체가 없는 건가요?”
• “비슷한 걸 구현한 다른 서비스 사례가 있을까요?”

이렇게 물으면, 진짜 불가능한 건지 아니면 우리 환경의 제약인지 구분할 수 있습니다.

2. 구조를 뜯어야 해서 공수가 크다

가장 흔한 케이스입니다. “구조상 안 됩니다”라는 말의 실체죠.

여기서 ‘구조’란 보통 이런 것들을 의미합니다:

• 데이터베이스 설계 (테이블 구조, 관계 설정)
• API 설계 (데이터를 주고받는 방식)
• 권한 체계 (누가 무엇을 할 수 있는지)
• 화면 전환 흐름 (사용자가 이동하는 경로)

물어볼 질문:

• “지금 구조에서 안 되는 이유가 뭔가요? (간단하게만)”
• “구조를 바꾸려면 어느 정도 시간이 걸릴까요?”
• “구조는 그대로 두고, 비슷한 효과를 낼 다른 방법은 없을까요?”

세 번째 질문이 핵심입니다. 많은 경우, 완전히 똑같이는 못 해도 80% 정도 만족시킬 우회 방법이 있거든요.

3. 보안/정책 검토가 필요하다

“보안 이슈”라는 말을 들으면, 기획자는 당황합니다. 내가 위험한 걸 요구한 건가 싶어서요.

하지만 실제로는:

• 진짜 보안 위험 (개인정보 노출, 권한 우회 등)
• 정책 미정 (법무/컴플라이언스 검토 필요)
• 개발자의 방어적 표현 (“혹시 몰라서”)

이 셋이 섞여 있습니다.

물어볼 질문:

• “어떤 보안 문제가 예상되나요?”
• “이 부분은 법무팀 검토가 필요한 건가요?”
• “다른 서비스에서는 이걸 어떻게 처리하나요?”

특히 세 번째 질문이 유용합니다. 경쟁사가 이미 구현했다면, 보안상 불가능한 건 아니라는 뜻이니까요.

4. 성능 문제가 예상된다

“이렇게 하면 느려져요”, “서버 부하가 커져요” 같은 말입니다.

여기서 중요한 건, 얼마나 느려지는지를 구체화하는 겁니다.

물어볼 질문:

• “사용자가 체감할 정도로 느려지나요?”
• “트래픽이 얼마나 늘어날 때 문제가 되나요?”
• “일단 소수 사용자로 테스트해보고 판단하면 안 될까요?”

많은 경우, “느려질 수 있다”는 가능성일 뿐, 실제 측정 전까지는 확신할 수 없습니다.

5. 우선순위가 안 맞는다 (솔직히 하기 싫다)

이건 기술 문제가 아니라 커뮤니케이션 문제입니다.

개발자가 “어렵다”고 표현했지만, 실제로는:

• 다른 긴급한 작업이 있다
• 이 기능의 가치를 납득하지 못했다
• 요구사항이 계속 바뀌어서 지쳤다

이럴 때는 기술 논의를 계속해봐야 평행선입니다.

물어볼 질문:

• “이 기능이 지금 시점에 왜 중요한지 다시 설명드려도 될까요?”
• “다른 업무와 우선순위 조율이 필요할까요?”
• “요구사항 중에 꼭 필요한 것과 나중에 해도 되는 것을 나눠볼까요?”

우선순위 문제는 PM이나 리드급과 함께 조율하는 게 좋습니다.

질문할 때 피해야 할 표현

“그냥 간단하게 할 수는 없나요?”

개발자 입장에서는 “내가 일을 복잡하게 만든다”는 뉘앙스로 들립니다. 차라리 이렇게 물어보세요:

“이 기능에서 가장 복잡한 부분이 어디인가요? 그 부분만 나중으로 미루고 나머지만 먼저 하면 어떨까요?”

“다른 데는 다 되던데요”

경쟁사를 언급하는 건 조심스럽습니다. 그들의 기술 스택, 팀 규모, 개발 기간을 모르니까요. 대신:

“○○ 서비스 사례를 보니 비슷한 기능이 있더라고요. 우리도 참고할 만한 부분이 있을까요?”

“이해가 안 되는데, 쉽게 설명해주세요”

“쉽게”라는 단어가 때로는 무례하게 들립니다. 이렇게 바꿔보세요:

“제가 기술 백그라운드가 없어서 잘 모르는데, ○○ 부분을 조금만 더 풀어서 설명해주실 수 있나요?”

대화의 목표는 ‘이해’가 아니라 ‘합의’

기획자가 모든 기술 용어를 완벽하게 이해할 필요는 없습니다. 중요한 건 합의 지점을 찾는 것이죠.

“웹소켓이 정확히 뭔지”를 몰라도, “실시간이 아니라 5~10초 간격 폴링으로 해도 사용자 경험에 큰 차이가 없다”는 결론을 내릴 수 있으면 됩니다.

다음 표는 기술 용어를 들었을 때 바로 물어볼 수 있는 핵심 질문들입니다:

개발자가 한 말	바로 물어볼 질문
“구조상 안 됩니다”	구조를 바꾸지 않고 비슷한 효과를 낼 방법은 없나요?
“보안 이슈가 있습니다”	구체적으로 어떤 위험이 있나요? 다른 서비스는 어떻게 하나요?
“성능 문제가 생깁니다”	사용자가 체감할 정도인가요? 트래픽이 얼마나 될 때 문제인가요?
“API 연동이 복잡합니다”	어느 부분이 가장 복잡한가요? 단계별로 나눠서 진행 가능한가요?
“기술 스택이 안 맞습니다”	기술 스택을 바꾸는 건 현실적이지 않다면, 현재 스택으로 할 수 있는 대안은요?

협업의 시작은 ‘존중’

마지막으로, 기획자가 기억해야 할 한 가지.

개발자는 “안 된다”고 말하려고 개발자가 된 게 아닙니다. 대부분은 좋은 제품을 만들고 싶어 하죠. 다만 기획자와 보는 각도가 다를 뿐입니다.

“기술을 모른다”는 게 약점이 아니라, “다른 관점을 가진 사람과 협업하는 능력”이 진짜 역량입니다. 질문을 잘하는 기획자가 좋은 결과를 만듭니다.

---

맺음말

개발자와의 대화에서 가장 중요한 건 용어를 외우는 게 아니라, 진짜 문제가 무엇인지 함께 찾아가는 태도입니다. “기술적으로 어렵다”는 말 뒤에는 구조, 우선순위, 성능, 정책 등 다양한 이유가 숨어 있습니다. 이 글에서 정리한 질문들을 활용해서, 서로 다른 언어로 말하는 두 직군이 같은 목표를 향해 갈 수 있기를 바랍니다.