'금방 되죠?'라는 한마디가 팀을 무너뜨릴 수 있다
회사에서 자주 보는 장면이 있습니다. 누구나 한 번쯤은 겪었을 법한, 너무 흔해서 오히려 말로 꺼내기 애매한 순간입니다. 회의가 길어지고, 일정은 이미 빡빡하게 잡혀 있고, 모두가 이번 주만 넘기면 된다는 마음으로 버티는 시기에 누군가가 아주 가벼운 톤으로 말을 꺼냅니다.
"HUD에 노출된 이 버튼을 팝업 창으로 옮기면 더 좋아질 것 같아요. 이거 어렵지 않죠? 금방 되는 거죠?"
그 한마디로 공기가 얼어붙는 걸 여러 번 봤습니다. 질문을 던진 쪽은 진짜로 '조금'이라고 생각할 수도 있습니다. 듣는 쪽은 '지금 이 타이밍에?'라는 말이 목구멍까지 올라옵니다. 겉으로 보면 말투 싸움처럼 보입니다. '왜 저렇게 말하지?' 혹은 '왜 저렇게 예민하게 받아치지?' 같은 평가가 붙습니다.
그런데 이 장면의 핵심은 감정이 아니라 '리스크'의 관점 차이입니다. 더 정확히는 프로젝트 리스크를 어떻게 인식하는지 그 차이가 말 한마디에 압축되어 튀어나오는 순간입니다.
기획자는 왜 가볍게 말할까?
기획자가 "금방 되는 거죠?"라고 말할 때 그 사람의 머릿속에는 대개 '효과'가 먼저 떠오릅니다. 버튼 위치가 다른 곳으로 옮겨지면 사용성이 더 좋아질 것 같고, 전환율이 오를 것 같고, UX가 더 좋아질 것 같고, 팀이 더 프로답게 보일 것 같습니다. 그 기대는 대부분 선의에서 시작합니다. 우리가 함께 만드는 제품을 더 좋게 만들고 싶은 마음에서 나온 말이니까요.
문제는 그 다음입니다. 구현 난이도와 검증 비용은 상대적으로 잘 상상하지 못합니다. 그건 그 사람의 책임 영역이 아니거나, 경험적으로 체감하기 어렵기 때문입니다. 그래서 요청은 "큰 방향성을 바꾼다는 건 아니에요. 그냥 위치만 바꾸는 거에요"라고 포장됩니다.
이 말에는 나름의 배려도 들어 있습니다. 부담을 줄여주려는 의도일 수 있습니다. 다만 그 배려는 종종 프로그래머에게 다른 신호로 전달됩니다. 요청하는 쪽은 '이 정도면 프로그래머를 힘들게 하는 건 아닐거야'라는 마음으로 스스로를 방어하고, 그 마음이 말끝에 붙습니다. "금방 되는 거죠?"라는 확인은 사실 내가 무리한 요구를 하는 건 아니라는 자기 확인일 때가 많습니다.
프로그래머는 왜 표정이 바로 굳을까?
반대로 프로그래머가 듣는 '조금'은 기획자가 느끼는 조금과는 전혀 다릅니다. 특히 막바지 빌드, 안정화 단계, QA가 진행되는 시점이라면 더욱 그렇습니다. UI 버튼 위치 변경은 리소스를 수정하는 문제로 끝나지 않는 경우가 많습니다. 레이아웃이 흔들릴 수 있고, 해상도 별로 깨질 수 있고, 반응형 대응이 별도로 필요할 수도 있고, 다른 UI 요소와 겹침이 생길 수도 있습니다. 무엇보다 무서운 건 따로 있습니다. 바뀐 건 버튼의 위치인데 새로 생기는 건 '책임'이라는 점입니다.
출시 후 버그가 발생하면 어떤 질문이 돌아오는지 실무자들은 알고 있습니다. "왜 QA에서 못 걸렀어요?", "왜 개발에서 확인 안 했어요?"라는 말이 나오기 시작합니다. 일정이 촉박했다는 사정은 그 순간 힘을 잃기 쉽고, 남는 건 결과와 책임 소재입니다. 그래서 프로그래머는 "버튼의 위치를 옮겨주세요"를 이렇게 번역해서 듣습니다.
"오늘 야근 좀 해주세요. 그리고 나중에 터지면 그건 당신 쪽으로 기억될 가능성이 큽니다."
이건 예민함이 아니라 계산입니다. 회사라는 조직이 기억하는 방식, 일이 기록되는 방식, 책임이 흘러가는 방향을 예측하는 능력입니다. 프로그래머가 화를 낸 게 아니라, 미래의 리스크를 미리 본 것이죠.
본질은 말투가 아니라 합의되지 않은 변경
그래서 저는 누군가의 말투만 탓하는 결론을 경계하게 됐습니다. 기획자 말투가 거칠어서도 프로그래머가 까칠해서도 아닙니다. 핵심은 타이밍과 책임 범위가 공유되지 않은 상태에서 변경 요구가 들어왔다입니다. 변경 요청이 들어오면 최소한 세 가지가 함께 움직여야 합니다.
1. 이 변경이 일정에 어떤 영향을 주는지
2. QA/검증 리스크는 누가 부담하는지
3. 출시 후 문제가 생기면 책임 범위를 어디까지 볼 건지
이러한 합의가 없는 상태에서 "금방 되는 거죠?"라는 말이 나오면 갈등은 거의 자동으로 발생합니다. 감정이 아니라 구조가 그렇게 만들기 때문입니다. 논점이 기능에서 사람으로 떨어지고, 그 순간부터 대화는 생산성을 잃습니다.
실무에서는 이상적인 대화를 길게 할 시간이 없습니다. 이런 경우 그럼 뭐라고 말해야 할까요? 프로그래머 입장에서 사용할 수 있는 문장을 정리하면 다음과 같습니다.
"지금 반영은 가능한데, 안정화 단계라서 수정 자체보다 QA 리스크가 클 겁니다. 오늘 밤 전체 테스트를 다시 돌려야 해서 일정이 하루 밀릴 수 있어요. 일정 조정이 가능한가요? 아니면 이건 다음 패치 후보로 돌릴까요?" 이런 대화의 힘은 감정이 없다는 데 있습니다. 대신 리스크, 일정 지연 가능성, 일정 반영 가능 여부, 선택지가 들어 있습니다.
이렇게 말하는 순간 대화의 층위가 바뀝니다. '기획 vs 프로그래머'의 감정 싸움에서 '프로젝트 의사결정'으로 올라갑니다. 그때부터는 싸움이 아니라 합의가 가능해 집니다. 상대도 머릿속 계산을 다시 시작합니다. 이건 버튼 하나가 아니라 일정 이야기라는 생각이 들고, 우선순위를 다시 보려고 시도합니다.
반대로 감정적인 대응은 피해야 합니다. "예?? 이제 와서 왜요?", "그건 말이 안 되죠", "안 됩니다"라는 말이 사실 틀린 말은 아닐 수 있습니다. 실제로 "이제 와서"일 수도 있고, "말이 안되는" 요구일 수도 있습니다. 그런데 조직에서 이러한 대화들은 기능/일정의 논점이 아니라 태도로 해석되는 경우가 많습니다. 그 순간부터 기획자의 마음 속에는 불만이 쌓입니다. 프로그래머가 협조적이지 않았고, 커뮤니케이션이 어려웠다고 기억됩니다.
그리고 그건 대부분 프로그래머에게 불리하게 작동합니다. 주요한 건 '승리'가 아니라 '상처를 줄이는 방식'입니다. 논점을 감정으로 끌어내리지 않고, 이성적으로 끌어올리는 것이 필요합니다. "이건 일정과 QA 리스크의 문제입니다"라고 프레임을 잡는 것이, 감정을 지키는 가장 실용적인 방법입니다.
"금방 되는 거죠?"가 사라지지 않는 이유
솔직히 말하면 "금방 되는 거죠?"라는 말은 앞으로도 사라지지 않을 겁니다. 회사는 출시가 임박해지면 마음은 촉박하고, 제품은 늘 개선할 것이 있고, 사람은 늘 자기 영역 밖의 비용을 잘 모릅니다. 그래서 이러한 문장을 없애려 하기보다, 이 문장이 나왔을 때 서로 상처를 주지 않도록 번역 체계를 만드는 쪽이 더 현실적이라고 생각합니다.
기획자는 효과를 보고 말하고, 프로그래머는 리스크를 보고 반응합니다. 둘 다 틀리지 않습니다. 다만 서로가 보는 방향이 다를 뿐입니다. 그러니 필요한 건 "당신 말투가 문제예요"가 아니라, "이 변경의 비용과 책임을 같이 보자"는 합의입니다.
누군가의 한마디가 팀을 무너뜨리는 게 아니라, 합의되지 않은 리스크가 팀을 무너뜨립니다. 그리고 그 리스크를 합의로 끌어올리는 가장 빠른 방법은 감정 대신 조건과 선택지를 말하는 것입니다. 다음에 누군가 또 유사한 발언을 하더라도 서로의 시야가 다름을 인지하고 커뮤니케이션 하면 어떨까 싶습니다.
"금방 되는 거죠?"
"네. 가능합니다. 다만 테스트가 추가로 필요해서 일정 조정이 있어야 합니다. 지금 반영할지, 패치로 돌릴지 논의해보고 결정하면 될 것 같네요."
이러한 대화가 불필요한 상처를 줄이고, 팀을 '싸우는 팀'에서 '결정하는 팀'으로 바꿔놓을 것이라 생각합니다.
Powered by Froala Editor