🚨 이 자료는 개발자의 소프트 스킬이 아닌 하드 스킬을 이야기합니다. 또한, 성장을 강요하는 자료도 아닙니다. 이 자료는 개발자가 성장하기 위한 방법론을 이야기합니다.

기술을 다루는 다른 직업과 마찬가지로 개발자 또한 끊임없는 학습을 해야 한다. 매년 새로운 기술이 등장하고 과거로부터 존재하던 방법론 또한 현시대에 맞춰 새롭게 변화한다. 이러한 변화에 대응하기 위해서는 끊임없는 학습이 필요하다. 하지만 학습에는 시간이 필요하고 시간은 한정적이다. 따라서 개발자는 학습을 위한 시간을 효율적으로 사용해야 한다.

그리고, 주니어, 시니어를 가리지 않고 개발과 관련된 공부 혹은 업무를 하다 보면 항상 다음과 같은 고민을 하게 된다.

• 무엇을 공부해야 할까?
• 일정 계산은 어떻게 할까?
• 잘하는 개발자란 뭘까?
• 내가 공부한 것을 어떻게 활용해야 할까?
• 내가 성장하고 있는게 맞을까?

이러한 고민들은 막연하기 때문에 쉽게 불안해진다. 아쉽게도 현실은 게임이 아니기 때문에 내가 정말로 성장했는지를 쉽게 알 수 있는 방법이 없다.

오늘의 목표는 앞서나온 질문에 답할 수 있게 되는 것이다. 지금부터 하나씩 살펴보자.

전략적인 학습

우리는 어릴때부터 많은 공부법, 암기법들을 들어왔다. 단어 잘 외우는 법, 집중하는 법 등 다양한 방법이 존재하고 각종 서적, 영상으로 많은 사람들에게 소비되고 있다. 이런 것들에 대해 안좋은 시선도 많지만 결국 공부하는 시간을 효율적으로 만드는 방법을 소개한다는 점에선 이 글과 유사하다.

우리의 삶은 너무나도 바쁘다. 잠도 자야하고 밥도 먹고 일도 하고 게임도 하고 술도 마시고... 자신의 의지로 놀때도 많지만 사회적인 이유로 어쩔 수 없이 참여하는 경우도 있다. 이런 상황에서 공부할 시간을 만드는 것은 쉽지 않다. 따라서 우리는 짧은 시간 내에 많은 것을 얻기 위해 전략적인 학습을 할 필요가 있다.

시간 대비 고효율을 내기 위해 필자가 제안하는 방식은 다음과 같은 단계를 거치는 것이다.

너무 당연한 단계라 생각할 수 있다. 좀 더 자세한 내용을 살펴보자.

진단

첫 번째로 진단 단계는 내가 무엇을 공부해야 하는지를 아는 것이다. 의외로 많은 개발자들이 이 단계에서 막히는 경우가 많다. 특히 시니어가 될 수록 내게 부족한 것이 무엇인지, 앞으로 무엇을 공부해야 하는지 갈피를 못잡는 경우가 많다. 이럴 때는 필요한 것을 구조적으로 나눠서 판단하는 것이 편하다.

개발의 세 가지 영역

필자는 개발자에게 필요한 하드 스킬에 대한 능력을 세 가지로 구분했다.

이 세 가지 능력은 커뮤니케이션이나 비즈니스 능력, 그 외 전문 지식을 제외한 개발 능력만 말한다. 필자는 이 세 가지 능력이 합쳐져서 개발자 개인의 종합적인 능력이 나온다고 생각한다. 이제 하나씩 무엇을 의미하는지 살펴보자.

사고의 영역

먼저 사고의 영역은 논리적, 추상적, 구조적 사고에 대한 영역을 말한다. 구체적으로 말하자면 '이치에 맞는지, 올바른 순서로 생각할 수 있는지, 비슷한 관점으로 묶고 중복 없이 배치할 수 있는지'라고 볼 수 있다. 즉, 사고의 영역은 어떤 문제에 대해 방법론이나 패러다임 기반으로 작게는 코드 레벨에서부터 크게는 대규모 시스템까지 설계할 수 있는 능력을 말한다. 개인적으로 필자는 사고의 영역이 개발자로서의 정체성이자 가장 중요한 영역이라고 생각한다.

기술의 영역

기술의 영역은 특정 언어나 프레임워크를 잘 다루거나 생각한 것을 그대로 코드로 잘 옮길 수 있는 능력을 말한다. 간단하게 표현하자면 도구를 사용하는 숙련도라고 볼 수 있다. 비유하자면 망치 잘 쓰는 법, 톱 잘 쓰는 법과 비슷한 영역이라 할 수 있다. 우리는 망치가 어떤 원리로 유용한지 몰라도 망치를 잘 사용할 수 있다. 코드를 작성하는 것도 마찬가지다.

과학의 영역

과학의 영역은 말 그대로 컴퓨터 과학에 대한 지식을 말한다. 주로 우리가 학생 때 배우는 하드웨어 시스템, 네트워크, 운영체제, 그래픽스, 암호학 등 이론적인 공부가 필요한 영역을 말한다.

컴퓨터 과학 지식은 개발자의 직관에 큰 도움이 된다. 특히 디버깅할 때 도움이 되는 경우가 많은데 문제를 해결하기 위한 긴 시간 삽질하던 도중 **혹시 이건가?**라는 생각이 들 때가 있다. 이런 부분은 대체로 메모리, 스레드, 네트워크 등의 문제일 가능성이 높다. 만약 컴퓨터 과학 지식이 없다면 이런 생각을 하지 못할 것이다. 그렇기 때문에 컴퓨터 과학 지식은 개발자에게 있어 문제 해결을 위한 직관을 키우는 데 큰 도움이 된다.

시너지 효과

앞서 소개한 세 가지 영역은 독립적인 것이 아닌 서로에게 영향력을 준다.

예를 들어, 사고의 영역과 기술의 영역이 묶이면 내가 사고한 것을 코드로 작성하는 것이라 볼 수 있다. 이는 사고의 흐름이 실제 코드 작성에 도움을 주는 것인데, 반대로 생각해 볼 수도 있다. 내가 기술을 잘 알고 있다면 사고의 영역을 단순하게 만드는 것도 가능하다. 예를 들어, 우리가 웹 서버 애플리케이션을 만들 때는 보통 프레임워크를 사용하기 때문에 요청을 어떻게 받을지, 응답을 어떻게 할지에 대해 고민하지 않는다. 이는 프레임워크를 통해 추상화된 것을 사용하기 때문에 구체적으로 사고하지 않아도 되기 때문이다. 흔히 농담으로 말하는 몸이 좋으면 머리가 편하다 같은 것이라 볼 수 있다.

사고와 과학의 영역도 마찬가지다. 만약 우리가 컴퓨터 과학에 대한 지식이 없다면 논리 과정에서 미처 빼먹은 예외가 있을 수 있다. 즉, 논리적으로 맞더라도 컴퓨터 과학적으로 틀릴 수 있다는 말이다. 예를 들어, 우리가 두 수를 더하는 함수를 만든다고 가정하자. 이 함수는 두 수를 더한 결과를 반환한다. 이 함수는 논리적으로는 맞지만 컴퓨터 과학적으로는 틀릴 수 있다. 만약 두 수의 합이 32비트 정수의 최댓값을 넘어간다면 문제가 발생한다. 따라서 컴퓨터 과학적으로는 틀린 것이다. 이런 단순한 사례가 아니더라도 컴퓨터 과학적 지식이 누락되어 생기는 결함은 생각보다 자주 발생한다.

의외로 기술과 과학의 영역도 서로 영향을 준다. 두 영역이 만나면 최적화라는 것이 나온다. 우리는 시간복잡도나 공간복잡도를 이용하여 코드의 성능을 평가할 수 있다. 그리고 더 깊이 들어가면 컴퓨터 구조나 네트워크 등의 지식을 이용하여 더 효율적인 코드를 작성할 수 있다. 결국 컴퓨터 과학적 지식을 통해 기술을 더 갈고닦을 수 있게 된다.

부족한 부분 파악하기

결국 앞서 소개한 세 가지 영역은 전부 중요하다. 우리가 골고루 편식하지 않고 학습해야 하는 이유기도 하다. 이제 이 세 가지 영역에서 내가 부족한 부분이 어떤 것인지를 파악해야 한다. 어떻게 할 수 있을까? 다음과 같이 단순하게 생각해 보자.

• 문제를 보고 로직을 설계하기가 어렵다면
  • 프로그램의 흐름을 파악하고 설계하는 사고 능력이 부족
• 생각한 것을 실제로 구현하기가 어렵다면
  • 코드로 구현하는 기술 능력이 부족
• 구현 후 성능이나 알 수 없는 문제가 생겼다면
  • 컴퓨터 과학에 대한 지식 부족. 만약 특정 지식을 요구하는 논리나 설계를 이해하기 힘들었다면 이쪽에 해당

우리는 학습하거나 일을 할 때 위와 같은 상황을 종종 접한다. 이런 상황이 반복된다면 내가 부족한 부분이 무엇인지 파악할 수 있다.

학습

부족한 부분을 알았다면 이제 학습을 통해 채워나가야 한다. 각 영역을 어떻게 학습하는 게 좋을까?

사고의 영역

먼저 사고라는 것은 단순히 공부를 많이 한다고 얻을 수 있는 것이 아니다. 책을 읽거나 다양한 사례를 체험하는 것을 통해 간접적으로 얻을 수는 있지만 직접적인 도움이 되지는 않는다. 필자가 생각하기에 제일 좋은 방법은 항상 의심하고 비교하고 분석하는 것이다.

• 무언가를 봤을 때 왜 저렇게 동작해야하는지 의심하기
• 저 방식이 다른 것과 어떤 차이가 있는지
• 어떤 원리로 동작하는지 분해하고 분석하기

위와 같은 방식으로 대상을 발견했다면 단계적 구조화, 추상화를 할 수 있다. 이는 사고의 영역을 향상하는 데 큰 도움이 된다. 좀 더 구체적으로 말하자면 대상에 대해 Top-Down으로 분해하거나 Bottom-Up으로 구체화하는 것이다. 예를 들면 다음과 같이 사고할 수 있다.

• 사용자는 로그인한다.
• 사용자는 브라우저를 통해 서버로 로그인 요청을 보낸다.
• 사용자는 로그인 페이지에서 Login 버튼을 클릭하면 요청을 보내고 로딩을 보여준다.
• Login 버튼을 클릭하면 바인딩된 onClick 이벤트가 실행되면서 로그인 API를 호출한다.
• ...

위 사례는 Top-Down 방식으로 로그인 한다라는 것을 분해한 것이다. 우리가 무심코 지나갔던 다양한 서비스의 기능을 이런 식으로 분해하고 분석하면 사고의 영역을 향상하는 데에 큰 도움이 된다.

만약 추상적, 구조적 사고에 더 관심이 있다면 필자가 이전에 발표했던 소프트웨어 설계를 위한 추상적, 구조적 사고를 참고하는 것을 추천한다.

기술의 영역

기술은 언어나 라이브러리, 프레임워크 같은 도구를 잘 이용하는 법이다. 코드를 잘 짜는 연습을 하고 싶다면 최대한 많이 코드를 작성하는 것이 중요하다. 효과적인 다른 방법이 있을 수 있지만 우선 하는 것이 중요하다. 필자는 개인적으로 코딩 테스트를 위한 문제를 풀어보는 것이 도움이 된다고 믿는다. 입력 데이터를 성능이나 쉽게 이용할 수 있도록 자료구조를 이용하여 변형하고 이를 알고리즘을 통해 논리적으로 풀어나가는 과정을 겪는 것은 코드를 잘 작성하는 능력에 큰 도움이 된다.

또한 라이브러리, 프레임워크 같은 도구는 공부할 때 공식 문서를 보는 것이 가장 좋다. 가끔 예외도 있지만 보통은 만든 사람 혹은 집단이 제일 올바르게 설명한다. 그렇기 때문에 되도록 공식 문서를 통해 도구의 기본적인 개념, 철학과 사용법을 익히는 것이 제일 좋다.

그리고 남의 도움을 받지 않고 스스로 생각하는 것이 좋다라는 미신이 있다. 물론 스스로 생각해 내는 것이 큰 도움이 되는 것은 사실이지만 일반적으로 이런 방식은 효율적이지 않다. 왜냐하면 남의 도움을 받는 것은 시간을 절약할 수 있기 때문이다. 도움을 받는 것이 꼭 누군가에게 물어보고 답변을 얻는 것만을 의미하지 않는다. 다양한 오픈소스, 글, 책들을 통해 사례에 대한 해답을 얻는 것도 도움을 받는 것이다. 많은 개발자가 어려워하는 코딩 테스트도 마찬가지다. 무조건 정답을 보지 않는 것이 좋은 것은 아니다. 정답을 보고 어떤 방식으로 풀었는지, 어떤 논리로 풀었는지를 보고 스스로 생각해 보는 것도 도움이 된다. 기술은 역사가 흐르면서 쌓인 결정체라고 볼 수 있다. 그렇기 때문에 이 결정체를 최대한 흡수하는 것이 중요하다.

과학의 영역

컴퓨터 과학은 여러 분야가 있지만 대체로 기반 지식이기 때문에 외워야 하는 것이 많다. 그래서 쉽고 빠르게 익힐 방법이 없다. 그렇기 때문에 꾸준히 학습하되 나에게 어떤 도움이 되는지 알아두는 것이 중요하다. 예를 들면 다음과 같다.

• 자료구조: 현실에 있는 무언가를 컴퓨터에서 다차원으로 표현하는 사고방식을 익힐 수 있다.
• 알고리즘: 사고의 흐름을 코드로 나타낼 수 있는 능력과 성능 계산을 할 수 있다.
• 컴퓨터 구조: 컴퓨터 내부 장치의 동작 이해와 이를 통한 최적화 방법을 익힐 수 있다.
• 운영체제: 컴퓨터의 자원을 효율적으로 관리하는 방법을 익힐 수 있다.
• 네트워크: 컴퓨터 간 통신 방법을 이해하고 비동기에 대한 처리 능력을 기를 수 있다.
• 그래픽스: 컴퓨터가 어떻게 화면을 그리는지 이해하고 이를 통해 성능을 향상시킬 수 있다.
• 암호학: 암호화, 복호화 방법을 이해하고 보안에 대한 이해를 높일 수 있다.
• ...

앞서 말한 것처럼 컴퓨터 과학 지식은 당장 나에게 큰 도움이 안 되는 것처럼 느껴질 수 있지만, 추후 디버깅이나 최적화를 해야할 때 큰 도움이 된다. 1%의 문제를 해결할 수 있는 지식이 이 영역이라 할 수 있다.

패턴 학습

앞서 소개한 각 사고, 기술, 과학의 영역이 묶여 하나의 패턴화를 할 수 있다. 정말 간단하게 생각해 보면 디자인 패턴이 있다. 그리고 그것보다 더 추상화해 보면 CRUD도 있다. 이런 패턴들은 업무에서 반복적으로 사용되는 패턴이다. 패턴들을 학습하고 익히면 실제 업무에서 때 큰 도움이 된다.

패턴 학습은 의식적으로 해야 한다. 이를 위해서 다음과 같은 방법을 사용할 수 있다.

1. 패턴을 눈치채면 그 즉시 정리해서 기록하자.
   • 어 이거 이전에도 봤던 것 같은데... 같은 기시감이 느껴진다면 패턴이다.
   • 유스케이스, 설계, 컴포넌트 등 다양한 영역에서 나타날 수 있다.
2. 안 해봤던 것을 해야 한다.
   • 매일 1km만 뛰는 사람은 1km를 잘 뛸 수 있지만 10km를 뛰는 것은 어려워한다.
   • 10년 차 개발자여도 모르는 영역에선 주니어다.
3. 공개된 소스를 많이 참고하자.
   • 분석하는 과정에서 많은 패턴을 발견할 수 있다.
   • 소스를 분석하기가 어렵다면 따라 치는 것부터 시작할 수 있다.
4. 실제로 적용해 보자.
   • 일부러 찾아다닐 필요 없이 개발하다 생각나면 적용하자.
   • 보이 스카웃 규칙¹을 적용하여 리팩토링 기회를 많이 만들어보자.

참고로 패턴을 파악하고 있다면 일정 계산을 하는 것도 편해진다. 왜냐하면 패턴을 안다는 것은 이미 한 번 경험을 해봤다는 뜻이기 때문이다. 따라서 처음엔 일정 계산이 안 되는 것이 정상이지만 점점 연차가 쌓이고 경험이 쌓이면서 아는 패턴이 많아지게 되면 구현에 어느 정도 시간이 걸릴지 알 수 있다. 복잡하거나 새로운 일이더라도 경험(패턴)을 조합하면 대략적인 예상 시간을 생각할 수 있다.

잘하는 개발자란

그래서 결국 잘하는 개발자란 업계에 따라 우선시 되는 것이 있을 수는 있지만 필자가 경험하기로 세 가지 영역이 골고루 잡힌 사람이 대체로 일을 잘한다. 그렇기 때문에 하나만 집중하는 것이 아니라 골고루 공부하는 것이 중요하다.

같은 경험을 10년 동안 열 번 반복하는 것과 10년 동안 매년 서로 다른 경험을 하는 것 사이에는 어마어마한 차이가 있다. 10년 동안 다른 프로젝트, 다른 기술, 다른 회사에서 일한 것과 10년 동안 같은 회사, 같은 프로젝트, 같은 사람, 같은 기술로만 일한 것은 크게 다르다.

- 소프트웨어 장인 정신 중...

또한 가장 안좋은 사례는 하나만 잘해서 내가 잘한다고 착각하는 것이다. 이런 경우엔 커리어적으로도 문제가 생길 가능성이 높다.

산출물

앞서 보여준 도식의 마지막 부분이 산출물이다. 필자는 학습했다면 가급적 산출물이 남는 것이 가장 좋다고 생각한다. 산출물의 종류에는 여러 가지가 있을 수 있지만 회사 업무를 제외하면 지식을 정리하는 것과 무언가를 만드는 것으로 나눌 수 있다. 이 둘은 모두 지식을 나누는 것으로 개발자 커뮤니티는 지식을 나누는 것에 굉장히 관대하다. 그렇기 때문에 피드백 문화도 잘 정착되어 있다. 따라서 개발자 커뮤니티를 통해 피드백을 받으면서 성장하는 것은 매우 큰 도움이 된다.

지식을 정리하는 것

지식을 정리하는 것은 내가 추상적으로 아는 것을 더 구체화하는 과정이다. 개인적으로 메모하거나 정리하는 것도 물론 가능하지만 다른 사람에게 공개해야 한다는 불편함이 성장을 돕는다고 생각한다. 즉, 적당한 스트레스를 통해 성장할 수 있다는 것이다. 또한, 앞서 말한 것처럼 다른 사람에게 공개하면 피드백을 받을 수 있기 때문에 더욱 좋다. 따라서 공개 블로그 포스팅이나 발표 자료를 만드는 것을 추천한다.

지식을 정리할 때는 목적이 있는 것이 좋다. 단순히 내가 배운 것을 그대로 옮기거나 따라 치는 것은 사실 학습에 있어서 아쉬운 점이 많다. 예를 들면 블로그 포스팅을 할 때는 단순히 적는 것이 아닌 어떻게 사람들에게 쉽게 전달할지, 내가 배운 것에서 빠진 것이 무엇인지를 생각해 볼 수 있다. 이런 방식으로 산출물을 만들면 학습한 것을 넘어서 제대로 알고 있는지 점검할 수 있다. 이에 대한 구체적인 방법으로 파인만 학습법이 있다.

우리가 어떤 지식을 이해했다는 기준은 어떻게 잡을 수 있을까? 아인슈타인은 간단히 설명할 수 없다면 제대로 이해하지 못한 것이라고 말했다. 즉, 설명하고자 하는 개념을 전혀 모르는 사람에게 쉽게 설명할 수 있는지로 이해를 판단할 수 있다는 것이다. 내가 제대로 이해했는지 판단하고 이를 빈틈없이 채우는 방법은 다음과 같다.

1. 어떠한 주제에 대해 내가 알고 있는 모든 내용을 목록으로 나열한다.
2. 그 개념을 전혀 모르는 사람에게 초등학생도 이해할 수 있는 언어로 설명한다.
3. 설명하는 데 빈틈이 있다면 그 틈을 채우기 위해 학습한다.
4. 익힌 정보를 다시 간략하게 정리한다.

위 네 단계를 계속 반복하는 것이 파인만 학습법이다. 우리는 생각보다 추상적인 정보로 학습하기에 곰곰히 생각해 보면 원리를 모르고 넘어가는 경우가 많다. 물론 무엇이든 적정 수준이 있다. 너무 깊게 파고드는 것은 오히려 다음 단계로 넘어가는 데에 방해가 될 수 있다. 예를 들어, if 문법은 조건에 따라 실행하는 코드를 분기한다. 그런데 어떻게 분기하는 걸까? 이를 설명하기 위해선 어셈블리와 컴퓨터 아키텍처에 대한 지식이 필요하다. 하지만 이 모든 지식을 다루는 것은 시간이 걸린다. 지금 나에게 필요한 것과 목적을 생각하면서 공부를 하는 것이 더 중요하다.

사실 글을 쓰거나 발표 자료를 만들면 위와 같은 학습법이 어느 정도 자연스럽게 실행된다.

1. 대략적인 목차를 잡는다.
2. 글을 써본다.
3. 쓰다 보니 모르는 부분, 전달하기 어려운 부분이 생긴다.
4. 그것에 대해 학습하고 정리한다.

파인만 학습법과 유사하지 않은가? 생각보다 지식을 공유하는 것은 스스로 큰 도움이 된다. 또한, 개발자로서 중요하다고 생각하는 추상적이고 구조적인 능력 또한 향상할 수 있다.

무언가를 만드는 것

무언가를 만드는 것은 내가 배운 지식을 실제로 활용해 보는 경험을 하는 것이다. 지식으로 아는 것과 실제로 경험하는 것은 큰 차이가 있다. 실제로 경험해 보기 위한 방법으로 오픈소스 라이브러리 혹은 프레임워크를 만들거나 개인 프로젝트를 할 수 있다.

이를 통해 얻을 수 있는 가장 큰 것은 실제 사례를 간접 체험할 수 있다는 것이다. 간접 체험을 통해 우리는 특정 시점에 사용할 수 있는 패턴을 익힐 수 있다. 예를 들어, 디자인 패턴을 학습했더라도 실제로 사용하지 않는다면 실제 업무에서 활용하기 어렵다. 이는 실제로 사용해도 될지 모르겠는 두려움일 수도 있고 사용할 시점을 눈치채지 못했을 수 있다. 이 글을 읽는 분 중 취미로 운동을 하는 사람이 있다면 머리로 생각하기 전에 몸이 움직인다는 느낌을 받은 적이 있을 것이다. 이는 반복 학습을 통해 머리로 생각하지 않아도 자연스럽게 몸이 움직이는 것이다. 개발자와 같은 지식 노동자도 마찬가지다. 실제 체험과 반복 학습을 통한 깨달음이 있다면 지식을 머리로 생각하지 않아도 자연스럽게 코드를 작성할 수 있게 된다.

필자가 느끼기로 오픈소스를 만드는 것과 개인 프로젝트를 하는 것은 얻을 수 있는 것이 다르다. 오픈소스를 만드는 것은 다른 개발자가 내가 만든 것을 사용한다라는 목적이 있고 개인 프로젝트는 사용자가 내 서비스를 이용한다라는 목적이 있다. 이 둘은 목적이 다르기 때문에 얻을 수 있는 것도 다르다.

오픈소스를 만들 때는 다른 개발자가 사용한다는 목적이 있기에 개발자 경험을 중시하게 된다. 따라서 최대한 쉽게 사용할 수 있게 해주면서 필요한 경우 확장도 할 수 있는 아키텍처를 생각하게 된다. 사실 업무 중에 만드는 코드는 이렇게까지 생각하는 경우가 많지 않다. 사용하는 사람이 한정적이고 해당 코드가 사용되는 곳도 한정적이기 때문이다. 하지만 오픈소스는 범용적으로 사용할 수 있는 경우가 대부분이기에 그에 따른 고민을 하게 된다. 따라서 오픈소스 라이브러리 개발은 개발자로서 설계 능력을 향상하는 데 큰 도움이 된다.

반면에 개인 프로젝트는 사용자가 사용한다는 목적이 있기 때문에 사용자 경험을 중시하게 된다. 따라서 사용자가 어떻게 서비스를 사용하는지, 어떤 기능을 사용하는지 등을 고민하게 된다. 이는 개발자로서 사용자 입장을 생각해볼 수 있는 기회가 된다. 또한, 프로젝트를 통해 서비스 개발에 필요한 전반적인 경험을 해볼 수도 있다. 서비스 개발에는 다양한 지식이 필요하다. 비즈니스 로직 작성뿐만 아니라 테스트 작성, CI/CD, 배포, 가상화, 클라우드, 보안 등 다양한 것들을 고려해야 한다. 따라서 개인 프로젝트를 하는 것은 서비스 개발에 필요한 전체적인 한 사이클을 경험해볼 수 있는 좋은 기회가 될 수 있다.

성장을 확인하기

앞서 지식을 정리하거나 무언가를 만드는 것을 통해 산출물을 내놓은 것은 나의 성장에 대한 체크포인트를 만드는 행위다. 당장 만든 산출물로는 내가 얼마나 성장했는지, 내가 어느 위치에 있는지를 알려주진 않는다. 하지만 과거에 만들어진 산출물을 보면 과거와 지금을 비교했을 때 얼마나 성장했는지 알기 쉬워진다. 꼭 산출물이 아니더라도 내가 과거에 작성했던 코드가 있다면 살펴보자. 아마 높은 확률로 '내가 왜 저렇게 만들었지?'라는 생각을 하게 될 것이다. 그런 생각이 든다면 성장한 것이다.

소프트 스킬에 대하여

이 글에서는 하드 스킬만 다뤘지만 소프트 스킬 또한 개발자에게 있어서 중요하다. 특히 AI가 발전하면서 개발자의 생산성에 크게 기여할 것이라는 예측이 많다. 그렇기 때문에 앞으로 소프트 스킬은 더욱 중요해질 것이다.

소프트 스킬은 꼭 커뮤니케이션 능력만을 의미하는 것은 아니다. 업무 프로세스를 잘 만들고 관리하는 것, 회사에서 다루는 도메인 지식을 잘 파악하는 것, 다른 개발자의 생산성에 도움을 주는 것 등 직접 개발하는 것 외에 일을 잘할 수 있게 해주는 모든 것이 소프트 스킬이라 할 수 있다. 이 글에서 해당 내용을 자세히 다루지는 않지만 소프트 스킬 또한 중요하다는 것을 알아두자.

마치며

이 글은 사실 작년에 발표한 자료를 기반으로 작성되었다. 이제 와서 다시 글로 정리하는 이유는 필자 또한 올해를 마치고 다시 마음을 다잡기 위해서다. 갑작스럽게 그런 생각을 하게 된 계기는 한 해를 마치며 개인 노트 앱을 정리하던 중 글을 하나 발견했기 때문이다.

나는 직조라는 단어를 좋아한다. 씨줄과 날줄이 서로 다른 방향으로 나아가고, 그 가운데 서로 교차하고 겹치면서 엮여 가는 그 감각이 직조(織造)라는 단어에 넉넉하게 묻어난다. 이 감각은 때로는 창조와 생산이라는, 무언가를 만들어간다는 짜릿하고 생동감 가득한 기운으로 다가오기도 하고 때로는 노동과 피로라는, 한껏 달음박질을 한 뒤에 정수리부터 뒷목까지 모든 에너지가 한꺼번에 빠져 나가는듯한 고단함으로 다가오기도 한다. 살아가는 일은 그 자체로 언덕과 내리막, 평지와 진흙탕길이 교차하듯 직조되는 일이고 ‘나’라는 존재 역시, 내 생애라는 어떤 시간과 그 속에서 움직여가는 내 자신이 직조하여 만들어진다.

이 직조의 감각이 잘 어울리는 또 다른 개념으로 ‘시간’이 있다. 시간을 의미하는 그리스어는 두 가지다. 수평으로 흘러가는 연속적인 시간의 개념인 크로노스와 특정한 혹은 순간이나 주관적인 시간의 개념인 카이로스다. 개개인은 누구나 저 두 가지 시간이 직조된 총체적 시간을 살아가기 마련이다. 삶은 자기만의 주관적인 시간, 그러니까 회상이나 추억 혹은 몰입(시간을 초월하여 시간이 가는 줄 모르게 집중) 같은 카이로스와 누구에게나 똑같이 흘러가는 24시간 7일과 같은 보편적인 크로노스가 교차하며 엮어낸 양탄자 위를 달리는 일이다.

어떤 분이 작성한 글인지 모르지만, 상당히 감명 깊게 읽었고 메모했던 기억이 있다. 출처를 못 찾았다는 점이 아쉽다. 나는 스스로 시간을 잘 사용했을까? 몰입을 잘했을까? 스스로 조금 아쉬운 한 해였다고 생각한다. 그것과 동시에 이 글의 기반인 발표 자료 마지막에 했던 말이 떠올랐다.

결국 이 모든 것은 시간을 투자해야 하는 일입니다. 너무나도 당연하지만 같은 조건이라면 무조건 시간을 많이 투자한 사람이 개발을 잘합니다. 물론 힘들겠지만, 개발을 단기간에 잘하고 싶다면 그만큼 시간을 많이 투자하시는 게 좋습니다. 시간을 쓰는 것이 아닌 나를 위한 투자라고 생각해 주세요.

올 한 해엔 학생들에게 했던 말을 정작 본인이 지키지 못했던 것 같다. 스스로 부끄러움을 느끼며 올해 회고 대신 이 글로 한 해를 마무리하기로 한다.

Footnotes

1. 보이 스카웃의 '떠날 때는 더 깨끗하게 떠나라'라는 규칙을 따라 코드를 작성할 때 주위를 더 깨끗하게 만들고 떠나라는 규칙이다. ↩