오랜만에 회사에 면접 지원이 들어왔다. 그동안 꽤 많은 분들의 면접자들을 만나봤는데, 문득 이런 생각이 들었다. '나는 좋은 면접관인가?'

나는 경력이 길지 않다. 하지만 회사의 개발자 수가 많지 않다보니 나도 면접관으로서 참여한다. 면접관으로서 면접자에 대한 질문을 준비해야 하는데, 처음엔 면접 질문을 검색해서 찾아봤다.

그런데 이런 생각이 들었다. '이런 질문은 정말 의미가 있는가?'

나는 왜 면접을 보는지 좀 더 자세하게 알고 싶었다. 면접자의 지식을 평가하기 위해서? 면접자의 성격이 좋은지 알기 위해서??

지식은 중요하지만 운 좋게 그분이 아는 질문만 했는지 알 수가 없다. 그리고 그 지식이 진짜 우리 회사에 도움이 되는 질문이 아니기도 했다. 또한 그 사람의 성격이 실제론 어떤지 짧은 시간 안에 모두 아는 것은 쉽지 않다. 그렇다면 어떻게 해야 할까?

소프트웨어 장인 면접하기

CTO님께서 추천해주신 '소프트웨어 장인' 도서를 읽다가 '소프트웨어 장인 면접하기' 라는 챕터를 보게 되었다.

이 챕터를 보고 후다닥 읽어봤다. 이 챕터에선 좋은 면접은 무엇이고, 우리 회사에 정말 도움이 되는 사람은 어떻게 알 수 있는지에 대한 것이 잘 나와있었다. 그리고 나는 내 과거를 반성했다.

이 책에선 좋은 면접을 위한 다양한 방법을 제시한다. 그런데 나는 이 중에서 '올바른 집중' 부분이 크게 와닿았다.

'우리의 핵심 가치는 무엇인가?' '더 잘하고 싶은, 더 나아지고 싶은 것들은 무엇인가?'

새로운 사람을 채용하기 전엔 이러한 질문을 먼저 던져야 한다.

무언가를 개선하고 시고, 도입하고 싶은 것들이 있을 때 새로 채용될 개발자는 그런 것을 성취하기 위한 지원군을 뽑아야 한다.

개발 방법론을 가치있게 여긴다면 면접 과정에서 그런 내용이 포함되어야 하고, 설계 개선이 필요하다면 그 스킬에 대해서 자세하게 물어봐야 한다. 우리 팀에 열정을 불어넣어줄 사람이 필요하다면 열정 가득한 사람을 선별해야 한다.

전혀 상관도 없는 사항들을 확인하느라 면접 시간을 낭비해서는 안된다는 것이다.

그런데 과연 내 과거 질문들은 그러했는가?

이번 면접은 정말 꼼꼼히 준비하기 위해 노력했다. 질문 수는 그 전보다 줄었지만 질문 하나 하나가 우리 회사에 도움이 되는 분일지 확인하기 위한, 그리고 지원자의 개발에 대한 애정이 진심인지 확인하기 위한 질문으로 구성했다. (물론 예상치 못하게 불필요해진 질문도 있었다)

그리고 그러한 질문을 바탕으로 아주 즐거운 면접이 진행됐다. 물론 내 질문 때문이기 보다 면접자 분이 솔직하게 이야기해준 덕분이라고 생각한다.

어쨋든 오늘의 면접은 매우 가치있었다.

현재 회사 프로젝트를 진행하면서 사업팀의 초기 기획과 너무 많은 것이 바뀌어버렸다.

예를 들면, 초기에 '순위의 변동'을 꼭 저장해놓아야 한다고 했기 때문에 '순위 로그'를 DB에 계속 저장하는 상황이었다. 하지만 현재는 순위의 변동을 아예 사용하지 않고 있다. 또한 상품에 필요한 정보라며 모두 저장하라고 했던 데이터들이 지금 와선 거의 쓸모가 없어졌다.

이처럼 갑자기 추가된 정보, 사라진 정보들이 꽤 많았다. 뿐만 아니라 현재 db구조가 초기 기획 의도에 맞춰져있다보니 현재와는 맞지 않는 경우도 많았다. 그래서 개발팀에서는 db 구조를 재설계하기로 했다.

mongodb의 구조를 재설계하는 원칙

개발을 시작하고 처음 사용했던 데이터베이스는 MySQL과 같은 관계형 데이터베이스였다. 관계형 데이터베이스의 스키마를 디자인할 땐 정규화 과정을 통해 데이터를 중복되지 않게 만드는 것이 매우 중요하다고 배웠다. 하지만 스키마에 대한 제약이 있기 때문에 스키마를 수정하기는 어렵다는 단점이 있다.

그러나 mongodb와 같은 비관계형 데이터베이스의 경우 스키마의 변경이 자유롭다. 개발팀에서는 이미 초기 프로젝트 상 많은 변경이 있을 거라고 예상하고 mongodb를 사용했기 때문에 이번 스키마 변경은 크게 부담스럽지 않았다.

그렇다면 mongodb를 설계하는 원칙은 보통 어떻게 될까? 일반적으로 Embedding 방식과 referencing 방식이 있다.

영어라 어려워보이지만 사실 Embedding은 하나의 테이블에 필요한 정보들을 모아놓는 것이고, referencing 방식은 마치 관계형 데이터베이스의 foreign key로 서로 참조하도록 하는 것과 같다.

이 원칙을 기본으로 현재 우리 db의 스키마 변경 원칙을 다음과 같이 세웠다.

1. 조회 시 항상 함께 사용하지만 현재 분리되어있는 정보들은 Embedding 방식으로 변경한다.
2. 조회 시 굳이 함께 있을 필요 없는 정보들은 referencing 방식으로 변경한다.
3. 불필요한 필드 및 데이터는 모두 삭제한다.
4. 데이터에서 혼란을 주는 부분을 변경한다. (초기 버전에서는 혼란스럽지 않았지만 현재는 혼란스러운 구조가 있었다)

이제 이 기준을 가지고 이제 전체 스키마를 점검 후 재설계를 하려고 한다.

이제 시작이므로 완성이 되면 다시 관련 글을 작성해보려고 한다.

그리고 Image는 Next Image를 사용하고 있는데, Next Image는 이미지 최적화를 프론트엔드 개발자가 신경쓸 필요가 없다는 점에서 매우 큰 장점을 가지고 있다.

하지만 lazy loading이 걸림돌이 되었다. 현재 서비스에서는 한 페이지에 많은 이미지들을 보여주고 있다. 그런데 이미지들이 화면에 보여지는데 lazy loading으로 인해 빨리 보여지지 않으니 사용자가 보기에 매우 느린 서비스라고 느낄 가능성이 있다.

그런데 github issue를 확인해보니 Nextjs 10 버전 이후에 production 버전에서 lazy loading이 많이 느려졌다는 글을 보게 되었다. 그 이유는 기존에 built in 되어있던 패키지인 sharp가 빠져있고 다른 패키지를 사용하고 있기 때문이라고 한다.

뿐만 아니라 lazy loading이라고 하더라도 더 빠르게 화면에 보여줄 수 있는 방법들을 확인할 수 있었다. (cache, next config 설정 등)

회사에서 이 부분을 적용 후 실제 속도가 얼마나 빨라지는지 한 번 측정해볼 필요가 있을 것 같다.

바로 NextJS의 hydration error 였다.

hydration error는 SSR(Server side rendering)을 통해 만들어진 html 파일에 javascript 이벤트를 등록하던 중 태그의 위치가 맞지 않거나 변경되어 제대로 이벤트를 등록하지 못하는 상황에서 발생하는 에러이다.

하지만 아무리 문서를 뒤져봐도 코드에는 문제가 없어보였다.

심지어 에러가 항상 발생하는게 아니고 10번 중에 한 번 간헐적으로 발생했기 때문에 에러를 찾기가 쉽지 않았다.

그래도 포기할 수는 없었다. 우리 서비스에서 가장 많이 발생하는 에러가 바로 hydration error였고, 그 에러를 계속 뒀다가는 점점 문제가 커질 것이라고 생각했기 때문이다.

우리는 여러 가지 방법을 시도해봤다.

hydration error가 발생했을 때의 SSR로 제공된 파일과 CSR을 하나하나 비교해보기도 하고, 네트워크 혹은 CPU에 과부화가 온 것은 아닌지 확인하기도 했다. 다른 여러 가지 방법들도 시도해봤지만 큰 문제가 없어보였다.

코드를 최소한으로 두고 발생하는 조건을 찾아보기로 했다. 그리고 가끔이지만 발생하는 조건은 바로 recoil에서 비동기로 api를 요청하는 부분이었다. 비동기로 감싸고 있는 컴포넌트는 NextJS의 dynamic import를 통해서 가져오고 있었다. 그리고 문서에 따라 dynamic의 옵션에 ssr: false 를 설정했다.

recoil 문서와 nextjs문서 상에서는 비동기로 가져오는 부분에서 문제가 없어보였다.

recoil 비동기 요청 방법: https://recoiljs.org/docs/guides/asynchronous-data-queries/ nextjs dynamic import: https://nextjs.org/docs/advanced-features/dynamic-import#with-no-ssr

그런데 한 가지 걸리는건 nextjs의 버전이었다. 우리는 nextjs의 12버전을 사용하고 있었다. 그리고 nextjs 12버전의 dynamic 코드 부분을 뜯어봤다.

그런데 확인해보니 이상한 점이 있었다. nextjs dynamic 부분에서 ssr을 false로 설정할 경우 react의 lazy를 이용하여 동적으로 가져오는 것으로 알고 있었는데, 그냥 null을 반환하는 것이 아닌가.

그리고 13버전의 코드를 확인해보니 같은 조건에서 Suspense와 React.lazy를 사용하고 있었다.

이 부분에서 nextjs 12 버전에서는 Suspense가 제대로 적용되지 않았을 가능성이 높다고 생각했고, 이번 기회에 13버전으로 업그레이드 후 배포해보았다. (13버전으로 업그레이드 하려면 꽤 많은 부분을 변경해야 해서 언제 해야하나 간을 보고 있었는데, 이번 기회에 업그레이드를 했다)

그런데,,,, 배포 후 더 이상 hydration error는 발생하지 않았다.

아무리 새로고침을 하고, 다시 들어가보아도 sentry에서는 어떤 메세지도 오지 않았다.

드디어 계속 해결하지 못했던 부분을 해결한 것이다.

CTO님의 조언과 팀원들의 도움이 정말 컸다.

드디어 끈질겼던 이 에러에서 해방이라는 생각에 매우 기쁜 하루였다.

그런데 특정 에러는 꽤 오랫동안 해결되지 않았던 에러이다. 지금까지 계속해서 잡으려고 노력했지만 너무 간헐적으로 발생하던 에러다보니 쉽게 해결되지 않았다.

하지만 이번 기회에 제대로 잡아보고 싶었다. 오늘은 하루종일 '어떤 조건'에서 발생하는지 찾는 시간이었다. 무조건 발생하는 에러가 아니라 너무 간헐적으로 발생하는 에러다보니 그 조건을 찾는 것이 쉽지 않다.

하지만 아쉽게도 그 조건을 찾지 못한 하루였다. 하루 종일 하나에 매몰되어 있었더니 조금은 지친 하루였다. 그래도 끝까지 파고든다면 꼭 잡을 수 있을거라고 믿는다.

루틴을 유지하는 것은 거대한 목표를 차근차근 이룰 수 있는 토대가 되기 때문이다.

나는 매일 하던대로 했는데, 나중에 시간이 지나고보면 꽤 많은 것을 이룬 상태가 된다. 뿐만 아니라 나 자신에 대한 자신감과 뿌듯함이 이루 말할 수 없을 것이다.

하지만 루틴을 만들어놓고, 루틴을 지키지 못하는 일이 발생한다. 예를 들면 지하철 출근 길에 책을 읽으려 했지만, 밤에 잠을 늦게 자서 지하철에서 잠만 잔 경우다.

하지만 누구나 루틴을 정착시키는데는 시간이 걸린다. 일주일에 한 번씩 점검하는 기간을 만들고, 좀 더 루틴을 잘 지킬 수 있는 방법을 고안해야겠다.

단순히 if else를 좀 더 깔끔하게 만드는 법, 자바스크립트 메서드 사용시 에러가 발생할 수 있는 부분을 미리 이야기해주는 것, 변수명이 난해한 것 등 부분적으로만 피드백을 하는 것이 가능하고, 전체 변경 파일을 보고 흐름을 이해하는 것은 쉽지 않다.

그래서 우리는 더 이상 다짜고짜 코드리뷰를 요청하지 않는다. 코드리뷰를 받고 싶은 부분 혹은 의심스러운 부분에 comment를 달아 코드 리뷰어에게 제대로 질문한다.

이 방법은 매우 도움이 된다고 생각한다. 실제로 질문을 하는 당사자도 본인의 코드를 보면서 다시 한 번 정리를 하는 계기가 되고, 코드 리뷰어 역시 명확하게 무엇을 궁금해하는지 인식하고 제대로 답해줄 수 있다.

즉, 코드 리뷰를 받고 싶은 사람과 코드 리뷰를 해주는 사람의 충분한 상호작용은 서로에게 도움이 될뿐만 아니라 더 효율적이라고 생각한다.

그래서 나는 요즘 내 생각을 대충 글로 쓰면서 정리하는 습관이 생겼다. 내 생각의 흐름을 글로 작성하다보면 집중력이 높아진다. 어떤 어려운 문제를 맞닥뜨렸을 때, 내 생각의 흐름을 하나하나 정리한다. 그리고 어떤 생각이 타당한지도 적는다.

만약 두 가지의 선택지에서 고민하고 있을 경우, 각 선택지의 장단점을 생각한다. 그렇게 정리하다보면 하나의 선택지를 결정하기 매우 쉬워진다.

항상 문제를 해결할 때는 정리하면서 타당한 결정을 하려고 노력하자.

기록하는 습관으로 인해 개인으로서, 그리고 팀으로서 좋은 성과를 낼 수 있다.

한꺼번에 여러 가지 일을 하는 중 또 다른 요청사항이 들어오기도 한다. 그럴 때마다 채팅창에서 이런 저런 토론을 하기도 한다. 그리고 어떤 결론에 도달한다. 그런데 이런 결과가 나오긴 했지만 제대로 정리하지 않으면 나도 모르게 채팅의 결과가 왜곡되거나 기억이 나지 않기도 한다.

그렇게 되면 서로 소통을 했음에도 불구하고 잘못된 결과물을 만나기도 한다. 즉, 항상 적어야 한다. 아무리 바쁘더라도 내가 해야할 일, 결정된 일은 항상 기록해야 한다.

기록하면 생각이 명확하게 정리되고, 생각이 명확하게 정리되면 우선순위 파악이 훨씬 수월해진다.

항상 기록하는 습관을 가지도록 해보자.

다른 사람의 코드를 읽을 수 있는 능력을 지니고 있다면 코드를 수정할 때 빠르게 수정 가능하며, 버그 발생 가능성을 줄일 수 있다.

또한 라이브러리 문서에서 분명 지원한다고 하는 기능이 왜 생각처럼 동작하지 않는지 확인할 수 있다.

최근에는 nextjs 문서에서 지원한다고 하는 기능이 생각처럼 동작하지 않아서 코드를 확인해봤더니 13 버전에서는 제대로 동작하고 12 버전에서는 일부 코드가 빠져있는 것을 확인했다.

또한 carousel 라이브러리에서는 특정 속성이 내가 생각했던 대로 동작하지 않아 코드를 분석했더니, 내가 생각한 것과는 다르게 동작했다.

다른 사람의 코드를 읽는다는 건 정말 어려운 일이지만 개발자에겐 피할 수 없는 일이다.

다른 사람의 코드를 잘 읽는 것, 그리고 더 나아가 내 코드를 읽기 쉽게 만드는 것이 매우 중요하다.

하지만 편안함이 너무 오래 지속될수록 그 편안함이 마치 당연한 것이 된다. 편안하지 않으면 항상 도망치게 된다. 새로운 도전은 점점 하지 않게 된다.

너무 루즈해지면서 더 새로운 것을 할 의욕이 사라지게 된다.

즉, 어려운 일이 있다는 건 삶의 의욕을 더 고취시키고, 더 성장할 수 있는 계기이다.

항상 잘 만들고 싶지만, 빨리 만들어 달라는 요청이 들어온다.

개발자 입장에서는 버그 없는 코드, 읽기 쉬운 코드를 위한 고민이 필요하지만, 사업팀 입장에서는 최대한 빨리 결과물이 나오고, 그 결과물을 테스트 해보고 싶어한다.

경력이 많거나, 경험이 아주 많으면 빨리 만드는 것과 잘 만드는 것을 둘 다 할 수 있겠지만 아직은 두 가지를 동시에 하는 것은 쉽지 않은 것 같다.

하지만 확실한 건 개발자로서의 욕심 때문에 무조건 사업팀의 요구를 무작정 무시하는 것은 절대로 좋은 생각이 아니다. (물론 개발자를 공장에서 찍어내는 기계처럼 대하지 않았을 때를 말한다)

결국 개발자의 핵심 역할은 사업이 잘 될 수 있도록 원하는 방향대로 구현하는 일이기 때문이다.

즉, 빨리 만들되 시간이 날 때마다 자주 리팩토링하는 습관을 들이는 것이 좋지 않을까 생각한다.

아무리 봐도 사용자에게 부정적인 경험을 줄 것 같은 UI 때문이었다. 좀 더 자세히 이야기하자면 화면의 컴포넌트 로딩 중 화면이 크게 변경되는 문제였다.

데이터가 없어 화면에 보이지 않다가 데이터가 생기면 갑자기 데이터가 엄청 많이 생기다보니 로딩 전, 로딩 중, 로딩 후 화면 모습이 너무 크게 바뀌었다.

회사에서 사용하고 있는 프레임워크의 가이드에 적용을 했다고 생각했지만 실제로 그렇게 적용되지 않았다.

분명 공식 문서 상에는 비동기 처리가 필요한 컴포넌트가 완전히 로드되기 전에 대체 컴포넌트를 보여준다고 했지만 아주 짧은 시간 동안 그 컴포넌트가 사라져버리는 문제였다.

그 문제를 해결해보기 위해 내가 문서를 혹시 잘못 읽은 건 아닌지, 그리고 내부 코드가 내가 생각했던 것과 다른 건 아닌지 정말 많이 뒤져봤다.

하지만 모두 똑같은 말 뿐이었다. 내가 적용한 대로 하면 문제가 없다는 듯한 글이었다.

하지만 오늘도 여전히 하루 종일 붙잡고 있던 결과, 문제를 찾고 결국 좀 더 좋은 UI를 제공할 수 있게 되었다.

비록 꽤 오랜 시간을 사용했지만 그 과정에서 많은 공부를 했다는 점에서 만족한다. 또한 해결되지 않을 것 같은 그 불편한 느낌을 참고 끝까지 해냈다는 점에서 나 자신이 자랑스러웠던 하루였다.

새로운 기술이 나왔다고 해서 읽어보지만 그 기술의 공식 문서는 낯선 용어들의 집합소이다.

특히 개발 경험이 부족할수록 더 어려워한다. 경험이 부족할수록 문서를 읽는데 어려움이 있다보니 쉬운 글들을 많이 찾게 된다.

물론 쉬운 글은 필요하다. 하지만 안타깝게도 구현해야 하는 난이도가 높아질수록 쉬운 글은 거의 없다고 보면 된다.

하지만 계속해서 어려운 글을 피하면 결국 연차가 쌓일수록 불안해진다. 제대로 이해하지 못하고 기술을 막 사용하다보면 내부 동작이 어떻게 돌아가는지, 왜 이렇게 되는지 모르게 되고, 결국 문제가 생기면 고치기가 더 힘들어진다.

꽤 많은 사람들이 이런 문제를 가지고 있을거라고 본다. 물론 나도 아직 그 단계를 벗어나지 못하고 있다.

이렇게도 해보고, 저렇게도 하면서 오랫동안 삽질을 하다가 겨우 겨우 하나를 이해하곤 한다.

그러나 이런 과정에서 대충 대충 넘어간다면 미래의 나는 100% 후회할 것이다. 아직은 당연히 쉽지 않다. 누구나 그렇다.

그 어려움을 견뎌내는 사람이 나중에 진짜로 잘하는 사람이 된다.

회사 동료분과 함께 헬스장을 끊었다. 몇 년 전만 해도 운동을 정말 좋아하고, 하지 않으면 불안해했는데, 이제는 하기가 너무 싫다.

하지만 운동을 꽤 오랫동안 하지 않으면서 어떤 일을 하든 추진력이 부족하다는 것을 알았다.

이제 드디어 운동을 다시 시작해보려고 한다. (과연 얼마나 갈지... ㅎ)

얼마나 갈지 모를 일이지만 새해를 맞아 운동을 꾸준히 가기 위해 노력해보자

개발자들은 항상 학습해야 한다. 주니어 개발자들은 지식이 많이 부족하기 때문에 학습해야 하고, 시니어 개발자들은 회사에 가장 필요한 기술을 적절한 곳에 사용하고, *주니어들을 리드하기 위해 *많은 것들을 학습해야 한다.

모든 개발자들은 항상 공부한다. 하지만 모든 개발자들이 효율적으로 학습하는 것은 아닐 것이다.

나를 포함해 많은 사람들이 하는 실수는 다음과 같을 것이다.

1. 책을 사서 끝까지 정독한다.
2. 강의를 구매하고 한 번만 듣는다.
3. 목적은 없지만 트렌드니까 기술을 적용해본다.

비효율적인 학습의 문제점

책 정독

책을 사서 끝까지 정독할 수 있는 사람은 정말 끈기 있는 사람이라고 생각하고 존경한다. 하지만 책만 정독하는 건 정말 비효율적이라고 생각한다. 사실상 책에는 정말 많은 정보가 들어있고, 그 모든 정보를 다 학습하기에는 너무 오랜 시간이 걸리기 때문이다. 결국 필요할 때, 참고하는 용도로 사용하게 된다. 거의 사전처럼 쓰게 되는 느낌이다. 내가 구매한 <딥 다이브 자바스크립트> 책이 딱 그렇게 쓰이고 있다...

강의 한 번만 보기

강의는 실제로 코드를 작성하면서 연습할 수 있어서 꽤 효율적인 방법이다. 하지만 한 번만 보는 건 거의 쓸모가 없다. 사람의 기억력으로는 한 번만 본 강의를 거의 기억할 수 없기 때문이다. 코딩을 처음 공부하기 시작했을 땐 거의 한 강의를 4번 정도 반복했던 것 같다. 아무리 봐도 이해하기 어려웠기 때문이다. 강의를 4번째 보기 시작할 때쯤에야 그나마 어떻게든 사용할 수 있었다.

하지만 취업 후 시간이 부족하다는 핑계로 강의를 구매해도 여러 번 반복하지 않았다. 한 번만 완강하는 것도 뿌듯하게 여기고 다음에 뭐할지 찾아보곤 했다. 그러나 이렇게 공부한 내용들은 지금 거의 기억나지 않는다. 결국 '나중에 다시 또 봐야지' 라는 헛된 희망을 품게 된다. ~내 돈... ㅜㅠ~~

목적 없이 기술 적용하기

정말 빠른 속도로 새로운 기술들이 나온다. 새로운 기술들이 나오면서 많은 사람들이 빠르게 적용해본다. 그런데 보통 새로운 기술들은 문서가 방대하다. (깔끔하고 짧은 문서도 있지만 프레임워크는 문서 내용이 많을 수밖에 없다고 생각한다)

처음부터 모든 걸 적용하려고 하면 무엇이 중요한지, 이 기술의 진짜 장점이 무엇인지 이해하지 못하곤 한다. 그렇게 되면 결국 동기부여를 잃고, 기술의 진짜 면모를 익힐 수 없을 것이다.

학습 프로세스 적용의 중요성

항상 어떤 일을 하든 본인만의 프로세스가 정말 중요하다고 생각한다. 프로세스가 있으면 쓸 때 없이 고민하는 시간과 의지력을 소모할 필요가 없다. 그리고 좋은 프로세스는 매우 효율적이다.

책 <소프트스킬>에서는 저자가 본인이 지난 수년간 새로운 기술, 언어, 프레임워크 등을 빠르게 익히기 위한 독학용 반복 시스템을 개발했다고 한다.

이 프로세스는 10단계로 구성되어 있는데, 제대로 적용한다면 정말 효율적이면서도 제대로 학습할 수 있을 것 같다.

10단계를 간단하게 작성하면 다음과 같다

1단계: 큰 그림을 보라 2단계: 범위를 정하라 3단계: 성공을 정의하라 4단계: 자료를 찾아라 5단계: 학습 계획을 세운다 6단계: 자료를 선별하라 7단계: 대충 사용할 수준까지 배워라 8단계: 놀아라 9단계: 유용한 일을 할 정도까지 배워라 10단계: 가르쳐라

얼핏보면 엄청 많아보이지만 당연히 해야하는 것들로 구성되어 있다. 나 역시 이렇게 블로그로 정리하면서 내 학습 프로세스를 제대로 구축하고 싶다.

다음 포스팅에는 각 단계에 대한 자세한 방법을 정리해보려고 한다.

'이번 주말은 이것도 하고, 저것도 하고, 또 저것도 해야지!'

하지만 대부분 계획만 많지 뿌듯하게 해낸 일 없이 주말이 다 지나간다.

그러나 최근에 읽은 <몰입>과 <소프트 스킬> 이라는 책을 읽으면서 하나를 제대로 집중하는 것의 중요성을 다시금 깨닫고, 모든 계획을 다 실천하지 못하더라도 하나라도 제대로 끝내자고 다짐했다.

그리고 오늘 하나의 일을 끝내기 전까지 다른 일을 하지 않겠다는 마음으로 계속 해봤다.

결국 약 4~5시간 만에 그 일을 제대로 해냈다.

아마 오늘도 마음만 급했다면 이것 저것 조금씩 건드렸다가 끝나는 하루가 아니었을까 싶다.

매일 조금씩, 그리고 제대로 해내는 하루하루를 보내 보자

우리 회사의 개발자 면접에서는 '30분 라이브 코딩'과 '기술 면접' 두 가지를 실시한다.

라이브 코딩은 사실 매우 간단한 문제이지만 지금까지 문제를 해결한 사람은 1, 2명 정도밖에 없었다.

아마 30분 이라는 짧은 시간에 대한 압박과 앞에 우리가 앉아있다는 것 때문에 긴장하시다보니 제 실력을 보여주지 못하는 것 같다. 나도 그 상황에선 얼마나 긴장될까 싶다.

그래서 우리는 '해결을 하는가' 보다는 '문제를 어떻게 접근하는가'에 좀 더 초점을 맞춘다.

라이브 코딩 과제는 버그가 있는 간단한 앱을 고치는 것인데, 우리가 말해주는 문제를 듣고 어떻게 해결하는지에 더 초점을 맞춘다.

1. 문제가 무엇인지 제대로 이해했는가
2. 문제의 원인을 분석하는가
3. 모르는 부분은 검색해서 찾아보는가

어떤 버그가 있는지는 우리가 다 말해주기 때문에 누구나 다 이해할 수 있을 것이다. 하지만 보통 문제의 원인이 무엇인지를 파악하지 않고, 바로 모든 코드를 처음부터 끝까지 다 읽어보는 분들이 많다.

다 읽기 시작하는 그 순간부터 문제를 30분 만에 해결하는 건 불가능하다고 보면 된다.

기술 면접에서는 아주 기본적인 지식 정도만 물어보고, 일을 하는 태도를 좀 더 많이 물어본다.

면접을 하다보면 '이 사람이 일에 대한 고민을 많이 하는 사람이구나' 라는 것이 한 번에 느껴진다.

물론 학생으로서의 경험만 있으면 그런 고민을 할 시간이 많이 부족하다. 나도 그랬으니 말이다. 나는 첫 면접에서 어떤 회사가 좋냐고 했을 때 "많이 질문하면 받아주는 회사가 좋습니다." 라는 어린이 같은 대답을 했다... 그리고 바로 광탈했다. ㅎ

하지만 본인만의 성장 목표, 일에 대한 열정이 있는 분들은 대답 하나 하나가 진심으로 느껴진다. 솔직하게 말씀하시는데 '와 이사람 찐이다...' 라는 생각이 든다. 면접관이지만 면접을 하면서도 많이 배운다.

많이 부족하지만 나름 면접관으로서 면접자들을 만나다보니 나는 어떻게 해야 하는가가 더 명확히 느껴졌다.

2023년은 더 성장하는 내가 되었으면 좋겠다.

npm(node package manager)은 노드js 환경에서 개발하는 분들은 모두 다 알고 있는 패키지 관리자이다.

아래 사이트에 들어가면 npm을 통해 정말 수많은 패키지들을 설치할 수 있다는 것을 알 수 있다. https://www.npmjs.com/

그러나 너무 많은 패키지들이 있다보니 _어떤 패키지를 사용할 것인가? _에 대한 고민을 할 수밖에 없다. 왜냐하면 비슷한 기능을 하는 패키지가 정말 많기 때문이다.

특히 한국 블로그를 검색하면 특정 기능을 위해 모두가 똑같은 패키지를 이용해서 똑같은 코드로 만드는 것을 많이 볼 수 있다. 그래서 더 좋은 패키지를 찾는데 어려움을 겪는 분들이 많다.

그래서 비슷한 기능을 하는 패키지들을 비교할 수 있는 사이트를 소개하려고 한다.

바로 npmtrends 라는 사이트이다. https://npmtrends.com/

위 사진에서 알 수 있듯이 자신이 사용하려고 했던 패키지를 검색하면 다음과 같은 정보를 확인할 수 있다.

1. 비슷한 기능을 하는 다른 패키지들
2. 다운로드 수
3. 각 통계 수치 (Stats - stars, updated)

이 정보들을 활용하여 실제로 많이 사용하는지(인기가 많을수록 안정성이 높은 패키지일 가능성이 높을 가능성이 높다), 꾸준히 업데이트가 되는지, 패키지 크기는 어떤지 등을 확인하고 좀 더 선택을 쉽게 할 수 있을 것이다.

그런데 마음이 급할 때, 관련 버그에 대한 지식이 너무 부족할 때 (특히 신입 때) 문제를 '제대로' 해결하는 것이 아니라 이것저것 시도하면서 우연히 해결하게 될 때가 있다.

나는 이런 사람이었다.

하지만 이런 습관은 정말 좋지 않은 습관이다.

명확한 문제 파악과 그에 맞는 해결 방안을 도출하는 것이 아니라, '우연히' 해결하는데 의지할 수밖에 없기 때문이다.

이런 해결 방식으로는 항상 '불안감'을 가질 수밖에 없다. 우연에 기대야하기 때문이다.

최근 carousel 라이브러리를 사용하는데 문제가 있었다. carousel의 내부 태그 높이에 따라 높이 조정이 되지 않는 문제가 있었다.

dynamicHeight라는 속성을 통해서 높이를 자동으로 조절할 수 있도록 설계되어있는 라이브러리임에도 불구하고 높이가 제대로 조정되지 않았다.

그래서 그 문제가 무엇인지 소스코드를 뒤져보았다.

알고보니 dynamicHeight의 기준은 img 태그였다. img 태그의 높이에 맞추도록 코드가 짜여있었다. 나는 carousel 내부에 div 태그를 사용하고 있었고, 그 div 태그의 height에 맞게 조정되기를 원했다.

문제의 원인을 파악하고 나니 해결 방법을 명확하게 결정할 수 있었다. 내부 소스코드 자체를 바꿀 수는 없으니 새로운 라이브러리를 사용하는 것이 효율적일 것이라고 판단했다. (물론 더 좋은 방법이 있을지도 모른다)

그리고 같은 문제가 발생하지 않도록 새로운 라이브러리의 소스코드를 미리 파악했다.

사실 명확한 원인 파악은 문제 해결 과정에서 너무나도 당연한 과정이다. 그러나 개발 지식이 부족한 상태에서는 명확한 원인 파악을 하기 전에 '당황'을 하고, 급하게 해결하고 싶은 마음이 들곤 한다.

하지만 이제는 더 이상 그런 방법은 통하지 않는다. 더 나은 개발자가 되기 위해선 항상 '명확한 원인 파악'을 먼저 하도록 노력해야 한다.