<div id="readability-page-1" class="page"><div><p><h2>백엔드 개발자에게 원하는 걸 말했는데, 왜 대화가 안될까?</h2></p></div><article><div><p>얼마 전 팀 내 주니어 개발자가 겪었던 사례를 소개하며 같은 개발자끼리도 커뮤니케이션이 왜 쉽지 않은지 소개하고 싶다.  </p><h2 id="나의-언어로만-말하기-고구마를-먹은-듯-목이-매이는-커뮤니케이션-시작"><a href="#%EB%82%98%EC%9D%98-%EC%96%B8%EC%96%B4%EB%A1%9C%EB%A7%8C-%EB%A7%90%ED%95%98%EA%B8%B0-%EA%B3%A0%EA%B5%AC%EB%A7%88%EB%A5%BC-%EB%A8%B9%EC%9D%80-%EB%93%AF-%EB%AA%A9%EC%9D%B4-%EB%A7%A4%EC%9D%B4%EB%8A%94-%EC%BB%A4%EB%AE%A4%EB%8B%88%EC%BC%80%EC%9D%B4%EC%85%98-%EC%8B%9C%EC%9E%91" aria-label="나의 언어로만 말하기 고구마를 먹은 듯 목이 매이는 커뮤니케이션 시작 permalink"></a>나의 언어로만 말하기: 고구마를 먹은 듯 목이 매이는 커뮤니케이션 시작</h2><p>프론트엔드 주니어 개발자(이하 프론트엔드 개발자)가 개발을 담당하는 페이지의 API 스펙을 백엔드 개발자와 논의하고 있었다.
프론트엔드 개발자는 한 가지 이슈가 있었다. 각각 독립적으로 수행되는 비동기 API A와 B, C 중, API C 응답을 처리하는 과정에서 API A와 B에 의존적이었다.
이때 타이밍 이슈가 염려되었고 백엔드 개발자에게 API C의 응답에 A, B를 같이 응답으로 내려 줄 수 있는지 협의하고 싶었다.<br>
(이런 상황은 프로젝트 환경 등 여러 가지 다른 점이 있으므로 이 같은 해결 방안은 이 포스팅의 주요 사안은 아니므로 논외로 하겠다.)  </p><p>논의 자리를 마련한 프론트엔드 개발자는 이런 백그라운드 설명 없이 API C에서 A, B의 값을 찾을 수가 없으니 추가해달라고 원하는 것을 말했다.
하지만 백엔드 개발자 입장에서는 이미 각각의 API 응답으로 제공되는데 API C 응답에서 원하는 값을 찾을 수 없다는 말만 되풀이하는 프론트엔드 개발자를 이해하기 어려웠다.
두 개발자 모두에게 이해하기 어렵고 진전없는 대화가 계속되었다. </p><p>사실 앞서 말했던 비동기 타이밍 이슈가 발생하게 된 배경이 있었는데 특정 third-party library를 사용하면서 생긴 것이었고, 이 라이브러리는 온전히 UX 요구사항 구현을 위한 것이다.
프론트엔드 개발자는 백엔드 개발자가 그것이 왜 필요하냐는 물음에 갑자기 써드파티 라이브러리를 이슈를 공유하기 시작했다. 이때부터 혼돈의 카오스가 시작되었다.
그 라이브러리 사용 이슈가 API 응답에 중복 값을 추가하는 것과 무슨 상관이란 말인가.  </p><p>앞선 문제에 대한 이해가 이루어지지 않은 상태에서 프론트엔드만의 이슈를 추가 더 꺼냄으로서 혼란만 가중되었고 아무런 협의 점도 찾지 못했다.   </p><h2 id="우리가-모두-아는-언어로-말해보기-공감대-형성"><a href="#%EC%9A%B0%EB%A6%AC%EA%B0%80-%EB%AA%A8%EB%91%90-%EC%95%84%EB%8A%94-%EC%96%B8%EC%96%B4%EB%A1%9C-%EB%A7%90%ED%95%B4%EB%B3%B4%EA%B8%B0-%EA%B3%B5%EA%B0%90%EB%8C%80-%ED%98%95%EC%84%B1" aria-label="우리가 모두 아는 언어로 말해보기 공감대 형성 permalink"></a>우리가 모두 아는 언어로 말해보기: 공감대 형성</h2><p>만약 프론트엔드 개발자는 백엔드 개발자에게 비동기 API의 의존성과 이로 인한 타이밍 이슈를 먼저 설명을 했다면 어땠을까? 문제 해결이 바로 될 수도 있고 혹은 바로 되지 않더라도 우리 모두 문제에 대한 이해가 이루어지고 공감대는 만들 수 있었을 것이다. 비동기 개념은 프론트엔드와 백엔드 모두에게 익숙한 내용이니 말이다.   </p><p><code>커뮤니케이션은 내게만 익숙한 말하기 편한 단어로 설명하는 것이 아니라 상대방이 이해하고 공감할 수 있는 말로 이루어져야 한다.</code>
그렇지 않다면 우리가 비록 한글을 쓰고 있지만 한 사람은 영어, 다른 한 사람은 일본어로 말하는 것과 다를 바가 없지 않겠는가.   </p><p>이것이 우리가 직군이 서로 다른 동료들, 이를테면 백엔드 개발자, 클라이언트 개발자, PO, 디자이너, QA 등과 협업할 때 쓰는 커뮤니케이션이기 때문이다.
개발자들끼리의 교집합을 찾고 그 안에서 대화를 풀어 갈 수 있어야 하고, 개발자가 아닌 기획이나 디자이너 등 분들과의 교집합에서도 대화를 할 수 있어야 하는 것이 소프트 스킬이다.    </p><p>어떤 문제이건 공감대가 형성이 된 뒤에 이슈를 논의하는 것은 공감대가 없는 상황과는 천지차이다. 충분한 공감대가 있다면 교집합 영역이 아닌 각자의 위치에서 자신만의 영역에서도 방법이 도출될 수도 있고 다양한 브레인스토밍을 해볼 수가 있는 것이다.    </p><p>프론트엔드 개발자는 써드파티 라이브러리 사용 이슈라는 나의 언어로 이야기를 꺼내기보다는 오히려 요구사항이라는 교집합에서 우리 모두가 아는 언어로 이야기를 풀어냈어야 한다. 그것이 우리가 함께 공유하고 이해하는 영역이기 때문이다.  </p><p><img src="https://baek.dev/assets/images/post/2023/2023_046_001.jpg" alt="Communication">  </p><p><a target="_blank" href="https://unsplash.com/ko/%EC%82%AC%EC%A7%84/QckxruozjRg">사진 출처</a></p><h2 id="필요하다면-위로-에스컬레이션"><a href="#%ED%95%84%EC%9A%94%ED%95%98%EB%8B%A4%EB%A9%B4-%EC%9C%84%EB%A1%9C-%EC%97%90%EC%8A%A4%EC%BB%AC%EB%A0%88%EC%9D%B4%EC%85%98" aria-label="필요하다면 위로 에스컬레이션 permalink"></a>필요하다면 위로 에스컬레이션</h2><p>여기서부터는 조금 특별한 상황을 만들어 보고 싶다.<br>
일부 개발자들이 겪는 어려운 상황 중 하나인데, 모두가 다 이해했고 공감대도 형성이 되었지만 트레이드오프가 발생할 수밖에 없는, 모두가 만족하기는 어려우는 상황이 되었다고 가정 해보자.  </p><p>어떻게 해야 될지 전전긍긍하기보다는 방법 1을 선택했을 때 생기는 장단점, 방법 2를 선택했을 때 얻는 장단점을 가지고 <code>사수 혹은 프로젝트 리더에게 상황을 알려야 한다. 이것이 에스컬레이션이다.</code> 프로젝트 리더는 규모나 회사 사정에 따라 다르겠지만 팀장 혹은 PO 등이다. </p><p>상황을 내 안에서만 고민하면서 개발 시간을 지연시켜서는 좋지 않다. 장단점 파악까지 마쳤다면 의사 결정권자에게 상황을 공유하고 팀을 넘어서 혹은 프로젝트를 넘어서 해결책이 있는지도 살펴봐야 하기 때문이다.
이 같은 행위를 에스컬레이션이라고 하며, 에스컬레이션 후 프로젝트 리더는 기술적으로 트레이드오프가 생기는 것을 인지했으므로 프로젝트 이해관계자와 함께 요구사항에 대해 논의한다.  </p><ol><li>의사 결정권자는 이 요구사항 구현에 추가로 필요한 개발 소요 시간을 체크 해본다. <ul><li>에스컬레이션 할 때 개발자는 적절한 추가 개발 소요 시간 등을 같이 전달하거나 미리 예상해 보면 빠른 의사 결정에 도움이 된다.</li></ul></li><li>의사 결정권자는 이 요구사항을 다른 방향으로 요구사항을 절충하거나 기능의 완성도 목표를 다시 설정해 본다.<ul><li>역시 이 과정에서 개발자는 요구사항 개발에 대한 트레이드오프에 대해 함게 논의하고 일정 조율에 의견을 제시하고 대화에 참여한다.</li></ul></li><li>2번 과정에서 의사 결정권자는 이 요구사항을 이번 개발 기간에 반듯이 필요한 구현인지 다시 한번 확인한다.   <ul><li>만약 필요하다면 프로젝트 일정 조정이 가능한지 확인한다.</li></ul></li><li>프로젝트 일정 조정이 어렵다면 요구사항을 축소하여 phase를 나누거나 다른 기능으로 요구사항을 재정비하는 것으로 논의는 계속 발전해 나갈 것이다.    <ul><li>이후 일정을 고려하여 개발 시 유연한 개발이 되도록 고민이 필요하다.     </li></ul></li></ol><p>1~4는 개발자가 직접 하기보다는 프로젝트 리더 입장에서 진행하는 스텝이고 각 단계의 세부에서 개발자는 의사결정에 참여하여 트레이드오프나 근거 등에 관한 이야기를 함께 나눌 수 있다.  </p><h2 id="이-모든-것이-실전-소프트스킬"><a href="#%EC%9D%B4-%EB%AA%A8%EB%93%A0-%EA%B2%83%EC%9D%B4-%EC%8B%A4%EC%A0%84-%EC%86%8C%ED%94%84%ED%8A%B8%EC%8A%A4%ED%82%AC" aria-label="이 모든 것이 실전 소프트스킬 permalink"></a>이 모든 것이 실전 소프트스킬</h2><p>때로는 너와 나, 둘이서 해결할 수 있는 일이 있지만 수면 위로 드러나지 못한 일들도 제법 많다. 이런 상황을 판단할 수 있는 능력을 점차 길러야 하고, 빠르게 에스컬레이션 하는 행동력도 갖추는 것도 개발자의 소프트스킬 중 커뮤니케이션이다.<br>
글 처음에 소개했던 사례를 볼 때, 개발자에게 커뮤니케이션 능력은 옵셔널이 아니라 일을 하면서 바로 피부로 느낄 수 있는 필수 스킬인 것이다.  </p><p>만약 내가 커뮤니케이션에 자신이 없거나 협의하는 데 어려움을 겪고 있다면 책을 읽거나 참여형 교육을 통해 능력을 획득해 볼 수도 있다. 오늘 소개한 이 글을 반추해 볼 때 직접 실천해 볼 수 있는 방법을 소개하고 싶다. </p><ol><li><code>상대방이 이해할 수 있는 언어 사용하기</code> <ul><li>상대방이 공감할 수 있는 말로 대화를 나누는 것이 중요하다. </li><li>각자의 전문 용어가 아닌, 공통된 지식을 바탕으로 설명해야 한다.</li></ul></li><li><code>이해와 공감대 형성하기</code> <ul><li>서로 이해하고 공감할 수 있는 교집합 영역에서 대화를 이어가야 한다. </li><li>이를 통해 상대방의 입장을 이해하고 문제 해결을 위한 브레인스토밍이 가능해진다.</li></ul></li><li><code>타협 가능한 트레이드오프인지 판단하여 서로의 제안을 수용하기</code>  <ul><li>모든 상황이 모두에게 100% 수용 가능하기는 어렵다. </li><li>이 글에서 소개되지는 않았지만 서로의 제한적인 상황과 프로젝트 일정 등 환경적인 부분을 고려하여 수용 가능한 선에서 타협을 해야 할 경우도 있다. 이를 이해하고 적절한 방법을 이해하는 자세도 필요하다. </li></ul></li><li><code>수용하기 어려운 트레이드오프라면 상황을 공유하고 에스컬레이션 하기</code>   <ul><li>그러나 임시방편(hacky)의 방법을 수용하거나 프로젝트 요구사항에 부합하지 않거나, 엣지 케이스를 무시하는 상황을 트레이드오프 하긴 어렵다. </li><li>이 같은 상황은 상황을 공유해서 더 나은 방법을 찾을 수 있도록 해야 한다. </li></ul></li></ol><hr><p>서로 다른 직군 간의 커뮤니케이션 개선은 상호 이해와 공감을 바탕으로 이루어져야 한다. 상대방이 이해할 수 있는 언어로 설명하고, 공감대를 형성한 후 문제를 해결해 나가는 것이 효과적인 소통의 핵심이다. 이를 통해 프로젝트의 성공적인 진행과 원활한 협업이 가능해질 것이다.   </p></div><p>쿠팡 파트너스 활동을 통해 일정액의 커미션을 제공받을 수 있습니다.</p></article></div>

아웃풋 트레이닝

BAEKDEV

얼마 전 팀 내 주니어 개발자가 겪었던 사례를 소개하며 같은 개발자끼리도 커뮤니케이션이 왜 쉽지 않은지 소개하고 싶다.  
나의 언어로만 말하기: 고구마를 먹은 듯 목이 매이는 커뮤니케이션 시작
프론트엔드 주니어 개발자(이하 프론트엔드 개발자)가 개발을 담당하는 페이지의 API 스펙을 백엔드 개발자와 논의하고 있었다.
프론트엔드 개발자는 한 가지 이슈가 있었다. 각각 독립적으로 수행되는 비동기 API A와 B, C 중, API C 응답을 처리하는 과정에서 API A와 B에 의존적이었다.
이때 타이밍 이슈가 염려되었고 백엔드 개발자에게 API C의 응답에 A, B를 같이 응답으로 내려 줄 수 있는지 협의하고 싶었다.
논의 자리를 마련한 프론트엔드 개발자는 이런 백그라운드 설명 없이 API C에서 A, B의 값을 찾을 수가 없으니 추가해달라고 원하는 것을 말했다.
하지만 백엔드 개발자 입장에서는 이미 각각의 API 응답으로 제공되는데 API C 응답에서 원하는 값을 찾을 수 없다는 말만 되풀이하는 프론트엔드 개발자를 이해하기 어려웠다.
두 개발자 모두에게 이해하기 어렵고 진전없는 대화가 계속되었다. 
사실 앞서 말했던 비동기 타이밍 이슈가 발생하게 된 배경이 있었는데 특정 third-party library를 사용하면서 생긴 것이었고, 이 라이브러리는 온전히 UX 요구사항 구현을 위한 것이다.
프론트엔드 개발자는 백엔드 개발자가 그것이 왜 필요하냐는 물음에 갑자기 써드파티 라이브러리를 이슈를 공유하기 시작했다. 이때부터 혼돈의 카오스가 시작되었다.
그 라이브러리 사용 이슈가 API 응답에 중복 값을 추가하는 것과 무슨 상관이란 말인가.  
앞선 문제에 대한 이해가 이루어지지 않은 상태에서 프론트엔드만의 이슈를 추가 더 꺼냄으로서 혼란만 가중되었고 아무런 협의 점도 찾지 못했다.   
우리가 모두 아는 언어로 말해보기: 공감대 형성
만약 프론트엔드 개발자는 백엔드 개발자에게 비동기 API의 의존성과 이로 인한 타이밍 이슈를 먼저 설명을 했다면 어땠을까? 문제 해결이 바로 될 수도 있고 혹은 바로 되지 않더라도 우리 모두 문제에 대한 이해가 이루어지고 공감대는 만들 수 있었을 것이다. 비동기 개념은 프론트엔드와 백엔드 모두에게 익숙한 내용이니 말이다.   
커뮤니케이션은 내게만 익숙한 말하기 편한 단어로 설명하는 것이 아니라 상대방이 이해하고 공감할 수 있는 말로 이루어져야 한다.
그렇지 않다면 우리가 비록 한글을 쓰고 있지만 한 사람은 영어, 다른 한 사람은 일본어로 말하는 것과 다를 바가 없지 않겠는가.   
이것이 우리가 직군이 서로 다른 동료들, 이를테면 백엔드 개발자, 클라이언트 개발자, PO, 디자이너, QA 등과 협업할 때 쓰는 커뮤니케이션이기 때문이다.
개발자들끼리의 교집합을 찾고 그 안에서 대화를 풀어 갈 수 있어야 하고, 개발자가 아닌 기획이나 디자이너 등 분들과의 교집합에서도 대화를 할 수 있어야 하는 것이 소프트 스킬이다.    
어떤 문제이건 공감대가 형성이 된 뒤에 이슈를 논의하는 것은 공감대가 없는 상황과는 천지차이다. 충분한 공감대가 있다면 교집합 영역이 아닌 각자의 위치에서 자신만의 영역에서도 방법이 도출될 수도 있고 다양한 브레인스토밍을 해볼 수가 있는 것이다.    
프론트엔드 개발자는 써드파티 라이브러리 사용 이슈라는 나의 언어로 이야기를 꺼내기보다는 오히려 요구사항이라는 교집합에서 우리 모두가 아는 언어로 이야기를 풀어냈어야 한다. 그것이 우리가 함께 공유하고 이해하는 영역이기 때문이다.  
사진 출처  
필요하다면 위로 에스컬레이션
여기서부터는 조금 특별한 상황을 만들어 보고 싶다.
어떻게 해야 될지 전전긍긍하기보다는 방법 1을 선택했을 때 생기는 장단점, 방법 2를 선택했을 때 얻는 장단점을 가지고 사수 혹은 프로젝트 리더에게 상황을 알려야 한다. 이것이 에스컬레이션이다. 프로젝트 리더는 규모나 회사 사정에 따라 다르겠지만 팀장 혹은 PO 등이다. 
상황을 내 안에서만 고민하면서 개발 시간을 지연시켜서는 좋지 않다. 장단점 파악까지 마쳤다면 의사 결정권자에게 상황을 공유하고 팀을 넘어서 혹은 프로젝트를 넘어서 해결책이 있는지도 살펴봐야 하기 때문이다.
이 같은 행위를 에스컬레이션이라고 하며, 에스컬레이션 후 프로젝트 리더는 기술적으로 트레이드오프가 생기는 것을 인지했으므로 프로젝트 이해관계자와 함께 요구사항에 대해 논의한다.  
의사 결정권자는 이 요구사항 구현에 추가로 필요한 개발 소요 시간을 체크 해본다. 
에스컬레이션 할 때 개발자는 적절한 추가 개발 소요 시간 등을 같이 전달하거나 미리 예상해 보면 빠른 의사 결정에 도움이 된다.
의사 결정권자는 이 요구사항을 다른 방향으로 요구사항을 절충하거나 기능의 완성도 목표를 다시 설정해 본다.
역시 이 과정에서 개발자는 요구사항 개발에 대한 트레이드오프에 대해 함게 논의하고 일정 조율에 의견을 제시하고 대화에 참여한다.
2번 과정에서 의사 결정권자는 이 요구사항을 이번 개발 기간에 반듯이 필요한 구현인지 다시 한번 확인한다.   
만약 필요하다면 프로젝트 일정 조정이 가능한지 확인한다.
프로젝트 일정 조정이 어렵다면 요구사항을 축소하여 phase를 나누거나 다른 기능으로 요구사항을 재정비하는 것으로 논의는 계속 발전해 나갈 것이다.    
이후 일정을 고려하여 개발 시 유연한 개발이 되도록 고민이 필요하다.     
1~4는 개발자가 직접 하기보다는 프로젝트 리더 입장에서 진행하는 스텝이고 각 단계의 세부에서 개발자는 의사결정에 참여하여 트레이드오프나 근거 등에 관한 이야기를 함께 나눌 수 있다.  
이 모든 것이 실전 소프트스킬
때로는 너와 나, 둘이서 해결할 수 있는 일이 있지만 수면 위로 드러나지 못한 일들도 제법 많다. 이런 상황을 판단할 수 있는 능력을 점차 길러야 하고, 빠르게 에스컬레이션 하는 행동력도 갖추는 것도 개발자의 소프트스킬 중 커뮤니케이션이다.
만약 내가 커뮤니케이션에 자신이 없거나 협의하는 데 어려움을 겪고 있다면 책을 읽거나 참여형 교육을 통해 능력을 획득해 볼 수도 있다. 오늘 소개한 이 글을 반추해 볼 때 직접 실천해 볼 수 있는 방법을 소개하고 싶다. 
상대방이 이해할 수 있는 언어 사용하기 
상대방이 공감할 수 있는 말로 대화를 나누는 것이 중요하다. 
각자의 전문 용어가 아닌, 공통된 지식을 바탕으로 설명해야 한다.
이해와 공감대 형성하기 
서로 이해하고 공감할 수 있는 교집합 영역에서 대화를 이어가야 한다. 
이를 통해 상대방의 입장을 이해하고 문제 해결을 위한 브레인스토밍이 가능해진다.
타협 가능한 트레이드오프인지 판단하여 서로의 제안을 수용하기  
모든 상황이 모두에게 100% 수용 가능하기는 어렵다. 
이 글에서 소개되지는 않았지만 서로의 제한적인 상황과 프로젝트 일정 등 환경적인 부분을 고려하여 수용 가능한 선에서 타협을 해야 할 경우도 있다. 이를 이해하고 적절한 방법을 이해하는 자세도 필요하다. 
수용하기 어려운 트레이드오프라면 상황을 공유하고 에스컬레이션 하기   
그러나 임시방편(hacky)의 방법을 수용하거나 프로젝트 요구사항에 부합하지 않거나, 엣지 케이스를 무시하는 상황을 트레이드오프 하긴 어렵다. 
이 같은 상황은 상황을 공유해서 더 나은 방법을 찾을 수 있도록 해야 한다. 
서로 다른 직군 간의 커뮤니케이션 개선은 상호 이해와 공감을 바탕으로 이루어져야 한다. 상대방이 이해할 수 있는 언어로 설명하고, 공감대를 형성한 후 문제를 해결해 나가는 것이 효과적인 소통의 핵심이다. 이를 통해 프로젝트의 성공적인 진행과 원활한 협업이 가능해질 것이다.

백엔드 개발자에게 원하는 걸 말했는데, 왜 대화가 안될까?

댓글