다른 서비스
NEW
기획
디자인
개발
프로덕트
아웃소싱
프리랜싱
비즈니스
최근 검색어
전체 삭제
최근 검색어가 없습니다.

개발

(비 개발자가) 개발자와 대화하기 위한 준비

 

요즘 ‘개발자’를 들어보지 않은 사람을 찾기 어려워졌습니다. 모든 산업군에서 IT가 담당하는 부분이 보조 및 지원에서 핵심 동력으로 변화하고 있기 때문입니다. 이러한 변화에 발맞춰 다양한 직무의 사람들 또한 변화해야 하는 세상이 되었습니다. 재밌는 점은 예전에는 기술의 변화에 따라서 다른 직군이 지금과 같은 움직임을 보이지는 않았습니다. 반면 언제부턴가 개발자에 관해서 알아야 하는 세상이 되어버렸습니다.

 

이런 변화는 1985년 하버드대학의 마이클 포터 교수가 기업의 활동을 분석하기 위해 제시한 가치사슬 모형(Value Chain model)을 보면 알 수 있습니다. 마이클 포터는 기업의 활동을 가치를 직접 창출하는 ‘주요 활동’과 주요 활동을 간접적으로 도와주는 ‘지원 활동’으로 나눠 설명하면서, 기술을 ‘지원 활동’으로 분류했습니다. 그는 ‘기술은 재고관리, 운영, 출고, 마케팅, 서비스 등의 모든 주요 활동에 걸쳐있다’라고 전했습니다.

 

가치사슬 모형
출처: 마이클포터 가치사슬 모형(Value Chain Model)

 

여기서 우리는 기술이 오늘날 모든 주요 활동에 걸쳐 있으면서 직접적으로 가치 창출에 기여하고 있는 점에 주목해야 합니다. 따라서 시대의 흐름과 경영의 방향이 기술과 밀접하게 접목되고 있는 요즘, 개발자와의 대화는 그리 생소한 일이 아닐 것입니다. 그래서 이번 글에서는 개발자와의 대화를 주제로 개발자와 협업 시 소통에 ‘필요한 것’들과 ‘방식’을 공유하는 내용을 전달하고자 합니다.

 

개발자 간 대화 살짝 살펴보기

개발자들은 과연 시스템을 개발하기 위한 의사소통을 어떻게 할까요? 사실 시스템 개발은 매우 복합적이라 단순히 몇 가지 항목을 가지고서 개발자의 대화라고 정의하기 어렵습니다. 다만 단편적으로 비 개발자분들에게 자주 노출이 되는 용어 몇 가지를 소개하겠습니다.

 

API(Application Programing Interface)

모바일 시대에 접어들면서 우리는 앱, 어플 등으로 부르며, 애플리케이션(Application)이라는 용어를 굉장히 친숙하게 사용하고 있습니다. 애플리케이션은 ‘우리가 원하는 서비스를 컴퓨팅 기기를 통해 수행할 수 있도록 응용한 프로그램’으로 이해하는 편이 쉽습니다.

 

API 연계서비스
출처: 전자정부프레임워크 Swagger UI 예시

 

개발자는 애플리케이션 프로그래밍을 위해 인터페이스에 관한 얘기를 주고받습니다. 이것이 바로 주위에서 심심치 않게 들리는 API(Application Programming interface)입니다. 개발자는 어떤 함수나 메소드 또는 서비스 주소를 호출하면 원하는 결과를 얻거나 줄 수 있을지를 API의 명세서를 통해 타인과 소통합니다. 때로는 웹 서비스를 설계하기 위해 Swagger 같은 API 도구의 명세 페이지 주소를 기획자에게 요청하기도 합니다.

 

프로토콜(Protocol)

앞서 말했듯이 API를 통한 의사소통은 구현의 강제가 없으므로 개발자는 상호 신뢰의 관계 속에서 개발하게 됩니다. 그런데 API보다 조금 더 엄격한 방식으로 안전한 방법으로 사용되는 방법이 있습니다. 바로 ‘프로토콜(Protocol)’입니다.

 

프로토콜은 네트워크 통신에서 사용되는 일종의 규약입니다. 컴퓨터 네트워크 환경에서 기기 간 데이터를 주고받으려면 사전 협의가 이뤄진 통신 협약이 필요합니다. ITU, IETF 등의 국제기구에서 국제통신규약과 표준을 제정합니다. RFC로 정의가 되어있습니다. 우리가 알고 있는 대부분의 통신 기반 서비스는 국제 표준 통신규약을 준수하며 운영합니다. 우리가 사용하는 웹서비스는 HTTP(Hypertext Transfer Protocol)이고, 메일은 POP3, SMTP, 파일전송은 FTP 등을 사용하고 있습니다.

 

프로토콜 규약
출처: RFC 7540 - HTTP2 프로토콜

 

개발자는 네트워크 기능이 있는 애플리케이션을 개발할 때 어떤 프로토콜을 사용할 것인지를 두고 대화하는 일도 잦습니다. 예를 들어 데이터의 송수신은 HTTP 기반의 REST로 할지, WS 혹은 WSS를 사용할 건지, MQTT를 통한 방법은 어떤지 등을 협업하는 개발자와 주고받습니다.

 

프로토콜 사용
출처: Protocol - Agilent Technology

 

유닛 테스트(Unit Test)

유닛 테스트는 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 코드를 말합니다. 개발자는 이런 코드를 읽고서 코드의 의도를 확인하고, 본인이 원하는 동작을 하는지를 확인하기도 합니다. 사실 소스 코드를 한 줄씩 읽으면 되겠지만 절대적으로 읽는 시간이 개발자에게 필요합니다. 더불어 단순히 읽는 것뿐만 아니라 코드 속에 있는 알고리즘을 이해하는 시간도 필요하고요. 이런 수고를 개발자들은 유닛 테스트를 통해 어느 정도 해소합니다. 그래서 유닛 테스트는 개발자 간 대화에서 주요 소재 중 하나입니다.

 

유닛 테스트
출처: 유닛 테스트 - 마틴파울러

 

개발자 간 대화 예시

우리는 위에서 API, 프로토콜 그리고 유닛테스트까지 걸쳐서 간략하게 살펴보았습니다. 이것 외에도 더 다양한 소재로 더 많은 이야기를 나누겠지만, 이 정도만 알아도 어렴풋이 아래 대화를 이해하실 수 있을 것입니다.

 

“A 씨 혹시 우리가 선택된 아이템의 정보를 이름순으로 10명씩 내림차순으로 받아보려고 하는데, 기존에 Json 받아 볼 수 있는 REST API 가 있을까요? 있다면 endpoint 나 Swagger 같은 API 문서 좀 주실래요?”

“안녕하세요? XXX사 B 개발자입니다. 귀사와의 데이터 연동을 위해서 제공할 수 있는 API 문서 부탁드립니다. 없으시다면 API 연동규격서 요청합니다. 더불어 MQTT 등의 프로토콜도 연동 가능한지 검토 부탁드리겠습니다.”

“K님이 작성하신 코드 동작은 단위 테스트 통해 잘 확인했습니다. 다만, 에러 테스트 부분이 이해가 안 되는데요. 코드상에서는 동작하지만 이렇게 의도해서 작성하신 이유가 있을까요?”

 

모든 개발자가 위와 같이 말하는 건 아니지만, 보통 이 정도 내용으로 이야기를 나눕니다.

 

 

비 개발자와 개발자의 대화

그렇다면 개발자와 일해야 하는 비 개발자분들은 어떻게 의사소통해야 할까요? 답은 간단합니다. 개발자에게 의뢰하여 개발하고 싶은 서비스 혹은 애플리케이션이 있다면 최대한 구체적으로 맥락에 맞게 설명해야 합니다. 이를 담고 있는 문서를 기획안이라고 부릅니다. 우리는 기획안을 개발자에게 잘 설명하고 이를 토대로 대화를 주고받는 것이죠. 개발자에게 시스템이나 애플리케이션에 관한 문의나 의견을 물어볼 때도 비슷합니다. 최대한 본인의 질문을 구체적으로 하면 됩니다. 그렇다면 어떻게 구체적으로 잘 설명할 수 있을까요?

 

코딩 기대 현실
출처: 코딩의 기대 vs 현실

 

육하원칙과 프레임워크

가장 기본적으로 육하원칙에 따라 본인이 원하는 서비스에 관련된 질문과 답변을 사전에 준비하고 개발자와 소통하는 것이 좋습니다. 일단 본인의 서비스를 누가, 언제, 어디서, 무엇을, 어떻게, 왜 쓰는지를 잘 설명하면 됩니다. 잘 완성된 기획서에는 이런 것들이 포함되어 있습니다. 그런데도 개발자와의 소통이 어려울 때가 있습니다. 왜냐하면 해당 기획서의 내용이 기획자와 업무 담당자 관점 중심으로 작성됐기 때문입니다. 이때 도움이 되는 것이 1987년 IBM의 존 자크만이 제시한 프레임워크입니다.

 

자크만 프레임워크
출처: 자크만 프레임워크 - Sparx Systems

 

존 자크만은 기업에서의 IT 자산운용을 위해 기획자, 업무담당자, 설계자 등 6가지의 이해관계자별 관점과 육하원칙을 기반으로 산출물을 만드는 자크만 프레임워크를 제시하였습니다. 여기서 우리는 해당 프레임워크에서 관점별 분류와 육하원칙의 내용을 쏙 뽑아내어 활용해 볼 수 있습니다. 특히 기획자, 업무담당자, 설계자, 엔지니어 등 네 가지의 관점으로 분류하여 개발자와의 대화에 사용하면 좋습니다.

 

예를 들어 ‘시스템을 누가, 언제, 어디서 사용하는지에 설명함(O/X)’ 등과 같이 나름의 체크리스트를 만들어서 개발자와의 대화에 활용하는 방식입니다.

 

대부분의 비 개발자분들이 편안하게 대화를 할 수 있는 부분은 비즈니스 모델까지입니다. 만약, 그 이상의 깊은 대화를 나눌 수 있다면 개발자는 조금 더 기술적으로 대화를 주고받을 수 있어서 편하게 의견을 개진할 수 있습니다.

 

예를 들어 아래와 같은 질문과 대화로 개발자와의 원활한 의사소통을 끌어낼 수 있습니다.

 

무엇을 (데이터) 

대화 예시

① 기획자의 관점(범위)“시스템에서 다뤄지는 정보들은 우리 서비스의 앞으로의 방향을 정하는 근거자료로 사용될 거예요.”
② 

업무 담당자의 관점(비즈니스 모델)

 “해당 정보는 매출, 주문, 고객 데이터와 관련이 있어요. 지역별 고객의 주문 건과 매출액을 알고 싶어요”
설계자의 관점(시스템 모델)

 “한 명의 고객이 여러 개의 계정을 이용할 수 있을까요?”

“저희 서비스는 매출과 주문이 다대다 관계인데, 이벤트 정보를 담는 테이블을 추가해서 관리 할 수 있나요?”

“이전에 작업 되던 데이터의 논리 ERD 파일을 제공해 드릴까요 ”

엔지니어의 관점(기술 모델)

“저희 서비스는 고객 테이블의 컬럼이 너무 많다고 들었는데, 정규화를 할 수 있을까요?”

“이전에 작업 되던 데이터의 물리 ERD 파일을 제공해 드릴까요?”

 

위의 대화 내용을 보면 범위①와 비즈니스 모델②까지는 제법 쉽게 이해됩니다. 그런데 시스템 모델③부터 어렵게 느껴집니다. 어려우니까 개발자에게 이런 일을 전적으로 맡기면 된다고 생각이 들기도 합니다. 하지만 시스템 모델을 다루는 지점이 개발자와 비 개발자 간의 대화가 꼭 필요한 지점입니다. 시스템 모델은 비즈니스 모델을 기반으로 물리적인 구현을 이어주는 설계를 다루는 중요한 지점이기 때문입니다. 좋은 설계를 위해서는 서로 최대한 수집 가능한 범위의 정보들을 기반으로 대화에 임하는 것이 좋습니다. 보통의 경우에는 개발자가 설계를 주도하고 비즈니스 데이터 수집은 업무담당자나 기획자가 진행합니다.

 

아직 내용이 어려우신 분들은 아래에 작성된 표를 살짝 참고 후 활용해보는 것도 좋습니다. 아래의 표는 기획자와 업무담당자의 관점을 기반으로 육하원칙의 각 항목을 나열한 질문입니다. 추상적인 질문이라 사용하기는 어렵겠지만, 개발자와 함께 구체적인 질문으로 만들고 답변을 만들어가는 과정을 통해서 더 나은 시스템 개발과 개선으로 이끌 수 있을 것으로 기대합니다.

관점별 분류 질문 예시
무엇을(데이터)개발자에게 비즈니스에서 원하는 정보의 규모와 현재 정보를 알 방법 등을 말했나요?
어떻게(기능)개발자에게 비즈니스 프로세스는 무엇이 있고, 어떻게 진행되기를 말했나요?
어디서(네트워크)개발자에게 비즈니스와 서비스가 사용되는 곳을 말했나요?
누가(사람)개발자에게 서비스를 사용할 사람들의 구성에 대해서 말했나요?
언제(시간)개발자에게 해당 서비스가 언제 쓰이는지를 말했나요?
왜(동기)개발자에게 해당 서비스의 비즈니스에서 갖는 의미와 추후 계획을 말했나요?

 

 

대화에 도움 되는 도구들

개발자와의 의사소통을 위한 도구로는 가장 쉽게 사용할 수 있는 것이 말과 글입니다. 다만 듣는 개발자로 하여금 충분한 상상력과 경험을 필요로 합니다. 이런 어려움을 돕고자 대화에 도움이 되도록 하는 다양한 도구들이 있습니다.

 

UX 분야에서 사용하는 고객여정지도나 와이어프레임을 활용하면 좋으며, 피그마, 제플린, XD 등 다양한 목킹(Mocking) 도구를 이용하는 방법도 있습니다.

 

의사소통 고객여정지도
출처: 고객여정지도 - nngroup.com

 

제플린 목업
출처: 제플린을 사용한 목업

 

예전부터 사용하던 ‘UML(Unified Modeling Language, 통합 모델링 언어)’을 이용하는 방법도 있습니다. 다만 UML은 다이어그램의 종류와 표기법이 많아서 초기 학습 난도가 높습니다. 따라서 조금 더 쉬운 ‘C4 모델(소프트웨어 시스템 아키텍처를 모델링하기 위한 린 그래픽 표기법)’을 활용하는 방법도 좋은 선택 방법입니다.

 

C4 모델
출처: C4 Model 예시

 

오로지 비즈니스 프로세스를 표현하는 방법으로는 ‘BPMN(Business Process Modeling Notation)’이 있습니다. BPMN을 이용하여 좀 더 비즈니스에 집중하여 내부 비즈니스 프로세스를 표현하는 방법을 고려할 수도 있습니다.

 

BPMN 표기법
출처: BPMN 표기법 - IBM

 

우리는 이러한 도구들을 통해 개발자와 소통을 원활하게, 그리고 도움이 될 수 있는 걸 목표로 합니다. 다만 도구가 대화에 장애물이면 안 됩니다. 만약 도구를 사용하고 배우는 데 어려움이 있다면 펜을 들고 정해진 형식 없이 노트나 칠판에 표현해서 대화하는 것도 괜찮습니다. 대화답게 서로 이해할 수 있으면 됩니다.

 

의사소통 비표준 다이어그램
출처: 의사소통 과정 중 도출된 비표준 다이어그램

 

 

끝내며

개발자와의 소통이 빈번해지고, 중요해지면서 비 개발자의 부담감 또한 함께 높아지고 있습니다. 그렇지만 비 개발자가 소통을 위해 열심히 노력하는 것처럼 개발자 또한 끊임없이 빠르게 변화하는 개발 업계에 대응하기 위해 부단히 노력하고 있습니다.

 

무엇보다 비 개발자와 개발자 모두 고객의 요구사항, 즉 비즈니스를 해결하여 가치를 제공하는 걸 우선시하고 있습니다. 비즈니스의 성공이 회사의 성공으로 이어지기 때문에 모두 같은 곳을 바라보면서 함께 고생하고 있는 셈입니다. 그러니 이번 글을 계기로 서로 너무 부담가지지 말고, 필요한 화제들을 적시 적소에 꺼내어 논의할 수 있도록 준비한 후 대화할 수 있기를 바랍니다.

 

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.

댓글 0

Jay Ahn

IT 컨설턴트 출신으로 지금은 백엔드 개발자로 일하며 경험을 쌓고 있습니다. 아주 작은 기업부터 외국계 글로벌 기업까지의 조직문화 경험이 있습니다. 건강한 문화를 전파하고, 개인의 성장에 자극이 될 수 있는 글과 이야기를 좋아합니다.

같은 분야를 다룬 글들을 권해드려요.

요즘 인기있는 이야기들을 권해드려요.

일주일에 한 번!
전문가들의 IT 이야기를 전달해드려요.

[구독하기] 버튼을 누르면 개인정보 처리방침에 동의됩니다.

일주일에 한 번! 전문가들의 요즘IT 이야기를 전달해드려요.

[구독하기] 버튼을 누르면 개인정보 처리방침에 동의됩니다.