[에세이] 본질을 추구하는 것의 의미

본질을 추구하는게 뭘까?

어떤 분야의 전문가들과 이야기를 하다보면 본질을 추구하라고 합니다.

"본질". 누구나 다 중요하다고 하지만 사실 이 단어가 가진 진정한 의미에 대해서 고민하는 사람은 많지 않다고 생각합니다. 저 또한 그랬고, 현재도 그렇습니다.

다만 최근 여러 Industry의 유명한 분들의 인터뷰, 동료들과의 커피쳇, 그리고 다른 회사의 리더쉽 포지션에 계신 분들과 이야기하면서 조금이나마 알게된 "Fundamental"의 의미에 대해서 이야기해보려고 합니다.

본질을 흉내내기

대학교 3학년 때, 친하게 지냈던 선배가 이런 이야기를 했습니다.

기교를 통해 해결하는건 진짜 해결하는게 아니야. 문제를 근본적으로 해결하는 방식을 보려고 해야지

선배와 함께 외주를 하며, 한 웹 페이지의 css 높이 계산을 어떻게 잘 할지 이야기를 하면서 들었던 이야기였습니다.

사실 이떄가 처음으로 Web Frontend 외주를 받으면서, 돈을 받고 웹 페이지를 만들었던 때였습니다.

이때는 프로그래밍을 잘 하던 시절도 아니어서 대충 검색해서, stack overflow와 velog에 있는 해결책들을 소위 부르트 포스 방식으로 될때까지 도입해서 문제를 해결하던 시절이었습니다.

기교를 통해 해결하는건 진짜 해결하는게 아니야. 문제를 근본적으로 해결하는 방식을 보려고 해야지

저 말은 문제를 일단 해결하면 된거 아닌가? 라고 생각하던 저에게 조금 큰 충격을 준 말이었습니다. 왜냐하면 저는 몇시간 동안 고민하고 검색해도 해결되지 않던 문제가 선배의 코드리뷰와 함께 금방 해결되었거든요.

그래서 크게 감명받았던 그때의 저는 블로그와 책에서 말하던, 소위 본질이라고 불릴 수 있는 것들을 하기 시작했습니다.

스타 개발자분들(그 당시 velopert, zerocho님의 블로그와 Github를 자주 봤네요)의 글을 정독하고, 그 분들의 소스코드를 보면서 사고 방식을 배우려고 했고, 라이브러리의 코드를 그냥 쓰지 않고 어떻게 구현했는지 그리고 어떤 자료구조로 구현되었는지 본질적으로 접근했습니다.

왜 본질을 추구하는가?

사실 위의 접근방식도 크게 틀린 방법은 아니라 생각합니다. 해당 접근 방식은 내 분야의 전문가가 되는 좋은 방법 중에 하나거든요.

내가 종사하는 분야의 전문가들이 어떻게 생각하고, 어떤 결과물들을 나왔는지 분석하고, 그걸 내 일에 적용하는 것.

잘하는 사람이 되기 위한 가장 간단한(그러나 쉽지는 않은) 레시피 입니다. 하지만 본질은 레시피를 따르는게 아닙니다

짐 켈러가 말한 본질의 의미

짐 켈러는 본질의 의미를 빵을 만드는 과정에 빗대어 말합니다.

빵을 만드는 것 자체는 정해진 레시피에 맞춰 밀가루를 담고, 물을 넣고, 이스트를 넣고, 발효한 뒤에 오븐에 구으면 된다

하지만 빵을 이해한다는 것은 생물학, 유통학, 물리학, 열역학을 이해하는 것이다

빵을 이해하면 오믈렛, 샌드위치 등 다양한 요리를 만들 수 있다

즉 본질을 이해해야 기존의 가치를 깨고 다른 가치있는 무엇인가를 만들 수 있다.

다만 꼭 모든 본질을 이해 해야할 필요는 없다. 본질을 모두 이해하려고 한다면 아무것도 만들 수 없을 것이다.

저는 해당 이야기가 마치 프로그래밍하는 과정과 같다고 생각했습니다. 사실 저희가 사용하는 모든 것들은 추상화를 통해 이루어 집니다.

예를 들면 Frontend 개발자로서 매일 사용하는 React, Next.js, lodash 등은 추상화된 하나의 Layer 입니다.

내부적으로 해당 라이브러리나 프레임워크가 어떻게 돌아가는지 신경쓸 필요는 없습니다. 사용자(프로그래머)는 본인이 의도한 목적을 빠르게 달성하는데 집중하면 됩니다.

하지만 프로그램을 최적화하거나 아예 새로운 무언가를 만드려고 한다면 추상화 Layer에 기저한 것들을 분석하고, 프로그래밍의 본질과 알고리즘 등의 본질을 이해해야합니다.

즉, 본질을 이해해야만 기존의 Recipe(추상화)를 깨드리고 새로운 Recipe(추상화)를 만들어낼 수 있습니다. 그리고 새로운 Recipe는 Value로 전환 됩니다. Value가 누군가에게는 돈, 편의, 사회적 변화, 도덕성이 될 수 있겠죠.

본질을 흉내내기에서 진짜 본질을 보기

짐 켈러의 인터뷰를 보고 내면적 울림이 꽤 강하게 있었습니다.

여태까지 공부했던 것들(Github Repo의 소스코드를 보고, 클론 코딩을 하고, 그들의 글을 읽는 것)은 본질을 본게 아닌 레시피들을 수집하고 있었다는 것을 깨달았거든요.

레시피들을 수집하는 것이 시간 낭비라고 생각하진 않습니다. 왜냐하면 그 과정속에서 발견해낸 것들, 예를 들면 React라는 기반에서 일을 좀 더 잘 하게 해주는 방법들(Ex. Compound Pattern, Colocation, Funtional Paradigm)을 알게 되었고, 직장에서도 일을 잘한다고 인정받게 해주는 것들이 많았습니다.

하지만 인터뷰의 말 그대로 Recipe만 수집하다보니 한계가 오는게 느껴졌던 것 같습니다. Frontend Engineer로 일하고 있는 현재 시점에서, 무엇을 더 공부해야 앞으로 나아갈 수 있을까 고민하고 있었거든요.

분명 더 나아갈 공간이 있지만, 어떤 방향으로 나아갈지 또 어떻게 나아가야할지 도저히 답변이 나오지 않았습니다. 이제는 위의 질문에 대한 답을 다음과 같이 답변할 수 있을 것 같습니다.

본질을 통해 사회에 새로운 가치를 만들 것

어떻게 본질을 추구할 것인가

오픈소스 기여를 할 것 같습니다.

How보다는 What에 집중하도록 하는, 현업에서 도움이 될 수 있는 새로운 추상화를 제공하는 곳에서 함께하려합니다.

최근 흥미롭게 보고 있는 es-toolkit 라이브러리에 기여하면서 평소 관심이 많던 함수형 프로그래밍을 좀 더 깊게 이해하려 합니다. Interface의 본질을 깊게 이해하고 싶기 때문입니다.

마무리

소개하고 싶은 글이 하나 있습니다.

최근 Frontend Scene에서 흥미롭게 읽었던 글인데요. 바로 useCallback과 useMemo의 차이를 아시나요 입니다

위 글에서 소개한 useCallback, useMemo라는 함수는 React를 사용하는 Frontend 개발자라면 하루에도 수 번 사용하는 함수입니다. 그런데 어떻게 구현되어있는지 대부분 관심이 없습니다. 사실 그게 추상화의 목적이면서 추상화가 가진 힘이거든요.

하지만 위 함수의 구현에 관심이 있었다면, Immutability나 javascript equal 연산자로 인해 발생했던 문제를 좀 더 빠르게 해결할 수 있지 않았을까? 그랬다면 시간을 절약했을 텐데 와 같은 생각을 했습니다.

이런 말이 있습니다

본질을 추구하고 기저에 깔린 무엇인가의 의미를 추구하다보면 시간을 큰 단위로 아낄 수 있습니다.

회사에 소속되어 가치를 창출해야하기 때문에, 항상 본질을 추구할 수도, 항상 가치를 추구할 수 없지만 그 사이에 적절한 수준을 찾아가야할 것 같습니다.

일을 하면 할수록 참 어려운 것 같습니다. 그래서 더 재밌기도 합니다