초급 소프트웨어 개발자 생존전략
* 이 글은 소프트웨어 개발자이자 컨설턴트인 Rufus Raghunath가 ThoughtWorks 블로그에 올린 글 How to be a junior software developer를 번역한 글입니다.
개요
ThoughtWorks에서 초급자로 근무할 때, 나는 운 좋게도 관심 있는 프로젝트에서 재능을 키우고 발전시킬 수 있는 기회가 있었고, 이 때 놀라운 사람들의 도움을 받았다. 이 기사에서, 내가 전문성 계발을 극 대화하기 위해 사용했던 전략을 공유하고 싶다. 만약 당신이 나와 비슷한 입장에 처해 있다면, 첫 번째 기술적 성공을 이루는 데 도움이 되기를 바란다. 만약 당신이 상급자이거나 팀 리더라면, 초급을 도와 성장시키고 생산성을 높이는데 도움을 줄 수 있기 바란다. 만약 당신이 회사 관리자라면, 초급자를 고용하고 배치하는 상황에서도움을 줄 수 있기를 기대한다.
학습법 배우기
초급자로서, 당신의 주된 가치는 현재 능 력이 아니라 잠재력에 있다는 것을 깨닫는 것이 중요하다. ThoughtWorks에서 기술 인터뷰 결과 당장 어디든지 생산에 투입할 생각으로 나를 뽑은 건 아니었다. 따라서 모든 시간을 소프트웨어 생산에만 집중할 것이 아니라 기술 개발 노력도 해야 한다. 자기 성찰을 실천하여 피드백으로 자신의 약점을 파악한다. 가용한 자원을 모두 사용하여 자신의 지식과 스킬을 개선한다. 상급자들에게 도움을 청하고, 코드 리뷰와 페어 프로그램도 요청한다. 작업 중인 업무에 대한 맥락을 알려면, 비즈니스 분석가, QA, 이해 관계자들과도 대화해야 한다. 결코 중단하지 말고, '항상 배운다'는 겸손한 태도를 견지한다. 같은 결과를 낼 수 있는 다른 대안들에 대해서도 안목을 기르자.
학습법 자체도 개발해야 할 기술이다. 나는 여러 다양한 기술을 보유한 상태로 ThoughtWorks에 입사한 것은 아니었다. 그런데 내가 참여한 모든 프로젝트들은 새로운 프로그래밍 언어, 새로운 도구, 새로운 프레임워크, 그리고 새로운 개념들을 담고 있어서 나에게는 숨막히는 공포감으로 다가왔다. 이때가 바로 가면증후군 impostor syndrome[1]이 가장 강하게 드러나고 자신의 신념을 해치는 순간이다. 그 기간이 지나면 당신은 패턴을 발견하기 시작 하는데, 대충 다음과 같은 흐름을 따른다.
- 열정, 열광
- 방해, 당혹
- 피상적 이해
- 기대감이 무너지면서 좌절
- 실무 지식, 생산성
- 정리하고 반복한다.
3번째 단계가 가장 위험한데, 자신이 하고 있는 일에 실패하고 있다는 것을 모르고 있기 때문이다. 그 보다는 차라리 좌절한 후 도움을 찾아 나서는 것이, 제대로 알지도 못하면서 다량의 스파게티 코드를 좋다고 양산 하는 것 보다 낫 다. 아이러니하게도, 단계3에서는 어쩌다 '생산성'을 얻는 소득도 있 다. 단계3을 탈출하자면, 작업에 대해서는 피드백을 구하고, 모르는 문제들은 학습하자. 그 동안 했던 일들은 임시로 한번 해 보았던 것으로 받아들이자.
일단 이 순환을 몇 차례 통과하면서, 새로운 기술로 믿고 작동되는 코드를 내놓을 수 있게 되면, 당신은 '하면 된다'라는 학 습태도를 갖게 된다. 당신의 능력에 자신감을 갖게 되어, 새로운 것들을 재빨리 손에 넣고 즐기기 시작한다. 그리고 더 중요한 것은, 비즈니스 이해 관계자들에게 납득시킬 수 있는 증거를 필요 시에 제시할 수 있다는 점이다. 나는 심지어 수석 개발자들 조차도 때로는 그들의 역할이 너무 한 쪽에 치우친 나머지 소극적으로 머무는 것을 알았다. 따라서 당신은 안전지대로부터 지속적으로 나와서 새로운 것들을 배울 수 있는 상황으로 들어와야 한다. 이 경험은 초급 개발자로서는 주된 장점이 될 것 이고, 특히 당신이 컨설턴트로 일한다면 더욱 그렇다. 향후 경력 개발에 맞추어 조율해 가자.
초급시절에 가치 불리기
배우는 것은 좋은 일이지만, 어느 시점에 이르러서는 소프트웨어를 직접 만들고 인도하는 리듬을 타야 한다. 책임도 적고 위험요소도 없는 일상 업무와는 별도로, 독립분야를 찾아 볼 것을 강력히 권한다. 거기서 당신은 팀에 가치를 부여하여 pet 프로젝트[2]로 발전시킬 수도 있을 테니까.
예로서 나는 첫 번째 프로젝트에서, 백엔드에서는 C#를 사용하고, 프런트엔드에서는 React+Redux를 사용했다. 이전에 사용해 본 적이 없었기 때문에, 생산성을 내기까지 가려면 습득해야 할 것이 너무 많았다. 운이 좋게도 내가 만난 기술 리더는 작업 위임의 중요성을 잘 알고 있었다. 우리 팀에서 쓰는 핵심 결과물 사용법을 내가 배우는 동안에도 자신감과 생산성을 유지할 수 있도록 배려해 주었다. 그 때, 우리는 비주얼 스튜디오 온라인에서 불완전한 오픈 소스 빌드 모니터링 도구를 사 용하고 있었고 그것을 구현하는 것이 내가 할 과제였다.
업무 맥락 상으로, 파이프 라인이 어떻게 작동하는지도 몰랐는데 나중에 알고 보니, 모니터링 코드는 Clojure로 작성 되었고, 내가 익숙했던 객체 지향 패러다임과는 유사해 보이지만 놀랄 만한 차이가 있었다. 그래서 한달 동안 밤낮으로 클로저와는 어울리지 않는 끔찍한 코드를 만들며, Rich Hickey의 설명도 열심히 경청해야 했다. 결국, 우리 팀은 작동되는 빌드 모니터링 프로그램을 확보하게 되었고, 나 자신은 함수형 프로그래밍에 대해 애착이 생겨나고 있었다.
내가 했던 다음 프로젝트는 자바 마이크로 서비스 플랫폼을 사용했는데, Docker, Kubernetes, 그리고 Cassandra도 함께 썼다. 다시 한번, 새로운 기술 스택을 사용하였다. 이번에는 새로운 툴과 개념을 사용할 수 있도록, 상당한 기간을 할애해서 UI 를 익히는 훈련을 했다. 그리고 이전의 경험을 살려 Reflux로 구현된 민감한 업무 흐름 코드를 Redux로 마이그레이션 해야 한다고 주장할 수 있었고 그대로 실행했다. 그 결과 자바 스크립트 테스트가 편해졌고, 상속받은 코드들로 복잡성이 줄고, 속도와 안정성은 향상되었다.
두 경우 모두, 나는 시간을 들여 배우고 난 후에야 생산성이 발휘되기 시작했다. 내가 할 수 있는 일을 식별하고 나서는 팀에 실질적 가치를 제공하기 시작했다. 이들 pet 프로젝트는 우리 팀과 이해 관계자 들과의 신뢰성과 신용, 자신감을 길러준 효과와 함께, 가면증후군은 줄여 주었고, 스스로 학습하는 것을 실험할 수 있었다.
어떤 일에서나 추가로 생산해야 할 유틸리티는 있기 마련이고, 리팩토링 해야 할 것 도 많다. Pet 프로젝트를 추구하는 것은 초급자로서 자신의 개발과 팀 관계에 특별한 도움을 주기 때문에, 계속해서 갈고 닦아 야 할 습관이다. 정말 짜릿하다!
Pet 프로젝트 선택하기
유감스럽게도, 공짜로 얻는 것은 없다. 다른 것과 마찬가지로, pet 프로젝트 유용성을 얻으려면 비용을 들여야 한다. 어디서 부터 시작해야 할지 몰라, 불확실하고 혼란스러울 수는 있다. 지지를 받지 못한다 고 느끼거나, 기능을 개발해서 인도해줘야 하는 부담을 느낄 수도 있다. 계속해서 시간과 작업과 노력을 추가해야 하는 점을 걱정할 수도 있다.
경험으로, 나는 그것들이 모두 진정 타당한 도전이라는 것을 확인할 수 있다. 또한, 계속 실망할 수도 있고, 계속 일이 안 풀리는 경우도 예상해야 한다. 이러한 문제를 개선하고자 프로젝트를 선정할 때 아래 사항을 제안한다.
- 작은 규모
- 명확한 목표 ('완료' 기준 명시)
- 부가 가치/ 평가받을 만한 내용
- 홍보하면 지지해줄 가능성이 높아진다(예: 팀, 회사, 커뮤니티 등)
- 즐겁다 / 그 자체가 바로 보상이다
더 나아가서, 실패와 무지를 모두 포용한 다. 내일이면 작동될 것이라는 허황된 생각일랑 버리자. 내일이면 알게 될 거야 라는 허황된 생각도 버리자.
그리고, 물론 자기 자신에게도 시간을 잘 쓰자. pet 프로젝트를 하는 것은 도움이 되고 재미도 있지만, 월급 받는 것 보다 더 많이 하라는 얘기는 아니다. 자신에게 의미 있는 일이라고 생각될 때, 그리고 시간 여유가 있을 때 선택해서 하면 된다. 팀에 시간을 알려서 업무 시간에 pet 프로젝트를 해도 되는지 확인해 볼 수도 있다. 가치가 있는 일이라면 명백히 허용해 줄 것이다.
결론
Agile 선언에 '계획을 준수 하기보다는 변화에 대처하라'는 신조가 있다. 지속해서 개선하고, 지속해서 공급한다. 제품 버전을 생성한 후, 결함을 관찰하고, 피드백을 수집하고, 요구 사항을 재평가 해서, 다음 버전을 생성한다. 작은 단위로 반복 하는 것이 낫다. 웅대한 비전을 강요하면 낡은 정보를 바탕으로 구성될 뿐이다. 초급 개발자로서, 자기 자신도 같은 방식으로 생각 하는 것이 유용하지 않겠는가?
끊임없이 학습하자
역자 주석
[1] 가면증후군impostor syndrome
유능하고 사회적으로 인정받는 사람이 자신의 능력에 대 해 의심하며 언젠가 무능함이 밝혀지지 않을까 걱정하는 심리 상태를 가리키는 용어
[2] Pet 프로젝트