연봉을 올리고 싶다면 ‘소프트 스킬’을 읽으세요.
개발자로 일하며 가장 흔하게 하는 착각이 바로 실력이 있으면, 실력만 있다면 내 처우가 올라갈 것이라는 기대입니다. 그런데 회사를 다니며 주변을 보니까 그렇지 않은 경우를 만나게 됩니다. 이 때에 우리는 큰 혼란을 겪게 되지요.
2016년이었습니다. 다니던 회사에서 고과를 잘 받아서 조기 진급도 했습니다. 그런데 여전히 제 처우는 만족스럽지 않았습니다. 당시 다니던 회사는 인센티브 비중이 높았는데 몇년간 성과급이 줄어들어 전체 소득은 비슷했거든요.
왜 점점 일은 늘어나는데, 더 잘한 것 같은데 제 처우는 나아지지 않았는지 궁금했습니다. 또 당시에 이직 준비를 하고 있어서 이력서 작성에 대한 고민도 있었구요. 그러던 차에 ‘소프트 스킬'이란 책을 접하게 되었습니다.
처음 책을 읽을 때에는 ‘그런가? 내가 이런걸 몰랐구나' 싶었으며, 2023년에 두번째 읽게 되었더니 슥슥 쉽게 읽혔습니다. 그 사이에 내가 놓친게 많구나 다시 시작해야지 하는 마음도 가지게 되었습니다.
소프트 스킬은 무엇인가?
책의 각주에서는 소프트 스킬을 아래처럼 설명합니다.
전문 지식, 기술력 등 업무 수행에 직접적으로 필요한 능력이 하드 스킬(Hard Skill)이라면 이러한 하드 스킬을 효율적으로 활용할 수 있게 도와주는 소통 능력, 실행력, 리더십 등 대인 관계와 관련된 정서적 능력이 소프트 스킬(Soft Skill)이다.
줄여 말하면 개발자의 하드 스킬은 개발 능력, 즉 코딩 스킬이 되고 소프트 스킬은 개발 업무를 수행하면서 일어나는 전반적인 과정에 대한 능력입니다. 주로 커뮤니케이션 영역이지요.
개발자들이 흔히 하는 말 중에 이런 말이 있어요.
“나는 컴퓨터가 편해요. 사람 상대하는 것이 어려워요"
그런데, 개발자들의 일의 시작과 끝은 사람입니다. 개발해야하는 업무의 요청도 개발 업무의 완성된 결과물도 모두 사람이 하는 일입니다. 물론 자동화를 잘해서 내 개발 결과물은 기계가 판단하는데요 라고 하더라도, 그 결과의 끝에는 사용자가 있을 것이고 평가를 하는 리더가 빠질 수는 없습니다.
밸런스 게임
여기 두 사람이 있습니다. 한명은 개발은 잘하지만 팀원과 문제가 있는 사람 이고 다른 사람은 개발은 보통이지만 팀에 기여도가 높은 사람입니다. 어떤 사람과 함께 일하고 싶은가요? 역시 개발잘하는 사람과 일하고 싶나요? 하지만 이 사람은 코드 리뷰 참여도 없고 진척도 공유도 안하고 미팅에서는 매번 부정적이라고 한다면요? 그래도 여전히 함께 하고 싶을까요? 아닐겁니다.
소프트 스킬은 바로 그런 때에 도움이 됩니다. 내가 해야하는 명확한 일들, 하드 스킬에 대하여 한계가 느껴질 때에 무얼 더 해야 하는가 하면 바로 소프트 스킬을 길러야 하는 것이죠. 우리가 흔히 말하는 ‘일 잘하는 사람'은 하드 스킬의 뛰어남도 있지만 하드 스킬만 뛰어난 사람은 아닙니다.
책 이야기
짧은 파트로 구성되어 총 74장(구판은 71장)으로 되어있습니다. 경력, 셀프 마케팅, 학습, 생산성, 재무관리, 건강, 영혼 이렇게 7부로 되어있는데요. 모두 읽지는 마세요. 재무관리 부터는 사실 가볍게 보거나 동의하지 않으면 보지 않아도 무방한 내용입니다.
다만 재무관리에서 ‘연봉 협상의 기술’은 꼭 읽으세요. 저는 첫 이직때 먼저 현재 연봉과 이직 최소 기대 연봉을 말했고, 당연히 해당 처우 협의는 실패하고 말았습니다. (그러나 한국에서는 원천 징수 영수증을 건네는 일이 당연한 지원 과정에 들어있네요)
이 책은 개발자 들이 흔히 무관심하게 생각하는 부분에 대한 시선 돌리기로 접근해야합니다. 너무 광적으로 믿으면 안된다고 생각하며 실제로 읽으면 한국 사정과는 다른 이야기도 많습니다.
책에서 일부 떼어내어 이야기하고 싶은 부분들입니다.
블로그 성공적으로 운영하기
이 챕터에는 블로그가 중요한 이유와 어떠한 유용함이 있는지 쓰여있습니다. 지금은 많은 개발자들이 셀프 브랜딩에 익숙하여 소셜 네트워크, 블로그, 깃헙 관리를 하는데요. 예전에는 이러한 것은 실력없는 사람들이 하는 것이다 라는 이상한 기조가 있었어요. (같이 잘하면 좋은데요)
사실 내가 잘한다고 해도 누가 알아줄 수 있을까요? 면접 시간은 언제나 모자릅니다.(지원자에게도 면접관에게도 양쪽 모두에게요)
그래서 블로그가 있다면 지원자를 파악하는 데 큰 도움이 될 수 있습니다. 다만 TIL은 성실성의 척도 외에는 도움이 되지 않습니다. (면접관이 다 살펴볼 수도 없습니다.) 처음에는 쉬운 글 부터 쓰세요. 시작하는 때에는 TIL도 사실은 좋습니다.
그러나 나를 증명해야 하는 시기에는 단순히 인터넷에 있는 내용의 재생산이 아닌 진짜 이야기를 써주세요. 회사의 사정상 모두 밝히지 않아도 좋으니 업무를 하면서 경험들이 특히 좋습니다. 저 또한 어느 지원 과정에서 추천인을 통해 제 블로그가 면접관에게 전달 되었고 좋은 인상을 받았다 라고 들은 바가 있습니다.
면접에서 혹시라도 블로그에 작성했던 기술 내용이라면 어떨까요? 단순하게 인터넷 내용의 학습 정리가 아닌 업무 경험의 내용, 이슈 해결 또는 교훈이었다면 아주 즐거운 면접 시간이 될 것입니다. 내가 모르는 임의의 주제가 아니라 내가 자신 있는 주제에 대한 내용으로 면접 시간을 소비하는 것이니까 굉장히 유리한 경우죠.
다른 사람이 읽으면 좋지만, 남이 읽지 않아도 좋습니다. 적어도 내 기술 경험에 대한 정리를 해두었다면 이직 면접 준비 시에 본인의 블로그 글을 읽어보는 것으로 도움이 될 테니까요.
바보 같아 보여도 괜찮다
책은 발표에 대한 이야기입니다. 처음은 긴장하고 실패하기 마련이며, 다른 사람들은 잘 기억하지 못한다는 내용이죠. 공개된 글(회사의 기술 블로그)을 쓰거나 컨퍼런스 발표(회사나 기술 커뮤니티) 경험은 흔하지 않으니 우리 주변의 예를 생각해볼까요?
누군가의 결혼식을 떠올려보세요. 결혼식 당시에는 축사나 축가, 행진 등을 모두 보지만 지나고 나면 기억나는 경우가 거의 없습니다. 그래서 우스개 소리로 밥 맛있는 곳에서 결혼식을 하는게 중요하다는 말도 있지요.
소프트 스킬이라고 해서 꼭 발표나 글쓰기에만 도전해야하는 것은 아닙니다. 코드 리뷰 역시도 소프트 스킬에 포함됩니다. 여태까지 코드 리뷰에 코멘트 남기기가 두려워 어려웠나요? 잘못된 내용을 남겨도 좋으니 참여하세요. 틀린 내용이라면 코드 작성자가 정정해서 답변 줄 거예요. 이메일도 메신저도 마찬가지입니다. 기다리지말고 먼저 연락해보세요.
비단 소프트 스킬만이 아닙니다. 하드 스킬도 마찬가지입니다. 저는 실제로 신입 사원 시절에 ‘누가 이런 실수를 해’ 급의 rm -rf /. 사건을 저질렀습니다. ./ 을 /. 으로 잘못 쓴거죠. 덕분에 회사 개발 서버와 연동된 저장소 프로세스들이 3중 백업되고 있었다는 사실도 알았습니다. 늦게까지 퇴근 못하고 복구한다고 야근하고 있었는데 지나가던 선배가 3중 백업을 알려주면서 복구 요청하면 된다고 퇴근하라고 일러준 것이 아직도 기억납니다. (그래도 개발 환경은 새로 설정해야했어요.) 이후에 저도 실수한 팀 동료가 있다면 항상 격려하고 사람의 실수를 막는 프로세스가 있어야지 동료의 탓이 아니라고 이야기해주고 있습니다.
할당 체계를 도입해 생산성을 높여라
마감일이 있는 일은 잘해내지만 마감일이 없으면 어렵다구요? 당연한 이야기입니다. 저도 그래요. 이 파트에서는 그런 부분을 극복할만한 방법들을 소개해줍니다. 게으른 사람이어서 혹은 흥미가 적어서 여러가지 핑계대지 않고 해낼 수 있는 방법이죠.
다만 회사 업무에서는 조심스럽습니다. 회사 업무 체계는 급격한 변경이 있을 수 있으니 할당 체계를 적용하였을 때 긴급한 일로 해내지 못할 수도 있으니까요. 이 챕터의 바로 앞 ‘뽀모도로 기법'에 흥미로운 내용들이 있습니다.
종일 소처럼 일했는데도 목록에 있는 작업을 모두 완료하지 못하고, 어마어마한 노력을 기울였음에도 실패한 것 같다고 느낀다.
게으름을 피웠는데도 목록에 있던 작업이 예상보다 쉬워서 모두 완료할 수 있다면 칭찬할 일이 아니다. 할 일 목록은 기준이 될 수 없다. 정말 중요한 것은 집중해서 완료한 작업의 양이다.
하루 동안 목표로 했던 뽀모도리를 모두 완수하고 나면 남는 시간에는 무엇을 하든 상관없다.
어떤가요? 보통 우리가 직장생활하면서 느낀 부분이 그대로죠? 어느 날은 보람차고 어느 날은 피곤하기만 하고요. 저도 이러한 반복 주기에 따른 할당 체게는 잘 해내는 편은 아닌데요. 그래도 이러한 내용을 생각하고 있으면 할당량 보다는 낮아도 어느 정도 진행을 하게 되더라구요.
작업 분할하기
정말 중요한 내용입니다. 작은 일은 누구나 쉽게 잘 해내지만, 커다란 일이 되면 해내지 못하는 부분들이 생겨납니다. 코드 작성과 리뷰도 마찬가지입니다. 우리가 코드 변경이 크면 작성한 사람도 리뷰할 사람도 어렵지요. 하지만 이를 나누어 올린다면 부담 없겠지요.
문제 나누기를 하세요. 업무를 혼자 나누기 어렵다면 팀원이나 팀장에게 도움을 요청해보세요. 다른 사람의 시선이 객관적으로 작용할 수도 있습니다. 수천 라인의 기능은 어렵지만 수십 라인의 기능은 쉽다는 것에 동의하시나요? 그렇다면 여러분은 이미 쪼개기를 잘 해낼 수 있는 사람입니다.
뭐라도 하는게 아무것도 하지 않는 것보다 낫다
정말 중요한 말입니다. 미팅을 하다보면 네거티브 케이스를 많이 만나게 되고, 1시간을 이야기해도 아무 결과가 없는 경우들이 있습니다. 어차피 엎어질 테니 하지 않고 기다리는 것이 현명해 보이나요? 시간이 허락한다면 심각한 손해가 발생하지 않는다면 해보세요.
실패한다고 하여도 실패 케이스를 정리해서 다음에 같은 상황에서 도움이 될 것입니다. 업무도 마찬가지입니다. 해본 경험이 면접에서 큰 도움이 됩니다. 특히나 실패한 경험은 왜 실패했는지를 정리해보세요. 다음엔 어떻게 해결해볼지도요.
마무리
호기롭게 연봉을 올리고 싶다면 소프트 스킬을 배우라고 하였는데요. 연봉과 개발 실력(하드 스킬)은 비례 관계가 아닙니다. 누군가는 좋은 실력으로도 낮은 처우를 받고, 누군가는 평범한 실력으로도 높은 연봉을 받습니다.
물론 처우가 전부는 아닙니다. 누군가는 개발 실력이 좋지만 같이 일하기 싫은 사람이고 누군가는 평범하지만 함께 일하고 싶은 사람입니다. 누군가를 추천해야할 때, 팀을 새로 구성할 때에 함께 일하고 싶은 동료가 되고 싶다면 소프트 스킬을 키우세요.
소프트웨어 개발자는 소프트웨어 개발만 잘하면 된다고 아직도 말하는 사람이 있다면 사기꾼입니다. “너는 개발만 해, 나머지는 내가 챙길게' 라는 뜻이죠. 아직 늦지 않았습니다. 지금부터 훌륭한 경력 관리를 해내세요 😁
