요구사항이 바뀔 때마다 화가 나는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-10-03

기획서가 수정되고, 지난주에 완성한 기능을 걷어내야 한다는 말을 들을 때가 있습니다. 정성껏 짠 코드가 버려지는 기분이 듭니다. 화가 치밀고 허탈해집니다.

200명 넘게 멘토링을 하면서 주니어들에게 자주 듣는 하소연이기도 합니다. "기획이 자꾸 바뀌어서 코드를 계속 갈아엎고 있어요."

그런데 왜 요구사항 변경 앞에서 이토록 무력하게 화가 날까요?

코드를 건축물로 바라보는 착각

개발자가 분노하는 첫 번째 이유는 코드를 영구적인 건축물로 생각하기 때문입니다. 한 줄 한 줄 쌓아 올린 성이 기획자의 말 한마디에 무너진다고 여깁니다.

지난 멘토링에서 2년 차 백엔드 멘티가 2주 동안 공들여 짠 주문 로직을 걷어내야 했을 때, 온종일 모니터만 보던 모습이 생생합니다. 들인 노력이 부정당했다고 느꼈기 때문입니다.

소프트웨어는 건물이 아닙니다. 가설을 검증하기 위해 세운 천막에 가깝습니다.

비즈니스는 살아있는 유기체입니다. 고객 반응에 따라 움직여야 살아남습니다. 요구사항이 절대 바뀌지 않는 시스템이 있다면, 그것은 아무도 쓰지 않는 죽은 서비스뿐입니다.

'어떻게'에 갇혀 '왜'를 묻지 않는 태도

요구사항 변경에 화가 나는 두 번째 이유는 구현 방법에만 몰두했기 때문입니다.

3년 차 멘티 한 분이 쿠폰 적용 로직을 정액제로 바꾸라는 요청에 사흘간 야근을 했다며 억울해했습니다. "기획팀이 왜 바꾸는지 물어봤나요?"라고 묻자 말문이 막혔습니다.

확인해보니 첫 결제 전환율이 8%에서 3%로 급락한 위기였습니다. 비즈니스의 급박한 사정을 알고 나자, 멘티는 분노 대신 전환율을 살릴 API 개선안을 먼저 냈습니다.

"왜 바꾸는가"를 알면 코드를 대하는 눈이 달라집니다. 버려지는 코드가 아까운 게 아니라, 이번 변경으로 문제를 제대로 풀 수 있을지가 보이기 시작합니다.

변화를 흡수하는 설계를 배우는 기회

요구사항 변경은 실력을 드러내는 솔직한 시험대입니다.

기획이 조금만 바뀌어도 전체 구조를 뒤흔들어야 한다면, 애초에 유연하지 못한 설계였음을 뜻합니다. 단단하게 결합된 코드, 하나의 클래스가 온갖 책임을 떠안은 코드는 변경 앞에서 맥없이 깨집니다.

실무 10년 동안 만난 뛰어난 시니어들은 기획이 뒤집혔을 때 필요한 파일 한두 개만 갈아 끼우고 퇴근하는 격리력을 갖추고 있었습니다.

요구사항이 뒤집힐 때마다 분노 대신 코드를 돌아봅니다. '내가 너무 이른 최적화를 했는가?', '인터페이스를 제대로 분리했다면 이 부분만 교체할 수 있지 않았을까?'

화가 나는 순간이야말로 객체지향과 모듈화의 진짜 가치를 온몸으로 배우는 시간입니다.

회사는 예술 작품을 감상하려고 개발자를 채용하지 않습니다. 비즈니스의 불확실성을 소프트웨어로 빠르게 검증하기 위해 고용합니다.

다음에 기획 변경 요청이 오면 한숨 대신 질문을 던집니다. 왜 바뀌는지 묻고, 그 변화를 유연하게 품어내는 코드를 만듭니다. 그 차이가 단순 코더와 문제를 푸는 엔지니어를 가릅니다.