<div id="readability-page-1" class="page"><div id="contents">
      <article id="entry">
         <div> 
	
	
<p>프로그래밍 능력, 소프트웨어 디자인 및 설계 등 업무 수행에 직접적으로 필요한 능력이 ‘하드 스킬(Hard Skill)’이라면 이러한 하드 스킬을 효율적으로 활용할 수 있게 도와주는 소통 능력, 실행력, 리더십 등 대인 관계와 관련된 정서적 능력을 ‘소프트 스킬(Soft Skill)’이라고 부르는데요.</p>



<p>대다수 소프트웨어 개발자들은 논리적인 사고를 하는 경우가 많다보니, 다른 사람도 자기처럼 논리적으로 사고해 줄거라고 여기는 경향이 있습니다. 그래서, 명확한 논리를 제시하기만 하면 상대가 자신의 생각을 잘 받아들일 거라고 착각을 하는 경우도 많구요. 자신의 아이디어를 내세우기 위해 논쟁을 하는 경우도 많고, 이 때 소프트 스킬이 부족하면 상대를 무시한다는 인상을 주면서 부정적인 행동이나 말을 하게 될 수 밖에 없습니다.</p>



<p>소셜 미디어에도 남을 배려하는 소프트 스킬이 부족한 언행으로 나쁜 평판을 얻게 되는 경우가 있는데, 자기 자신 뿐만 아니라 회사에도 피해를 주게 됩니다. 개발자의 하드 스킬은 혼자서 어느 정도 노력하면 얻어질 수 있지만, 소프트 스킬은 그렇지 않습니다. 그래서 개발자들이 소프트 스킬을 연마할 수 있는 몇 가지 방법을 이야기해 보려고 합니다. 각론에서는 결국 부딪히면서 배울 수 밖에 없겠지만요.</p>



<p><strong>◼ 개발자 채용 면접에 자주 들어가세요</strong><br>회사에서 직원이 아닌 다른 사람을 만나서 깊이 있게 이야기를 나눌 수 있는 가장 좋은 기회가 있다면, 바로 채용 면접입니다. 당연히 준비가 안된 상태로 면접을 보면 안되고, 회사가 제공하는 면접 교육 및 지침 등을 우선 숙지하고, 면접관 옆에서 배우는 쉐도잉(shadowing) 과정을 거쳐야 합니다.</p>



<p>개발자 중에 면접에 들어가기 싫어하는 분들이 있는데, 매니저가 코딩 테스트나 화이드보드 인터뷰 같은 기술적인 토론을 하는 인터뷰는 꽤 흥미롭기 때문에 그런 기회를 만들어주는 게 좋습니다. 주니어라면 이런 인터뷰에 쉐도잉 하는 것만으로도 많이 배울 수 있는데, 그런 기회를 달라고 떼를 쓰세요. 저도 스타트업 CTO로 있을 때 상당히 많은 면접을 보았지만, Daum에서 CTO 스탭으로 일하면서 임원 면접 쉐도잉을 하면서 배운 것이 많습니다.</p>



<p>아마존 채용 과정에서도 <a href="https://www.aboutamazon.eu/news/working-at-amazon/what-is-a-bar-raiser-at-amazon">바-레이저(Bar Raiser)</a>라고 불리는 명예 면접관이 있습니다. 그 분들은 일상 업무 외에도 자원 봉사로 인터뷰를 하면서 채용 과정에 객관적인 조언 역할을 합니다. 많은 경우, 매니저가 아님에도 불구하고 수 백회의 인터뷰를 하고 오랜 교육을 거쳐 선정된 분들로 다른 팀의 채용도 돕고 있습니다. 면접 과정은 업무 능력과 함께 자신의 소프트 스킬을 향상시킬 수 있는 가장 좋은 방법 중 하나입니다.</p>



<p><strong>◼ 사내 기술 태스크 포스팀(TFT)에 참여하세요</strong><br>회사에서 일을 하다보면 자신의 업무의 영역은 상당히 좁습니다. 자기 소속팀과 협업 팀 이상으로 넘어가기가 쉽지 않구요. 그런 상태가 오래가다 보면 회사 내부 일에 대해 근시안적인 시각을 가질 뿐만 아니라 만나는 사람의 한계도 만들어지게 됩니다.이럴 때, 단기적인 목표를 가지고 여러 팀이 협업을 위해 모였다 헤어지는 태스크 포스팀을 발제하거나 참여하는 것을 권장합니다.</p>



<p>“모든 사람의 일은 아무 사람의 일도 아니다”라는 말이 있듯이, 회사에는 항상 깨진 유리창처럼 방치되어 있거나, 중요한 것 같은데 아무도 안하는 일이 있기 마련인데요. Daum에서 API 개발팀을 담당하고 있을 때에 비슷한 일이 많았습니다. 예를 들어, 지도 API를 개선해야 하는 요구가 있을 때, 사내 API 통합 플랫폼을 만들어야 할 때, 신규 API를 만들려는 팀에 인력이 부족해서 지원을 해야 할때, 수시로 3-6개월짜리 단발성 TFT가 많았습니다. 아마 여러분 팀에도 다른 팀과 협업해야 하는 단기 프로젝트가 꽤 있을 거에요.</p>



<p>대개 TFT는 20-30% 정도의 비율로 기존 업무를 병행하는 경우가 많아서 참여를 꺼리는 경우가 많습니다. 제 경험으로는 회사 안팎을 이해하고 더 많은 분들을 만날 수 있는 기회가 많았습니다. 업무를 통해 다른 팀 구성원들과 일할 수 있는 합법적 기회(?)를 얻는 것이고, 사내 대인 관계의 폭이 넓어지면서 팀내 이동 기회를 얻는 경우도 상당히 많구요. 진리의 부바부, 팀바팀이라고 같은 회사내에서도 팀의 구조, 업무나 소통 방식이 다양한데 그런 걸 간접 체험할 수 있습니다.</p>



<p><strong>◼ 느슨한 사내 기술 커뮤니티를 만들어보세요</strong><br>회사 커뮤니티라고 하면 취미나 공부 주제를 공유하는 사내 동아리를 생각하기 쉬운데요. 팀의 업무로 하기에는 곤란하고, 사내 TFT로 발제하기는 장기적인, 그러면서 업무를 취미로 삼을 수 있는 꺼리를 찾아 사람을 모아 보는 것도 좋습니다.</p>



<p>예를 들면, 사내 공통 라이브러리나 프레임워크가 있는데 운영을 담당하는 팀이 없을 때, 마치 오픈 소스 커뮤니티 처럼 느슨한 업무성 조직을 만들 수 있겠죠. 회사에서 중요하게 생각하는 기술 토픽이 있으면, 이를 조사하고 발제하는 모임을 만들 수도 있구요. 많은 IT 기업들이 기술 블로그를 운영하고 있는데, 주제 선정, 편집, 리뷰 등을 해 주는 사람들이 모여서 하는 것도 좋습니다.</p>



<p>저도 AWS 내에서 본업 외에도 적어도 5개의 느슨한 업무 커뮤니티를 직접 운영하거나 속해있기도 합니다. 여기에는 저보다 직무 레벨이 훨씬 높은 분도 계시고, 주니어 분들도 계십니다. 같은 관심사로 모여 있다 보니까 여러 가지 조언을 주고 받기도 하고, 조금 실수를 했더라도 이해하면서 고쳐주기도 합니다.</p>



<p>회사에서 업무 목표를 세울 때, 70%는 본인의 주 업무, 20%는 부가 업무(혹은 실험), 그리고 적어도 10% 정도는 자기 계발에 할당하게 됩니다. 느슨한 사내 기술 활동에 10%를 사용하고, 사내 TFT 참여에 20% 정도 쓸 수 있다면, 하드스킬과 소프트 스킬을 함께 충족할 수 있을 것 같습니다.</p>



<p><strong>◼ 소프트 스킬은 영향력을 강화해준다</strong><br>시니어가 되면 프로그래밍 능력 뿐만 아니라 자신의 개발 경험을 전파할 수 있는 영향력이 필수적입니다. 자신의 코드는 잘 짜지만, 경험을 전수하는 능력이 부족하고, 다른 사람과 소통이 서툴다면, 그 사람의 영향력은 한정적일 수 밖에 없습니다. 팀 매니저나 임원이 되지 않더라도, 자신의 기술적 영향력이 팀을 넘어서고, 본부를 넘어서고, 회사로 확장되어야 시니어로 대접 받을 수 있습니다.</p>



<p>아마존에서는 이런 분들이 <a href="https://www.amazon.jobs/en/landing_pages/principal-engineer-hiring">프린시펄 엔지니어(Principal Engineer)</a>가 됩니다. 일반 개발자로서 갈 수 있는 최상위 직무 레벨인데요. 대부분 본인이 직접 코딩 업무를 하면서도 적어도 3개 팀 이상의 아키텍처와 디자인에 대해 리뷰해 주는 일을 해야 합니다. 해당 팀들의 기술적인 문제에 대한 해법을 생각하고, 개별 프로젝트에서 직접 설계 및 코딩하면서, 각 팀의 전체 기술 역량을 끌어 올리도록 돕는 일을 합니다. 기술적인 측면에서 비전가(Visionary)의 역할을 하기 때문에 흔히 작은 CTO라고 부르게 됩니다. 소프트 스킬이 부족하면 절대로 할 수 없는 일입니다.</p>



<p>개발자에게 하드스킬이 중요하냐? 소프트스킬이 중요하냐?라는 토론이 꽤 많은데요. 당연히 둘다 중요합니다. 세상의 모든 일이 다 마찬가지인데, 개발자만 예외가 될 수는 없죠. 그런데도, 유독 개발자 커뮤니티에서 그런 이야기가 꽤 많은 거 보면, 코딩 실력이 뛰어난 천재 개발자가 십만명을 먹여살린다는 환상이 있다거나, 사실 소프트 스킬 그런거 귀찮고 내 개발만 잘 하고 싶다 이런 생각이 꽤 많아서 그런것 같은데요.</p>



<p>환상속의 코드 구루는 여러분이 아니고, 진짜 10만명 중에 한 명 있을까 말까할 겁니다. 혼자서 내 개발만 잘하고 싶다면, 일인 스타트업을 하거나 프리랜서를 해야지 협업을 통해 가치를 창출하는 회사와는 맞지 않을 겁니다. 그러니까 길게 가고 싶다면, 두 가지를 겸비하세요. 그래야만 (매니저, 임원, 창업 등) 다른 기회도 얻을 수 있습니다.</p>
<div><h3>더 읽어 볼 글</h3></div>	

	<p>※ <a href="http://channy.creation.net/about/#disclaimer" target="new">Disclaimer</a>- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources.)</p>

        <p><small>- ;</small></p>

	
	


	<p><small>* 이 글의 댓글 일부는 <a href="https://indieweb.org/Webmention">Webmention</a> 도구를 이용하여, 소셜 미디어 공유 반응(Comments, Like, Tweet)을 수집한 것입니다.</small></p>

<div id="respond"><h3>답글 남기기</h3>





</div>
   </div></article>
</div></div>

Channy's Blog

프로그래밍 능력, 소프트웨어 디자인 및 설계 등 업무 수행에 직접적으로 필요한 능력이 ‘하드 스킬(Hard Skill)’이라면 이러한 하드 스킬을 효율적으로 활용할 수 있게 도와주는 소통 능력, 실행력, 리더십 등 대인 관계와 관련된 정서적 능력을 ‘소프트 스킬(Soft Skill)’이라고 부르는데요.
대다수 소프트웨어 개발자들은 논리적인 사고를 하는 경우가 많다보니, 다른 사람도 자기처럼 논리적으로 사고해 줄거라고 여기는 경향이 있습니다. 그래서, 명확한 논리를 제시하기만 하면 상대가 자신의 생각을 잘 받아들일 거라고 착각을 하는 경우도 많구요. 자신의 아이디어를 내세우기 위해 논쟁을 하는 경우도 많고, 이 때 소프트 스킬이 부족하면 상대를 무시한다는 인상을 주면서 부정적인 행동이나 말을 하게 될 수 밖에 없습니다.
소셜 미디어에도 남을 배려하는 소프트 스킬이 부족한 언행으로 나쁜 평판을 얻게 되는 경우가 있는데, 자기 자신 뿐만 아니라 회사에도 피해를 주게 됩니다. 개발자의 하드 스킬은 혼자서 어느 정도 노력하면 얻어질 수 있지만, 소프트 스킬은 그렇지 않습니다. 그래서 개발자들이 소프트 스킬을 연마할 수 있는 몇 가지 방법을 이야기해 보려고 합니다. 각론에서는 결국 부딪히면서 배울 수 밖에 없겠지만요.
 개발자 채용 면접에 자주 들어가세요
회사에서 직원이 아닌 다른 사람을 만나서 깊이 있게 이야기를 나눌 수 있는 가장 좋은 기회가 있다면, 바로 채용 면접입니다. 당연히 준비가 안된 상태로 면접을 보면 안되고, 회사가 제공하는 면접 교육 및 지침 등을 우선 숙지하고, 면접관 옆에서 배우는 쉐도잉(shadowing) 과정을 거쳐야 합니다.
개발자 중에 면접에 들어가기 싫어하는 분들이 있는데, 매니저가 코딩 테스트나 화이드보드 인터뷰 같은 기술적인 토론을 하는 인터뷰는 꽤 흥미롭기 때문에 그런 기회를 만들어주는 게 좋습니다. 주니어라면 이런 인터뷰에 쉐도잉 하는 것만으로도 많이 배울 수 있는데, 그런 기회를 달라고 떼를 쓰세요. 저도 스타트업 CTO로 있을 때 상당히 많은 면접을 보았지만, Daum에서 CTO 스탭으로 일하면서 임원 면접 쉐도잉을 하면서 배운 것이 많습니다.
아마존 채용 과정에서도 바-레이저(Bar Raiser)라고 불리는 명예 면접관이 있습니다. 그 분들은 일상 업무 외에도 자원 봉사로 인터뷰를 하면서 채용 과정에 객관적인 조언 역할을 합니다. 많은 경우, 매니저가 아님에도 불구하고 수 백회의 인터뷰를 하고 오랜 교육을 거쳐 선정된 분들로 다른 팀의 채용도 돕고 있습니다. 면접 과정은 업무 능력과 함께 자신의 소프트 스킬을 향상시킬 수 있는 가장 좋은 방법 중 하나입니다.
 사내 기술 태스크 포스팀(TFT)에 참여하세요
회사에서 일을 하다보면 자신의 업무의 영역은 상당히 좁습니다. 자기 소속팀과 협업 팀 이상으로 넘어가기가 쉽지 않구요. 그런 상태가 오래가다 보면 회사 내부 일에 대해 근시안적인 시각을 가질 뿐만 아니라 만나는 사람의 한계도 만들어지게 됩니다.이럴 때, 단기적인 목표를 가지고 여러 팀이 협업을 위해 모였다 헤어지는 태스크 포스팀을 발제하거나 참여하는 것을 권장합니다.
“모든 사람의 일은 아무 사람의 일도 아니다”라는 말이 있듯이, 회사에는 항상 깨진 유리창처럼 방치되어 있거나, 중요한 것 같은데 아무도 안하는 일이 있기 마련인데요. Daum에서 API 개발팀을 담당하고 있을 때에 비슷한 일이 많았습니다. 예를 들어, 지도 API를 개선해야 하는 요구가 있을 때, 사내 API 통합 플랫폼을 만들어야 할 때, 신규 API를 만들려는 팀에 인력이 부족해서 지원을 해야 할때, 수시로 3-6개월짜리 단발성 TFT가 많았습니다. 아마 여러분 팀에도 다른 팀과 협업해야 하는 단기 프로젝트가 꽤 있을 거에요.
대개 TFT는 20-30% 정도의 비율로 기존 업무를 병행하는 경우가 많아서 참여를 꺼리는 경우가 많습니다. 제 경험으로는 회사 안팎을 이해하고 더 많은 분들을 만날 수 있는 기회가 많았습니다. 업무를 통해 다른 팀 구성원들과 일할 수 있는 합법적 기회(?)를 얻는 것이고, 사내 대인 관계의 폭이 넓어지면서 팀내 이동 기회를 얻는 경우도 상당히 많구요. 진리의 부바부, 팀바팀이라고 같은 회사내에서도 팀의 구조, 업무나 소통 방식이 다양한데 그런 걸 간접 체험할 수 있습니다.
 느슨한 사내 기술 커뮤니티를 만들어보세요
회사 커뮤니티라고 하면 취미나 공부 주제를 공유하는 사내 동아리를 생각하기 쉬운데요. 팀의 업무로 하기에는 곤란하고, 사내 TFT로 발제하기는 장기적인, 그러면서 업무를 취미로 삼을 수 있는 꺼리를 찾아 사람을 모아 보는 것도 좋습니다.
예를 들면, 사내 공통 라이브러리나 프레임워크가 있는데 운영을 담당하는 팀이 없을 때, 마치 오픈 소스 커뮤니티 처럼 느슨한 업무성 조직을 만들 수 있겠죠. 회사에서 중요하게 생각하는 기술 토픽이 있으면, 이를 조사하고 발제하는 모임을 만들 수도 있구요. 많은 IT 기업들이 기술 블로그를 운영하고 있는데, 주제 선정, 편집, 리뷰 등을 해 주는 사람들이 모여서 하는 것도 좋습니다.
저도 AWS 내에서 본업 외에도 적어도 5개의 느슨한 업무 커뮤니티를 직접 운영하거나 속해있기도 합니다. 여기에는 저보다 직무 레벨이 훨씬 높은 분도 계시고, 주니어 분들도 계십니다. 같은 관심사로 모여 있다 보니까 여러 가지 조언을 주고 받기도 하고, 조금 실수를 했더라도 이해하면서 고쳐주기도 합니다.
회사에서 업무 목표를 세울 때, 70%는 본인의 주 업무, 20%는 부가 업무(혹은 실험), 그리고 적어도 10% 정도는 자기 계발에 할당하게 됩니다. 느슨한 사내 기술 활동에 10%를 사용하고, 사내 TFT 참여에 20% 정도 쓸 수 있다면, 하드스킬과 소프트 스킬을 함께 충족할 수 있을 것 같습니다.
 소프트 스킬은 영향력을 강화해준다
시니어가 되면 프로그래밍 능력 뿐만 아니라 자신의 개발 경험을 전파할 수 있는 영향력이 필수적입니다. 자신의 코드는 잘 짜지만, 경험을 전수하는 능력이 부족하고, 다른 사람과 소통이 서툴다면, 그 사람의 영향력은 한정적일 수 밖에 없습니다. 팀 매니저나 임원이 되지 않더라도, 자신의 기술적 영향력이 팀을 넘어서고, 본부를 넘어서고, 회사로 확장되어야 시니어로 대접 받을 수 있습니다.
아마존에서는 이런 분들이 프린시펄 엔지니어(Principal Engineer)가 됩니다. 일반 개발자로서 갈 수 있는 최상위 직무 레벨인데요. 대부분 본인이 직접 코딩 업무를 하면서도 적어도 3개 팀 이상의 아키텍처와 디자인에 대해 리뷰해 주는 일을 해야 합니다. 해당 팀들의 기술적인 문제에 대한 해법을 생각하고, 개별 프로젝트에서 직접 설계 및 코딩하면서, 각 팀의 전체 기술 역량을 끌어 올리도록 돕는 일을 합니다. 기술적인 측면에서 비전가(Visionary)의 역할을 하기 때문에 흔히 작은 CTO라고 부르게 됩니다. 소프트 스킬이 부족하면 절대로 할 수 없는 일입니다.
개발자에게 하드스킬이 중요하냐? 소프트스킬이 중요하냐?라는 토론이 꽤 많은데요. 당연히 둘다 중요합니다. 세상의 모든 일이 다 마찬가지인데, 개발자만 예외가 될 수는 없죠. 그런데도, 유독 개발자 커뮤니티에서 그런 이야기가 꽤 많은 거 보면, 코딩 실력이 뛰어난 천재 개발자가 십만명을 먹여살린다는 환상이 있다거나, 사실 소프트 스킬 그런거 귀찮고 내 개발만 잘 하고 싶다 이런 생각이 꽤 많아서 그런것 같은데요.
환상속의 코드 구루는 여러분이 아니고, 진짜 10만명 중에 한 명 있을까 말까할 겁니다. 혼자서 내 개발만 잘하고 싶다면, 일인 스타트업을 하거나 프리랜서를 해야지 협업을 통해 가치를 창출하는 회사와는 맞지 않을 겁니다. 그러니까 길게 가고 싶다면, 두 가지를 겸비하세요. 그래야만 (매니저, 임원, 창업 등) 다른 기회도 얻을 수 있습니다.

소프트웨어 개발자가 ‘소프트 스킬’ 쌓는 방법

댓글