|
1. 도서 선정 이유 직장인에게 자주 언급되는 밸런스 게임이 있습니다. 바로 "일을 너무 잘하지만 4가지 없는 팀원 vs 일 못하지만 정말 착한 팀원" 입니다. 옛날에는 "당연히 회사에 일하러 왔는데 성격 좀 별로여도 일 잘하는 게 중요하지!!" 라고 생각했습니다. 요즘에는 생각이 조금 바뀌어서, 조직 생활에서 성격이 좋지 않아 커뮤니케이션이 어렵다면 그또한 실력 부족으로 취급해야 하는 것이 아닐까? 라고 생각합니다. 두 경우 모두 별로지만.. 최근 소통할 일이 많아지다 보니, 4가지 없는 것은 단체 생활에서는 일 못하는 것이나 마찬가지라는 생각도 들더라고요. 일을 잘 하니 당장 눈 앞에서 뭔가 만들어지긴 하겠지만, 장기적인 관점에서 오래 일하고 싶은 사람은 아니겠다 싶었습니다. 1인 기업처럼 혼자서 모든 일을 해야 하는 특수한 경우가 아닌 이상 직장인들은 대체로 누군가와 함께 일합니다. 기술 관련 직무에서는 업무 능력을 하드 스킬과 소프트 스킬을 나누어 구분하는데요. 기술에 대한 하드 스킬이야 요즘 누구나 쉽게 온라인을 통해 배우고 적용할 수 있지만, 소프트 스킬은 누가 붙잡고 알려주지 않으니 오히려 습득하기 어려운 것 같습니다. 함께 일하기 위해서는 소프트 스킬이 필수고 이 책이 길잡이가 좀 되지 않을까 싶어 이번 리뷰 도서로 신청했습니다. 2. 목차와 주요 내용 2.1. Part 1. 시각적 커뮤니케이션 다이어그램과 시각 자료들의 패턴과 안티 패턴을 소개합니다. 프로그래밍에 디자인 패턴이 있는 것처럼, 커뮤니케이션을 위한 시각 자료에도 패턴이 있다고 합니다. 출판사리뷰에서 써있는 것처럼 자료들은 "개발자를 위한 필수 커뮤니케이션 스킬"에 걸맞은 예시들로 구성되어 있어 이해하기에 좋았습니다. 여러 조언들도 공감이 되어 재미있게 읽었습니다. 독자들이 읽었을 때 이해하기 어렵다면 실패한 소통이라는 점은 정말 아무리 강조해도 지나치지 않은 지점인 것 같습니다. 색상을 구분할 수 없는 사람들을 위해 패턴이나 기호를 이용해야 한다는 지적도 인상 깊습니다. 지금까지 자료를 만들면서 색상을 구별하기 어려운 사람이 있을 것이니 배려해야겠다는 생각을 해본 적이 없어 반성했습니다.. 앞으로 다이어그램을 그리거나 그래프를 그리는 작업을 할 때, 색상으로 구분하기보다 선(line)의 대비, 기호(e.g. git의 +(녹색), -(빨간색) 기호) 등을 활용하는 방안을 먼저 고려해야겠습니다. 2.2. Part 2. 멀티모달 커뮤니케이션 이 장에서는 서면, 언어적 및 비언어적 커뮤니케이션 패턴을 소개합니다. 기술 문서는 문학 글쓰기와 다르게 작가의 작성과 독자의 이해를 위한 패턴이 있어서, 배운다면 누구나 적용할 수 있는 요소라고 여겨집니다. 예를 들면 축약어 정의하기(독자의 도메인에 따라 다르게 이해할 수도 있는 경우를 방지), 구체화를 위해 약동사보다는 강동사 사용하기(e.g. happen ＞ generate), 짧은 문장으로 쓰기, 일관된 어휘 사용하기가 있습니다. 특히 독자를 고려하기 위해 스스로에게 질문해야 할 것들을 제시해준 것이 꽤 꿀팁인 것 같습니다. 독자는 내가 글을 쓰는 주제에 대해 얼마나 알고 있는가? 독자가 뒤떨어진 지식을 가지고 있는가? 독자가 달성하고자 하는 목표는 무엇인가? 독자는 목표를 달성하기 위해 무엇을 배워야 하는가? 독자가 특정 순서로 이 작업을 수행해야 하는가? 글을 쓰는 사람은 이러한 질문에 답을 생각해보고, 독자들의 요구를 충족시킬 수 있는 방향으로 글을 구조화하고 정보를 포함해야 한다고 조언합니다. 가끔 기술 블로그를 보다보면 글을 읽기 전 필요한 사전 지식에 대해 명시하고 시작하는 경우가 있던데, 그런 글쓰기가 독자를 배려한 글쓰기의 좋은 사례 같네요. 요즘 애플워치 등 전자 시계를 통해 알람을 많이 확인하는 것 같아요. 저또한 전화나 문자는 핸드폰보다 워치 알람을 통해 먼저 확인하는 편인데요. 온전히 집중하기(243p)에서 소통을 위해 전자기기 알람 끄기, 상대방이 말할 때 끼어들지 않기 등 여러 조언을 보며 집중을 못하지는 않았는지 반성하였습니다..?? 잠깐만 다른 것에 눈을 돌려도 기존 일에 다시 집중하기가 정말 어려운데.. 앞으로 더 신경써서 집중해야겠다고 다짐했습니다. 2.3. Part 3. 지식 전달하기 이 장에서는 문서화와 지식 관리를 개선하기 위한 전략들을 소개합니다. 다른 조언들보다 "소프트웨어와 아키텍처에서 핵심이 되는 것은 곧 사람이다. 소프트웨어를 사용하는 것도, 도움을 주는 것도 사람이며, 소프트웨어를 설계, 디자인, 코딩하는 것도 사람이다."(356p)라는 내용이 기억에 많이 남았습니다. 종종 사람이 제일 중요하다는 지점을 놓쳐 무리하게 일을 주는 등 오류를 범하는 사례가 발생하는데요. 사람을 현명하게 활용해야 개개인에게 주인의식을 부여하고 나아가 매출 증진까지 이어질 수 있지 않을까 생각이 들었습니다. JIT 아키텍처(Just-In-Time Architecture)은 새로운 관점을 제공해주었습니다. JIT 아키텍처는 "미래에 필요할 것으로 추정되는 것이 아니라, 지금 필요한 것만 결정하고 문서화하는 것"(379p)입니다. 개발이라고 하면 오랜 시간이 걸려도 기반을 탄탄하게 가져가야 하지 않을까, 생각했었는데요. 작업에 따라 요구 사항이 바뀔 수 있고 결정에 대한 최신 정보를 얻을 수 있으니, 유연성을 높이고 위험을 줄이기 위해 결정을 미루는 것도 방법이 될 수 있다는 것을 배웠습니다. 2.4. Part 4. 원격으로 소통하기 포스트 코로나가 되면서 체감하기로는 원격으로 일하는 일은 많이 줄어든 것 같습니다. 다만 외국계 기업이나 프리랜서와 함께 일하는 경우 등 원격으로 소통해야 하는 일이 많다면 이 파트가 유용할 것이라 생각합니다. 원격 근무 환경에서 어떤 점들을 특히 유의해야 하는지, 원칙과 소통 전략은 어떻게 가져가야 하는지 등을 설명해줍니다. 특히 다른 문화적 환경에서 근무하는 사람들과 소통할 때 고려해야 하는 요소들, 나라별 근무 시간이나 공휴일과 기념일 등을 파악해야 한다는 점은 신기했습니다. 글로벌하게 일해본 경험이 없어 생각하지 못한 내용들이었습니다. 나중에 언젠가 그런 기회가 있다면 다시 이 파트를 펼쳐봐야겠습니다. 3. 도서 후기 "못 하면 티가 나지만, 잘 해도 당장 가시적인 성과로 비치지 않는 것이 커뮤니케이션"(19p) 이라는 옮긴이의 말이 크게 공감이 되었습니다. 반면교사 사례들만 잔뜩 보았기 때문일까요..?? 제 경력이 짧아 일반화할 수는 없지만.. 이상적인 방식으로 커뮤니케이션하는 경우는 드물고 각 환경에서 답습한 방식을 따르는 경우가 더 빈번한 것 같습니다. 이전 방식이 소통에 효율적이라면 계속 따라도 되겠지만, 방식을 평가하며 더 나은 방향을 고민하는 것도 필요하다는 생각이 드네요. 책에서 알려준 방식들의 효과를 확인하기 위해서는 여러 방면에 걸쳐 장기간 시도하며 습관으로 만드는 과정이 필요할 것 같습니다. 나중에는 꼭 체득이 되어 업무 생산성을 높여서 반드시 가시적인 성과로 나타나길 바라며 후기는 마무리하겠습니다. 한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다. |
 프로그래밍과 기술적 문제 해결을 중시하는 개발자에게도, 효과적인 커뮤니케이션 능력은 필수적이다. 그동안 개발자들이 주로 코드에 집중했다면, "코드 밖 커뮤니케이션 리뷰"는 그 너머의 중요한 영역, 즉 효과적인 소통과 지식 전달에 대한 중요한 인사이트를 제공합니다. 이 책의 서문에는 함께 일하고 싶은 개발자가 되기위한 코드 밖 커뮤니케이션 스킬 완벽 가이드라고 씌여있지만, 읽다보면 개발자뿐만 아니라 기획자, 디자이너 등 팀 내 다양한 역할을 맡은 사람들에게도 필요한 내용이라는 생각이 들었다.책의 첫 번째 챕터에서는 시각적 커뮤니케이션의 중요성을 다루고 있다. 복잡한 개념이나 프로세스를 시각적으로 정리하는 것은 정보 전달에 매우 효과적이며, 특히 다이어그램과 관계 테이블을 사용하는 방법을 강조한다. 다이어그램은 단순한 그림이 아니라, 정보의 흐름과 관계를 명확하게 시각화하여 이해를 돕는 중요한 도구이고, 이러한 시각 자료에서 보편적인 기호, UX(사용자 경험), 가독성을 고려하는 것이 필수적이라는 점이 눈에 띄었다. 이 부분은 개발자나 디자이너가 협업할 때, 복잡한 시스템을 명확히 전달하는 데 큰 도움이 될거라는 생각이 들었다. 특히 프로세스 과정에서 다양한 옵션들이 있는 경우 그림으로 그려서 프로세스를 정리해 놓으면 예외처리에 필요한 기능이라던가 페이지들을 디자이너와 개발자 들이 쉽게 파악하고, 놓친부분이 있다면 빨리 파악해서 피드백을 줄수 있다고 생각한다. 두 번째 챕터에서는 멀티모달 커뮤니케이션을 다루며, 다양한 방식의 소통을 통한 효과적인 메시지 전달 방법을 제시한다. 서면 커뮤니케이션부터 비언어적 소통, 그리고 수사학의 3요소(로고스, 에토스, 파토스)를 활용하는 방법까지, 다양한 커뮤니케이션 채널을 어떻게 활용해야 하는지에 대해 설명하는데 특히 이 부분에서는 팀원 간의 상호 이해를 돕기 위해 다각적인 접근이 필요하다는 점을 강조하고 있다. 단순히 말이나 글로 소통하는 것에서 그치지 않고, 다양한 표현 방식을 사용해 의도를 명확히 전달하는 방법을 배우게 된다. 업무를 하다보면 텍스트로만 전달 했을땐 생각보다 다양한 방법으로 각자 해석하고 있어서 서로 같은 내용으로 이해하고 있는건지 명확히 확인 해야 할 일이 종종 생기는데, 그런 상황을 조금이라도 덜 발생시키기 위해서 이 챕터를 보고 고민해보면 좋을 것 같다. 세 번째 챕터에서 다루는 지식 전달하기는 개인적으로 이 책에서 가장 중요한 부분이라고 생각했다. 이 챕터는 지식 관리와 문서화의 중요성을 강조하며, 효율적인 정보 공유가 어떻게 협업을 촉진하고 프로젝트 성공에 기여하는지 설명한다. 특히 피드백의 중요성에 대해 깊이 다루는데, 실제 여러팀과 업무를 하다보면, 피드백이 늦으면 늦을수록 온갖팀이 고생은 다하고 다시 엎어서 일정이 밀리는 경우가 발생하는데, 실무자들 사이에서 피드백을 빠르고 정확하게 주고받는 것이 프로젝트의 방향성을 조정하는 데 결정적인 역할을 하는지 알수 있었다. 그래서 이 챕터도 개발자 뿐만 아니라 관련 프로젝트를 진행하는 모든 팀이 함께 읽고 더 나은 방향을 위해 노력했으면 좋겠다라는 생각이 들었다. 마지막으로, 네 번째 챕터는 원격 근무 상황에서의 커뮤니케이션을 다뤘다. 팬데믹을 겪으며 원격 근무가 급격히 늘어났고, 그 이후로도 다시 대면근무로 돌아가긴 했지만, 원격 근무는 여전히 많은 기업에 남아있다. 이 챕터에서는 다른 시간대나 장소에서 일하는 팀원들과의 시간 동기화와 근무 패턴 존중의 필요성을 강조하고 또한, 원격 근무 시 에너지 관리와 생산성 향상을 위해 서로의 소통 채널을 적절히 활용하는 방법을 설명한다. 분명 누군가는 이 제도를 악용하는 사람이 있기에, 원격 근무의 효과를 극대화하기 위한 필수적인 원칙을 세워 진행한다면 실무자 뿐만 아니라, 경영진도 실무자들을 믿고 원격근무를 시행 할 수 있을 것이라는 생각이 들었다. "코드 밖 커뮤니케이션 리뷰" 는 각 장마다 구체적인 사례와 실용적인 팁을 제공하며, 실무에서의 커뮤니케이션 효율성을 크게 높일 수 있다. 시각적 자료를 활용한 명확한 설명, 다양한 커뮤니케이션 방법, 지식의 공유와 피드백 문화, 그리고 원격 소통의 전략 등, 이 책에서 다루는 모든 주제는 팀워크를 강화하고 프로젝트의 성공을 돕는 필수적인 요소들을 담았다. 이 책에 나왔던 여러 예시들 중 몇가지는 바쁘더라도 당장 도입해서 활용하고 싶은 것들도 있었고, 특히 시각적 커뮤니케이션과 피드백의 중요성을 다시 한 번 깨달았다. 협업 환경에서의 소통을 개선하고 싶은 모든 분들께 이 책을 추천한다. "한빛미디어 ＜나는리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다." |
|
|
|
신기한 책을 만났습니다. "팀원 온보딩부터 UML 활용법, 글쓰기 스킬, 원격 근무 노하우까지"라는 부제가 굉장히 호기심을 자극합니다. 우리나라에는 이런 부류의 책은 잘 안나왔던 것 같아서요.  아래 왼쪽과 오른쪽 페이지 다이어그램의 차이점이 느껴지시나요? 화살표를 수평수직으로만 바꿨을 뿐인데 상당히 눈에 보기 좋게 변했습니다. (저도 비슷한 그래프를 왼쪽처럼 그렸던 기억이 있어서요.)  아래 다이어그램은 어떤가요? 얼핏 보면 비슷해보이는데요. 왼쪽은 구조와 동작을 동시에 표현했습니다. 더 복잡하고 중구난방 느낌이 있는데 반해 불필요한 요소를 제거한 오른쪽 다이어그램이 더 명확하게 느껴집니다. 기술 문서 작성 팁이 정말 중요한 포인트를 체크해줍니다. 제발 하고싶은 얘기가 무엇인지 그 요점부터 시작하지 않는 보고서는 답답하기 그지 없습니다. 기술 문서기에 범위와 출처를 표시해주고, 예외사항을 명시하는 것은 전달력과 객관성을 높이는 방법입니다. 대상 독자를 넓게 보면 보고서도 보고 받는 사람 입장을 생각해야 합니다.(90%는 그냥 쓰고싶은 대로, 하고싶은 말만 나열합니다)  이런 설명이 와닿지 않는 사람들도 계속 쓰면서 반복해서 보다보면 익숙해질 것 같습니다.  흥미로운 부분중에 "Zoom은 왜 피로할까? 라는 내용도 있었습니다. 눈을 가까이서 마주치는 것이 부담스럽고, 스스로가 자신을 보는 것은 피곤하다는 연구결과가 있다고 하네요. 잘 몰랐었지만 다소 공감이 되는 부분입니다.  뒷편에 이메일 작성시 좋은 방법도 소개되어있습니다. 저는 신입사원이라면 이메일 작성법부터 배워야 한다고 생각합니다. 수많은 두서없는 이메일을 필터링하고 이해하는데 우린 너무 많은 시간을 소비하고 있거든요. "로못 말투 지양하기" 도 뻔한 얘기인데, 그렇게 하지 않는 사람들이 정말 많습니다. 평소에 쓰지 않는 용어들을 남발하는 것은 전문성과 거리가 너무 멉니다. 예를들어 언제까지 미제출시 불이익이 있을 거라는 표현은 어떤가요? "미제출" 도 어색하지만 기본적으로 부정적 화법입니다. 언제까지 제출해주시면 어떤 업무처리에 효과적이다라는 긍정적 표현을 써보는 것도 방법입니다. 이책이 기가 막히게 직장생활에서, 특히 IT 부서와 일함에 있어 필요한 틈새를 찾아 여러가지를 알려줍니다. 특히 신입사원이 꼭 읽어봤으면 하는 책입니다. "한빛미디어 ＜나는리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다." |
# 총평 - IT 직무 내에서 사람과의 커뮤니케이션을 어려워하는 사람에겐 바이블과 같은 책 - - (인문계 사람들과의 대화를 위한) '공대생의 재사회화'가 목표로 생각될 만큼 사람과의 상세한 커뮤니케이션 방식이 적혀있음- 예컨대 서면 커뮤니케이션이나 제스처를 통한 비언어적 커뮤니케이션 등 - 그외 특정 위치에서의 고려해야 할 점(ex. 팀장의 위치에서 소통 등) - 특히 협력을 요하는 부분들에서 하나부터 열까지 세세하게 서술하기에 프로그래머들에게 적합 # 책 내용 - 프로젝트 도식화 등을 다루는 내용은 오히려 적은 편이며, 팀 내 커뮤니케이션을 위한 tip이 더 많음 - 특히 Part2 '멀티모달 커뮤니케이션' 은 개발자가 아니더라도 일잘러가 되고 싶은 사람들은 모두 읽어야 하는 내용 - 효과적인 커뮤니케이션을 위한 문서 구조화 - 기술문서 작성을 위한 민토 피라미드 원칙 - 의사소통을 위한 언어적, 비언어적 커뮤니케이션 - 고객 및 동료와의 소통 시 설득하기 위한 방안 등 - Part4 '원격으로 소통하기'는 IT업계에서는 빠질 수 없는 주제라고 보여짐  # 추천 이유 및 대상추천 사유 - IT개발자는 필연적으로 '지식의 저주'에 갇히게 되어있음 (자신의 전문적 지식수준을 가늠하지 못함) - 해당 책은 비개발자 뿐만 아니라, 팀 내의 주니어나 다양한 문화권을 가진 사람과의 소통도 전제 - 중간 관리자에게 가장 큰 메리트가 있는 책이지만, IT직무에서 일하는 사람이면 한 번 쯤은 읽는 것을 추천 추천 대상 - PM(Project Manager, Product manager etc)으로 업무를 시작하는 사람 - IT계열에서 팀장으로 승진한 사람 or 코딩 업무보다 프레젠테이션 등 사무업무를 수행하는 중간 관리자 - 경력 5~10년차 중니어 개발자 - 일잘러로 성장하고 싶은 주니어 개발자 #리뷰어클럽리뷰 |
|
책 개요: "코드 밖 커뮤니케이션"은 다양한 배경을 가진 이해관계자들과 원활하게 소통하기 위한 다양한 방법들을 다루는 책입니다. 저자인 재퀴 리드는 기술적 전문 지식과 커뮤니케이션 능력을 결합하여 소프트웨어 개발자와 엔지니어들이 더 나은 커뮤니케이션을 할 수 있도록 돕는 전문가입니다. 주요 내용: 이 책은 총 4파트로 구성되어 있습니다. 첫 파트에서는 다이어그램과 같은 시각 자료를 활용한 커뮤니케이션을 다룹니다. 두 번째 파트에서는 서면, 언어적 및 비언어적 커뮤니케이션을 다룹니다. 세 번째 파트에서는 지식을 전달하기 위한 효율적인 방법을 다룹니다. 마지막 파트에서는 최근 트랜드인 원격 커뮤니케이션에 대한 내용을 다룹니다. 장점:
추천 대상: "코드 밖 커뮤니케이션"은 상황별로 효율적인 커뮤니케이션을 하시고 싶은 분에게 유용합니다. 특히 다양한 이해관계자와 소통하는 일이 많으시다면 한 번쯤 읽어보시는 것을 추천합니다. 총평: "코드 밖 커뮤니케이션"은 상황별로 커뮤니케이션을 어떻게 하면 좋을지 관심이 있으시다면 읽어 보시는 것을 추천합니다. 특히 원격 근무를 하고 계시다면 원격 커뮤니케이션에 대한 이해도를 높일 수 있습니다. YES24 리뷰어클럽 서평단 자격으로 작성한 리뷰입니다 #리뷰어클럽리뷰 |
|
'프로젝트의 구성은 코드를 구성하는 것 못지않게 그 외의 구성이 중요하다' 실무에 투입되고 주니어 단계를 넘게 되면 코딩 이후로 더욱 많은 관점에서 코드를 바라보는 연습을 해야 한다. 즉, 이제부터는 단순히 로직을 구성하는 것이 아닌, 나의 서비스를 사용하는 대상자 (사용자)의 입장에서 코딩을 진행하기 위한 절차이다. 여기서 의미하는 코딩이라는 의미는 단순히 프로그램 상에 돌아가는 바이너리를 구성하는 일련의 과정을 지칭하는 것이 아니다. 즉, 사용자가 필요로 하는 명세, 설계를 위한 논의 과정에서 발생했던 모든 과정 등을 포함한다. 명세는 UML을 포함하여 다양한 표현 방식으로 표현될 수 있다. 다만 한 가지 확실한 것은 사용자의 필요에 따라서 큰 그림 -＞ 중간 그림 -＞ 자세한 그림 순으로 명세가 기획되고 구성되어야 한다는 점이다. 여러분이 레고를 하나 사더라도 레고의 큰 그림을 보고 처음에 레고를 선택한다는 점을 명심하라. 사용자도 여러분들의 상품을 고르기 전에 반드시 여러분들이 제시하는 큰 그림을 보고 상품을 고르려 할 것이다. 설계 역시 명세와 비슷한 흐름으로 구성된다. 다만 설계는 스펙이라는 보다 자세한 내용이 구성된다. 이 경우 각 스펙에 대한 자세한 시나리오와 구성을 각각 그려둔 표나 혹은 flow가 그려진 설계가 있으면 좋다. 사람의 기억력에는 반드시 한계가 있기 때문에, 이를 체계화하여 구성해야 망각하지 않는다는 것을 명심해야 한다. 마지막은 커뮤니케이션이다. 커뮤니케이션은 개발자 간에도 사용자와 개발자, 기획자 간에도 발생한다. 양질의 커뮤니케이션을 위해서는 반드시 커뮤니케이션 상 서로가 추구하는 바를 명확히 하고 이를 확고히 해야 하는 부분에 목적이 있다. 이를 위해서 커뮤니케이션 상 발생하는 코스트를 최소화하기 위해서 slack과 같은 다양한 툴들을 사용하면 좋다. 여러분들의 프로젝트가 목적하는 바에 맞는 적절한 도구들을 사용하여 커뮤니케이션의 효율을 극대화하도록 하자. 【 코드 밖 커뮤니케이션을 읽고 나서 】 '프로그래머는 단순 코드를 짜는 사람이 아니다.' 언젠가 개발 관련 책에서 읽었던 내용이다. 쥬니어-중니어 대략 10년 차까지는 나는 프로그래머란 단순 코드를 구성하는, 상품을 빠르고 정확하게 뽑아내어 사용자가 필요로 하는 기능을 제공하는 것이 프로그래머의 사명이라 생각했다. 하지만, 이제는 시대가 변했다. 단순 프로그래밍의 경우에는 AI가 우리 인간을 압도하는 시대가 도래한 것이다. 그렇다면 인간이 기계보다 잘하는 것에 집중해야 하는데, 그것은 바로 스토리를 구성하는 것이다. 서비스를 만들더라도 서비스의 전체 그림을 그리고 거기에 스토리를 집어넣는 일련의 과정 말이다. 이처럼 하루하루 개발자의 생태계가 빠르게 변화하는 중에 시대에 맞춰 스스로를 탈바꿈 시키는 것 역시. 이제는 개발자에게 중요한 역량 중 한 부분이 되었다. #본 도서는 "한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다. |
 어떤 분야든 비슷할 것 같은데, 내가 하는 일만 잘 한다고 하여서 끝은 아니다. 같이 일하던 동료도 나에게 그런 말을 한 적이 있다. 개발만 하면 될 줄 알았더니 같이 프로젝트를 하는 사람이랑 소통을 하는 것도 쉽지 않고, 문서 작업은 더더욱 쉽지 않다고 말이다. 물론 나 또한 쉽지 않다고 생각하기 때문에, 나와 같은 사람이라면 읽어 보면 좋을 책이다. ＜코드 밖 커뮤니케이션＞은 제목에서도 볼 수 있듯이, 코드가 아닌 코드 밖의 커뮤니케이션에 관한 팁을 알려준다. 그러니 IT 프로젝트를 참여하는 팀원들이라면 읽어보면 좋을 것 같다.파트는 각각 [시각적 커뮤니케이션, 멀티모달 커뮤니케이션, 지식 전달하기, 원격으로 소통하기] 로 총 4개로 분류되어 있다. 그리고 파트 안에는 여러 챕터들이 존재한다. 앞 챕터를 읽어야, 뒤의 챕터가 조금 더 이해가 잘 되는 경우도 있지만! 꼭 읽지 않고 읽고 싶은 챕터부터 읽어도 큰 상관은 없어 보였다.  아 그리고 참고할 것은 이 책 전반에서 필자가 [폴리글롯 미디어]라는 예시를 사용했다. 폴리글롯 미디어 시스템에 기반한 다이어그램이나 이 상자 스타일 형식으로 예시들을 보여준다. 모든 예시들은 가상이지만 전부 필자의 경험과 학습에 기반한 것이라고 하니, 읽기 전에 참고하면 좋을 것 같다. 읽다가 기억해 두면 좋을 것 같거나, 나중에 참고할 문장에 대해서는 하이라이트를 했다. 자주 인용되는 브라이언 푸트와 조셉 요더의 훌륭한 명언이 있다고 한다. '좋은 아키텍처가 비싸다고 생각한다면, 나쁜 아키텍처를 시도해 보라.' 위 인용문을 바탕으로 아래에는 커뮤니케이션에 대해 적은 글도 있다. '좋은 커뮤니케이션이 비용이 많이 든다고 생각한다면 나쁜 커뮤니케이션을 시도해 보라.' 어쩌면 대부분의 상황이 비슷하지 않을까? 하는 생각을 했다. 처음에는 좋아 보이는 나쁜 것들이 반복되면, 결국에는 나쁜 것(또는 상황)이 고착되어 버린다. 그렇게 시간이 흐른 후에는 당연히 좋은 것(또는 상황)으로 돌리려고 노력을 해도, 비용이 커질 수밖에 없다. 가장 쉬운 예로는 바로 '코드'가 그럴 수 있겠다. 어쨌든 돌아가게만 하면 끝이라고 생각한다면, 추후에 유지 보수할 때는 톡톡히 그 대가를 치르게 될 것이니 말이다. 그러니 시작이 참 중요한 것 같다는 생각을 했다. 커뮤니케이션을 쉽게 할 수 있는 방법을 찾는 게 쉽지는 않겠지만, 그럼에도 어쨌든 시작을 잘 하는 것이 중요하지 않을까. 이 책의 앞부분에는 UML에 관련된 게 많이 나온다. 이 책의 제목의 단어 중 하나인 '커뮤니케이션'을 위해서는 다이어그램도 얼마나 중요한지를 알 수 있다. 개발자나 기획자, 마케터 등등 관련 프로젝트 담당자들이랑 소통을 할 때는 상대방이 이해하기 쉽도록 설명해 주는 것이 중요하다. 그렇기 때문에 다이어그램을 만들 때도 이를 고려하여 가독성 있으면서도, 시각적으로도 보기 좋게 만들어야 한다는 것이다. 근래에 UML은 아니고, 플로우차트를 그려서 사수분께 보여드린 적이 있었다. 그때 당시에 각 도형의 위치나 색깔 같은 걸 맞추었었다. 하지만 이 책을 읽다 보니, 다이어그램이나 플로우차트 같은 것을 보여줄 때, 모두 컬러로 보여줄 수 없는 상황도 있을 수 있다는 것이었다. 예를 들어 프린트를 한다고 치자. 근데 그 프린트물이 흑백으로만 출력이 된다면, 컬러의 구분은 의미가 없어진다. 그러니 그런 상황까지 고려할 수 있다면, 컬러 대신 빗금이나 도트 모양 같은 것으로 구분하는 것. 물론 변수는 많을 테니, 그 모든 상황을 다 고려할 수는 없을 테다. 그럼에도 항상 최선이 무엇인지 스스로 생각을 해보는 건 꽤나 중요한 것 같다고 느꼈다.또 관심 있게 읽었던 부분은 기술 문서 작성과 관련된 부분이다. 일상적으로 적는 글과 기술 문서를 작성하는 것은 읽는 대상이 다르다. 그렇기 때문에 기술 문서 작성을 일상적으로 적는 글처럼 적는 것은 안 된다는 것이다. 읽는 대상을 고려하여, 구조화하고 가독성 있게 쓰는 것이 중요하다는 것. 또 와닿았던 부분은 프로젝트 마인드가 아니라 프로덕트 마인드를 가지고 일을 해야 한다는 것이다. 보통의 프로젝트는 기한이 있기 때문에, 그 프로젝트가 끝난 이후에는 다시 살펴보는 게 쉽지 않다. 하지만 프로덕트 중심으로 사고방식을 전환하고, 프로덕트별로 지식을 정리하면 문서의 검색 가능성도 향상된다고 한다. 프로덕트 중심으로 정리가 되어 있다면, 추후에 이 프로덕트와 관련된 프로젝트를 하는 사람들에게도 쉽게 공유가 될 수 있다는 것이다. 당장 눈앞에 닥친 상황만 보이기 마련인데, 조금 더 포괄적으로 바라봐야겠다는 생각을 했다. 그 외에도 소프트 스킬과 관련된 다양한 정보를 얻을 수 있으니, 코드 외의 커뮤니케이션에 어려움을 겪는 이라면, 읽어보면 도움이 될 것 같다. 한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공 받아 작성된 서평입니다. |