시뻘건 개발 도전기

개발자의 학습 태도 본문

기타/기타

개발자의 학습 태도

시뻘건볼때기 2020. 10. 5. 23:57
반응형

  본 글은 소프트웨어 학습 태도를 읽고 참고하여 개인적인 생각과 경험을 바탕으로 작성한다.

 

1. 내가 걷는 속력과 방향을 인지하자.

  개발은 혼자 하는 것이 아니다. 같은 팀원, 타 팀원, 그리고 관리자와 함께 진행한다. 이렇게 많은 사람들과 함께 업무를 진행하면서 각각 업무량도 다를 것이고 각자 일처리 속도와 습득속도 등 차이점이 있을 수 있다. 특히 일처리 속도에 대해서는 개발방향을 잘못 잡거나 필요한 기술 학습에 대해 잘못 접근하는 등에 이유로 인해 필요 이상으로 시간을 낭비할 수도 있다. (물론 언젠가는 도움이 될 수도 있겠지만 당장 처리해야하는 업무 관점에서 볼 때는 시간낭비)

  문제 해결을 위해 방안을 몰색하고 방안을 구현하기 위해 필요한 부분들을 학습하여 내가 맞닥뜨린 문제와 일관성이 있는지 판단해야한다. 이 부분은 몇 번이고 반복될 수 있다.

 

2. 익숙한 것을 내려놓고, 낯선 방식으로 해결하자.

  항상 문제는 익숙한 곳에서 발생한다. 내가 직접 직장 업무에서 발견된 몇몇 문제점은 내가 7-8년 동안 너무나도 익숙하고 당연했던 부분에서 발생했다. 익숙함에 대한 리스크가 너무 큰 나머지 새로운 것들을 받아드리기 시작했다.

  내 자신이 학습하고 이해하고 누군가에게 설명하는 과정까지의 방식 전부를 바꿔보았다. 항상 "넌 너무 빨라"라는 이야기를 해주시는 몇몇 분이 계신다. 빠르지만 정확하지 않은 것이 가장 큰 단점이고 난 그 것을 인지했다. 그래서 처음부터 차근차근 속도를 늦추고 정확하고 깊게 학습하려고 노력했다. 일부로 익숙한 방식으로 하지 않았고 새로운 방식으로 시작했다. 이 블로그를 처음 만든 이유도 바로 이 것이다. 아직은 서툴지만 문제점이 줄어드는 것이 느껴지고 있다.

  이를테면 개발 툴 또는 code editor 을 바꿔보거나, build tool을 바꿔도 보는 등 할 수 있는 것들이 많다. 물론 새로운 방식을 받아드리면서 학습이 필요할 것이다. (알고 사용하려면)

 

3. 개구리를 해부하지 말고, 직접 만들어봐라.

  docs, API 등을 참고하여 코드를 하나하나 다 까서 보면서 학습하는 것도 방법이 될 수 이따. 마치 학창시절 때 교과서와 참고서만 주구장창 외우던 시절처럼. 내가 학습하고 있는 바로 그 것을 완벽에 가깝게 오로지 나의 코드로 만들기 위해서는 그 누구보다 잘 알고 있어야 가능할 것이다.

  아주 예전에 만들어진 서버를 지금 우리가 사용하는 프레임워크 버전으로 포팅 작업이 있었다. 그러나 그 누구도 엄두를 내지 못한다. 덩치가 작은 서버도 아니었을 뿐더러 핵심 역할을 하는 서버이기도 하였고, 당시 개발자가 한 분도 남아있지 않았기 때문에 잘 알고 있는 현 재직 개발자가 없어서다. 그만큼 직접 만들어보는 것 만큼 확실하고 깊은 학습 방법은 없을 것같다.

 

4. 자존심을 버리고, 자존감을 키우자.

  주니어 개발자의 직장 생활처럼 나는 자존감이 매우 낮았다. 물론 자존심도 없었다. 대학 시절때도 마찬가지였고, 어딜다고 나보다 어린 친구들의 능력은 항상 나보다 훨신 뛰어났다. 그럴 때마다 자존심이 상했다. 나는 열심히 뛰었는데 누군가는 택시를 타고, 비행기를 타고 가는 것처럼.

  자존심을 내새우는 것은 바보같은 짓이다. 남들과 비교하면서 채찍질을 하는 것은 나의 자존심만 높이고 자존감은 바닥을 기어다니게하는 원인이된다. 비교대상은 항상 자기자신을 삼아보자. 어제보다 오늘 무언가 더 알았다면 성장한 것이고, 내일 할 계획이 있다면 가능성이 있다는 증거다.

 

5. 결과만 보기보다는 과정을 보자.

  개발은 무에서 유를 창조하는 것 혹은 문제를 해결하여 새로운 방안을 구현하는 것이다. 그렇기 때문에 많은 이들이 결과가 전부인 것 마냥 이야기를 한다. "와 너가 그거 개발했어? 대박이다!", "이거 너가 개발한거야? 쫌 하는데?" 등과 같은 이야기를 많이 들었다. 그들은 내가 어떻게 개발했는지는 중요하지 않았다.

  개발 업무를 진행할 때 문제해결을 위한 방안, 판단, 추론, 비교, 설득, 전달, 소통 등의 과정이 있을 것이고, 설계, 테스트, 리뷰, QA, 협업 등과 같은 과정도 포함될 것이다. 코드는 극히 일부분일 뿐이다. 결과물도 중요하지만, 업무 과정을 얼마나 적합하게 잘 하는가?에 대한 해답도 중요하다. 함께 일하고 싶은 개발자가 되는 것은 굉장히 어려운 일일 수 있다. 

 

6. 실수를 반복하면서 적어도 하나씩 개선하라.

  완벽한 사람은 없다. 우리 모두가 완벽해지려고 노력할 뿐이고 완벽에 가깝게 업무를 볼 뿐이다. 누구나 실수를하기 마련이다. 하지만 모두가 그 실수를 반복하는 것이 문제가 된다. 내가 나의 실수를 인지했을 때 바로 캐치하여 고치려고 노력해야한다. "다음엔 안그러겠지" 하다가 결국 그 것이 실력이 되버리기 마련이다.

  실수를 두려워하지 말자. 누구나 다 하는 실수 나도 하는 것이다. 그 실수를 잡아 다신 같은 실수를 반복하지 않는 것이 중요할 뿐이다. 실수는 하지 않는 것이 아니라 관리하는 것이다.

  실수를 반복하지 않기 위해 어떤 액션을 취해야하는지 곰곰히 잘 생각해보고 알아보자. 이 것 또한 성장의 큰 힘이 될 수 있다.

 

7. 스스로 여러가지 답을 찾고, 남에게 공유하라.

  개발은 답이 없다. 하나의 답을 찾아 느낌표를 찍지 말자. 여러 개의 답을 찾아 토론을 통해 최적의 해답을 찾을 뿐이다. 개발자는 말랑말랑하고 유연한 사고방식을 가질 필요가 있다. 닫혀버린 사고방식은 그 자리에 계속 머물게할 것이다. 남에게 나의 생각을 강요하거나 잘잘못을 따지는 행위는 정말 바보같은 짓이지 내가 상대방보다 뛰어난 것이 결코 아니다.

  코드리뷰를 한다면 팀원이 짠 코드를 내 입맛대로 작성해보고 공유하는 것도 좋은 방식이 될 수 있고, 팀 내의 특정한 룰을 각자 정해서 토론하는 것도 좋은 방법이다. 토론의 결과는 답이 없다. 다만 최적의 결과물을 도출할 뿐.

반응형
Comments