<div id="readability-page-1" class="page"><article>
        <h2 id="당신이-아무리-공부해도-개발-실력이-늘지-않는-이유"><a href="#당신이-아무리-공부해도-개발-실력이-늘지-않는-이유" title="당신이 아무리 공부해도 개발 실력이 늘지 않는 이유"></a>당신이 아무리 공부해도 개발 실력이 늘지 않는 이유</h2><h2 id="지식은-기술이-아니다"><a href="#지식은-기술이-아니다" title="지식은 기술이 아니다"></a>지식은 기술이 아니다</h2><blockquote><p>백엔드 개발자 4년 차인 A 씨는 퇴근 후에 자기 개발을 위해 기술 도서를 꾸준히 읽는다. 최근에는 리팩토링이라는 책을 읽고 사내의 개발자들에게 자신이 공부한 것에 대해 발표도 했다. 하지만 아쉬운 점도 있다. 마음만 먹으면 언제든 리팩토링 할 수는 있지만 항상 바쁜 일정 때문에 리팩토링 할 시간이 없다. 사실 지금도 그럭저럭 잘 돌아가고 있는데 리팩토링을 한다고 새로운 비지니스 가치가 더해지는 것도 아니니 그 시간에 새로운 기능을 하나 더 만드는게 낫지 않나 싶기도 하다.</p>
<p>이전엔 테스트주도개발이라는 책을 읽고 실무에 적용해보려고 했지만, 이 역시 막상 실무에 사용해보려고 하니 시간이 너무 많이 걸려서 실효성이 없어 보였다. Ruby on Rails로 유명한 DHH 가 ‘<a target="_blank" rel="noopener" href="https://dhh.dk/2014/tdd-is-dead-long-live-testing.html">TDD 는 죽었다</a>‘ 라는 글을 썼다는 걸 보니 실제로 실효성이 없는 것 같다는 생각도 들었다. </p>
</blockquote>

<p>개발자 A 씨는 리팩토링과 TDD 에 대해 어느 정도의 기술(skill)을 가지고 있을까? A 씨는 지식은 풍부하지만 기술을 가진 것은 아니다. 왜냐하면 기술은 지식 자체에서 오는 것이 아니라 지식에 기반하여 훈련하고 실행하는 과정에서 습득되는 것이기 때문이다. skill 에 대한 영영사전에 의미를 보면 다음과 같다.</p>
<blockquote><p>an ability to do something well, especially because you have learned and practised it</p>
</blockquote>

<p>practise는 practice 와 같은 의미인데 연습하다, 훈련하다의 의미를 지니고 있다. 기술은 훈련과 실천의 과정에서 습득되며 기술로서 활용될 때 가치를 얻게 된다. 그래서 나는 우리 팀원들에게 항상 ‘지식은 기술이 아니다’ 라는 이야기를 꼭 한다.</p>
<h2 id="규율-기술-역량"><a href="#규율-기술-역량" title="규율 * 기술 = 역량"></a>규율 * 기술 = 역량</h2><p>Management 3.0 에 ‘규율 * 기술 = 역량’ 이라는 내용이 있다. 개인적으로는 무릎을 탁치게 하는 공식이라고 생각했다. 앞에서 분명 지식은 기술이 아니라고 했다. 그럼 기술만 있으면 전문가로서의 역량이 뛰어나다고 볼 수 있을까? 그것만으로는 뭔가 좀 부족하다. 엔진 점검을 자주 잊어버리는 조종사, 손씻기를 뺴먹는 외과 의사, 도마나 칼을 제대로 닦지 않는 요리사는 어떤가? 저런 부분들은 기술도 아니고 한 두번 깜박한다고 당장 큰일이 생기지는 않을 것이다. 하지만 이런 부분들이 전문가들은 중요한 규율 중에 하나라는 것을 잘 알고 있기 때문에 의식하지 않아도 자연스럽게 행할 수 있도록 노력한다. </p>
<p>개발자들에게 있어 규율은 어떤 것들이 있을까? 언어나 팀에서 지정한 컨벤션을 준수하거나, 개발한 내용에 대한 테스트 수행, 클린 코드를 위한 네이밍 규칙, 사용하지 않는 코드나 주석의 제거, 불필요한 임시 변수의 할당 등 여러가지가 있을 것이다. 이것들은 기술이라고 볼 수는 없지만 좋은 품질의 개발을 하는데 있어서 필요한 요소들이다.</p>
<h2 id="사소한-차이가-명품을-만든다"><a href="#사소한-차이가-명품을-만든다" title="사소한 차이가 명품을 만든다"></a>사소한 차이가 명품을 만든다</h2><p>여러 개발자를 만나다보면 생각보다 많은 개발자가 개발 고수에 대한 잘못된 환상을 가지고 있다는 생각을 하게 되었다. 개발 고수는 남들이 잘 모르는 특별한 기술을 가지고 있다고 생각하는 것이다. 그래서 자신도 언젠가 그런 고수를 만나 마치 무협지에서 은거하고 있단 무림 고수를 만나 아무에게도 전수되지 않은 무공을 습득하는 모습을 기대한다. </p>
<p>하지만 현실에서의 고수는 그런 모습이 아니다. 누구나 머리로는 알고 있지만 여러 이유로 하지 않는 아주 작고 사소한 것들을 당연한 듯이 해나가는 사람이다. 요리 경력이 40년이 넘은 중식 전문 쉐프인 이연복 쉐프가 자신의 노하우가 담긴 레시피를 공개하는 것을 보고 누군가가 레시피를 다 가르쳐줘도 되냐는 질문에 그는 다음과 같이 대답한다.</p>
<p><img src="https://wonderer80.github.io/images/chef.jpg" alt="고수의 여유" title="게으른 사람은 안 해요"></p>
<p>식당을 창업하기 위해 레시피를 최소 수백에서 수천만원의 돈을 주고 구매한다고 한다. 그럼에도 불구하고 이연복 쉐프가 자신의 레시피를 공개하는 이유는 자신의 요리의 가치는 단순히 레시피에서 오는 것이 아니라 오랜 세월동안 다져진 본인의 역량에서 온다는 것을 알기 때문일 것이다. </p>
<p>나는 개발자의 역량을 향상시키기 위해서는 항상 내가 하는 일과 맞닿아있는 부분 안에서 새로운 것을 찾아내고 시도해야 한다고 생각한다. 내가 실제로 사용하지 않는 기술 지식을 공부하는 것은 교양의 측면에서 도움이 될 수는 있으나 내 기술이 되기는 어렵다. 초보자 딱지를 벗고 나면 무엇이든 만들 수 있겠다는 자신감이 들지만 그게 끝이 아니다. 명품과 짝퉁의 차이는 생각보다 아주 작은 차이에서 온다. 그 한없이 작고 사소한 것의 차이들이 누적되어 발휘되는 결과이다. 언제든 내가 마음만 먹으면, 혹은 어떤 환경이 주어지면 할 수 있다고 생각한 많은 것들은 착각이다. 그런 상황은 오지 않는다. 뛰어난 개발자는 어떠한 상황인지를 따지지 않고 그냥 해내는 사람이다. 그리고 지식이 아니라 결과를 통해 피드백을 받고 학습하게 된다. </p>
<p>그동안 이런 저런 핑계로 머리로는 알고 있었지만 실천하지 않고 있었던 것들이 있었는가? 혹은 이제는 더이상 내가 다루고 있는 기술 스택이나 도메인에서 배울 부분이나 개선할 부분이 없다고 생각하지는 않았는가? 이 글을 통해 자신을 되돌아보는 기회가 되면 좋을 것 같다.</p>

    </article></div>

wonderland

당신이 아무리 공부해도 개발 실력이 늘지 않는 이유
지식은 기술이 아니다
백엔드 개발자 4년 차인 A 씨는 퇴근 후에 자기 개발을 위해 기술 도서를 꾸준히 읽는다. 최근에는 리팩토링이라는 책을 읽고 사내의 개발자들에게 자신이 공부한 것에 대해 발표도 했다. 하지만 아쉬운 점도 있다. 마음만 먹으면 언제든 리팩토링 할 수는 있지만 항상 바쁜 일정 때문에 리팩토링 할 시간이 없다. 사실 지금도 그럭저럭 잘 돌아가고 있는데 리팩토링을 한다고 새로운 비지니스 가치가 더해지는 것도 아니니 그 시간에 새로운 기능을 하나 더 만드는게 낫지 않나 싶기도 하다.
이전엔 테스트주도개발이라는 책을 읽고 실무에 적용해보려고 했지만, 이 역시 막상 실무에 사용해보려고 하니 시간이 너무 많이 걸려서 실효성이 없어 보였다. Ruby on Rails로 유명한 DHH 가 ‘TDD 는 죽었다‘ 라는 글을 썼다는 걸 보니 실제로 실효성이 없는 것 같다는 생각도 들었다. 
개발자 A 씨는 리팩토링과 TDD 에 대해 어느 정도의 기술(skill)을 가지고 있을까? A 씨는 지식은 풍부하지만 기술을 가진 것은 아니다. 왜냐하면 기술은 지식 자체에서 오는 것이 아니라 지식에 기반하여 훈련하고 실행하는 과정에서 습득되는 것이기 때문이다. skill 에 대한 영영사전에 의미를 보면 다음과 같다.
an ability to do something well, especially because you have learned and practised it
practise는 practice 와 같은 의미인데 연습하다, 훈련하다의 의미를 지니고 있다. 기술은 훈련과 실천의 과정에서 습득되며 기술로서 활용될 때 가치를 얻게 된다. 그래서 나는 우리 팀원들에게 항상 ‘지식은 기술이 아니다’ 라는 이야기를 꼭 한다.
규율 * 기술 = 역량
Management 3.0 에 ‘규율 * 기술 = 역량’ 이라는 내용이 있다. 개인적으로는 무릎을 탁치게 하는 공식이라고 생각했다. 앞에서 분명 지식은 기술이 아니라고 했다. 그럼 기술만 있으면 전문가로서의 역량이 뛰어나다고 볼 수 있을까? 그것만으로는 뭔가 좀 부족하다. 엔진 점검을 자주 잊어버리는 조종사, 손씻기를 뺴먹는 외과 의사, 도마나 칼을 제대로 닦지 않는 요리사는 어떤가? 저런 부분들은 기술도 아니고 한 두번 깜박한다고 당장 큰일이 생기지는 않을 것이다. 하지만 이런 부분들이 전문가들은 중요한 규율 중에 하나라는 것을 잘 알고 있기 때문에 의식하지 않아도 자연스럽게 행할 수 있도록 노력한다. 
개발자들에게 있어 규율은 어떤 것들이 있을까? 언어나 팀에서 지정한 컨벤션을 준수하거나, 개발한 내용에 대한 테스트 수행, 클린 코드를 위한 네이밍 규칙, 사용하지 않는 코드나 주석의 제거, 불필요한 임시 변수의 할당 등 여러가지가 있을 것이다. 이것들은 기술이라고 볼 수는 없지만 좋은 품질의 개발을 하는데 있어서 필요한 요소들이다.
사소한 차이가 명품을 만든다
여러 개발자를 만나다보면 생각보다 많은 개발자가 개발 고수에 대한 잘못된 환상을 가지고 있다는 생각을 하게 되었다. 개발 고수는 남들이 잘 모르는 특별한 기술을 가지고 있다고 생각하는 것이다. 그래서 자신도 언젠가 그런 고수를 만나 마치 무협지에서 은거하고 있단 무림 고수를 만나 아무에게도 전수되지 않은 무공을 습득하는 모습을 기대한다. 
하지만 현실에서의 고수는 그런 모습이 아니다. 누구나 머리로는 알고 있지만 여러 이유로 하지 않는 아주 작고 사소한 것들을 당연한 듯이 해나가는 사람이다. 요리 경력이 40년이 넘은 중식 전문 쉐프인 이연복 쉐프가 자신의 노하우가 담긴 레시피를 공개하는 것을 보고 누군가가 레시피를 다 가르쳐줘도 되냐는 질문에 그는 다음과 같이 대답한다.
식당을 창업하기 위해 레시피를 최소 수백에서 수천만원의 돈을 주고 구매한다고 한다. 그럼에도 불구하고 이연복 쉐프가 자신의 레시피를 공개하는 이유는 자신의 요리의 가치는 단순히 레시피에서 오는 것이 아니라 오랜 세월동안 다져진 본인의 역량에서 온다는 것을 알기 때문일 것이다. 
나는 개발자의 역량을 향상시키기 위해서는 항상 내가 하는 일과 맞닿아있는 부분 안에서 새로운 것을 찾아내고 시도해야 한다고 생각한다. 내가 실제로 사용하지 않는 기술 지식을 공부하는 것은 교양의 측면에서 도움이 될 수는 있으나 내 기술이 되기는 어렵다. 초보자 딱지를 벗고 나면 무엇이든 만들 수 있겠다는 자신감이 들지만 그게 끝이 아니다. 명품과 짝퉁의 차이는 생각보다 아주 작은 차이에서 온다. 그 한없이 작고 사소한 것의 차이들이 누적되어 발휘되는 결과이다. 언제든 내가 마음만 먹으면, 혹은 어떤 환경이 주어지면 할 수 있다고 생각한 많은 것들은 착각이다. 그런 상황은 오지 않는다. 뛰어난 개발자는 어떠한 상황인지를 따지지 않고 그냥 해내는 사람이다. 그리고 지식이 아니라 결과를 통해 피드백을 받고 학습하게 된다. 
그동안 이런 저런 핑계로 머리로는 알고 있었지만 실천하지 않고 있었던 것들이 있었는가? 혹은 이제는 더이상 내가 다루고 있는 기술 스택이나 도메인에서 배울 부분이나 개선할 부분이 없다고 생각하지는 않았는가? 이 글을 통해 자신을 되돌아보는 기회가 되면 좋을 것 같다.

당신이 아무리 공부해도 개발 실력이 늘지 않는 이유

댓글