어느덧 지금 다니고 있는 회사에서 일한지 1년이 지나갔고 나는 '2년차' 개발자가 되었다.
지난 1년을 키워드 하나로 표현해보자면 이것일 것이다.
임포스터 증후군
자기 자신을 자기 자신을 실력있는 사람들 사이에 운으로 들어온 사기꾼이라고 생각하며, 자신의 '사기 행각'이 드러나 큰 해를 입을 것이라고 불안해하는 현상이라고 한다.
그도 그럴 것이 처음으로 합류한 회사가 경력직 위주로 채용하는 회사였고, 실제 지금까지도 팀내에서 가장 연차가 낮다. (가장 어리진 않지만..)
하지만 정말 운좋게도 좋은 팀원들을 많났고, 특히 정말 적극적으로 도움을 많이 주시는 사수격 팀원분을 만나 빠르게 적응할 수 있었다.
하지만 그것과 별개로 '나는 팀내에서 내 역할을 잘하고 있는가?', '더 나은 개발자가 되려면 어떻게 해야할까' 같은 고민들이 마음 속 구석에서 해소되지 않은채 찝찝하게 남아있었다.
이런 고민 속에서 김창준님의 '함께 자라기' 라는 책을 접했고, 책을 정독하며 그동안 들었던 고민에 대한 답변을 받을 수 있었고 성장의 방향을 재정립할 수 있었다. 본인이 느낀 고민에 대해 책을 통해 어떤 답변을 받았는지, 또는 인상 깊었던 내용들을 공유하고자 한다.
연차에 관하여
개발자 채용 공고에서 항상 빠지지 않는 항목이다. 'n년차 이상'. 그렇다면 과연 연차는 채용에 있어서 효과적인 지표일까.
책에선 채용 시 가장 효과적인 예측변수를 측정하는 연구를 소개한다.
사람을 뽑을 때 뭘 봐야 잘 뽑았다고 소문이 나는지에 대한 연구입니다.
- 비효과적인 변수: 연차, 학력
- 효과적인 변수: 작업 샘플 테스트(사전과제), 아이큐 지능 테스트, 구조화된 인터뷰, 성실성, 성격 테스트
결과적으로 연차는 크게 중요하지 않다는 것이다. 하지만 연차가 완전히 의미가 없는 것은 아닌게, 경력이 얼마 되지 않았을 때 몇 년간은 연차의 상관성은 꽤 높은 편이라고 한다. 대부분의 IT 회사에서 3년차 이상을 선호하는 이유이지 않을까.
아무튼 연차가 조금이라도 높아지면 그 상관성은 곤두박칠치게 되고, 책에서는 단순히 높은 연차는 본인의 실력을 보장해주지 않고 진정한 실력향상을 위해서는 '의도적 수련'이 필수적이라고 말한다.
컴퓨터로 대체되기 힘든 일
no-code, copilot 같은 개발자들의 밥줄을 위협하는 기술/도구 들이 나올 때마다 괜히 걱정이 든다.
책에서는 옥스퍼드 대학교에서 머신러닝 연구자들을 데리고 어떤 직업이 컴퓨터로 자동화가 가능한지 평가한 연구를 소개한다.
재밌는 것은 소프트웨어 개발 직군을 다음과 같은 차이로 2가지로 분류했다는 것이다. (명칭은 중요하지 않다)
- 소프트웨어 개발자: 사용자의 요구사항을 분석하고 그에 대한 솔루션을 설계하는 사람
- 컴퓨터 프로그래머: 스펙대로 코드를 만드는 사람
이때 소프트웨어 개발자는 702개의 직업 중 컴퓨터화될 확률이 낮은 직업으로 130등이고, 컴퓨터 프로그래머는 293등으로 컴퓨터화될 확률이 꽤 높은 편이다.
컴퓨터 프로그래머는 다른 사람이 준 스펙대로 개발하는 것으로 그 과정에서 협상, 설득이 크게 필요하지 않다. 반면에 소프트웨어 개발자는 뭘 만들지를 고민하고 설계하는 부분이 포함되며, 그 과정에서 타인과 상호작용하는 업무가 많다.
즉 앞으로 살아남는 개발자가 되기 위해선 설계 및 타인과 인터렉션 능력이 필요하다. 개발자의 인터렉션 능력은 책 전반에 걸쳐 계속 강조한다.
의도적 수련의 조건
본인의 역량 향상을 위해 다양한 것들을 시도해볼 수 있겠다. (언어 공부, 토이 프로젝트, 관련 서적 읽기, 알고리즘 공부 등등...)
모두 의도적 수련이 될 수 있겠지만 필요한 조건들이 있다.
- 타당성
- 직관이 적용되는 영역에 어느 정도 인과관계와 규칙성이 존재해야 한다. 예를 들어 포커는 타당성이 있지만 주사위 던지기는 타당성이 없다.
- 피드백
- 자신이 내린 직관적 판단에 대해 빨리 피드백을 받고 이를 통해 학습할 기회가 주어지는 환경이 갖춰져야 한다.
- 적절한 난이도
- 실력과 난이도가 엇비슷하게 맞아야 인간이 몰입을 경험하고 이를 통해 퍼포먼스와 학습 능력이 최대치가 된다.
실수는 예방하는 것이 아니라 관리하는 것이다
본인이 일하면서 가장 자존감이 곤두박칠 칠때는 내 실수로 인하여 서비스에 장애가 발생할 때였다.
물론 라이브 배포에 앞서 내부 테스트, QA 과정을 거치므로 실제 서비스에서 장애가 발생하는 경우는 드물었지만,
입사 초반에는 QA 테스트에서 이슈가 발생하도 심하게 자책을 했던 때가 있었다. 지금도 실수를 하면 스스로를 많이 채찍질 한다.
책에서는 실수의 발생은 필수 불가결하며, 전문가들도 실수에 대해 자유롭지 못하다고 말하고 있다. 그렇기 때문에 실수를 예방하는 것보다는 어떻게 관리해야하는지가 더 중요하다는 것이다.
가령 실수가 발생했을때,
- 나쁜 결과가 되기 전에 일찍 발견하고 빨리 고치는 것
- 학습을 통해 다음 행동할 때는 이렇게 하자 는 계획을 세우는 것
이 실수를 관리하는 태도이다.
진정한 개발 고수
내 상상 속의 개발 고수의 모습은 개발 지식이 매우 뛰어난 사람이었다. 본인 전문 도메인에 대해 매우 해박하고, 몰입하여 어쩌면 약간 geek 스러운 모습이 있는 사람을 개발 고수라고 생각하고 있었다.
하지만 벨 연구소에서 수십 년에 걸쳐 진행한 뛰어난 연구자의 특성에 대한 연구 결과에서는, 뛰어난 연구자와 그렇지 않은 연구자를 가르는 결정적인 요인 중 하나는 사회적 자본 (소셜 네트워크)의 차이었다고 한다. 뛰어난 연구자는 같은 부탁들 해도 훨씬 더 짧은 시간안에 타인의 도움을 받았다.
또한 최근 소프트웨어 공학에서 이뤄진 연구의 결과에 따르면, 뛰어난 소프트웨어 개발자일수록 타인과 인터렉션에 더 많은 시간을 쓰며 초보 개발자들에게 조언을 할때 사회적인 측면을 함께 고려하는 개발자라고 한다.
사회적 기술을 훈련한다는게 막막할 수도 있지만, 당장 주변 사람들과 매일 주고받는 인사, 지나가는 대화, 물어보기 등에 신경을 쓰고, 더 나아가 기록하고, 복기하고, 다르게 인터렉션한다고 하면 어떻게 했으면 좋았을까를 생각해 보는 것만으로 훈련이 된다고 한다.
감정을 배제할 수 없다
개발자라면 항상 데이터를 기반으로 이성적이고 논리적으로 설득해야 한다라는 생각을 갖고 있었다. 더 타당한 데이터를 근거로 내 말이 맞음을 전달하는 것이 설득이라고 생각하고 있었다.
하지만 논리적이라는 것도 결국 상대적이다. 그리고 논리랑 감정적 판단을 분리할 수가 없다. 감정과 의사결정을 연결하는 특정 뇌 영역에 손상을 입은 환자들을 연구한 결과 우리는 의사결정을 하는 과정에 감정적이고 직관적인 부분이 큰 역할을 하고 있으며, 그런 감정적 부분이 배제된다면 의사결정을 제대로 할 수 없다라는 사실이 밝혀졌다.
남을 설득하려면 논리성과 객관성에 대한 환성을 버려야 합니다. 그래야 현실적으로 설득이 가능합니다. ... 출발은 결국 내가 설득하려는 사람에게서 하는 것입니다. 자료에서 출발하는 것이 아닙니다.
설득을 하기 위해서 '객관적' 자료를 모으는 부분 이상으로 상대를 이해하는 데 많은 시간을 투자해야 한다.
실제 전문가가 일하는 방식
진정한 전문가라면 설계부터 구현까지 철저하게 계획하고 단계적으로 일을 진행하지 않을까?
실제 연구에선 뛰어난 팀들은 삼투압적 의사소통을 한다고 한다. 삼투압적 모형에서는 은연 중에 서로 간에 정보가 스며든다. 예를 들어 프로그래밍하다가 '이거 안되는데 아는 사람?' 라고 외치면 테이블 건너편의 디자이너가 답을 해주고, 기획자가 우연히 듣고 끼어들며 새롭고 가치 있는 정보를 주는 것이다.
더 높은 품질을 얻기 위해서는 분석-설계-구현-테스트-전개 단계를 계속 반복하는 것이 필요하다. 어느 한 단계를 한번에 완료하는 것은 더 낮은 품질로 가는 지름길이다. 각 단계를 얼마씩 배치할까를 고민하지말고, 어떻게 해야 각 단계를 모두 왔다갔다할 수 있을까를 고민해야 한다.
애자일의 씨앗
애자일을 한 문장으로 압축한다면 다음과 같이 표현할 수 있다.
고객에게 매일 가치를 전하라
우선 고객을 정의할 수 있어야 하고,
피드백을 받는 빈도가 높아야 하고,
실제로 가치를 생성하고 있는지를 점검해야하는 것이다.
후기
지난 1년간 본인이 겪은 가장 큰 성장은 기술적인 성장이다. 다양한 기술 스택을 접할 수 있었고, 사용하고 있는 기술 스택의 장/단점을 파악하여 어떤 상황에서 사용해야 하는지 의견을 낼 수 있다. 또한 팀원들의 코드 리뷰를 통해 단련되어, 생산성 있는 코드를 작성할 수 있는 능력을 함양했다. (물론 주관적인 판단이다)
다만 본인이 취약하다고 생각했던 부분은 커뮤니케이션이었고, 실제로 가장 큰 스트레스였다. 성향상 남들 앞에서 말하는 것을 좋아하지 않고 잘하지 못한다. 커뮤니케이션이 잘 안될때마다 '개발자는 개발만 잘하면 되지..' 라고 자기합리화 했다. 이러한 생각들을 책을 통해 반성할 수 있었고, 앞으로 나아가야할 방향을 재설정할 수 있었다.
위에서도 말했듯이 위 내용들은 본인이 평소에 고민했었거나, 인상 깊었던 내용들을 위주로 적은 것이며 책에서는 훨씬 더 많은 내용들을 다룬다. 성장에 관심이 많고 고민이 있는 사람이라면 꼭 한번 읽어보는 것을 추천한다.