최근 인스타그램에서 흥미로운 릴스(Reels)를 하나 봤습니다. 데일리 스탠드업(Daily Standup)에서 일어난 프로젝트 매니저와 개발자의 대화를 다룬 영상입니다. 프로젝트 매니저가 개발자의 대화에 끼어들자, 개발자가 아는 척하지 말라며 호통을 치더군요. 릴스에 달린 댓글을 재미있게 읽으면서도, 사실 마음 한편이 편치 않았습니다. ‘혹시 나와 함께 일하는 개발자들도 비슷한 생각이면 어쩌지?’ 하는 걱정이 들었기 때문입니다. <출처: Corporate Dumpster Fire> 화성에서 온 개발자, 금성에서 온 비개발자 하지만 저 역시 할 말은 있습니다. 개발자들은 보통 기술적인 내용을 비개발자에게 잘 설명해 주지 않습니다. 제가 기술적인 내용을 이해하려고 아무리 열심히 공부해도 실제로 프로그래밍하지 않으면 상세한 내용을 이해하기는 어렵습니다. 가끔 대화를 잘 따라가고 있다고 생각하다가도 한편으로는 제대로 이해한 게 맞는지 의문이 듭니다. 이건 저만의 문제는 아닐 겁니다. 많은 사람이 다양한 채널을 통해 개발자와의 소통이 어렵다고 이야기합니다. 개발자의 생각이나 언어 구조가 보통 사람과는 다르다고 느끼며, 비개발자들 대부분이 최소한의 IT 용어나 개발 지식을 익히며 어떻게든 대화하려고 노력하고 있습니다. <출처: 레딧 r/ProgrammerHumor 채널> 개발자는 진짜 화성에서 왔을까? 개발자의 입장도 들어볼 필요가 있습니다. 개발자는 비개발자와의 대화를 어떻게 생각할까요? 아마 이런 생각이 있을 겁니다. ‘비개발자를 대상으로 기술적인 내용을 설명할 때, 어디서부터 시작해야 할지 모르겠습니다.’‘당연하다고 생각되는 용어나 프로세스를 모두 설명하기에는 시간이 부족합니다.’‘보이지 않는 로직과 코드를 상대방이 이해하도록 설명하는 데 한계가 있습니다.’ 개발자 역시 이렇게 고민하면서 비개발자와의 소통을 위해 나름 노력하고 있습니다. 개발자가 쓰는 언어의 3가지 특징서로가 고민하고 노력하는데도 우리는 왜 계속 소통에 어려움을 겪는 걸까요? 이를 이해하기 위해 우리는 먼저 개발자의 언어에 대해 조금 더 진지하게 들여다볼 필요가 있습니다. 1. 개발자는 이중언어 사용자(bilingual)다개발자는 한국어와 컴퓨터 언어를 사용하는 이중언어 능력자입니다. 이렇게 생각하면 개발자와의 소통에 대한 어려움을 조금 더 쉽게 받아들일 수 있습니다. 개발자는 대부분의 시간을 프로그래밍하면서 컴퓨터와 소통하는 데 할애하며, 하루에도 두 가지 이상의 언어를 계속해서 사용합니다. 그러니 Java, Python, C++ 등 다양한 컴퓨터 언어를 다른 사람에게 설명하려면 일종의 “이중 번역” 작업이 필요할 수 있습니다. 2. 프로그래밍은 추상화에 묶인 예술이다소프트웨어라는 것은 추상적입니다. 코드 자체는 개발자 이외의 사용자들이 눈으로 볼 수 없습니다. 결국 사용자는 개발자가 프로그래밍한 추상화된 시스템을 UI를 거쳐 경험할 뿐입니다. 따라서 비개발자가 개발자의 언어를 이해하려는 시도는 자칫 ‘장님 코끼리 만지는 격’이 될 수 있습니다. 사용자가 접하는 화면이나 기능은 전체 시스템의 일부분에 불과하기 때문입니다. 일부만 보고 그 안에 담긴 로직과 영향 있는 모든 시스템을 파악하는 것은 불가능에 가깝습니다. 3. 새로운 IT 용어와 서비스들이 계속 만들어진다.개발자와 대화하다 보면 다양한 IT 용어와 서비스들을 접하게 됩니다. API(Application Programming Interfaces), MSA(Micro Services Architecture) 같은 약어뿐만 아니라, 최근 AI로 인해 자주 나온 LLM(Large Language Model)처럼 새로운 개념들도 등장하고 있습니다. 이외에도 플랫폼마다 사용하는 서비스와 도구들이 너무 많습니다. 예를 들어 AWS에서 제공하는 수많은 서비스들의 이름과 활용법에 대한 이해가 먼저 이루어지지 않으면, 시스템의 작동 원리를 정확히 이해하기 어렵습니다. 개발자의 언어를 이중 번역하는 방법 지식의 차이를 뛰어넘는 소통 방법이 있을까요?개발자의 언어에 대한 세 가지 사실을 정리하다 보니, 문득 API 인증 방식 변경과 관련한 프로젝트가 떠올랐습니다. 그 프로젝트의 킥오프 미팅(Kick-off meeting)에서 담당 개발자는 변경될 API 인증 방식과 그 장단점에 대해 열정적으로 설명했습니다. 그의 설명이 끝나갈 때쯤 회의에 있던 한 사람이 손을 들고 질문했습니다. “죄송한데… API가 뭐예요?” 한 사람의 용기 있는 질문이 나오자 봇물이 터지듯 다양한 질문들이 쏟아져 나왔습니다. “API 인증 방식이 바뀌면 사용자에게 어떤 영향이 있나요?”“왜 토큰(Token) 대신 OAuth 인증을 사용하나요?” 이렇게 다양한 수준의 질문들이 꼬리에 꼬리를 물었습니다. 개발자는 시간 관계상 미처 모든 질문에 답하지 못했고, 미팅은 그렇게 끝이 났습니다. 돌이켜 보면 이런 식의 미팅이 꽤 많았던 것 같습니다. 개발자는 자신이 이해한 기술 내용을 어떻게든 설명하려고 애쓰고, 비개발자들은 이를 이해하기 위해 각자의 지식과 경험을 총동원하며 애쓰는 장면 말이죠. 아판타시아(Aphantasia): 같은 것을 말하지만 모두 다른 상상을 한다미팅에 참여했던 사람들은 개발자의 설명을 듣고 API 인증을 어떻게 이해했을까요? 저는 ‘API 인증’이라는 말을 듣고, 회원가입 때 필요한 인증 단계가 먼저 떠올랐습니다. 통신사와 휴대전화 번호를 입력하고 인증 번호를 받아 회원가입을 완료하는 과정을 자연스럽게 연상했습니다. Token이나 OAuth 혹은 API Key와 같은 작동 개념을 자세히 이해하지는 못했지만, 제가 경험한 기억과 정보의 조각으로 나름의 API 인증 방식을 상상하고 있었습니다. 혹시 아판타시아(Aphantasia)라는 단어를 들어보셨나요? 아판타시아란 ‘마음속으로 그림을 그리는 능력’을 뜻하는 용어로, 사람의 뇌가 눈으로 직접 보지 않아도 상상으로 이미지를 떠올리는 능력을 가졌음을 의미합니다. 아시아 사람과 서양 사람에게 ‘배(Pear)’라는 과일을 상상해 보라고 하면, 각자 경험과 정보에 따라 나름대로 배의 모습을 상상합니다. 이처럼 모든 소통과 이해는 서로가 가진 경험과 정보를 바탕으로, 개인적인 상상을 통해 이루어집니다. 그날 미팅에 참여했던 사람들은 모두 어떤 모습의 API를 머릿속에 그리고 있었을까요? 같은 주제에 서로 다른 상상을 하는 사람들 <출처: 작가> ByteByteGo의 이미지 하나로 이해한 API 인증 방식들미팅 이후 저는 개발자가 설명한 API 인증 방식에 대해 조금 더 자세히 이해하고 싶었습니다. 그러던 중 ByteByteGo에서 제공한 API 인증 방법에 대한 시스템 디자인(System Design) 이미지를 보게 되었습니다. 그 이미지를 본 순간, 미팅에서 개발자가 설명하려고 노력한 인증 방법의 흐름과 예시들이 너무나 쉽게 이해되었습니다. 만약 미팅 당시 이 이미지를 함께 보여주며 API 인증 방식에 대해 설명하고 피드백을 받았다면 어땠을까요? 적어도 미팅에 참여한 모두가 API 인증 방식이 어떻게 동작하고 어떤 상황에서 활용되는지 어느 정도는 이해할 수 있었을 겁니다. <출처: ByteByteGo> 이 경험으로 깨달은 것이 있습니다. 개발자가 비개발자와 소통하기 위해 노력할 때, 기술이나 프로세스를 이해시키는 것이 아닌 자신의 생각을 시각화해 보여주는 것이 가장 효과적이라는 생각입니다. 생각의 시각화가 주는 커뮤니케이션의 힘 이미 개발자는 Visible Working을 하고 있습니다!『Making Work Visible(업무 시각화)』이라는 책이 있습니다. 이 책은 주로 업무 효율화를 위한 시각화 방법을 설명하고 있습니다. 특히 칸반 보드(Kanban Board)나 업무 흐름표처럼 업무의 흐름과 진행 상황을 시각화하는 방법을 주로 다룹니다. 하지만 결국 시각화의 본질은 ‘사람들 간의 원활한 소통을 가능하게 하는 것’이라는 점도 강조하고 있습니다. 서로가 가진 문맥(Context)을 이해하고, 합의한 공동의 목표를 달성하는 것이 시각화의 진정한 목적이라는 겁니다. <출처: Book - Make Work Visible, Dominica DeGrandi> 사실 이미 많은 개발자가 눈에 보이지 않는 코드와 업무를 시각화하며 일하고 있습니다. 개발 문서를 작성할 때 다양한 종류의 다이어그램(Diagram)을 그리고, 지라(Jira)나 서비스나우(ServiceNow)로 진행 중인 업무를 문맥화하며, 흐름을 시각화하고 있습니다. 이처럼 생각을 시각화하는 일은 결코 거창한 게 아닙니다. 개발자들은 이미 더 나은 커뮤니케이션과 업무 이해를 위해 생각을 시각화하는 방법을 알고 있고, 또 익숙합니다. 다만 언제, 무엇을, 어떻게 활용해야 할지 조금 더 고민할 필요가 있을 뿐입니다. 대상과 목적에 따라 달라져야 할 생각의 시각화<출처: Alex Ellis Blog> 개발자가 생각을 시각화할 때 고려해야 할 가장 중요한 점은 ‘상대방의 지식 수준과 대화의 목적을 명확하게 이해해야 한다’는 것입니다. 예를 들어, 개발자가 시스템 사용자에게 새로 추가될 기능의 영향에 관해 설명하고 싶다면, 이를 시스템 화면을 바탕으로 시각화하여 설명할 수 있어야 합니다. 사용자는 보통 눈에 보이는 시스템의 화면과 기능에 대해서만 알고 있기 때문입니다. 이처럼 시스템 데모나 테스트 요청, 프로젝트 설명 등 다양한 상황에서 비개발자들과 대화가 필요한 순간, 조금만 더 그들의 입장에서 생각을 시각화해 설명하면 어떨까요? 더욱 즐겁고 생산적인 대화를 만들어 나갈 수 있을 겁니다. <출처: Sourcetrail> 꼭 비개발자가 아닌 개발자 간의 소통에도 시각화는 효과적입니다. 이미 코드를 쉽게 시각화할 수 있는 여러 아이디어와 툴들이 존재합니다. 그중에서도 특히 오픈소스 툴인 Sourcetrail은 함수와 변수들의 관계처럼 복잡한 소스코드의 관계와 종속성을 알기 쉬운 그래프로 시각화하여 보여줍니다. 또한 Visual Studio의 코드 맵(Code Map)을 이용하면 코드를 일일이 읽지 않고도 프로그램 상의 코드 관계를 빠르게 파악할 수 있습니다. 이러한 툴과 기능 외에도 코드를 효과적으로 시각화하기 위한 다양한 아이디어들이 있습니다. 더 자세히 이해하고 싶다면 아래 글들을 한 번 참고해 보는 것도 좋겠습니다. We need visual programming. No, not like that.How do you visualize code?Visualization Techniques for Programmers (and Why You Should Be Using Them) 마치며사실 개발자들끼리 대화도 말로만 하다 보면 서로 다르게 이해하며 불필요한 오해나 업무의 모호함을 키울 수 있습니다. 더욱이 비개발자들이 가진 서로 다른 업무 배경과 지식, 우선순위를 생각하면, 개발자와 소통하는 것은 더욱 어렵게 느껴질 수밖에 없습니다. 이렇게 지식 수준이 다른 사람들을 대상으로 개발자의 언어를 효과적으로 번역할 수 있는 최고의 방법은, 단연코 시각화입니다. 개인이 가진 경험과 이해로 각자 상상하는 것이 아니라 서로의 생각을 시각화하여 명확하게 보여주는 것. 이만큼 쉽고 빠르게 소통할 수 있는 방법은 없습니다. 더 나은 대화를 위해 나에게 맞는 생각의 시각화 방법을 찾아보고 더욱 즐거운 커뮤니케이션을 해보는 건 어떨까요? ©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
0명 뉴스레터 구독 중0명 뉴스레터 구독 중