주니어 개발자의 흔한 실수: 알고 있다는 착각

지난 몇 년 동안은 코로나19의 여파로, 대한민국을 비롯한 전 세계적으로 개발자에 대한 관심이 폭발적으로 증가했던 적이 있습니다. 우스갯소리로 3D 직종이라고 불리었던 이전과 비교되는 상황이었죠. IT 산업의 성장과 반강제 비대면이 겹쳐 개발자의 수요가 급격히 늘어났고, 많은 사람들이 개발자의 길에 도전했습니다. 당시의 흐름으로 비전공자, 전공자 할 것 없이 다양한 배경을 가진 사람들이 개발을 시작했고, 여러 교육기관이나 부트캠프, 온라인 강의 등을 통해 개발자를 직업으로 선택하는 사람도 늘었습니다.

그리고 현재, 그 당시 개발을 시작했던 사람들은 어느 정도 경력을 쌓은 주니어 개발자가 되었을 텐데요. 신입 시절의 긴장감과 두려움은 줄고, 이젠 업무도 꽤 익숙해졌다고 생각할 겁니다. 여러 프로젝트를 통해 실무 감각도 생기고, 자신감도 붙기 시작하니까요. 그러나 바로 이 시점에서 주니어 개발자들이 흔히 겪는 실수가 있습니다. 이번 글에서는 주니어 개발자들이 자주 겪는 ‘알고 있다는 착각’에 대해 이야기해 보고자 합니다.

신입 개발자와 주니어 개발자

사실 신입 개발자와 주니어 개발자를 나누는 절대적인 기준은 없습니다. 따라서 저는 약 0년 차~1년 차까지 신입으로 보고, 그 이후부터 주니어 개발자라고 생각합니다.

1) 모든 것이 새로웠던 시기는 지나가고

신입 개발자는 말 그대로 개발 업무를 처음 시작한 단계로, 대부분의 업무와 기술, 그리고 조직 문화 자체가 낯설고 모든 것이 새롭습니다. 개발 업무도 처음일 수 있지만, 회사 생활 자체가 처음인 경우도 많을 겁니다. 그래서 이 시점에는 실무에 깊게 관여하기보다는 주어진 과제를 이해하고, 기본적인 개발 도구와 함께 협업하는 방식을 익히는 것에 집중합니다. 이미 정해져 있는 기술 스택과 개발 프로세스에 열심히 적응해야 하죠.

그렇게 시간이 흘러 1년 이상 실무를 경험하면, 이제 신입을 벗어나 주니어 개발자의 단계에 접어들게 됩니다. 이때부터는 더 이상 모든 것이 새롭지 않습니다. 자신이 맡은 서비스나 프로젝트의 한 사이클 이상을 경험하게 되고, 업무 흐름과 반복되는 문제, 해결 방법에 대해서도 어느 정도 감을 잡게 됩니다. 만약 이직 없이 한 조직에서 쭉 일했다면, 자신이 담당한 도메인에 대한 이해도가 높아지고 자신감도 붙습니다.

2) 확실히 안다는 것의 함정

도메인을 이해하고, 사용하는 도구도 익숙해졌습니다. 이 기능에는 어떤 라이브러리가 적합해 보이고, 이 문제를 해결할 때는 이 방법이 맞을 거란 생각이 듭니다. 그러다 보니 내가 아는 것에 대해서도 확신이 생깁니다. 그러나 문제는 여기에서 발생합니다. ‘확실히 안다는 것’은 대체 무엇일까요? 이것이 어떤 결과를 불러올까요?

확실히 안다는 것을 정의하기는 다소 어렵습니다. 그렇다면 반대로 표현하면 무엇일지 생각해 볼까요? 확실히 알지는 못한다는 것은, ‘누군가에게 설명하기는 어려운 것’이라고 생각할 수 있습니다. 저는 프론트엔드 개발자라서 친숙한 프론트엔드 기술을 예시로 들어볼게요.

정말 확실하게 알고 있나요?

1) Next.js를 아시나요?

요즘 프론트엔드 기술 중 ‘Next.js’가 많이 쓰입니다. 아마 이 글을 읽는 분들 중에서도 잘 아시는 분이 있을 텐데요. Next.js를 설명하려면 리액트의 동작 원리나 업데이트, 그리고 앞으로의 방향성에 대해서도 같이 언급하게 됩니다. Next.js는 리액트의 프레임워크이기 때문이죠.

그런데 방금 이 설명, 무리 없이 이해되셨나요? 정말 다 알고 있는 내용일까요? 조금 더 곱씹어 봅시다. "Next.js가 리액트의 프레임워크다.", "리액트의 방향성이 Next.js에 영향을 준다"라는 말은 무슨 의미일까요? 이를 이해하려면 먼저 리액트가 무엇인지, 프레임워크란 무엇인지 알아야 합니다. 방금 그 내용을 당연히 알고 있다고 생각하고 지나쳤다면, 아마 '확실히 안다'라고 착각했을 수도 있습니다.

그렇다면 React는 무엇인가요?

설명하기 어려우셨나요? 리액트가 무엇인지는 React 공식 문서에 명확하게 적혀 있습니다.

“사용자 인터페이스(UI)를 만들기 위한 JavaScript 라이브러리”

여기에서 조금 더 아래쪽을 보면 추가 설명이 되어 있습니다.

정리해 보면, 리액트는 ‘상호 작용이 많은 UI를 만들 때 생기는 어려움을 줄여주는 선언형 UI 라이브러리’라고 설명할 수 있습니다. 그렇다면 Next.js가 리액트의 프레임워크라는 건 어떤 의미일까요?

Next.js는 어떤 새로운 언어로써 존재하는 것이 아닌, JavaScript 언어의 라이브러리 중 하나인 리액트를 사용하는 프레임워크라고 정리할 수 있습니다. 즉, Next.js보다 리액트가 먼저, 리액트보다 앞서 자바스크립트가 있다는 의미죠. 따라서 Next.js의 방향성에 대해 논하려면, 당연히 리액트의 방향성이 따라오는 겁니다.

2) 브라우저 검색 창에 ‘www.google.com’을 입력하면 어떤 일이 발생하나요?

프론트엔드에 관해 이야기했으니, 이번에는 좀 더 보통의 예시를 들어보겠습니다. 꽤 익숙한 질문이죠? 개발자 면접 질문을 검색하면 단골 질문으로 적혀있는 것 중 하나입니다. 어떻게 답변할 건가요? 확실하게 안다고 생각하시나요? 아래 내용을 읽기 전에 본인만의 답변을 만들어보세요.

가장 간단하게는 이렇게 답변할 수 있을 겁니다.

Client에서 www.google.com의 Web Server로 index.html을 Request한다.
Web Server에서 필요한 데이터를 불러온 후 index.html을 Response한다.
Client에서 전달받은 index.html을 브라우저에 렌더링한다.

틀린 설명은 아니지만, 이보다 자세히 이야기할 수도 있을 겁니다.

Client에서 DNS로 www.google.com를 질의해서 IP 정보를 알아낸다.
이하 동일

컴퓨터는 www.google.com의 IP를 알지 못합니다. 따지고 보면 이는 ‘주현이네 집’과 같은 포괄적인 명칭이기 때문이죠. 이 ‘주현이네 집’(도메인)의 실제 주소(IP)를 알기 위해서 명칭과 주소가 매핑되어 있는 어떤 책자(DNS)를 먼저 확인해야 합니다. 이제 조금 더 구체적으로 설명되었네요. 그러나 이를 확실히 설명하기 위해서는 Domain의 개념과 DNS 등 네트워크 CS 지식이 수반되어야 합니다. (캐싱 내용은 생략했습니다.)

그렇다면 이제 완전히 알고 있는 걸까요? 더 자세히 들어가 봅시다. 사실 특정 IP로 Request를 한다는 식으로 간단하게 표현하지만, 이 과정도 그렇게 간단하지 않습니다. DNS에서 IP를 알아낸 후, Request하는 부분부터 다시 적어보겠습니다. (편의상 http로 요청했다고 가정하겠습니다.)

알아낸 IP를 OS에서 제공하는 Socket API를 통해 네트워크 요청을 생성합니다.
이때 IP 패킷을 생성하고, TCP Header와 HTTP Data를 추가합니다.
생성된 IP 패킷은 Ethernet Frame으로 캡슐화시킵니다.
Ethernet을 사용하기 위해 ARP로 라우터의 MAC 주소를 알아냅니다.
생성했던 이더넷 프레임을 LAN을 통해 라우터로 전송합니다.
라우터에서는 Header의 Destination address를 확인하고 네트워크에 맞는 라우터로 패킷을 전송하거나 Destination address로 전송합니다.

… 이하 생략

어떤가요? 알게 모르게 정말 많은 내용이 들어있습니다. 이 개념을 완전히 이해하기 위해서는 OSI 7-Layer와 TCP의 3 Way-Handshake, 그리고 패킷을 포함한 여러 네트워크 지식을 알고 있어야 합니다. 재밌는 점은 아직 브라우저의 동작은 물론, 서버의 동작까지도 도착하지 못했다는 점이죠. 이렇게 우리가 사용하고 있는 기술들은 사실 상당히 복잡하고, 은밀하게 이루어져 있습니다. 어떤가요? 위에서 미리 생각해 봤던 답변과 지금의 내용은 모두 확실히 알고 있던 부분인가요?

3) 이게 정말 필요한가요?

여기까지 읽고 나면 아마 이런 의문이 들 수 있습니다. 대체 이게 내가 공부하는 프론트엔드(또는 여러 직무들)에 어떤 도움이 되는 거지?

맞습니다. 실제로 이런 내용은 잘 모르고도 충분히 잘하고 있는데 말이죠. 회사에서 일할 때도 이런 네트워크 레벨까지 고려하지 않는 경우가 많고요.

여기서 제가 말하고 싶은 건 네트워크 지식(또는 CS 지식)을 반드시 공부해라!가 아닙니다. 그보단 사실 우리가 사용하는 추상화된 기술 아래 이런 것들도 존재하므로, 무엇이든 확실히 안다고 말하는 건 불가능하다는 것입니다.

제가 앞서 확실히 안다는 것의 함정에 대해 언급했는데요. 확실히 안다는 것의 함정은 더 이상 알려고 하지 않는다는 겁니다. 왜냐하면 나는 이미 알고 있는데, 굳이 더 알아볼 필요는 없다고 생각하니까요. 우리가 덧셈, 뺄셈을 다시 공부하지 않는 것과 같은 이치입니다. 문제는 모르는 것과 사실 모르고 있는데, 더 알려고 하지 않는 것은 완전히 다르기 때문이죠.

심리학에서 말하는 ‘더닝크루거 효과(Dunning-Kruger Effect)’는 이러한 현상을 잘 설명해 줍니다. 자신이 얼마나 모르는지 모르는 상태, 이른바 ‘우매함의 봉우리’에서 많은 시간을 쓰게 될수록 성장하기는 어려워집니다. 확실히 안다고 착각하고 있는 시간이 길어질수록, 이 우매함의 봉우리에서 오랜 시간을 쓰는 것이죠. 또 내가 확실히 알고 있다고 생각하면, 나와 다른 의견을 가진 사람들이 틀렸다고 단정 짓게 되고, 더욱더 봉우리에 오래 묶여 있게 됩니다.

그럼 어떻게 해야 할까요?

1) ‘확실히 안다’라는 생각을 버리자

앞선 이야기에 비해 해결책이 너무 간단하다고 생각하셨나요? 하지만 이걸 지키긴 생각보다 어렵습니다. 한 곳 또는 한 직종에 오래 머무를수록 더욱 어려워집니다. 내가 계속해 왔던 것이라, 그것이 유일한 정답이라고 생각하기 때문이죠. 따라서 이것 하나만은 꼭 기억해야 합니다.

“아는 것보다, 모른다는 것을 아는 게 더 중요합니다.”

내가 모르는 부분이 있다는 걸 인정하고, 이에 관한 의견들을 많이 받아보며 꾸준히 학습해야 합니다. 만약 그 대상이 나보다 저연차라고 할지라도 말이죠. 저 역시 앞서 CS 관련 내용을 적었지만, 사실 더 Low-level에 다가갈수록 모르는 지식이 많습니다. 이렇게 모르는 부분이 있음을 인정하고, 언젠가 기회가 되면 더 자세히 알아보고 싶다고 생각합니다.

2) 작동 원리를 이해하기

우리가 흔히 사용하는 기술들은 사실 수많은 추상화 위에 존재합니다. React, Next.js, fetch API, 브라우저 렌더링 등 많은 기술들이, 그리고 그 기술들을 이루는 기술 또한 추상화되어 존재하죠. 이를 너무 당연하게만 생각하지 않는 것이 중요하다고 생각합니다. 전부 알아야 한다는 게 아니라, 아직도 모르는 부분이 있다고 생각해야 한다는 겁니다. 이 작은 차이가 개발자로서 더 성장할 수 있을지 없을지를 결정합니다.

마치며

개발자는 매일 복잡한 기술을 다루지만, 때로는 그 기술이 어떻게 동작하는지조차 모른 채 지나치기도 합니다. Next.js를 안다고 말하면서도 React, JavaScript의 동작 방식에 대해서는 모르고, 브라우저의 렌더링 방식에 관해 설명하지 못하는 경우도 흔합니다.

그러나 모르는 걸 인정하는 것, 그리고 그 속의 원리를 들여다보려는 시도는 개발자를 한 단계 성장시키는 데 가장 중요한 태도가 됩니다. 기술은 계속 바뀌고 추상화는 더 깊어지지만, 기초는 크게 변하지 않습니다. 추상화된 기술만 보고 섣불리 정답이라고 생각하는 건 성장에 도움이 되지 않습니다.

모든 것에 관심을 가지고 기술을 연구해, 오버 엔지니어링(Over Engineering)을 하라는 뜻은 아닙니다. 다만 배우고자 하는 자세를 잃지 않는 것만으로 충분합니다. 또 새로운 기술을 배우기에 급급하기보다는 본질을 이해하는 데 집중하다 보면, 어느새 실수는 줄어들고 한층 성장한 자신을 마주하게 될 것입니다.