혹시 이런 경험, 한두 번쯤은 있으신가요? 아니, 솔직히 말하면 이런 일이 일주일에 한 번은 생기지 않나요? 많은 개발자가 거절을 어려워합니다. 그리고 그 대가는 생각보다 큽니다. 주말 근무, 번아웃, 버그투성이 코드, 그리고 결국 "왜 그때 안 된다고 말하지 못했을까"라는 자괴감까지 들죠. 개발자에게 거절과 협상은 선택이 아닙니다. 자신의 시간을 지키고, 코드 품질을 유지하며, 10년, 20년을 버티기 위한 생존 기술입니다.

미리 요점만 콕 집어보면?

개발자에게 거절과 협상은 선택이 아닙니다. 자신의 시간을 지키고, 코드 품질을 유지하며, 10년, 20년을 버티기 위한 생존 기술입니다.
그런데 아이러니한 건, 거절하지 못하는 것이 오히려 팀에 더 큰 피해를 준다는 사실입니다.
역설적이지만, 가장 신뢰받는 개발자는 "No"를 잘 말하는 사람입니다.

왜, 자꾸 거절을 못 할까?

1) 착한 사람 증후군

제 주변에는 유독 "착한 개발자"가 많습니다. 아니, 정확히는 착해 보이려는 개발자가 많습니다. "내가 거절하면 동료한테 피해가 가는 거 아냐?", "팀워크 해치는 이기적인 놈으로 찍히면 어쩌지?", "도와달라는데 거절하면 너무 냉정한 거 아닌가?" 특히 한국 개발자들은 더 심합니다. 문화적으로 '눈치'를 보고, '분위기'를 읽고, '민폐'를 끼치지 않으려 하니까요. PM이 난처한 표정을 짓는 순간, 우리는 이미 반쯤 저버린 겁니다.

그런데 아이러니한 건, 거절하지 못하는 것이 오히려 팀에 더 큰 피해를 준다는 사실입니다. 과부하로 코드 품질이 떨어지고, 데드라인을 못 지키고, 결국 번아웃으로 한 달씩 쉬게 되면 그게 팀에 더 민폐 아닐까요? 적절한 거절은 이기심이 아니라 팀을 위한 책임입니다.

2) 기술적 낙관주의

개발자는 타고난 문제 해결사입니다. 문제를 보면 자동으로 "어떻게 풀지?"를 고민하죠. 이런 성향이 장점이기도 하지만, 거절을 어렵게 만드는 약점이기도 합니다.

"CRUD 하나 추가하는 거잖아. 하루면 되겠네."
"기존 코드 복붙해서 조금만 고치면 끝 아냐?"
"간단한 기능이니까 금방이지 뭐."

그런데 막상 시작하면 어떤가요? 예상치 못한 버그가 터지고, 엣지 케이스가 산더미처럼 쏟아지고, 레거시 코드는 스파게티처럼 엉켜있고, 기획서는 구멍투성이입니다. 결국 하루 작업이 일주일로 늘어나고, 자신을 자책하게 됩니다. '내가 멍청해서 그런가...' 아닙니다. 당신이 멍청한 게 아닙니다. 많은 개발자들이 기술적 낙관주의 실수를 합니다.

3) 평가에 대한 두려움

주니어 개발자일수록 이 두려움이 큽니다. "거절하면 평가에 안 좋게 나오는 거 아냐?" "승진에서 밀리는 거 아냐?" "다음 좋은 프로젝트에서 빠지는 거 아냐?" 그래서 무리한 요청에도 "네"라고 답합니다. 회사에 빨리 자리 잡고 싶고, 인정받고 싶으니까요.

그런데 여기 반전이 있습니다. 무조건 수락하는 게 오히려 평가를 깎아 먹습니다. 데드라인을 못 지키고, 코드 품질이 떨어지고, 결국 "저 사람 자기 관리 못 하네"라는 낙인이 찍힙니다. 반대로 적절히 거절하고 협상하는 개발자는 어떻게 평가받을까요? "현실적이고 책임감 있는 사람"으로 평가받습니다. 약속은 적게 하되, 한 약속은 반드시 지키는 사람 말이죠.

거절하지 못했을 때의 대가

1) 번아웃의 늪

모든 요청을 다 받아들이면 어떻게 될까요? 처음에는 괜찮습니다. "이 정도야 뭐"하면서 버티죠. 하지만 시간이 지나면서 과부하가 쌓입니다. 저녁 약속은 매번 취소되고, 주말에도 노트북을 열고, 취미는 기억 속에서 사라지고, 운동은 사치가 됩니다. 그리고 어느 순간 무너집니다.

거절을 모르는 시니어 개발자의 이야기를 한번 창작해 보겠습니다. 그는 거절을 모르는 개발자입니다. '시니어니까 이 정도는 해야지'라는 생각으로 모든 걸 떠안았습니다. PM의 급한 요청도, 주니어의 끝없는 질문도, 아무도 손대지 않는 레거시 코드도 전부요. 어느 월요일 아침이었습니다. 출근길 지하철 안에서 갑자기 숨이 막혔다고 합니다. 심장이 터질 것 같았고, 식은땀이 났고, 다리가 풀렸죠. 공황장애였습니다. 병원에서는 과로라고 했고, 그는 2개월간 병가를 냈습니다.

복귀 후 그가 동료 개발자에게 이런 말을 합니다. "거절은 무책임한 게 아니더라. 오히려 나를 지켜야 팀도 지킬 수 있어. 내가 쓰러지면 결국 모두에게 피해잖아." 그의 목소리에는 후회보다 깨달음이 묻어났습니다. "이제 알았어. 모든 요청에 '네'라고 하는 게 성실함이 아니라는 걸. 내가 할 수 있는 것과 없는 것을 구분하고, 솔직하게 말하는 게 진짜 프로더라고."

그 후 그는 변했습니다. 무리한 요청이 오면 현재 작업 목록을 보여주며 우선순위를 조율했고, 자신의 한계를 솔직하게 인정했습니다. 그렇게 거절을 모르던 개발자는 이제 현명하게 거절하는 개발자가 되었습니다.

2) 코드 품질의 하락

시간이 부족하면 뭐가 제일 먼저 희생될까요? 바로 코드 품질입니다.

"테스트 코드? 나중에 쓰지 뭐."

"리팩토링? 일단 기능부터 돌리고 보자."

"문서화? 코드가 문서지 뭐."

결과는? 3개월 후 그 코드를 다시 열었을 때 이렇게 중얼거리게 됩니다.

"도대체 이 코드를 누가 짠 거야... 아, 내가 짰네."

더 큰 문제는 악순환입니다. 코드 품질이 낮으면 디버깅에 시간이 더 들고, 그러면 새 작업 시간이 더 부족해지고, 결국 또 품질을 포기하게 됩니다. 거절하지 못한 대가를 미래의 내가 치르는 겁니다. 기술 부채는 이자가 붙는 빚과 같습니다. 나중에는 원금보다 이자가 더 커집니다.

3) 정작 중요한 일을 못함

항상 남의 급한 일만 처리하다 보면 정작 중요한 건 손도 못 댑니다.

시스템 개선? "나중에..."
새로운 기술 학습? "여유 있을 때..."
개인 프로젝트? "다음 달에..."
기술 부채 해소? "스프린트 끝나고..."

스티븐 코비의 시간 관리 매트릭스를 아시나요? 일을 네 가지 기준으로 나눕니다.

긴급하고 중요한 일
긴급하지 않지만 중요한 일
긴급하지만 중요하지 않은 일
둘 다 아닌 일

거절 못 하는 개발자는 3번(긴급하지만 중요하지 않은 일)에 시간을 다 쓰고, 2번(긴급하지 않지만 중요한 일)은 영원히 못 합니다. 그리고 나중에 이렇게 한탄하겠죠. "매일 남의 급한 일만 처리했더니 제 성장은 멈춰있네요. 새 기술도 못 배웠고, 포트폴리오도 없고... 남의 우선순위로 살다가 제 미래를 놓쳤어요."

효과적인 거절 방법

1) "No" 대신 "Yes, but..." 전략

거절이 어려운 진짜 이유는 "안 됩니다"라는 말 자체가 부담스럽기 때문입니다. 그럼 어떻게 할까요?

나쁜 거절: "안 됩니다. 저 바빠요."

좋은 거절:

"이번 주는 어렵지만, 다음 주 월요일부터 시작하면 수요일까지 완성 가능합니다."
"네, 가능합니다. 다만 지금 진행 중인 A 기능을 먼저 끝내야 하는데, 이걸 미루고 새 기능 먼저 할까요?"
"할 수 있습니다. 단, 예상 시간이 3일인데요. 범위를 줄이면 더 빨리 가능할 것 같습니다. 핵심 기능만 먼저 구현하고 나머지는 다음 스프린트에 하면 어떨까요?"

차이가 보이시나요? 거절이 아니라 협상입니다. "안 된다"가 아니라 "이렇게 하면 된다"를 말하는 겁니다.

2) 구체적 스크립트 제공

그럼 이제 실전에서 바로 쓸 수 있게 스크립트를 상황별로 정리했습니다.

시간이 부족할 때:

"이번 주는 A, B 작업으로 꽉 차 있습니다. 다음 주 화요일부터 가능한데 괜찮으신가요?"
"예상 시간이 3일인데, 현재 스프린트에는 2일밖에 여유가 없어요. 범위를 줄이거나 다음 스프린트로 조정하면 어떨까요?"

요구사항이 애매할 때:

"흥미로운 기능이네요. 다만 구체적인 요구사항 정리가 필요할 것 같아요."
"지금 정보로는 정확한 예상이 어렵습니다. 프로토타입 먼저 만들어서 검토 후 일정 확정하면 어떨까요?"

다른 일이 우선일 때:

"중요한 요청인 건 알지만, 현재 C 작업이 더 우선순위 높다고 알고 있어요. 팀장님과 우선순위 조율해 보면 어떨까요?"

전혀 모르는 분야일 때:

"할 수는 있지만 익숙하지 않아서 시간이 2배로 걸릴 수 있어요. 전문가한테 맡기는 게 효율적일 것 같은데 어떠세요?"

3) 우선순위 기반 협상법

거절의 핵심은 우선순위입니다. "안 된다"가 아니라 "이것보다 저것이 먼저입니다"라는 메시지를 전달하는 것이죠. 효과적인 방법은 현재 작업 목록을 시각화하는 것입니다. 간단한 테이블로 정리해 보세요.

새 요청이 오면 이 표를 보여주며 물어보세요. "현재 이런 작업들이 있는데, 새 작업을 넣으려면 어떤 걸 조정할까요?" 이렇게 하면 의사결정 책임이 요청자에게 넘어갑니다. 그리고 대부분 이렇게 말합니다. "아, 그럼 다음 주에 해도 되겠네요." 현재 작업 목록을 시각화 하는 건 최고의 방어막입니다.

거절은 프로의 능력이다

역설적이지만, 가장 신뢰받는 개발자는 "No"를 잘 말하는 사람입니다. 왜? 그들은 약속을 지키니까요. 무분별하게 수락했다가 데드라인 못 지키는 것보다, 현실적으로 거절하고 확실히 완성하는 게 훨씬 프로페셔널합니다. 거절은 신뢰를 깎는 게 아닙니다. 오히려 신뢰를 쌓는 과정입니다. 물론 처음에는 어렵습니다. 특히 주니어 개발자에게는 더욱 그렇죠. 하지만 작은 것부터 시작하세요.

내일부터 당장 시작할 수 있는 것들

1) 즉답 금지령

PM이 "이거 이번 주에 가능해요?"라고 물으면 바로 "네"라고 하지 마세요. 대신 이렇게 말하세요. "잠깐만요, 현재 일정 확인하고 10분 후에 답변드릴게요." 이 10분이 당신을 구합니다. 감정이 아니라 현실로 판단할 수 있는 시간이니까요.

2) 투명한 일정 공유

매주 월요일, 이번 주 작업 목록을 팀에 공유하세요. 슬랙이든, 이메일이든, 스탠드업이든 상관없습니다. "이번 주는 A 기능 구현(3일), B 버그 수정(1일), C 리팩토링(1일) 예정입니다." 이렇게 하면 새 요청이 왔을 때 "월요일에 공유한 목록 보셨죠?"라고 자연스럽게 말할 수 있습니다.

3) "네, 그런데..." 화법 익히기

거절을 바로 하지 못하겠다면, 조건부 수락을 연습하세요. "네, 가능합니다. 다만 현재 진행 중인 A 작업을 미루면 되는데, 괜찮으신가요?" "할 수 있습니다. 단, 예상 시간이 5일인데요. 범위를 줄이면 3일로 가능할 것 같습니다." 이건 거절이 아닙니다. 의사 결정권을 상대에게 넘기는 겁니다.

4) 거절은 책임감의 표현

거절은 이기심이 아닙니다. 자신의 시간을 지키고, 코드 품질을 유지하며, 장기적으로 팀에 기여하기 위한 책임감의 표현입니다. 거절과 협상은 코딩만큼이나 중요한 커리어 스킬입니다. 코드를 잘 짜는 것도 중요하지만, 자신의 시간과 에너지를 잘 관리하는 것도 중요합니다. 그것이 10년, 20년을 버티는 개발자와 5년 만에 번아웃으로 떠나는 개발자의 차이죠. 여러분의 "No"는 미래의 더 나은 "Yes"를 위한 투자인 걸 잊지 마세요.

<참조>

[국민일보] 하루하루 알차게 보내고 싶다면… 코비의 시간관리 ‘매트릭스’ 활용을