신기한 연구소

하루 종일 책상에 앉아서 수학 문제를 열심히 푸는 고등학생 아들이 있다. 하지만 열심히 하는 만큼 성적은 나오지 않고 점점 의욕을 잃어가는 듯 보였다.  이러다 수포자가 되면 어쩌나?라는 생각이 들었다.

대학 시절 필수 과목에 미적분학이 있었다. 대학 1학년 신입생때는 당연히 놀았다. 열심히 놀고 또 놀았다. 그리고 성적은 D가 나왔다. 당연한 결과였다. 시험 시간 내내 끙끙 앓기는 했지만 결국 반도 못 풀고 제출했기 때문이다. 왜? 공부를 안 했으니까... 정말 어려웠다.

시험 문제가 어려운 이유?

아이들이 시험을 보고 성적이 안나오면 항상 어렵다는 표현을 사용한다. 개발할 때도 마찬가지다. 조금 난이도 있는 로직이 나오거나 새로운 프로그램을 사용할 때 (Git, MAS 등) 어렵다는 표현을 사용한다. 우리는 어렵다는 표현을 내 자신이 이해를 못 했거나 해결하지 못한 경우 또는 전혀 모르겠을 때 어렵다는 표현을 사용한다. 여기서 답이 있다. 어렵다는 의미는 사실 모르는 것이다. 모르는 것을 어렵다는 표현을 사용하고 마치 우리가 해결할 수 없다는 의미로 받아들이고 넘겨버린다. 그리고 수포자가 되는 것이다.

열심히 해도 성적이 안올라요.

우리 주변을 보면 정말 열심히 하면서 사는 사람들을 많이 본다. 예전에 유명했단 3당 4락(3시간 자면 합격, 4시간 자면 떨어진다)이 그 예일 수 있다. 그런데 이상한 점을 볼 수 있다. 누구보다 열심히 하고 사는데 나아지질 않는 경우다. 왜 그럴까? 관찰도 해보고 깊이 생각을 해봤다. 사실 열심히 한다는 것은 시간을 많이 투자하는 경우에 자주 사용하는 표현이다. 수학 공부를 정말 열심히 하지만 성적이 안 오르는 이유는 노동을 하기 때문이다. 갑자기 공부하는데 노동이라는 표현이 왜 나올까? 우리 집 고등학생을 예로 들어보겠다. 책상에 정말 오래 앉아서 종일 수학 문제를 푼다. 그런데 이게 공부일까? 노동일까? 

노동은 공부가 아니다. 공부는 무엇인가?

수학 공부하는 고등학생 아이를 보면서 왜 노동이라는 표현을 썼을까? 바로 아는 문제만 열심히 풀고 있었기 때문이다. 한두 번 풀어보니 이미 아는 문제라 더 반복할 필요가 없음에도 계속 반복해서 아는 문제들만 열심히 풀고 있다. 1등급이나 블랙라벨 같은 고난도 문제를 왜 안 풀어보는지 물어봤다. 분명 시험 뒷부분은 난이도 있는 문제가 나오는데도 관련 문제를 찾아서 풀어보지도 않는다. 그냥 어려워서 못 풀겠단다. 그래서 아예 풀어보지도 않는다. 아는 문제 열심히 반복해서 풀어봐야 뻔한 비슷한 점수만 나온다. 아무리 열심히 해도 그 점수대를 넘어서질 못한다. 왜? 바로 점수를 얻어야 하는 그 뒤의 난이도 있는 문제를 풀지 않기 때문이다. 결국 공부가 아닌 노동으로 열심히 시간만 버리고 있는 것이다. 점수를 얻기 위해서는 시험 때마다 못 풀어서 점수를 얻지 못한 부분을 공략해야 하는데 말이다. 모른다고 어렵다고 표현하는 그 난이도 문제에 집중하고 풀어낼 방법을 찾아 시간을 투자해야 바로 공부를 하는 것이다. 다른 말로 아는 것만 열심히 풀지 말고 어렵고 모르는 문제에 시간을 투자해서 난이도 있는 문제를 푸는 것이 공부다. 몰랐던(어려운) 내용을 내가 알아내는 것이 바로 공부다.

열심히 일하는데 야근하는 이유.

 일이라고 다르지 않다. 정말 열심히 코딩하는 직원이 있었다. 누가 봐도 열심히 한다. 그렇기에 일정도 잘 맞추고 품질도 좋고 일을 잘한다는 평가도 있을 듯한다. 하지만 매일 야근하고 주말까지 나오지만 결과는 꽝이다. 일정도 못 맞추고 품질도 개판인 경우가 많다. 제대로 된 기술과 효율적인 업무 처리 없이 그냥 열심히만 하기에 야근해도 답이 안 나오는 경우다. 아인슈타인이 했던 유명한 말이 있다. 내가 좋아하는 명언 같은 말인데 "같은 일을 반복하면 서 다른 결과를 기대하는 것인 미친 짓이다"라고 들어본 사람도 있을 것이다. 맞는 말이다. 요즘 IT 회사들이 많이 힘들다. 그래서 다들 제안서를 더 많이 쓴다. 일은 많지 않기에 업체들의 경쟁이 엄청 심하다. 그런 상황에서 제안서 작업을 경험할 기회가 생겼다.

열심히 제안서를 작성하는데 계속 떨어지는 이유

방금까지 설명한 부분이 이유다. 제안서 작업이 떨어지는 이유는 떨어지게 작성을 하기 때문이다. 이게 무슨 소리냐고? 예전에 떨어진 제안서를 다시 꺼내서 복붙을 한다. 또는 여기저기 다른 제안서에서 비슷한 내용은 가져와 짜집기를 한다. 그리고 줄을 맞추고 폰트를 맞추고 색상을 맞춘다. 아니 이런 외적인 부분에 더 집중하고 시간을 엄청 투자한다. 그냥 봐도 될거 같은가? 엄청난 돈을 들여서 프로젝트를 진행하기 위해 제안 요청서를 작성한다. 그 요청서에는 이번 프로젝트에 꼭 필요한 내용과 기존 프로젝트에서 힘들게 진행한 경험을 피하고 싶기에 그런 부분 또한 요청서에 기입한다. 즉, 괜히 아무 업체나 선정했다간 담당 직원만 엄청 힘들어지기 때문에 제안 요청서에는 정말 필요한 것과 도움을 받고 싶은 부분이 표현되어 있을 것이다. 하지만 보통은 그런 내용은 보지 않고 그냥 누더기처럼 짜집기를 한 후 겉만 번지르르하게 꾸미고 제출한다. 당연히 떨어진다. 제안 요청서를 잘 읽고, 물론 엉성하게 작성된 경우도 있지만, 핵심을 잘 정리한 후 미팅을 통해 더 확실히 무엇을 요구하고 도움이 필요한지 파악한 후 제안서를 작성해야 한다. 맨바닥부터 시작하기는 시간도 부족하고 표현의 질도 떨어질 수 있기에 기존에 잘 작성된 제안서를 기반으로 작성하는 것도 방법이긴 하다. 하지만 내용이 더 중요하다. 제발 쓸데없는 부분에 많은 시간을 투자하지 말자.

열심히 하면 용서가 된다.

회사 임원의 입에서 나온 말이다. 열심히 하면 용서가 된단다. 과연 CEO나 오너도 같은 생각일까? 만약 그렇다면 그 회사는 오래가지 못할 것이다. 열심히 하는 것과 잘하는 것은 엄연히 다르다. 처음 시작하는 경우 열심히 하면서 실수도 하고 실패도 하면서 성장한다. 이런 경우 열심히라는 표현이 잘 어울린다. 하지만 회사는 성과와 매출이 중요하다. 매번 열심히 하니까 용서가 된다고? 빨리 그만둬야 할 임원이다. 매출이 중요한 기업에서는 열심히는 당연한 밑바탕이고 잘해야 한다. 열심히만 한다? 아무 필요 없다. 야근에 주말까지 열심히 해서 제안발표에 떨어지는 임원과 효율적으로 근무시간을 잘 활용해서 제안발표를 잘 따오는 임원 중 누가 더 필요한 임원일까?

난 열심히 했으니깐 됐어!    응 아니야!

성공하고 싶다면 효율적으로 잘 해야 한다. 열심히.

이제 열심히 하는 것은 성공하는 길이 아닌 것을 알았을 것이다. 잘 해야 한다. 아무리 열심히 해도 수학 점수가 60점대가 나온다면 잘못하고 있는 것이다. 나머지 40점을 왜 못 얻는지를 분석하고 그 40점을 얻기 위해 준비하고 여기서 열심히 해야 한다. 맨날 야근하고 주말까지 나와 일하는데 제안하는 족족 떨어진다고? 엉터리로 하고 있기 때문이다. 매번 같은 방식으로 짜집기 하는 제안서로 다른 결과를 기대하는 것은 미친 짓이라니까! 방법을 바꿔야지. 책을 읽는 사람과 읽지 않는 사람은 분명 차이가 있다. 갑자기 책 이야기를 하는 이유는 효율적으로 잘해서 성공하고 싶다면 정보가 필요하다. 그 모든 정보는 책에서 얻을 수 있다. 뭐 직접 경험해서 얻을 수 있지만 많은 시간이 걸리기도 하고 못 얻을 수도 있다. 주변 사람들과 책에 대해 이야기하면서 많이 놀란 점이 있는데, 바로 다들 책을 읽지 않는다는 것이다. 

새로운 도전을 위해서

그냥 그곳에 있으면서 불평하고 반항해도 변하지 않는다. 책에서 읽은 내용인데 다른 사람을 변화시키는 것은 거의 불가능하다고 한다. 그리고 자기 자신을 변화시키는 것도 어렵단다. 그래도 내 자신을 변화 시키는 것이 다른 사람을 바꾸는 것보단 쉽다. 그래서 많은 책을 읽고 마음을 단련시키고 있다. 그냥 앉아서 변하길 기다린다면 안 변한다. 새롭게 도전해 보련다. 40점을 얻기 위해 움직일 것이다. 아니 벌써 시작했다. 그냥 존버하라는 사람들도 있다. 인생 짧다. 이렇게 존버하려고 태어난 건 아니고 인생이 아깝다. 새로운 도전을 위해 나는 나아갈 것이다. 

그러기 위해서는 열심히 하는 것보다 잘하는 것에 집중할 것이다. 심지어 노는 것도 잘 놀 것이다.

모두 즐거운 인생을 위해 도전해 보자!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

예를 들어보겠다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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