튜토리얼 지옥에서 벗어나기 (1)
Imposter syndrome is the psychological experience of feeling like a fake or a phony despite any genuine success that you have achieved. It can show up in the context of work, relationships, friendships, or just overall. It’s a very common and frustrating phenomenon because it holds us back from the self-confidence we’ve earned and deserve to feel.
임포스터 증후군은, 진정한 성공을 거둔 상황에서도 자신이 가짜나 사기꾼 같다는 심리적 경험입니다. 이는 업무, 관계, 우정, 또는 전반적인 상황에서 나타날 수 있습니다. 우리가 성취를 하면서 얻고 느껴야 할 자신감을 막아버리기 때문에 좌절스러운 기분을 느낄 수 있습니다.
몇일 전, 오프라인 개발자 미팅에서 현직에서 10년차 경력을 보유하신 분을 뵌 적이 있었다. 대한민국의 국민이라면 누구나 아는 회사에서 중요한 업무를 맡으시는 분 이였는데, 그 분이 하신 말씀중에서 뇌리에 떠나가지 않는 말이 있었다.
10년차인데, 아직 내가 그에 준하는 역량이나 기술을 갖추었는지 아직 잘 모르겠어요…
이 말이 왜 오랫동안 기억속에 남아 있는 것일까? 나는 두가지의 이유가 있다고 생각했다.
- 10년차 이상의 개발자를 뵙는것은 처음이였고,
- 연차가 높게 쌓인 개발자 역시 “임포스터 신드롬”을 겪는다는 것에 (나쁜 의미로서 받았다는게 아니라) 충격을 받았기 때문이다.
이렇게 생각하다보니 개발자들 사이에 만연한 “임포스터 신드롬”에 관해 글을 써보는 것도 좋겠다 라는 결심이 들었다. 개발자에게 임포스터 신드롬이 생기는 이유는 무엇일까? 그리고 그런 현상을 스스로 어떻게 잘 컨트롤 해야할까?
스스로 바보가 된 것 같은 기분
글을 시작하면서 임포스터 신드롬에 대해서 한가지 말씀드려야 할 게 있다. 이 글은 “임포스터 신드롬”에 관한 완전무결한 해결책을 주지는 못 할 것이다. 개발자에게 있어서 임포스터 신드롬은 극복하기 어려운 현상이라고 생각하고, 또한 뚜렷한 해결책이 있는 것도 아니다. 지금 이 글을 쓰고 있는 글쓴이 조차도 임포스터 신드롬에서 완벽하게 빠져나오지 못했다. 임포스터 신드롬에 대해 해결책이 존재하지 않는 이유에는 크게 두가지가 있다. 하나는 스스로의 내면과 싸워야한다는 점에서 그렇고, 또 하나는 극복을 했더라도 “언젠가는 다시 찾아올” 현상이기 때문이다.
특히 계속해서 새로운 기술이 나오면서 끊임없이 공부해야하는 개발자 입장에서는 더더욱 그렇다. 지식의 양은 무한하고, 헤엄쳐야 할 바다는 지평선 너머로까지 끊임없이 존재한다. 그런데 내 옆자리에 앉아있는 동기는 저 멀리까지 나아간 것처럼 보인다. 어느 분야 하나를 공부하고 싶은데 공부해야할 기술은 방대하고, 이 와중에도 끊임없이 새로운 기술이 등장하며 “이 새로운 기술, 혹은 테크닉을 안배우면 낙오된 것 같은” 기분이 든다.
이 현상이 개발을 접한지 얼마 안되는 취준생들에게 흔하다는 것은 필자도 겪어보았기 때문에 알고 있었는데, 지난 몇달간 연차가 어느정도 쌓인 개발자들과 이야기하면서 그들 역시 겪고 있는 문제라는 것을 알게 되었다. 결국 임포스터 신드롬은 개발자라면 벗어날 수 없는 문제인걸까.
튜토리얼 지옥과 끊임없는 굴레
임포스터 신드롬에 관한 뚜렷한 정답은 앞 문단에서도 말했듯, 안타깝게도 존재하지 않는다. 그러나 경험담을 공유 해볼 수는 있을 것 같다. 한때 나는 임포스터 신드롬에 시달렸고, 유데미와 인프런에서 강의를 미친듯이 샀으며, 결국엔 그것이 바보같다는 것을 깨달았다. 그래서 “튜토리얼 지옥” 에 갇히고 간신히 벗어날 수 있었던 경험을 공유해보고자 한다.
지금은 백엔드 개발자로 완전히 노선을 정했지만, 원래 나는 데이터 분석 (전공) 에서 부터 프론트엔드로 길을 바꾸면서 개발을 시작했었다. 2년전 프론트엔드를 처음 공부하면서 느꼈던 신선한 충격은 아직도 잊혀지지 않는다. 딥러닝 모델을 배포하고 웹에서 백엔드와 결합된 템플릿 엔진으로 API를 받아오는 정도의 개발을 하고 있었던 나는, React로 쉽게 인터랙티브한 웹앱을 구현 할 수 있다는 것에 큰 흥미를 느꼈다. 그래서 여느 프론트엔드 개발자들이 가는 테크트리처럼, Javascript-Typescript를 공부하고, React를 공부하고, 상태관리를 공부하는 등의 길을 걸어가고 있었다. 여기까지는 순탄했다. 공부양에 압박감을 느끼지도 않았고, 프론트엔드 세계가 꽤 매력적이라고 생각하고 있던 참이었다.
문제는 테크 블로그, 유튜브를 접하게 되면서 시작되었다. 프론트엔드는 React와 Typescript만 잘 파면 될 것이라고 생각했는데, 그 너머에 새로운 기술이 산재해있다는 것은 프론트엔드를 공부하고 얼마 지나지 않은 시점에서였다. 새로운 컨셉, 새로운 기술들이 달 단위로 소개되고 “꼭 배워야 하는 것” 처럼 홍보되었다. 이때부터 나는 임포스터 신드롬에 시달리게 되었다.
당연하겠지만 그 기술, 컨셉들을 모조리 배운다는 것은 불가능하다. 하지만 나는 불안했다. 그 개념들을 따라잡지 않으면 안될 것 같았고, 당장 필요하진 않더라도 일단 배워둬야 할 것 같은 기분에 시달렸다. 그래서 유데미나 인프런에서 강의를 사고, 하루종일 그 강의를 듣고, 그 과정을 계속해서 반복했다. 나는 이른바 “튜토리얼 지옥”에 빠지게 된 것이다.
그런데 하루종일 강의를 듣고, 또 사고, 다시 듣고 하는 과정을 아무리 반복해보아도 내가 여전히 부족하다는 생각에서 벗어날 수 없었다. 그 과정에서 프론트엔드 생태계에서는 새로운 컨셉이 다시 등장했고, 그것이 쿨한것처럼 홍보가 되고, 다시 나의 생각은 원점으로 돌아가기를 반복하고 있었기 때문이다. 나는 항상 부족한 개발자였다.
중요한 것은 지식이 아니라 해결하려는 “문제” 이다
그러던 어느날, 나는 문득 이런 생각이 들었다. “어쩌면, 강의가 무조건적인 해답은 아니지 않을까?”
물론 강의가 좋은점도 많은 것이 사실이다. 더 나은 아키텍쳐의 방향성을 제시 해 줄수도 있고, 공식문서에서 어렵게 설명 해놓은 개념을 쉽게 풀어서 설명해주기도 한다. 하지만, 가장 중요한 것은 내가 배울려고 하는 것이 어떤 “문제”를 해결하는지 아는 것이다. React는 어떤 문제를 해결하기 위해 세상에 등장했을까? Spring이 서버 개발에 있어서 어떤 이점을 가져다 줄까? 안타깝게도 많은 강의들은 이 점을 설명해주지 않는다. 그저 많은 기업에서 쓰고 있고, 업계 표준처럼 자리 잡았고, 그러니 강의를 듣는 당신도 배워야 한다는 논지로 개요를 설명하는 것이 일반적이다.
하지만 꼭 그 기술들이 나의 상황에 맞으리라는 법은 없다. 어쩌면 프로젝트를 진행하는데 있어서 꼭 Spring이 아니라 Python의 Flask가 더 적합한 상황이 있을 수도 있다. 어쩌면 React가 아니라 고전적인 템플릿 엔진이 프로젝트에 더 어울리는 경우도 있을 것이다. 중요한 것은 그 기술이 얼마나 유명하고 업계 표준으로 자리 잡았고, 흥미로운지가 아니라, 취업과 별개로 내가 “왜” 필요한지에 대해 비판적으로 사고하는 것이다.
나는 프론트엔드보다 백엔드가 더 성향에 잘 맞는다는 것을 깨달은 뒤, 한국에서는 업계 표준처럼 자리잡은 Java-Spring이 아닌 Golang을 공부했다. 이유는 단순했다. 적재적소에 코드만 넣기만 하면 되는 프레임워크를 공부하기 보다는 밑바닥부터 설계해볼 수 있는 경험이 나에게 절대적으로 필요하다고 생각했고, 기본 라이브러리가 잘 구성되어 있는 Golang이 가장 적합했기 때문이다.
이 시점부터 공부하는 과정에서 강의를 물론 조금씩 듣긴 했지만, 그보다는 공식문서를 많이 찾아보기 시작했다. 공식문서는 나에게 절대적인 해답보다는 도구를 쥐고 흔드는 방법을 제시해주었고, 그 과정에서 내가 직접 고민 할 수 있는 기회를 많이 주었다. 공식문서에 기재되어있는 기본적인 튜토리얼에서 더 발전시켜보고, 리팩토링하고, 코드를 더 개선해 나갔다.