신기한 연구소

개발자는 글쓰기를 잘해야 한다

25년 차 개발자인 나는 지금도 글쓰기 책도 읽고 쓰기 연습을 한다.

개발자가 코딩만 잘하면 되지 글쓰기는 왜 배울까?

정규직 개발자, 프로젝트에 투입된 개발자는 코딩도 하지만 문서 작업도 한다.

개발자가 글쓰기를 잘해야 하는 이유

개발자가 코딩만 하면 좋겠지만 문서 작업도 엄청나다.

글쓰기를 잘해야 문서 작업도 잘한다.

개발자가 글쓰기를 못하면 어떻게 될까?

매주 작성하는 주간보고서를 보자.

나는 일주일간 작업한 내용을 빠짐없이 작성했고 제출한다.

리더는 주간 보고서를 보고 자신이 이해할 때까지 질문을 한다.

개발자가 주는 대로 취합했다가 고객사 주간보고 때 문제가 생기기 때문이다.

상세하지 않은 내용에 대해 고객이 문의를 하면 보고자도 체크를 하지 않았기에 답을 못한다.

그래서 리더는 취합할 때 본인이 이해할 수 있는 수준으로 작성을 요청하거나 질문을 통해 수정한다.

매주 반복된다면 리더는 개발자에게 짜증이 날 것이다.

글쓰기 능력이 필요한 상황이다.

개발자 글쓰기의 핵심은?

글쓰기의 핵심은 글을 읽는 독자(리더, 고객)를 위한 것이다.

개발자 기준으로 쓰면 안 된다.

글로써 상대에게 내 의견을 전달하기 때문이다.

잘못 쓴 글이 얼마나 많은 문제를 만드는지 예를 들어보자.

올해 초 일이다.

어떤 직원이 고객사에 보낼 메일을 작성 중이었다.

요청 문서를 보고 궁금하거나 이해가 안 되는 부분에 대한 정보를 얻기 위해서였다.

위에서 좀 도와주라는 요청이 있어서 옆에 갔다.

그 직원이 쓴 메일을 읽어봤는데 질문의 뜻을 이해하지 못했다.

그 직원에게 정확하게 원하는 정보가 무엇인지 물었다.

메일에 쓴 질문에 대해 말로 추가 설명을 해줬지만 이해가 안 가서 계속 돼 물었다.

순간 이 직원은 무엇을 물어봐야 하는지 조차 모른다는 사실을 알았다.

요청서의 내용을 읽었지만 이해가 안 되었고 무엇을 알아야 하는지도 몰랐다.

고급 등급인데 원하는 정보를 얻기 위한 질문도 못하는 상황이었다.

나도 이해가 필요해서 질문을 하다 보니 고객사에 메일을 몇 번 보낸 상황이었다.

고객사도 질문지 메일을 받고 답답해하는 상황이었다.

질문이 정확하지 않으니 고객사 답변도 엉뚱한 내용으로 채워져 있었다.

요청서를 보고 상황을 파악한 뒤 필요한 질문을 다시 만들어줬다.

그렇게 메일을 보내니 고객사도 무엇을 원하는지 알았다면서 정확한 답변을 보내왔다.

글쓰기가 왜 필요한지 알겠는가?

글쓰기의 핵심은 내가 읽기 위해 쓰는 것이 아니다. 상대방이 읽을 글을 쓰는 것이다.

글쓰기를 잘하면 말도 논리적으로 잘하게 된다

수많은 프로젝트를 하면서 많은 다툼을 봤다.

다툼의 가장 큰 이유는 잘못된 의사전달과 소통이었다.

고객은 A를 생각하고 요청을 하면 기획이나 개발은 B를 생각하고 실행한다.

시간이 지나고 결과물이 나오고 A를 기대했던 고객은 B를 보고 어리둥절해한다.

그리고 다툼이 시작된다.

실제로 뉴스에도 나왔던 유명 프로젝트를 진행하다 겪은 일이다.

고객에서 회의를 요청했다.

기획과 리더들이 모였다.

고객사는 추가 요청 A에 대해 설명을 했다.

기획과 리더들과 A에 대한 이야기를 하다가 B 이야기도 나왔다.

사실 B도 고객사가 요청한 내용은 맞다.

이번 회의는 B가 아닌 A가 추가되었다는 내용이었다.

지금 기획은 A에 관심이 없고 B에 대한 결정이 필요했다.

회의가 끝날즈음 기획은 B에 대해 정리를 하고 고객도 동의했다.

A에 대한 정리는 없었다.

기획에게 A는 어떻게 할 거냐고 물으니 B만 하면 된다고 했다.

지금 이 회의는 추가 요청인 A에 대한 의사결정을 하는 자리라고 다시 확인하라고 했다.

기획은 B 얘기만 계속했다.

그때 고객이 수고했다면서 회의실을 나가려고 했다.

A는 어떻게 결정된 거냐고 내가 물었다.

고객은 추가 요청 A를 하기로 한 거 아니 냔다.

기획이 당황하면서 A는 뭐냐고 한다.

다시 회의를 했다.

일 잘한다고 소문난 임원급 기획이었다.

글쓰기를 공부하면 이런 상황이 발생하지 않는다.

회의의 주제를 정하고 정리한 뒤 결론을 적는다면 이런 불상사는 발생하지 않는다.

만약 내가 체크하지 않았다면 고객의 추가 요청 A는 물 건너가고 나중에 이슈가 되었을 것이다.

개발자 글쓰기로 얻는 효과는?

생각하는 힘을 키울 수 있다.

글을 써보면 안다.

생각을 안 할 수가 없다.

판단하는 힘도 키울 수 있다.

프로젝트 진행 시 판단을 잘못해서 고생하는 경우가 많다.

리더가 잘못된 판단을 해서 고생한 기억이 있을 것이다.

설득하는 힘을 키울 수 있다.

O2O 프로젝트 진행할 때였다.

개발자들은 오픈을 앞두고 마지막까지 일정을 맞추기 위해 고군분투 중이었다.

추가 개발을 할 수 있는 틈이 없었다.

만약 이 상황에서 개발자들에게 추가로~라는 말을 꺼내면 짜증 대폭발과 함께 도망갈 분위기였다.

어느 날,

고객이 와서 추가 개발을 요청했다.

개발자는 지금 일정으로 불가능하다고 했다.

고객도 위에서 요청이 오고 계약된 부분이라 꼭 해야 한다고 했다.

시끄러워졌다.

리더가 상황을 보더니 개발자에게 고객이 요청한 부분을 개발하자고 한다.

개발자는 못한다고 화를 냈다.

다들 난처한 상황이 된 것이다.

고객은 다시 일정을 확인해 본다고 올라갔다.

여기서 생각의 힘이 필요하다.

그리고 판단의 힘도 필요하다.

고객이 돌아왔다.

일정을 확인했지만 계약 때문에 꼭 해야 한다고 했다.

지금 진행하는 것도 해야 한다고 하면서.. 어쩌죠?라는 표정을 짓는다.

만약 리더가 둘 다 할게요라는 잘못된 판단을 내리면 상황은 더 악화될 것이다.

이때는 설득의 힘이 필요하다.

계약 때문에 추가 개발이 먼저 진행해야 한다면 바꿀 수 없다.

현재 진행 중인 일정은 계약과 관계가 없고 일정만 조정하면 되는 일이다.

우선 추가건을 먼저 하고 나서 다시 이어 하는 것으로 설득했다.

글쓰기를 잘하면 모든 상황에서 생각, 판단, 설득의 능력도 발달하게 된다.

그럼 글쓰기 공부는 어떻게 하나요?

처음 이야기 했던 책을 읽으면 된다.

글쓰기 책은 많다.

나도 많은 책을 읽어봤지만 어떤 책은 초반에 덮은 적도 있다.

글쓰기 공부에 적합한 책 2권을 추천해 본다.

"기자의 글쓰기, 박종인"

"150년 하버드 글쓰기 비법, 송숙희"

이 책들을 읽으면 공통점을 찾을 수 있다.

자신에게 맞는 부분을 잘 적용해서 매일 꾸준히 글을 써보자.

운동하면 근육이 생기듯,

반복적으로 하면 달인이 되듯

글쓰기도 매일 습관일 들여서 하면 근육이 생긴다.

개발자에게 글쓰기는 필수 능력이다.

20년 이상 개발을 하면서 다양한 프로그래밍 언어와 개발툴을 사용했다. 해당 언어에 대한 책을 읽고 코딩도 하고 사이트에서 검색도 했다. 매번 다른 환경에서 개발을 해야 했기에 개발자는 항상 공부를 해야만 했다.

하지만 막상 프로젝트에 투입되면 개발만 잘한다고 되지 않는다는 것을 알게 된다. 아마 다음과 같은 개발자를 봤거나 혹시 내가 그런 개발자가 아닌가 생각을 할 수 있다.

- 회의 등 대화 시 항상 다른 사람의 말을 자르고 답답하는 표정을 지으며 본인의 의견을 이야기한다.

- 그래서 끝까지 들어 달라고 하면 알았다 하고 바로 본인이 다르게 생각이 들면 또 자르고 들어온다.

- 회의 주제와 관계없는 자신의 무용담을 이야기하면서 시간을 소모한다.

- 개발 요청을 하면 "내가 왜?"라고 이야기한다.

- 항상 어렵다, 안된다 같은 부정적인 이야기만 한다.

- 본인한테 필요한 이야기만 하고 상대 이야기는 듣지 않는다. 특히 현업이나 영업 상사가 이런 경우가 많다.

- 코드에 문제가 있음에도 인정하지 않는다. 그리고 본인 코드는 확인하지 않고 상대방 문제라고 한다. 심지어 증거를 보여줘도...

- 새로운 트렌드에 대해 공부는 하기 싫고 예전에 방식대로 해도 문제없지 않나?라는 꼰대 같은 생각을 한다.

- 하지만 프로젝트가 진행되다 보면 문제가 커지고 있음이 발견되고 결국 다른 개발자들이 피해를 보게 된다.

- 고객(현업)과 회의 후 그들의 요구는 무시하고 본인 생각대로 진행한다. 하지만 나중에 문제가 되고 책임을 회피한다.

- 진행 중인 일정이 있음에도 당장 본인이 필요한 것을 해달라고 우겨댄다. 그리고 진행 중인 것도 일정 준수해 달라고 한다.

최근까지 프로젝트를 하면서 실제 일어났던 일들을 예로 들어보았다. 

위 예를 봤다면 공통점이 있음을 발견했을 것이다. 바로 소통에 문제가 있다.

보통 사람들은 이기적인 부분이 있다. 또한 자존심도 강하고 무시당하는 것을 원하지 않는다. 그렇기 때문에 대화할 때 자신을 돋보이고 싶어 하는 것이다. 

회의 중 다른 사람이 이야기할 때 순간 자신의 의견과 다르다고 생각되면 바로 자르고 자신이 옳다는 것을 강하게 어필하면서 주목받고 싶어 하는 것이다. 또한 자신의 의견을 이야기하다 보면 지속적으로 자신의 잘난 부분을 강조하고 싶어 하는 마음 때문에 주제와 벗어난 이야기를 하게 되는 것이다.

흔히 조리 있게 말을 못 한다는 표현을 이럴 때 사용하기도 한다. 

혼자 개발만 잘한다고 절대 성공적인 개발자가 되는 것은 아니다. 아니, 될 수 없다. 아무리 개발을 잘한다 해도 혼자 하는 프로젝트가 아니기 때문에 소통이 정말 중요하다고 할 수 있다.

최근에는 리더가 팀원들 앞에서 어떤 사안에 대해 이야기하는데 알아듣기 힘들 정도였다. 리더 본인은 더 잘 표현하고 이해시키고 싶어서 이런저런 예를 들었던 거 같은데 사실 문제 핵심과 전혀 관계없는 내용이었다. 약간 억지 부리는 듯한 느낌도 들었다. 

개발 공부는 개발자로 당연한 것이다. 하지만 개발자 포털 등에 커뮤니티 게시판을 가 보면 다양한 개발 관련 공부를 하고 있다는 글을 볼 수 있다. 본인의 성장을 위해서는 당연히 새로운 기술도 공부해야 하고 현재 기술력을 키워 나가야 한다. 

위에서도 이야기했듯이 개발만으로는 성장하는 개발자가 될 수 없다. 혼자 하는 것이 아니기 때문이다.

그렇다면 어떤 부분을 더 보강해야 할까? 바로 독서를 해야 한다. 

그럼 어떤 책을 읽으면 좋을까? 어떤 책이든 다양한 부분에 도움이 되기 때문에 읽으면 좋다. 하지만 소통의 문제가 있다는 이야기를 위에서 언급했듯이 이 부분을 좀 더 잘 발전시킬 수 있는 책을 읽는다면 도움이 될 것이다.

개발자가 소통과 원활한 프로젝트 진행 그리고 성장을 위해서 꼭 읽었으면 하는 분야가 있다.

바로 "영업과 마케팅"에 관한 책이다.

기술을 업으로 삼는 개발자가 영업이나 마케팅이 왜 필요할까?라는 의문을 가질 수 있다. 그런 책들은 회사에서 영업하는 사람들이 읽어야 하는 것 아닐까?

단순이 영업과 마케팅이라는 두 단어만 보면 개발자로 왜 이런 분야의 책을 읽어야 하는지 이해하기 어려울 수 있다. 그런데 중요한 것은 영업과 마케팅을 다시 생각해 보면 모두 고객의 마음을 움직인다는 것에 공통점을 찾을 수 있다. 여기서 말하는 고객은 영업 입장에서는 물건을 구매해 주는 사람이 고객일 것이다. 개발자로 프로젝트에서 고객의 개념을 생각해 본다면 고객사의 고객, 현업뿐 아니라 개발팀의 모두가 나에게 고객 같은 존재가 될 수 있다. 그 이유는 그들의 마음을 움직여야 하기 때문에다.

회의 시간에 내 의견을 잘 전달하고 상대방이 공감해서 좋은 결과가 나오기를 기대할 것이다. 고집 쎈 고객도 있을 것이고 일정에 맞춰 개발 중인데 다른 일을 중간에 끼워서 해달라고 요구하는 경우도 일정 조율등을 통해 잘 해결되기를 바랄 것이다.

그래서 개발자라도 영업과 마케팅에 관한 책을 읽어야 한다. 그 분야의 책을 읽어보면  상대의 마음을 어떻게 움직이는지 그 방법이 잘 설명되어 있다. 

나 또한 그 분야의 책을 많이 읽으면서 프로젝트에서 개발자로 어떻게 상대의 마음을 움직일 수 있을지 많은 도움을 받았고 실제 프로젝트에서 많이 사용해서 인정받기도 했다.

예를 들어보겠다.

상대방의 마음을 이해하고 그들이 필요한 것이 무엇인지 파악한 뒤 얽혀 있던 문제들을 하나씩 풀어내는 업무를 맡은 적이 있었다. 사람들의 마음이 다 다르기 때문에 쉬운 것은 아니었다. 정말 짜증이 엄청 날 때도 있었지만 내 목표는 감정 배제하고 갈등을 해소해서 잘 진행되게 하는 것이었다.  그 업무가 정리되고 개발자로 스프링 배치를 열심히 개발하고 있었다. 

어느 날 PMO에서 잠깐 이야기를 하자고 불렀다. 오픈이 다가오는데 개발팀장이 메일 솔루션 도입에 발목을 잡고 있다고 한다. 가서 아무리 설득하고 업체에서도 통화를 해봤지만 개발팀장은 뜻을 굽히지 않고 본인이 원하는 방식을 강하게 요구했다. 이게 해결 안 되면 오픈을 할 수 없었다. 그 내용을 우선 들어보니 개발팀장에 약간 옛날 방식을 생각하고 예전에 그런 이슈로 문제가 되었던 적이 있었나 보다. 그래서 이번에도 본인이 경험했던 부분이기에 더 강하게 고집을 피웠던 것이다. 주변에서는 이제 다른 방식이라 전혀 문제 되지 않는다고 해도 들으려고 하지 않아서 멘붕에 빠진 상태였던 것이다. 그런데 나보고 가서 해결을 해달라고 한다. 사실 그 개발팀장이랑 사이가 좋은 건 아니어서 썩 내키지 않았다. 하지만 그 부분이 해결 안 되면 오픈을 못한다고 도와달라고 하니 어쩔 수 없이 응했다. 개발팀장을 만나기 전 정보가 필요했기에 업체와도 통화해서 개발팀장이 걸고넘어지는 기술적 부분을 다시 듣고 확인했다. 그리고 만났다.

PMO와 개발 업체에서 개발팀장의 마음을 움직이는데 실패한 원인은 바로 네가 틀렸고 이제는 이제 맞다고 이야기하면서 진행을 요청했기 때문이다. 팀장급이면 나이도 있고 고집도 있을 뿐만 아니라 자존심도 엄청 쎄다. 그런 상황에서 네가 틀렸다는 식으로 이야기하니 화가 났을 것이고 사실 별 문제가 아니었을지라도 안된다고 했을 가능성이 크다. 우선 상대의 마음을 움직이려면 그의 의견을 존중하고 현재 상황을 잘 설명하고 그 의견으로 인해 본인에게 책임져야 할 불리한 상황이 발생할 수 있기에 우선 새로운 방식으로 진행하고 개발팀장이 주장하는 그 부분에 대해 모니터링하면서 추후 필요시 적용하는 것이 좋겠다는 의견을 제시했다.

처음에는 우선 왜 현재 방식대로 하면 안 되는지 의견을 묻고 말 자르지 않고 끝까지 들었다. 그리고 그 의견에 대해 공감했다. 그리고 현재 오픈을 하기 위해서 개발팀장의 의견대로 하려면 오픈 일정에 차질이 생긴다고 이야기했다. 오픈하면 개발팀장의 그 문제가 당장은 일어나지 않고 추후 발생할 여지가 있다고 이야기하니 공감했다. 지금 시간상 적용은 어렵고 오픈이 안되면 누군가 책임을 져야 하기에 우선 오픈하고 그 문제가 발생할 부분을 모니터링해서 시간을 확보한 뒤 나중에 조치하는 것이 어떠냐고 물었다.

결과는? 당연히 오케이 했다. 그 이유는 본인의 의견을 무시하지도 않았고 오픈에 대한 책임 소재에 본인도 부담을 갖게 되었고 시간을 벌고 추후 반영할 수 있다는 설득으로 모두가 만족하는 해결책이 된 것이었다. 그리고 오픈했다.

이렇게 사람의 마음을 움직여서 일의 진행을 매끄럽게 하는 것이 팀으로 일할 때는 정말 중요하다. 

그래서 영업과 마케팅에 관한 책을 적극 추천하는 것이다.

최근이 읽은 책 하나를 추천해 보겠다.

와타세 켄이 쓰고 유아이북스에서 출판한 "마음을 흔드는 영업의 법칙"이다. 

이 책을 읽으면 우리가 생각한 것과는 전혀 다른 방식으로 고객의 마음을 얻는 비법을 알게 된다.

난 영업이 아닌데?라는 생각을 버리고 개발자로 프로젝트에서 내가 원하는 것을 얻기 위해 필요한 기술을 하나 더 익힌다고 생각하고 이 책을 읽으면 된다. 그리고 기존에 프로젝트에서 겪었던 상황에서 이 책에서 배운 노하우를 적용하면 어떻게 되었을까? 상상해 보는 것도 좋다. 

사실 요즘에는 개발 관련 서적보다 마케팅과 심리에 대한 책을 더 많이 읽는다. 그리고 주변을 살피면 책의 힘을 느끼게 된다. 왜 책을 읽어야 하는지 알게 된다는 것이다.

사냥(개발)을 할 때 사냥에 필요한 좋은 도구들이나 멋진 의상도 중요하고 총을 잘 쏘는 것(코딩)도 중요하지만 사냥감(고객)의 특성과 활동 패턴을 익히는 것(소통)도 겸해야 전문 사냥꾼(개발자)이 된다.

개발자들이여~  출퇴근할 때 시간 허비하지 말고 책을 읽어라! 성공하고 싶다면...