Fix format

_posts/2024-06-22-개발자의 커뮤니케이션.md

@@ -10,7 +10,8 @@
 
 그럼 회사에 개발자로 입사했을때 주로 커뮤니케이션하게 되는 사람들은 누가 있을까? 현 직장과 전 직장 경험을 바탕으로 정리해보면 크게 이렇게 나눌 수 있을것 같다.
 
-1. CX (Customer eXperience / CS), Marketing
+### CX (Customer eXperience / CS), Marketing
+
 나의 개인적인 경험으로는 이전 직장에서는 주로 마케팅 팀과 의사소통할 일이 많았고, 현 직장에서는 고객대응 팀과 이야기할 일이 많다. 이는 회사의 업무 분담에 따라 회사마다 다를 것으로 생각된다. 이 둘을 같이 분류한 것은 두 팀 모두 기술, 도메인에 대한 전문적인 지식을 갖고 있지 않은 경우가 많고, 보다 소비자 중심적으로 문제상황에 접근하시기 때문이다. 따라서 효과적으로 의사소통하기 위해서는 우리도 우리가 만드는 서비스를 기술적인 관점이 아닌 사용자 관점에서 이해하고 전달할 수 있어야한다.
 
 예시를 들자면 이런거다. 회사 서비스에 장애가 나서 1시간 가량 서비스가 불가했다. 이때 개발자들이 주로 전달하고자 하는것은 이런 것들이다.
@@ -22,17 +23,22 @@
 * 몇명의 고객이 영향을 받았는지
 * 그들이 맞이한 오류 메시지 또는 화면은 구체적으로 어떤건지
 * 고객들의 서비스에 대한 신뢰를 유지하기 위해 해명은 어떻게 할건지
+
+
 이러한 것들을 궁금해하고, 고민하신다. 이런 관점의 차이를 인지하고 대화에 임해야 좀 더 효과적으로 핀트에 맞는 커뮤니케이션이 가능해진다.
 
-2. PO (Product Owner / PM), Designer
+### PO (Product Owner / PM), Designer
+
 PO나 디자이너 분들은 사용자 워크플로우와 큰 그림에 대한 이해가 높다. 나의 개인적인 경험으로 기획자, PO분들과의 대화는 개발자가 너무 좁은 부분에 매몰되지 않게 도와주고, 시야를 넓혀준다. 이런 의사소통은 언뜻 보기에는 크게 중요하지 않아보여도 사실은 개발에 있어서 엄청 중요하다.
 
 어떤 도시를 정말 예쁘게 효율적으로 지으려면 어떻게 해야할까? 답은 **뭐가 들어갈지 전부 계획해놓으면 된다**. 그래서 계획 도시는 점진적으로 확장해나간 도시에 비해 동선이 효율적이고 배치가 깔끔하다. 코드도 마찬가지다. 어떤 부분을 지속적으로 확장해나갈 계획이 있다면, 그 부분에 있어서는 추상화를 거쳐서 확장 가능하게 만들어놔야한다. 반대로, 확장의 여지가 없는 부분이라면 굳이 이런저런 디자인 패턴을 적용해서 복잡성을 가중시킬 필요가 없다. 서비스를 기획하시는 분들은 늘 이런 계획이 한발 더 앞서있다. 그렇기 때문에 그들과 항상 sync하고 align되어 있기 위해 커뮤니케이션을 적극적으로 해야한다.
 
-3. DA (Data Analyst)
+### DA (Data Analyst)
+
 DA분과는 정말 아쉽게도 아직 적극적으로 협업할 일이 없었다. 이후 DA분과 협업할 일이 생긴다면, 그 경험이 어땠는지에 대해 글을 쓰겠다.
 
-4. Developer
+### Developer
+
 마지막으로 같은 개발자분들이다. 개발자분들은 대체로 같은 용어를 쓰고 같은 사고회로를 거치기 때문에 다른 포지션에 비해 의사소통이 수월한 면이 있다. 하지만 개발자도 다 같은 개발자가 아니며, 세부 포지션에 따라 또 다양하게 나뉘게 된다. 서버개발자의 입장에서 본다면, 같은 서버개발자를 제외하고 이야기하게 되는 직군은 크게 프론트 개발자, 데브옵스 개발자, 데이터베이스 관리자(DBA)가 있다.
 
 데브옵스, 플랫폼 개발자분들과는 주로 장애 상황에서 원인 식별을 위해 많이 의사소통하게 된다. 백엔드 개발자는 디버깅이나 전체적인 서비스 이해를 위해 데브옵스 개발자가 아니더라도 기본적인 데브옵스에 대한 지식이 필수라고 생각한다. 이를 바탕으로 데브옵스 분들과 장애상황에 대해 논의하고 그에 대한 대책도 강구할 수 있게 된다. 나도 데브옵스에 대한 기본적인 이해를 위해 AWS 자격증을 취득한 적이 있다. 이후 시간을 내서 K8S 관련 자격증에도 도전해볼 생각이다. (자격증을 따는게 의미가 있다는 뜻은 아니다. 그냥 나는 뭔가의 목표가 있는 편이 공부하는데 도움이 된다.) DBA 분과는 슬로우쿼리 최적화 / DB 장애 상황 등에서 주로 이야기하게 되는데, 데브옵스와 마찬가지로 서버개발자는 데이터베이스에 대해 DBA와 원활하게 대화할 정도의 지식이 요구된다고 생각한다. 이 부분에 대해서는 아직 내가 많이 부족해서 앞으로 공부를 계속할 생각이다.