비즈니스는 모르겠고 개발만 하고 싶다는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-10-20

"저는 복잡한 비즈니스 로직 말고, 대용량 트래픽이나 순수 기술적인 문제만 풀고 싶습니다."

멘토링을 신청한 2년 차 백엔드 개발자 민우 씨가 진지한 표정으로 꺼낸 첫마디였습니다. 비즈니스는 기획자나 사업 부서가 고민할 일이고, 개발자는 코드의 성능과 아키텍처에만 집중하는 것이 진짜 엔지니어의 길이라 믿고 있었습니다.

과연 그럴까요? 회사는 왜 기술만 아는 개발자보다 비즈니스를 이해하는 개발자에게 두 배의 연봉을 줄까요?

코드는 비즈니스를 표현하는 도구에 불과합니다

민우 씨에게 현재 담당하는 결제 시스템의 정산 주기가 왜 3일인지 물었습니다. 대답하지 못했습니다. 테이블 스키마에 왜 특정 상태 컬럼이 들어갔는지도 몰랐습니다. "기획서에 그렇게 적혀 있어서요."

도메인을 모르는 개발자가 짠 코드는 겉보기에만 멀쩡합니다. 비즈니스 맥락이 빠진 설계는 작은 정책 변경 하나에도 와르르 무너집니다. 예외 처리는 엉뚱한 곳에서 터지고, 롤백 조건은 현실의 돈 흐름과 어긋납니다. 기술적으로 매끄러운 코드가 실제로는 사업을 위협하는 시한폭탄이 되는 순간입니다.

비즈니스를 모르면 기술 선택의 기준을 잃습니다

200명이 넘는 주니어 개발자를 만나며 본 공통된 착각이 있습니다. 유행하는 기술을 도입하는 것이 실력이라고 믿는 태도입니다.

사용자 100명인 사내 어드민에 카프카와 MSA를 붙이겠다고 3주를 쓴 3년 차 개발자가 있었습니다. 왜 카프카가 필요한지 묻자 "비동기 처리를 공부해보고 싶어서"라고 답했습니다. 비즈니스를 이해하지 못하는 개발자는 언제나 자기 만족을 위해 기술을 고릅니다.

회사가 지금 풀어야 할 병목이 무엇인지, 이 기능이 어떤 고객 가치를 만드는지 모르면 올바른 기술 결정을 내릴 수 없습니다. 오버엔지니어링은 개발자의 열정이 아니라 도메인 무지에서 나옵니다.

연봉을 결정하는 건 코드 라인이 아니라 문제 해결입니다

면접관이나 팀장이 "이 프로젝트에서 가장 어려웠던 점이 무엇인가요?"라고 물을 때가 있습니다. 탈락하는 개발자는 라이브러리 버전 충돌이나 프레임워크 설정 이야기를 꺼냅니다.

합격하는 개발자는 다릅니다. "고객의 주문 취소율이 급증하던 원인이 결제 타임아웃 정책에 있음을 발견하고, 비즈니스 정책을 재정의해 손실을 40% 줄였습니다."

시장은 코드를 많이 치는 타자수를 원하지 않습니다. 기술을 지렛대 삼아 사업의 병목을 부숴주는 해결사를 원합니다. 도메인을 깊게 파고들어 기획의 허점을 먼저 짚어내는 사람. 그런 개발자가 대체 불가능한 인재가 됩니다.

코드 밖으로 시선을 돌리십시오. 내가 치는 코드 한 줄이 고객에게 어떻게 닿고, 회사의 통장에 어떤 숫자로 찍히는지 추적하십시오. 비즈니스를 집요하게 이해하려는 순간, 비로소 진짜 엔지니어링이 시작됩니다.