오늘은 개발자가 된다고 말했다

Posted Jun 6, 2025

By KIM SAN

17 min read

오늘은 개발자가 된다고 말했다

오늘도 개발자가 안 된다고 말했다

최근 ‘오늘도 개발자가 안 된다고 말했다’라는 비개발자가 개발자와 어떻게 하면 원활하게 소통할 수 있을지에 대해 설명한 책을 인상 깊게 읽었습니다. 책에서는 협업에 긍정적인 개발자 유형뿐만 아니라 ‘냉소적이고 딱딱한 말투’, ‘영어로 된 낯선 개발 용어를 늘어놓는’ 등의 부정적인 타입의 개발자도 함께 소개합니다. 저는 두 유형의 개발자를 모두 겪어본 경험이 있어 책을 읽으며 공감도 되고 한편으로는 웃기기도 씁쓸하기도 했습니다.

IT업계에는 기획자, 디자이너 등 다양한 직군이 있지만 유독 개발자는 별종 취급을 받고는 합니다. 제 생각에는 그 이유가 프로그래밍이라는 작업 자체가 0과 1로 이루어진 순수하고 복잡한 로직의 세계를 다루기 때문인 것 같습니다. 프로그래밍 자체가 일상의 언어 및 사고 방식과 비교했을 때 매우 이질적인 세계이기 때문에 비개발자에게는 낯설게 느껴질 수 밖에 없는 것입니다.

‘도메인 전문가’와의 간극

모든 사람이 전문적 수준의 개발 지식을 갖춰야 하는 것은 아니지만 디지털 전환(DX)을 넘어 인공지능 전환(AX)이 주요 트렌드가 된 지금, 개발자와 비개발자 사이의 간극이 지나치게 큰 것은 바람직하지 않습니다. 특히 대부분의 웹서비스 기업에서는 이 간극이 더욱 심각한 문제로 작용합니다. 간극이 크다는 것은 비개발자가 회사의 핵심 비즈니스 모델을 충분히 이해하지 못한다는 의미이며, 개발자는 다른 직군이 가진 소중한 현장 지식과 인사이트를 흡수하지 못한다는 뜻이기 때문입니다.

도메인 주도 개발(DDD)에서는 비개발자를 도메인에 대해 풍부한 지식을 가지고 있는 ‘도메인 전문가’라고 표현하며 효율적인 프로그래밍을 위해 개발자와 도메인 전문가 간에 공통의 언어(ubiquitous language)를 만드는 것이 필수라고 주장합니다. 이처럼 긴밀한 협업이 이루어지려면 도메인 전문가도 기본적인 개발 지식을 갖추고 조직 문화 역시 이를 뒷받침할 수 있도록 정비되어야 하는 등 전사적인 노력이 필요합니다.

다만 이번 글에서는 주제를 좁혀 백엔드 개발자 입장에서 도메인 전문가와 효과적으로 소통하기 위한 전략에 대해 제 개인적인 경험을 바탕으로 이야기해보려 합니다.

전략 1 : 풍부한 설명

꾸준한 문서 업데이트의 어려움 등 실용적 문제를 이유로 클린코드, 도메인 주도 설계 등의 책에서는 개발문서를 최소화 할 것을 권장합니다. 그러나 소통 단계에 한정하면 이해를 돕기 위한 문서는 풍부할 수록 좋습니다. 특히 대부분의 결과물을 눈으로 확인할 수 있는 프론트와 달리 백엔드의 경우 추상적인 로직을 다루기 때문에 더욱 문서작성 역량이 요구됩니다. 저는 주로 아래의 방법을 즐겨 사용합니다.

UML

전통적으로 많이 쓰이는 강력한 방법론입니다. 플로우 차트, 시퀀스 다이어그램 등 다양한 방법으로 비즈니스 로직을 시각화 할 수 있습니다. 단 제 경험 상 UML만으로는 이해가 어렵다고 말씀주시는 경우가 종종 있었습니다.

시나리오

실제 유즈케이스를 구체적인 시나리오 형태로 제공하는 방법도 유용합니다. 예를 들어 상품을 3BOX 이상 구매한 고객을 대상으로 단 1명만 당첨 가능한 선착순 이벤트가 있다고 가정할 경우 아래와 같은 시나리오를 제공할 수 있습니다.

이름	구매한 BOX 수
철수	3
영희	2
민수	4

응모시점	응모자 이름	응모 결과(응답 메시지)
12:00	영희	2BOX 더 구매 후 응모 가능합니다
13:00	철수	당첨되셨습니다.
13:01	민수	마감되었습니다
14:00	영희(2BOX 추가 구매)	마감되었습니다

위의 예시는 단순한 시나리오라 효용성이 크게 느껴지지 않을 수 있습니다. 하지만 시나리오 방법은 로직이 복잡하거나 추상적일수록 효과적입니다. 철수와 영희(혹은 Alice와 Bob)와 함께라면 어떤 로직이든 쉽게 풀어낼 수 있습니다.

비유

풍부한 비유는 직관적인 이해를 도울 수 있습니다. 예를 들어 저는 클라이언트-서버의 개념을 설명할 때 커피숍 비유를 즐겨 사용합니다.

클라이언트는 손님, 바리스타는 서버, 매대는 API입니다.
손님이 매대를 뛰어넘어 직접 커피를 타서 먹을 경우 엄청난 혼잡이 빚어질 것입니다. 이는 보안과 시스템 결합도의 관점에서 API의 중요성을 설명하는 예시입니다.
더 뛰어난 바리스타를 고용할 경우 더 많은 손님을 받을 수 있습니다. 그러나 아무리 뛰어난 바리스타라도 감당할 수 있는 고객의 수에는 한계가 있습니다. 이 경우 바리스타의 수를 늘리면 더 저렴하고 효율적으로 대응이 가능합니다. 이는 scale-up과 scale-out에 대한 예시입니다.

단 비유는 엄밀한 이해를 제공하지 못하므로 오해가 발생하지 않도록 신중하게 사용해야 합니다. 위의 커피숍 비유를 예시로 들자면 scale-out은 대부분의 상황에서 저렴한 방법이지만 실제 커피숍에서는 최저임금으로 인해 바리스타의 수를 늘리는 것이 저렴하지 않을 수 있습니다.

위키

시스템이 복잡할 수록 맥락 혹은 조직에 따라 동일한 개념을 다양한 이름으로 부르고는 합니다. 이 경우 이해관계자가 모여 공통의 보편적 언어(ubiquitous language)를 추출하고 위키에 기록하는 것이 필요합니다. 자세한 내용은 전략 2에서 다룹니다.

기타 방법

백엔드 개발자 입장에서 자주 쓸 일은 없지만 스토리보드, Mock UI 등의 시각화 방법도 유용합니다. 특히 최근 AI의 발전 덕분에 실제 프로덕트와 유사한 Mock 페이지를 빠르게 제작할 수 있게 되었습니다.

전략 2 : 보편적 언어를 바탕으로 순수한 로직을 추출하기

상술한 전략들 덕분에 각종 비즈니스 로직에 대한 이해도를 높일 수 있었습니다. 다음으로 도메인 전문가들과 함께 보편적 언어를 바탕으로 순수한 로직을 추출해야 합니다. 보편적 언어(Ubiquitous Language)란 도메인 주도 개발(DDD)에서 나온 개념으로 모든 구성원이 같은 개념을 같은 의미로 사용하도록 하기 위한 언어입니다. 비즈니스 로직의 명칭은 마치 생물이 다양한 종으로 진화하듯, 조직 내에서 시간이 지남에 따라 점점 더 다양하게 분화되고는 합니다. 특히 부서 간 소통이 부족한 조직일수록 같은 개념에 대해 서로 다른 용어를 사용하는 갈라파고스화가 심화되어 소통에 어려움을 겪습니다. 소프트웨어 개발에서는 이러한 용어의 다양성은 오히려 비효율적이므로 가지치기를 통해 보편적 언어를 수렴해야 합니다.

다음으로는 보편적 언어를 바탕으로 순수한 로직을 추출해야 합니다. 불확실성이 큰 곳에서 이윤을 남길 수 있기 때문에 비즈니스의 세계에서는 일정 부분 회색지대가 존재할 수도 있겠습니다. 그러나 모호함은 그 자체로 버그거나 유지보수를 어렵게 만들기 때문에 프로그래밍에서 만큼은 회색지대를 용납할 수 없습니다. 개발자는 조직 내 개념과 요구사항을 정제된 로직으로 변환하는 깔때기의 역할을 맡으며 반드시 주도적으로 과정을 이끌어야 합니다. 왜냐하면 순수한 로직을 추출하는 책임이 개발자에게 있으며 그 역할을 수행할 수 있는 적합한 역량을 가진 사람도 개발자이기 때문입니다. 물론 다른 직군도 논리적 사고를 요구받지만, 개발자는 업무 특성상 성장 과정에서 정교한 논리적 사고 능력을 자연스럽게 체득할 기회가 많습니다.

전략 3 : 상냥하고 적극적인 태도

농담이 아닙니다. 어쩌면 위의 전략 전부를 합한 것보다 상냥하고 적극적인 태도가 더 중요할 수도 있습니다. 아직 직장인으로써 경력이 길지는 않지만 ‘냉소적이고 딱딱한 말투’, ‘고의적으로 영어로 된 낯선 개발 용어를 늘어놓는’ 등의 오늘도 안된다고 말하는 부정적인 개발자를 종종 접했습니다. 그 개발자들이 부정적인 태도를 가지게 된 것은 오로지 그들만의 잘못은 아닙니다. 예전에는 열정이 있었으나 개발자를 부품으로 보는 조직문화, 열악한 처우, 웹개발에 대한 몰이해 등으로 인해 지친 경우가 대부분이었습니다.

그러나 냉소적인 팀원이 한두 명만 있어도 팀의 분위기가 망가집니다. 부정적인 태도는 곰팡이처럼 퍼져 나가고, 결국엔 의욕 있는 사람들마저 입을 닫게 만듭니다. 기술력도, 프로세스도 중요하지만 함께 일하는 사람들 간의 신뢰와 분위기를 해치는 태도는 그 어떤 전략도 의미 없게 만듭니다.