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

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

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

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

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

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

API(Application Programing Interface)

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

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

프로토콜(Protocol)

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

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

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

유닛 테스트(Unit Test)

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

개발자 간 대화 예시

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

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

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

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

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

비 개발자와 개발자의 대화

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

육하원칙과 프레임워크

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

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

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

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

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

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

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

대화에 도움 되는 도구들

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

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

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

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

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

끝내며

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

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

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