<p>드라마앤컴퍼니에서 2년 10개월정도의 커리어를 마무리하고 토스로 이직하게 되었다. 그 과정에서 성장했던 것들을 기록해보려고 한다.</p>
<h3>이유</h3>
<p>이직에는 이유가 있어야한다. 나의 경우에는 불안감이었다. 불안은 참으로 어려운 감정이다. 여태까지 나를 성장시킨 원동력이기도 하면서, 늘 내가 올바르지 않은 판단을 할 때의 근본적인 원인이기도 하기 때문이다. 그렇지만 연료로 활용할 가치는 너무나 충분한 감정이라는 것은 부정하지 않는다. 그러다가 재직기간을 2년정도 채워 갈 때 문득 '지금 회사에서 정말 10년동안 일해도 좋겠다.'라는 생각이 들었고 나의 불안은 이런 생각에서 시작했다.</p>
<p>불안함이 없어서 생기는 불안이 있었다. 내 삶은 불안의 연속이었다. 검정고시 고졸이라는 저학력에 대한 불안과 한 순간도 경제활동을 하지 않으면 생계유지에 치명적이기 때문에 생기는 금전적인 불안감. 그 것 말고도 인간관계에서도 늘 불안이 따라왔다. 그러다가 안정적인 직장을 얻고, 좋은 사람들을 많이 알게 되면서 삶에서 불안이 많이 걷어낼 수 있었던 것 같다. 어느 순간부터는 안락함 속에서 삶을 유지하는 것에 익숙해지고 있었다. 내가 앞으로 나아갈 이유에 대한 고민은 당연하게 찾아왔다.</p>
<p>불안하지 않아서 불안함이 생겼다. 어찌보면 나는 불안중독인 사람인 것 같기도 한데 가치판단은 보류하고 그 불안함에 쫓기다 보면 나는 결론적으로는 나아지는 방향으로 가고 있었기 때문에 무언가 행동해야 했다. 그래서 생각한 것이 이직이었다. 그렇게 충동적으로 작년 말에 이력서를 처음 넣기 시작하면서 이직을 시작했다.</p>
<h3>실패</h3>
<p>결론적으로 첫 도전은 실패했다. 이직은 작년 10월 말 부터 4월정도까지 액티브하게 시도했는데 모두 실패했다. 물론 그 과정에서 얻은 경험들은 굉장히 좋았다. 배우는 것도 많았다. 그리고 느낀 건 역시 뭐든 경험을 통해서 얻어야 한다는 것이었다. 이직후기나 면접후기 200개 읽어보는 건 큰 도움이 되지 못했던 것 같다. (위로는 받았다)</p>
<p>실패에 대한 큰 원인들을 생각해보면 그 시기의 고용시장 상황이 좋지 않았던 점, 내가 면접 경험이 턱없이 부족했던 점, 그리고 내 생각의 깊이가 그렇게 깊지 않았던 점 들이 있을 것 같다. 아무튼 여러가지 이유로 나는 수차례 좋지 않은 결과와 마주해야 했고 어느 순간부터는 이게 오기가 생겨서 '이직을 위한 이직’을 하고 있다는 생각이 들었을 때 쯤 중단했다. 뭔가 이대로 이직을 멈추면 실패하는 것, 포기하는 것 이라는 생각에 휩싸여 있었던 것 같다. 그런 생각들이 나를 갉아먹고 있을 때 다행히 스톱할 수 있었다.</p>
<h3>정비</h3>
<p>결국 액티브하게 이직을 하려던 마음을 멈추고 먼저 나를 좀 돌아봤다. 나는 어떤 개발자인가? 나를 채용하고 싶은 이유가 있을까? 먼저 찾아야 하는 건 나의 '특별한 강점’이라는 생각이 들었다. 생각 해 보니 면접중에 '정원님이 다른 개발자들과 비교했을 때 특별히 더 잘하는 것이 있나요?'라는 노골적인 질문을 받은 적도 있었다. 그러면서 내가 면접관으로 참여할 때의 일화가 생각이 났다. 면접자는 분명히 모든 질문에 대부분 대답을 했고, 우려되는 부분이 없었음에도 '뽑아야 하는 이유’를 찾기 어려운 면접자분이셨다. 그 때 나는 스스로 면접관의 역량이 부족하다고 많이 자책했던 기억이 난다. 내가 그 면접자의 강점을 잘 이끌어내는 질문들을 했어야 했는데 그러지 못했다. 그렇기 때문에 나는 면접자에게서 어떤 특별한 '뽑아야 하는 이유’를 찾지 못했고 결국에는 그 분을 뽑지 않았다.</p>
<p>그 때는 스스로 면접관으로서 역량이 너무 부족했기 때문이라고 생각하고 많이 힘들어 했었다. 한 사람의 채용과정에서 내 역량 부족으로 제대로 된 평가를 하지 못했다는 것에 대한 죄책감 같은 것들이 들었다. 물론 반은 맞는 말이지만, 자신을 뽑아야 하는 이유를 어필하고 보여주는 것도 면접자로서의 책임이고 역량이라는 것을 면접자로 면접에 참여하면서 느꼈다.</p>
<p>그래서 일단은 김정원이라는 프론트엔드 개발자가 어떤 강점이 있고, 어떤 특별함이 있는지에 대해서 많이 생각해봤다. 내가 막연하게 생각하고 있던 나의 장점들을 정리해봤다. ‘제품을 만드는 것에 적극적이고 문제를 해결하는 것에 포커스를 맞춘다’ 라는 메이커로서의 역량이 있었고, '타입스크립트에 대한 깊은 이해도를 기반으로 실무코드에 잘 활용하고, CSS 속성들에 관심이 많아서 적재적소에 잘 활용할 수 있는 것, 번들러와 모노레포와 같은 프론트엔드 개발환경에 대한 경험과 클라우드 인프라에 대한 기본적인 이해도를 갖고있다’라는 엔지니어로서의 역량이 있었다. 또 '구성원과 친하게 지낼 수 있다’라는 커뮤니케이션 역량도 있었다. 이 중에서 사실 커뮤니케이션 역량은 면접 과정에서는 말로 풀어내는 것 보다는 면접 경험 전반에 녹아드는 영역이라고 생각한다.</p>
<p>아무튼 이렇게 한 차례 이직 시도를 마무리하면서 스스로에 대한 생각을 정리하면서 앞으로 어떻게 나의 역량을 정의하고 방향을 정할지 생각하는 시간을 가졌다.</p>
<h3>잠깐 사족</h3>
<p>사실 처음 이직을 시도할 때는 굉장히 근자감에 차 있었다. 우리 회사에서 이직한 분들은 모두 다 괜찮은 회사로 잘 이직을 했었고 내가 지금 회사에 입사할 때도 한 번에 입사할 수 있었기 때문이었다. 그리고 스스로 능력에 대해서도 좋게 생각하고 있었다. 좋게 생각하면 자신감이지만 어느정도 오만함을 넘나들고 있었다. 그런데 결과는 앞서 얘기한 것 처럼 좋지 않았다. 인터넷에는 3~4개의 회사를 동시에 합격해서 좋은 곳으로 이직했다는 후기들이 많았었고 나도 그런 미래(?)를 생각하고 있었다. 하지만 현실은 그러지 못했고 내 생각에는 하향 지원으로 넣어본 곳에서 탈락통보를 받기도 하면서 많이 위축되기도 했었다.</p>
<p>지금 생각 해 보면 '면접은 운칠기삼’이라는 말이 어느정도는 맞는 것 같다. 물론 결정적으로는 '기삼’이 제대로 받쳐준다는 전제가 있어야 하겠지만 역시 '운칠’의 영역도 크다고 생각이 든다. 그 때의 시장 상황이나 내가 가고싶은 회사에서 회사에서 필요로 하는 사람, 그리고 내가 어떤 역량에 강점이 있는지 그리고 그걸 봐줄 수 있는 면접관인지까지. 여러가지 예측 불가능한 변수들이 지속적으로 변화한다. 나도 시장이 좋을 때 면접 준비를 철저하게 잘 해서 이직을 했다면 여러군데를 동시에 합격해서 이직하는 경험을 할 수 있었을수도 있고… (아닐 수도 있고… ^^)</p>
<p>아무튼 결국 '운칠기삼’의 중요한 포인트는 ‘포기하지 않는 것’ 정도라고 생각한다.</p>
<h3>이직</h3>
<p>그리고 6월달 쯤에 토스에서 Frontend Platform 공개채용을 진행했고 JD를 보니 내가 지금 회사에서 고민하고 공부했던 일들과 겹치는 것들이 많았고 점점 해당 영역에 흥미를 느끼고 있었던 시점이어서 ‘정말로 큰 기대 없이’ 지원을 해보게 되었다. 물론 토스는 너무나 가고싶던 회사 중 하나였고 특히 내가 사용자로서 팬심이 큰 서비스였다. 그런데도 큰 기대가 없었다는 걸 강조하는 건 어디든 지원을 할 때 나름 기대 안하려고 하지만 내심 기대하는 게 있기 마련인데 이번에는 진짜 없었고(아마 앞선 실패로 인해 자신감이 많이 낮아졌던 탓도 있을 것이다), 전형중에 '시험 전형’이라는 게 있었기 때문에 그냥 내가 지식들을 잘 습득한건지 확인해볼까 하는 마음이 더 컸었다. 시험도 그냥 내가 배운 것 위주로 풀면 되겠다 싶어서 미리 공부를 하지도 않았다. 그런데 내가 잘 공부했었는지 면접을 볼 기회를 잡았고 그대로 최종 합격까지 갈 수 있었다.</p>
<h3>토스의 면접</h3>
<p>토스의 이번 면접 경험은 정말 좋았다. 사실 이전에 토스의 다른 계열사의 면접을 본 적이 있었는데 그 때는 큰 감흥이 없었는데 이번 면접과정은 정말 좋았다. (그 때는 탈락해서 그런 걸수도 있다 ^^) 기술 면접에서는 내 이력서를 정말 자세히 읽어본게 느껴질 만큼 나의 강점들을 잘 이끌어 낼 수 있는 대화로 이끌어 주셨다. 이 전에 내가 고민했던 '면접관의 역량’에 빗대어 봤을 때 역량있는 면접관 분들이라는 느낌이 들었다. 이후 소문의(?) 컬쳐핏 면접도 좋았다. 간략하게 설명하자면 그냥 '있는 그대로의 나’를 보여주면 되었고 '있는 그대로의 생각’을 보여주면 됐다. 다른 컬쳐핏 면접은 보면 가끔 뭔가 '정답’을 말해야 할 것 같고, 그 회사에 대해서 얼마나 알고있는지를 시험보듯 면접이 진행되는데 토스에서는 그런 느낌을 받지 못했다. 그러다보니 면접이 끝나고도 ‘잘 봤다’ 혹은 '망했다’는 생각 자체가 안들었다. 그냥 나는 내 이야기들을 했을 뿐이라서 그러지 않았나 싶다.</p>
<p>그리고 레퍼런스 체크와 오퍼레터 과정을 거쳐서 '최종 합격’을 할 수 있었다. 넉넉하게 보면 거의 1년 정도가 걸린 이직이었다. 주변에서도 많이 축하해줘서 뿌듯했다.</p>
<h3>유종의 미</h3>
<p>나는 다니던 회사에 대해서 애정이 여전히 크다. 드라마앤컴퍼니의 구성원들이나 일하는 방식들에서도 배울점이 아직 너무나 많고, 리멤버라는 서비스에도 애정이 많다. 그리고 당연하지만 아직 내가 해볼 수 있는 것들도 여전히 많다고 생각한다. 그 중에서도 가장 많은 부분을 차지하는 건 '좋은 동료들’이다. 마지막에 재호님과의 원온원에서도 그 얘기를 하면서 살짝 울먹거리기까지 했을 정도였다.</p>
<p>아무튼 그렇기 때문에 남은 시간동안 최대한 유종의 미를 지키고 싶었다. 인수인계할 수 있는 것들을 문서화하고 같이 일했던 사람들과 원온원을 많이 만들고, 나에게 의지했던 사업팀 사람들도 나의 부재가 크지 않도록 파트원 분들에게 많은 부탁도 드렸다… 너무너무 좋은 사람들과 일할 수 있었다는 생각에 지금 이 글을 쓰면서도 가슴이 벅차오르고 있다… (아무튼 진심임)</p>
<p>퇴사하는 날 까지 정시퇴근을 포기하면서 끝까지 많은 사람들과 이야기하고 너무 좋게 마무리 했다. (물론 살짝 아쉬운 것도 있었지만… ^^) 새로운 곳에 가서도 좋은 사람들과 일할 수 있으면 좋겠다. 이런 우려들을 동료들에게 이야기 하면 늘 '정원님이 하기 나름일 거예요’라는 대답을 해줬다. 그게 늘 용기가 되는 것 같다. 토스에서도 사람들과 즐겁게 일할 수 있도록…! 하기 나름을 잘 해보자. 아자아자!</p>
<h3>다음 목표</h3>
<p>나는 검정고시 졸업이라는 객관적으로 아쉬운 학력 갖고 있다. 물론 나는 이것에 대한 불만은 없다. 학력이라는 것은 현대사회를 살아감에 있어서 여전히 중요하지만 그렇다고 절대 극복할 수 없는 것은 아니다. 그걸 내가 지금 증명하고 있다는 생각도 있다. 그런 맥락에서 네임밸류 있는 회사에 간다는 건 나를 설명하기 좀 더 편해지는 것이기도 하다. 이제는 학력을 경력으로 어느정도는 커버할 수 있지 않을까 하는 기대도 있다. (특히 어른들과에 대화에서 고졸 커밍아웃은 늘 1초 정도의 정적을 가져와서 힘들다.)</p>
<p>이런 이야기를 한 이유는 학력과는 별개로 정말 지식의 습득을 위한 공부를 하고싶다는 욕심이 생겼고 그에 맞는 목표를 만들고 있기 때문이다. 특히 요즘에는 AI에 관심이 많은데 AI는 특히 전문 교육과정이 필요한 것 같다. 일단 선형대수학같은 수학적인 부분 부터 시작해서 머신러닝이나 딥러닝 같은 알고리즘을 이해하려면 독학으로는 좀 어렵지 않을까 싶다. 그래서 사이버대학교나 학점은행제 같은 방법으로 공부를 해볼까 생각중인데 회사를 다니면서 할 수 있을지는 잘 모르겠다… 일단은 그런 생각이 있고…</p>
<p>그리고 돈 모으기도 시작했다. 나는 30살 평생 돈을 제대로 모아본 적이 없는데, 최근에는 결혼을 하고 가정을 만들고 싶다는 개인적인 목표가 생겨서 제대로 재테크를 해볼 생각이다. 최근에는 ISA계좌를 만들어서 ETF에 투자를 해보고 있다. 사실 아직도 잘 모르겠는데 결혼 하려면 돈을 모아야 한다. 라는 단순한 이유를 갖고 실행중이다.</p>
<h3>끝으로</h3>
<p>글이 생각보다 길어졌다. 고졸이라는 키워드로 어그로를 끌었지만 사실 고졸과 관련된 이야기는 별로 없다… 나는 지금까지 살면서 직접적으로 고졸이라서 느끼는 디메리트가 많지 않은 것 같다고 생각한다. 물론 분명히 내가 모르게 있었겠지만, 내가 모르니까 된 거 아닌가…? 그럼 럭키 비키 아닌가…? 그렇게 생각한다. 이 글을 읽는 분이 있다면… 음… 아무튼 다 잘 될 겁니다. 꾸준히 열심히 최선의 최선을 다해보세요.</p>
<p>참고로 첫 출근은 9월 9일이다. 아직 출근도 안한 시점에서 이런 글을 쓰는 게 맞나 싶긴하지만, 글 쓸수 있는 여유가 있을 때 써놔야 할 것 같아서 썼다. 무사히(?) 3MR기간을 마칠 때 쯤 새로운 포스팅을 하는 게 단기적인 목표이다.</p>


3년차 프론트엔드 이직기록

View Transition API 알아보기

<p>Typescript 5.4 beta가 출시되었고 그에 따라서 <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-5-4-beta/">블로그 포스팅</a>이 올라왔다. 그 중에서 <code>NoInfer</code>라는 이름의 유틸리티 타입이 추가된 게 눈에 띄었는데, 제법 유용하고 자주 사용될 유틸리티 타입이라는 생각이 들어서 정리해봤다. 위 포스팅에서도 잘 설명되어 있지만 간단하게 알아보자.</p>
<h3>No Inference</h3>
<p>직역하면 '추론하지 마세요’겠다. 말 그대로 타입 추론을 하지 못하게 하는 유틸리티 타입인데, 타입을 작성하다보면 타입을 미리 결정하지 못하고 추론을 통해서 결정해야 하는 상황이 있을 때 보통 제네릭을 활용하여 해결한다. 예를 들어 아래와 같은 상황이 있다.</p>
<pre><code class="language-ts"><span class="hljs-keyword">function</span> pick&lt;T&gt;(<span class="hljs-attr">collection</span>: <span class="hljs-keyword">readonly</span> T[], <span class="hljs-attr">item</span>: <span class="hljs-built_in">string</span>): T {
  <span class="hljs-keyword">return</span> collection.<span class="hljs-title function_">find</span>(<span class="hljs-function">(<span class="hljs-params">_item</span>) =&gt;</span> _item === item);
}
</code></pre>
<p>배열의 요소를 하나 가져오는 함수이다. 그런데 이렇게 하게 된다면 가져오는 아이템의 타입이 너무 열려있어서 좋지 않다. collection의 타입에 따라 item의 타입이 결정될 수 있도록 하고싶은 의도로 코드를 다음과 같이 수정할 수 있다.</p>
<pre><code class="language-ts"><span class="hljs-keyword">function</span> pick&lt;T&gt;(<span class="hljs-attr">collection</span>: <span class="hljs-keyword">readonly</span> T[], <span class="hljs-attr">item</span>: T): T {
  <span class="hljs-keyword">return</span> collection.<span class="hljs-title function_">find</span>(<span class="hljs-function">(<span class="hljs-params">_item</span>) =&gt;</span> _item === item);
}
</code></pre>
<p>그러나 이렇게 타입을 선언하고 실제 사용하게 되면 예상과는 다르게 동작하는 걸 알 수 있다.</p>
<pre><code class="language-ts"><span class="hljs-keyword">const</span> fruits = [<span class="hljs-string">&quot;apple&quot;</span>, <span class="hljs-string">&quot;banana&quot;</span>, <span class="hljs-string">&quot;tomato&quot;</span>] <span class="hljs-keyword">as</span> <span class="hljs-keyword">const</span>;
<span class="hljs-keyword">const</span> item = <span class="hljs-title function_">pick</span>(fruits, <span class="hljs-string">&quot;pineapple&quot;</span>);
<span class="hljs-comment">//    ^</span>
<span class="hljs-comment">//    &#x27;apple&#x27; | &#x27;banana&#x27; | &#x27;tomato&#x27; | &#x27;pineapple&#x27;</span>
</code></pre>
<p><code>pick</code>의 두 번째 인자가 fruits의 요소가 아닌데도 타입에러를 발생시키지 않고 같이 추론의 대상이 되는 문제가 발생한다. 순서대로 첫 번째 인자 T가 추론되어 타입이 결정되고 두번째 인자의 타입은 결정된 타입으로 처리될 거라 기대했지만, 두 번째 인자에서도 동일한 제네릭 T가 사용되기 때문에 함수가 호출될 때 제네릭의 구조가 만족할 수 있는 결과로 추론되어 원하지 않는 상황이 발생했다.</p>
<p>하지만 타입스크립트로 개발을 하다보면 이미 이런 상황들을 많이 겪었고 다음과 같은 방법들을 통해서 해결할 수 있다는 걸 이미 알고 있다.</p>
<pre><code class="language-ts"><span class="hljs-comment">// 제네릭을 하나 더 추가하고 첫 번째 제네릭의 하위 타입으로 만든다</span>
<span class="hljs-keyword">function</span> pick&lt;T, I <span class="hljs-keyword">extends</span> T&gt;(<span class="hljs-attr">collection</span>: <span class="hljs-keyword">readonly</span> T[], <span class="hljs-attr">item</span>: I): T;

<span class="hljs-comment">// 호출 할 때 먼저 제네릭을 확정한다</span>
pick&lt;<span class="hljs-keyword">typeof</span> fruits[<span class="hljs-built_in">number</span>]&gt;(fruits, <span class="hljs-string">&quot;pineapple&quot;</span>);
</code></pre>
<p>보통은 첫 번째 방법을 더 활용하겠지만, T타입의 추론을 막기위해서 제네릭을 하나 더 사용해야 하고 I타입은 오직 T타입의 참조를 위해서만 사용되기 때문에 합리적인 방법은 아니다. 이쯤 되면 <code>NoInfer</code>유틸리티 타입의 역할이 추론될 것이다. <code>NoInfer</code>유틸리티 타입을 사용하면 아래와 같이 합리적이고 간단한 방법으로 처리할 수 있다.</p>
<pre><code class="language-ts"><span class="hljs-keyword">function</span> pick&lt;T&gt;(<span class="hljs-attr">collection</span>: <span class="hljs-keyword">readonly</span> T[], <span class="hljs-attr">item</span>: <span class="hljs-title class_">NoInfer</span>&lt;T&gt;): T;
</code></pre>
<h3>포스팅 한 이유</h3>
<p>최근 Solid.js의 내부 구현이 궁금해서 소스코드를 뒤져보다가 NoInfer 타입을 직접 구현해서 사용하고 있었던 걸 보고 신기하고 유용하다 생각하고 있었는데, 며칠 뒤에 타입스크립트 5.4 베타에 포함될 거라는 이야기를 듣고 반가워서 정리 해 봤다.</p>
<p>만약 <code>NoInfer</code>유틸리티 타입을 미리 사용해 보고 싶다면 아래와 같이 사용할 수 있다.</p>
<pre><code class="language-ts"><span class="hljs-keyword">type</span> <span class="hljs-title class_">NoInfer</span>&lt;T <span class="hljs-keyword">extends</span> <span class="hljs-built_in">any</span>&gt; = [T][T <span class="hljs-keyword">extends</span> <span class="hljs-built_in">any</span> ? <span class="hljs-number">0</span> : <span class="hljs-built_in">never</span>];
</code></pre>
<p>그런데 튜플 타입의 인덱싱을 통해서 어떻게 추론을 막는건지 궁금해서 ChatGPT에게 물어보니 아래와 같은 답변을 해줬다.</p>
<blockquote>
<h4>타입 추론 방지</h4>
<p>튜플과 인덱싱된 접근을 사용하는 것은 타입스크립트의 타입 추론 메커니즘을 '우회’하는 방법입니다. 특정 타입 T에 대해 [T][0]과 같은 표현을 사용하면, 타입스크립트는 T의 타입을 직접적으로 추론하는 대신, T 타입의 요소를 포함하는 튜플의 첫 번째 요소의 타입을 추론하게 됩니다. 이 과정에서 타입스크립트는 T의 타입을 '고정’시키고 추가적인 추론을 수행하지 않으려고 합니다.</p>
<h4>인덱싱된 접근의 역할</h4>
<p>인덱싱된 접근은 타입스크립트에게 타입 정보를 '사용’하도록 강제합니다. 즉, [T][0]은 타입스크립트에게 T 타입의 값을 단순히 사용하는 것이 아니라, 특정 구조(이 경우 튜플) 내에서 T의 타입을 확인하도록 요구합니다. 이 과정에서 타입 추론이 특정 지점에서 ‘멈추고’, 명시적으로 제공된 타입이나 이전에 추론된 타입을 그대로 사용하게 합니다.</p>
</blockquote>
<p>이걸 보고 생각난 것이 <code>never</code>타입을 추론하기 위해서</p>
<pre><code class="language-ts"><span class="hljs-keyword">type</span> <span class="hljs-title class_">IsNever</span>&lt;T&gt; = [T] <span class="hljs-keyword">extends</span> [<span class="hljs-built_in">never</span>] ? <span class="hljs-literal">true</span> : <span class="hljs-literal">false</span>;
</code></pre>
<p>같은 식으로 타입을 튜플의 원소로서 타입을 '확정(가두기)'한 뒤 참조하는 느낌과 비슷하다고 느꼈다.</p>
<p>또한 <code>NoInfer</code>유틸리티 타입에 대해 논의한 <a href="https://github.com/microsoft/TypeScript/issues/14829">깃허브 이슈</a>도 있으니 궁금하면 읽어봐도 재밌을 듯 하다.</p>


NoInfer 알아보기

<p>2022년에 이어서 2023년도 개발자로 보냈다. 2023년에는 기술 관련 포스팅을 좀 많이 작성해보려고 했는데… 2개 정도 올렸다… 그 중에 하나는 재작년 태스크에 대한 트러블슈팅… 블로그를 많이 남겨야 하는 이유중에는 특히 내가 한 해동안 뭘 했는지 기록을 남기는 용도로서도 굉장히 중요하단 걸 느꼈다. 분명 알찬 한해를 보낸 것 같은데 블로그만 보면 별 거 안한 것 같아 보이고 그러니 좀 서운(?)하다. 올 해는 전반적으로 뭔가 폭발적인 성장! 10보 전진! 같은 것 보다는 내년의 추진력을 위해 준비하는 한 해가 되었는데 그만큼 평화롭기도 하면서 뭔가 뒤흔들어야 한다는 위기감도 같이 느꼈다. 하지만 나는 뭐든 기대 이상으로 잘 하니까 너무 걱정말자…! (아무튼 믿기)</p>
<h2>개인</h2>
<p>먼저 올해 내가 개인적으로 이룬 성장들… 이 퍼뜩 떠오르지는 않아서 아쉽다. 열심히 회사 생활을 했고 더 좋은 코드에 대한 막연함을 조금씩 실제로 코드에 반영해 보기도 했지만 어쩐지 아쉬움이 남는 이유가 뭘까 생각 해 보니 느껴지는 게 아마 '의식적인 성장’이 부족했기 때문이 아닌가 싶다. 작년에 '성장’이란 게 내가 좋은 개발자가 되기 위해서 노력하면 알아서 따라올 것이라고 말했었는데, 스스로 내린 결론에 좀 안일하게 참여했었다. <strong>성장을 위한 성장</strong>은 여전히 경계해야 하지만, 그렇다고 그냥 성장이 알아서 따라오는 건 아닌 것 같다. 내가 어떤 부분에서 성장했는지 아는 것도 성장의 일부인데 올 해는 그런 부분들이 제대로 못 챙겼던 것 같다.</p>
<h4>독서</h4>
<p>클린 아키텍처를 읽었다. 그동안 막연하게 알고 있으면서 알고 있다고 착각하던 것들을 좀 명료하게 머릿속에 정리할 수 있었다. 흩어져서 얽히는 관심사를 나누는 다양한 방법들에 대한 고민들을 해소하는 방법들에 대해서 좀 더 정확하게 볼 수 있게 된 듯 하다. 물론 1회독에 모든 내용을 이해하지는 못했지만 굉장히 적절한 타이밍에 읽었다는 생각이다. 만약 좀 더 빨리 읽었다면 분명 이해하지 못한 부분이 더 많았을테고 더 늦게 읽었다면 왜 이걸 이제야…! 했을 것 같다. 마침 내가 고민하고 있는 부분들에 대해서 설명해주고 있었기 때문에 더 효과적으로 읽을 수 있었던 것 같다.</p>
<p>그리고 웹파트 내에서도 '함께 자라기’라는 책을 읽으면서 북스터디를 했는데 역시 도움되는 내용들이 많았다. 협업을 하면서도 그렇지만 개인적으로도 어떤 태도로 함께 해야하는지, 결국 우리가 함께 잘 해야하는 이유가 무엇인지에 대해서 조금 더 명확하게 알 수 있었다. 읽는 동안 파트원들 모두가 공감할 수 있었던 부분들이 많았다. 우리가 어떨 때 효율적으로 일하고 어떤 상황에서 건강하게 의사소통 할 수 있는지는 이미 경험으로 막연히 알고 있었고, 그것들을 합리적으로 설명해주는 것 만으로 의식적인 습득을 할 수 있었고 그런 방법들을 '내 것’으로 만드는 데에 도움이 되었다.</p>
<h4>직관</h4>
<p>올 해는 '의식적으로 좋은 코드를 작성’하기 위한 고민을 많이했다. (혹은 ‘의식적으로 나쁜 코드 피하기’) 동료 분 중에 한 분이 '정원님은 직관이 좋다’라고 말씀해 주신 적이 있었는데 그 이야기를 처음 들었을 때는 단순하게 '오 내가 직관을 잘 활용하는 구나’라고 생각하고 기분이 좋았는데, 스스로 곰곰히 생각 해 보니 직관을 잘 활용한다기 보다는 그냥 직관에 의존하면서 코드를 작성하고 있었지 않았나 싶었다. 분명 결과물은 괜찮은 것 같은데 이게 왜 괜찮은지 설명해 보라고 하면 할 수 있을까? 라는 두려움이 생긴 것이다. 그래서 클린 아키텍처를 읽기 시작했다. 지식보다는 경험이 중요한 것은 알고있지만 내 경험을 올바르게 공유하고 더 개선하기 위해서는 경험을 지식으로 정제할 수 있어야 한다. 올 해는 그것에 대한 중요성을 확실하게 느꼈고, 다양한 방법으로 나아지려고 하고 있다. 그 방법 중에 하나로 <a href="/2023/%EC%A7%81%EA%B4%80-%EC%A3%BC%EB%8F%84-%EA%B0%9C%EB%B0%9C%EC%97%90%EC%84%9C-%EB%B2%97%EC%96%B4%EB%82%98%EA%B8%B0">직관 주도 개발에서 벗어나기</a> 포스팅을 작성했다.</p>
<h2>회사</h2>
<h4>흑자전환</h4>
<p>회사가 흑자전환을 했다! 처음 입사할 때 재호님 면접에서 '지금 회사가 J커브를 목전에 두고 있다고 생각하고 그 과정을 같이 나아가고 싶다’고 말씀드렸었는데 정말 그 일이 일어나니 제법 가슴이 웅장해졌었다. 내가 앞으로 회사원으로 일을 하면서도 이번에 얻은 '함께 이겨내는 경험’이 굉장히 값진 경험으로 작용할 거라는 기대가 된다. 물론 회사원이 아니라 내 일을 하게 되더라도</p>
<h4>채용</h4>
<p>흑자전환과 함께 제품팀의 인원을 크게 증가시키게 되었고 드디어 우리 파트의 인원 보충이 결정되었다. 무려 11명까지 TO가 나왔다. 같은 IC레벨의 동료분께서 많은 부분들을 책임져 주신 덕분에 채용도 무사히 진행되었다. (이 자리를 빌어 J님께 다시 한 번 감사합니다…) 한 분은 오퍼가 잘 되지 않아서 지금은 10명까지는 인원이 채용되었고 한 명이 더 남았다. 함께 일하고 싶은 사람들을 채용하기 위해서는 필연적으로 면접을 봐야하는데 나에게 면접관으로 참여할 수 있는 기회도 많이 주어졌었다. 처음에는 많이 부담스러웠지만, 면접을 보다 보니 정량적인 기준보다는 어떤 '느낌적인 느낌’이란 게 생각보다 많이 작용하게 된다는 걸 알았다. 그래서 면접관도 역량이 굉장히 중요하다… 면접관들에게 '같이 일하고 싶은 동료’라는 이미지를 주는 것은 지원자의 역량이 가장 클 것이지만 그것을 100% 보여줄 수 있는 좋은 질문들과 대화를 이끌어내는 것이 쉽지 않다는 것이다. 그리고 그 결과들을 통해서 함께 하고싶은가? 라는 질문에 대한 결정을 하는 것도 쉽지 않다. 면접을 보고 두 시간을 넘게 같이 면접을 본 동료와 고민하기도 했었다. 이런 모든 과정에서 같이 팀을 만들어나가는 경험으로서 값진 고민들을 많이 할 수 있었다. 사실 ‘내가 면접관으로써 충분한 역량을 갖고 있는가?’ 라는 질문에는 아직 답을 잘 못하겠지만, 아무튼 최선을 다했다!</p>
<h4>동기부여</h4>
<p>하지만 나는 개인적으로 올 해 '일’에 대한 동기부여를 크게 받지는 못했다. 나름 노력은 했는데 자연 발생(?)하는 동기부여와 노력으로 얻은 동기부여는 조금 다르다. 자연산이 아니라 양식 동기부여(…)같은 느낌이라고 설명하면 적절한 비유가 될 것 같다. 물론 동기부여를 양식으로 얻을 수 있는 것도 중요하다. 앞으로 일을 하면서 모든 일들이 재미있고 내가 하고싶고 강한 동기부여를 느끼고 하지는 않을 테니까. 개발자이면서 회사원으로써 일을 지속가능하게 하기 위해서는 스스로 동인을 계속 찾아야 한다. 그게 아니면 그냥 부품처럼 일하게 되는 거라고 생각한다. 그런 맥락에서 올 해는 그런 것들을 잘 연습할 수 있었다. 정신승리도 승리다! 아무튼 내가 하는 일을 사랑할 수 있도록 끊임없이 노력해야 한다. (너무 괴롭지 않은 선에서)</p>
<h4>파운데이션크루</h4>
<p>크루 특성상 하나의 제품을 맡지 않고, '제품 전반’이라는 모호한 범위를 담당해야 하기 때문에 크루원이 모두 한 가지 목표에 집중하기 어려웠다. 이런 저런 상황들이 고려되어 9월달 부터는 코어크루에서 파운데이션크루로 크루명도 변경했다. 올 해 상반기는 크루 내 메인태스크로 '투데이 탭’을 개발했는데 웹은 스콥아웃이 되어서 굵직한 태스크는 없었다. 그래서 CS 혹은 사업팀 요청사항들을 개선해주는 등 지원업무가 많았어서 보니까 위에서 말한 것 처럼 동기 부여가 쉽지 않았다. 이런 과정에서 그냥 할 수 있는 태스크들을 내가 어렵게 해보는 등의 노력을 좀 더 했으면 좋았을 걸 하는 아쉬움도 있다.</p>
<h4>ISMS-P</h4>
<p>하반기 크루 태스크는 ISMS-P 대응을 위한 작업이 메인이었다. 내가 주도적으로 진행했던 태스크는, 1. 기존 어드민의 Internal API를 모두 API Gateway로 옮기는 작업, 2. 구버전 어드민의 채용관련 기능을 모두 옮겨오는 작업, 3. 제품 전체에 환경변수를 인프라단계에서 주입하도록 변경하는 작업 이었다.</p>
<p>API Gateway 적용 작업은 정말 공교롭게도 이전에 내가 어드민에서 내부 API를 처리하는 방법을 일원화하는 작업을 했었는데 그게 도움이 되어서 생각보다 빨리 끝낼 수 있었다. 그리고 구버전 어드민 이전에서는 반복되는 UI와 Form에 대해서 추상화된 구조를 정의한 뒤 작업하여서 그나마 순조롭게 진행할 수 있었다. 또 View에서 사용했던 테이블을 다시 추상화해서 Form 내부에서 활용해야 하는 상황이 있었는데 이 때 컴포넌트 구조에 대한 고민을 많이 할 수 있었다. 마지막으로 전품 전체에 대한 환경변수 처리에 대해서는 빌드타임과 런타임이 인프라 내에서 어떻게 처리되고 빌드타입에서 주입된 환경변수들이 Next.js내에서 어떤 식으로 Resolve되고, 실제로 빌드된 서버가 동작할 때 어떤 상황에서 빌드타임 환경변수와 런타임 환경변수를 참조하는지 명확하게 이해할 수 있었다. 그리고 같이 해결한 것 중 하나가 기존에 ECS가 아니라 EC2에 PM2로 서버를 띄우던 서비스가 있었는데 해당 프로젝트를 데브옵스 팀에서 ECS로 옮겨주셔서 거기서 내가 PM2를 걷어내는 작업을 진행했고 덕분에 기존에 갖고있던 환경변수 주입 타이밍 이슈로 SSG페이지를 생성하지 못했던 문제를 같이 해결할 수 있었다. 환경변수 관련 작업에서는 인프라와 컨테이너 전반에 대한 경험을 많이 할 수 있어서 좋았다.</p>
<hr>
<p>2022년 까지는 확실히 회사에서 얻을 수 있는 성장들이 많았는데 2023년은 개인의 노력으로 얻어야 하는 성장의 비율이 늘어났다. 그 과정에서 솔직히 방황하면서 보낸 시간들이 있었지만 그게 절대 낭비라고 생각하지는 않는다. 덕분에 엄청 많은 고민들을 할 수 있었고 무조건 필요한 시간이었으니 차라리 2년차 개발자일 때 깨달아서 다행이라고 생각한다. 물론 아직 진행중인 고민들도 엄청나게 많다. (진짜 엄청 많다) 그러므로 2023년은 문제정의의 해라고 생각하고 2024년은 그 문제들을 하나씩 격파하는 해가 될 것이라는 기대감을 가져봐야겠다. 아무튼 2024년, 멋지게 보내보자! 아뵤뵷~!</p>


3년차 프론트엔드 이직기록

View Transition API 알아보기

NoInfer 알아보기

2023년 회고