KwonYG

Self Review

블로그 warm-up 포스트, 여태 했던 일과 기억남는 일 list-up

학부(2017~2020)

2017

  • 군 제대 후 2년을 휴학하고 복학.
  • 전공 공부외엔 딱히 특별한 걸 하진 않았고, 후배들과 얼굴이나 익히고 다시 학교생활에 적응하는 1년을 보냈다.
  • 그리고 연말에 학교에서 웹 기술 세미나들을 연속해서 개최했는데, 이걸 들으면서 보냈다.
    • linux 기초, 도커, git, HTML, CSS 등(당시에 못알아먹는게 더 많았는데, 그냥 들으러 갔다.)

2018

  • 1학기 쯤 네이버가 부스트에이스라는 실무형 온라인 교육프로그램을 운영한 적 있다.
    • 아직 실험단계라 무료로 코드리뷰와 온라인 교육을 받았고, 중간에 오프라인 교육도 있었다. -> 코드스쿼드의 크롱님이 프론트 담당이었다.
    • 웹 과정은 풀스택으로 진행되었고 내기억으론 당시 개발 스펙이(spring4, jsp, mysql, HTML, CSS, javascript)로 진행되었다.
    • 현직자 코드리뷰도 함께 진행되었었는데, 내 기억으론 실험단계여서 그런지 코드리뷰가 한달 가까이 진행되지 않은 적도 많고 시행착오가 많아 수료생이 많지는 않았을거 같다.(그래도 수료생이 아예 없진 않았다.)
    • 당시 첫번째 리뷰가 좋았던 기억이 나는데, 이때 리뷰가 나에겐 encourage로 작용했다.
    • 수료는 못했지만 '삽질' 인내심도 길러보고, 구글링 노하우도 나름 터득하고, 이쁘게 만들진 못했지만 어떻게든 만들어내는 경험을 쌓았다.
    • 개인적으론 부산에서 이런 교육은 접할 기회가 적어 잘되길 바랬지만, 더 이상 운영하진 않는거 같다.
  • 좀 특이하지만 학교에서 웹 프로그래밍란 수업이 있었다. 그리고 교수는 대학원 과정을 밟고 있는 실무자분이셨다.
    • 여러 컨퍼런스에서 발표경험이 있는 분이셨고, 개인적으로도 조언을 많이 구했다.
    • 수업은 spring boot, Thymeleaf, Jquery, hibernate를 이용해 Resume 사이트를 만들었다.
      • Thymeleaf, Jquery를 가르치고 싶어서 가르치셨다기보단 백엔드 개발자분이라 프론트는 React와 같은 존재만 알려주고, 저 기술 이제 안쓸거같으니까 react나 vue 공부하라고 하셨던게 기억난다.(지금 생각하면 소름)
    • 그리고 가끔 후배들이랑 이야기 나눌때, 이 분이 우리학교 학생 절반은 살린거나 다름없다는 말을 우스갯소리로 할 때가 종종 있다.
  • 이 해 첫 팀프로젝트가 경험을 쌓았다.(코드리뷰 서비스)
    • 부스트에이스에 영감을 받아 코드리뷰가 가능한 stackoverflow 느낌으로 프로젝트를 진행했다.
    • 코드 에디터로 codemirror 사용했고 여기다가 코멘트를 달 수 있게 API를 커스터마이징 하는 형태로 진행했다.
  • 18년 끝날때 쯤 친구1, 친구2가 연락이 왔다.
    • 고등학교때부터 친구이긴 했지만, 중간에 휴학을 길게해서 연은 크게 없었다.(지금은 만나면 제일 편하게 말나누는 사이)
    • 부산 오픈소스 머시기..? 정확힌 기억안나는데 어떤 그룹을 만드는데 같이하자는 이야기를 아웃닭에서 맥주를 마시면서 그간 안부와 함께 제안했었다.
    • 당연히 한다고 했고, 얼마안가 그룹은 흐지부지됐다.

2019

  • 부산 오픈소스 머시기는 잘 안됐지만, 친구1, 친구2와 개발공부는 계속했다.
  • 5월 중에 엔젤 핵 해커톤이 열린다고 해서 친구들과 사비로 기차표를 끊고 해커톤에 참가했다.
    • 참가하기 전에 이미 아이디어 구상과 프로젝트 진행은 어느 완성 되어 있었고, 해커톤 당일날 구현만 하면 되는 그런 상태라고 믿었던거(?) 같다
    • 해커톤 당일날 백엔드 쪽에 이슈가 생겼는데, 새벽될 때까지 잡히지 않았고 친구들이 지쳐보여 숙소로 보내고 혼자 대회장에서 백엔드 이슈가 해결되었다고 가정하고 프론트 개발을 계속했다.
    • 친구들이 아침에 대회장에 왔을 땐, 친구들은 이미 의욕이 많이 꺾인 상태였고 완성하지 못할거 같아 기권하고 사우나에 가서 피로를 풀고 부산으로 내려왔다.
    • 믿는다는 핑계로 내가 소통을 안한게 더 큰 원인이었지만, 당시엔 친구들한테 실망감이 더 컸고 혼자 공부하겠다고 선언했다.
    • 아량 넓은 친구들이 해커톤때 생긴 오해를 풀어줬고, 대회와 상관 없이 프로젝트를 다시 함께 시작했고 실제 서비스까지 했다. 그리고 그 서비스는 1년 동안 유지 됐다.(지금은 닫았고 리뉴얼 진행하다 중단된 front만 남았다.)
  • 여름 방학에 DnD 1기 모집을 부산에서 했다.
    • 처음엔 지역 개발자 지망생을 위한 비영리 단체였고, 1기때는 실험 단계인거 같았다.
      • 처음이었지만 운영이 체계적이었고, 운영진쪽에서 이탈율을 줄이기 위해 계속 개선해서 지금은 이탈율이 거의 없어보인다.
    • 후배1, 후배2, 후배3 과 함께 팀을 맺어 프로젝트를 만들었다.
    • 당시 기억으론 최종 발표 일주일 전까지 매칭시스템이 동작하지 않았던거 같은데, 그래도 랩실에서 야식먹으며 밤새가며 개발하는게 재밌었다.
    • 무사히 잘 끝났지만, 서비스를 운영하지는 않았다.
  • 그리고 본격적으로 이력서를 쓰기 시작했다.
    • 포트폴리오도 마음대로, 이력서도 내 마음대로 썼던거 같다.(지금은 이렇게 잔망스럽게 못하겠다.)

2020

  • 2020년 2월 졸업
  • 인턴을 끝내고 한 6개월 정도 재정비기간을 갖고 첫 직장에 커리어를 시작.

네이버 인턴 (2019.11 ~ 2020.01)

  • 급하게 고시원을 잡고 정자동에서 2개월간 생활했다.
  • 그때 했던 건 이런걸 했다.
    • 스마트렌즈 약식 구현
    • 빠른 길 찾기
    • 말줄임, HTML 태그 모듈 구현 및 성능 개선
    • 무한히 쌓이는 DOM 환경 렌더링 성능 개선
  • 당시 못했다고 생각했는데, 돌이켜보면 성과가 있었는데도 스스로 성에 안차서 어필도 못했고 혼자 타지생활에 감정적으로도 힘들었던거 같다.
    • 말줄임, HTML 태그 모듈 구현 및 성능 개선
      • 이진 탐색으로 되어있는 부분을 수식으로 2배 가량 빠르게 만들었고, Text 1개와 HTML 1개를 동일한 요소로 추상화해 공통로직으로 분리했다.
    • 무한히 쌓이는 DOM 환경 렌더링 성능 개선
      • Dom Recycle, Virtual-DOM 구현해 성능을 유지시키는데는 성공했는데, Virtual-DOM을 직접구현하는게 패착이었던거 같다. 이걸 구현하는데 시간을 다 썼다.
        • 지금 생각해보면 layout 이후의 과정을 줄이는데 집중했다면 훨씬 더 나은 결과가 나왔을거 같다.
        • 또 Virtual-DOM 에서 diff하고 나서 삭제할 JS-DOM들이 제때 GC에서 삭제되지 않아 GC 쪽에서 시간이 오래걸렸던거로 기억한다.
        • 당시 코드를 돌아가 볼 수 있다면 다시 살펴보고 싶다.
  • 이때 경험이 지금 요긴하게 쓰이는거 보니, 일할 때 감정은 순간이고 결과는 남는거 같다.

NHN 커머스 (2020.09 ~ 2021.11)

  • 당시 NHN 커머스에서 FE 개발팀 빌딩멤버를 구하고 있던 상황이었고, 면접때 나눈 대화는 기억 안나지만 관심사가 비슷하다는 기분이 들어 면접경험이 좋았던 기억이 난다.

    • 면접 프로세스가 쉽지는 않았는데, 서류 -> 전화면접 -> 화상 면접 -> 라이브코딩 -> 2차 면접 -> 최종합격 순이었다.

  • 이런거 했었다.

    • JSP 기반의 레거시 프로젝트를 Vue + TypeScript로 전환
      • 정확히는 중국쪽에서 진행한 프로젝트를 이어받아 개발했다가 맞을거 같다.
    • Jest, vue/test-utils
    • 주문 클레임쪽 케이스가 많아서 한번 수정하면 사이드이펙트 우려가 컸다.
    • 그게 귀찮아서 계산 케이스별로 테스트케이스를 짰었다.
    • standard-version, commitlint를 이용해 버저닝 및 체인지로그 자동화하도록 했다.
      • standard-version을 쓴 이유는, 그때 gitlab-ci를 건들 수 없었고 로컬환경에서 버저닝을 진행해야하는 상황으로 기억한다.
      • standard-version이 local git-repo에만 영향을 미치면서 버저닝 할 수 있는 유일한 선택지라 사용했다. 하지만 로컬에서 범핑하고 태깅하는 작업이 제법 귀찮았던거로 기억한다.
        • 그래서 remote 에서는 semantic-release가 유용하다고 README에 적혀있던거로 기억한다.
      • commitlint는 change-log 자동화를 위해 썼었다.
        • 편할거라 생각했지만 팀원마다 feature, fix, refactor 상황인지 생각하는 기준이 다르고, 그러다 보니 의미있는 change-log로 작성되지는 않았던거 같다.
        • release-note만 잘 관리하는거도 괜찮치 않나라는 생각이 지금은 든다.

  • 퇴사이유는 일이 힘들어서였다.

    • NHN 커머스에 있는 동안 먼저 다른 과업을 쳐내고 뒤늦게 ASAP로 합류하는 과정이 1년 동안(premium, pro, skin) 지속됐는데, 소모적인 개발이 지속되는 것이 적잖이 스트레스였다.
    • 스스로 스트레스 해소법도 찾지 못해, 그 어떠한 일에도 집중할 수 없을 정도로 지쳐버린 상태가 되었고, 후에 건강검진 자율신경계 검사에서 최악 단계를 받았다.
    • 후에 sony-store 진행하는 중 퇴사면담을 요청드렸다.
      • 기획자나 개발자 각자 사정이 있을 텐데, 그걸 이해하려기 보다는 상대한테 점점 부정적인 생각이 들기 시작했다고 말씀드렸다. 이게 딱히 팀원들에게도 좋은 영향을 미치지도 않을 거고 좋은 팀 분위기를 안좋게 만들거 같다고 말씀드렸다.
      • 개인의 문제라고 생각했는데, 팀장님은 개인의 문제라기 보단 조직의 일하는 방식에 문제가 있는거라고 하셨다. 차츰 바꿀 생각이고, 다시 업무 분장을 조정해 롤을 정리할 예정이라 하셨던거로 기억한다.
        • 실제로 그런 부분 변화를 시도하셨지만, 내가 이미 어떠한 일에도 집중할 수 없는 상태에 놓여있었다.

  • 지금 NHN 커머스 이야기를 들어보면 이후에 일정압박도 딱히 없고, 하고싶은 개발을 할 수 있는거 같아 보였다.

  • 팀에 개발에 진심인 팀원이 많았다. 아직도 몇명은 연락을 주고 받는 사이인데, 소식을 들으면 다들 여전히 열정적이고 이 때 팀원들은 어떤 형태로든 커리어 끝은 좋을거 같다는 생각이 든다.

  • 그리고 선퇴사 후 한달 쉬고 버킷플레이스로 이직했다.

버킷플레이스 (2021.12 ~ 현)

  • 6개월 동안 생각보다 다양한걸 했다.

  • 번들러 POC

    • '라이브러리' 번들링에 사용할 번들러를 검토해봤다.
      • code splitting: aplication 번들에 유용한 기능이라 비교대상에서 제외했다.
      • support esm,cjs: 트리셰이킹 여부를 위해 필요했다.
      • Non-Javascript resources support: 다른 리소스와 함께 번들해야하는 케이스가 발생할 수 있었다.
      • Output module format: webpack처럼 commonJS out format만 지원하면(지금은 esm이 공식지원되는지 확인 못해봤다) Tree Shaking 지원 되지 않았다.
      • transformation(support old browser): 조사 당시엔 IE 11을 완전히 drop한 상황이 아니라 고려했다.
      • Tree Shaking(Dead code elimination): 번들 최적화가 지원되어야 한다.
    • Webpack만 esm 방식의 Output module format을 공식 지원하지 않았고(당시 기준), 나머지는 3대 번들러(webpack, rollup, parcel)가 모두 지원했다.
    • 차세대 번들러 vite도 살펴보긴 했는데, next.js은 vite를 지원하지 않고, 라이브러리 모드에서는 딱히 이점이 보이지 않아 캐싱을 활용해 빌드타임이 가장 빠른 parcel를 사용하기로 했다.
    • 확실히 vite가 애플리케이션 개발에서 develop 할때 답답함이 없는거 같다.

  • 공통 모듈 번들러 환경 세팅

  • 어드민 esbuild-loader 적용

  • 인생 첫 전사발표

  • Jotai

    • atom 기반 상태 관리 라이브러리인데, 모든 기능을 사용해본건 아니지만 이런 생각이 들었다.
    • 아톰을 변경하는 부분도 action으로 취급 했었는데, 단순 아톰 업데이트를 action으로 취급하는건 useAtom이나 useUpdateAtom등 이미 아톰을 업데이트 할 수 있는 채널이 많은 상황에서 불필요한 액션들이 추가되는 기분을 받았다.
      • 그래서 액션은 여러 아톰을 update하거나 다른 비즈니스 로직을 포함하는 경우에만 action을 정의하기로 룰을 바꾸니, 액션의 수도 많이 줄어들었다.
    • atomWithStorage
      • 처음에는 LocalStorage를 사용할때마다 이 유틸아톰을 사용했는데, "로컬스토리지를 아톰처럼 쓰고 싶을 때 쓰기 좋고, 로컬스토리지를 대체할 용도로 쓰면 좀 불편"하다.
      • 이유는 로컬스토리지 자체는 리렌더를 기대하지 않는데, 이 로컬스토리지를 아톰처럼 동작하게 만드는 atomWithStorage를 쓰면 로컬스토리지가 변경될때마다 이 아톰을 구독하고 있는 컴포넌트들이 다 리렌더 된다.
    • 아톰조합
      • 큰 아톰을 사용하면 여러아톰이 필요한 경우 import 가 줄어들어 좋을거라 생각했다.
      • 근데 같은 같은 아톰을 쓰는데 어떤곳은 작은아톰 하나만 쓰고, 어떤곳은 큰 아톰에서 get해서 사용하게 되면서 아톰 접근 방법 채널이 2개 생기게 된다.
      • 그리고 단일 아톰 1개만 업데이트하더라도, 만약 업데이트한 아톰이 큰아톰 조합에 쓰인다면, 큰아톰을 쓰고 있는 컴포넌트들이 다 리렌더되었다.
      • 아톰을 만들어 쓸려면 룰이나 바운더리에 고민이 필요할거 같은데, 아직 좋을거 같은 인사이트는 못찾았다.
    • Jotai도 그렇고 Recoil도 그렇고, 구독하고 있는 아톰을 잘 관리하기 위해서 최대한 액션이랑 구독 아톰의 수를 필요한 것만 최소로 가져가는게 좋을거 같다.

  • 네이버지도를 리액트 컴포넌트 조합방식으로 사용할 수 있도록 포팅하고 라이브러리로 개발했다.

    • 네이버지도는 React flow를 타지 않아, 순수 자바스크립트로는 금방 해결될 문제들이 React 특성 때문에 버그로 이어지는 케이스가 많았다.
      • 이런 케이스들을 해결한 상태에서 React Component로 제공하도록 만드는게 목적이었다.
    • 네이버지도 관련된 인스턴스들을 메모이제이션 하고 useEffect에 지도 option prop 변화를 감지할때마다 instance의 setter함수를 호출하는 형태로 진행했다.
      • 이렇게 만들고 나서 드는 생각인데 useEffect에서 네이버 지도 인스턴스 setter함수를 호출해 부수효과를 이용한다는 느낌이 좀 드는데, useEffect라는 이름이 붙여진 이유를 조금 이해할 수 있었다.
    • 네이버지도 인스턴스를 주입받는 Overlay 클래스는 Map 콘텍스트를 따로 두어 NaverMap 컴포넌트 안에 조합하지 않으면 Error를 던지도록 설계했다.
    • 실제론 React flow대로 동작하진 않지만(당연히 네이버지도가 원래 React를 고려하지 않았으니), 사용부에선 React 처럼 사용할 수 있도록 개발했다.

  • 네이버 지도에 성능을 의존하는 상황이었기 때문에, 화면에 몇개의 마커가 표시되는 것이 적절한지 파악했다.

    • playwright로 일정한 드래그 위치, 속도 등 유저행동을 자동화하고 tracing api로 추출된 파일로 지표를 정리했다.
    • 이때 네이버 인턴때 개발자, 동기를 보며 자극받아 공부한 내용들이 크게 도움이 되었다.

  • 만든 지도 라이브러리를 이용해 새로운 서비스를 릴리즈 했다.

    • 전사적으로 처음 시도하는 부분을 맡아 부담되었지만, 릴리즈 되는 순간 하길 잘했다는 생각이 들었다.
    • 멋있다는 말을 개발 시작한 이래로 가장 많이 들었던 순간인거 같다. 아직은 develop할게 많지만, 확장성이 높은 서비스가 생겨 기쁘다.

  • 인터뷰 워킹 그룹 CS Knowledge에 volunteer로 문제 몇 개 냈다.

    • 일이랑 겹쳐서 많이 신경쓰지 못해 조금 아쉽다.

  • 팀 분위기가 블라인드에서 부럽다는 이야기가 나올 정도로 좋은데, 팀운이 매번 좋은게 정말 다행이다.

    • 아주 slow 하지만, 통통 튀는 분들 덕에 말주변이 조금씩 생기고 있는 기분도 든다.
    • 6개월 동안 한걸 리스트업해보니 적진 않았던거 같다. 그리고 과업 진행할 땐 몰랐는데 돌이켜보면 팀원 한 분이 encourage 해줘서 가능했던거 같다.
    • TL 분이 다른 회사에선 넘어갈법한 내용도 꼼꼼하게 집고 리뷰하는 스타일이시라, 큰 도움이 되고 있다.

  • 버킷플레이스는 2주에 한번 리드와 1on1 미팅을 필수로 진행한다.

    • 여러명 앞에서 성과를 어필하는걸 오글거려하는 성격인데, 1on1 에서는 2주간 어떻게 개발했는지 편하게 말할 수 있는 환경이라 좋다.
    • prefix로 있는 질문이 있는데, 이 질문이 2주 동안 개발을 생각하면서 하게 만드는 장치가 되는거 같다. 꼭 개발 뿐만아니라 다른 영역에도 쓰기 좋은 질문같다.

  • 그 밖에

ETC

  • 운동을 시작했다.

    • 살이 부쩍 많이 쪘는데, 최근 운동하면서 2주 동안 5kg정도 감량했다.
    • 주변에서도 살이 빠지는게 보인다고 하니 나도 덩달아 재밌어서 꾸준히하게 된다.
    • 기분탓인지 모르겠지만 집중도 전보다 잘 되는 느낌이다.
    • 끝나고 나면 스트레스도 해소된다.
    • 더 빼야하지만 변화가 외모랑 수치로 보이니 재미있다.

  • 스터디 운영

    • 모르는 사람들과 스터디를 열었다.
    • 참가자로만 있다 처음으로 운영을 해봤는데, 내가 아이스브레이킹에 능한 성격은 아닌거 같다.
    • 그래도 용기내서 뭔갈 해보니, 결과에 상관없이 평소와 다르게 시도해보니 뿌듯한 점은 있어서 좋다.

  • 디자인패턴 스터디

    • 가벼운 느낌으로 시작한 스터디인데, 제법 도움이 되었다.
    • 초반엔 예제로만 했는데, 뒤로가면서 실제 적용사례의 일부를 발췌해 적용해보면서 공부했다.
    • 책 이외에 여러 아티클의 다양한 시각들도 함께 조사했다.
    • 가벼우면서 유익해서 2022년 잘한 일 중 하나가 되었다.

  • 비개발 서적 독서를 시작했다.

    • 전자책 리더기를 구매해서 출퇴근시간에 읽는다.
    • 책을 씹어먹는다는 느낌보단, 읽다가 마음에 드는 구절을 북마크 하는 정도로 가볍게 보고 있다.

  • 결식 아동 후원

    • 이상하리 만큼 졸업 후 오늘까지 운이 좋았던거 같다.
    • 부자가 된 건 아니지만 그래도 궁한건 아니니, 조금이나마 도움이 될 수 있는 부분을 찾다 기부를 선택했다.
    • 해외 결연도 생각해보았지만, 그래도 우리나라 결식아동 지원을 선택했다.

  • 기억하고 싶은 말

    • 2022년 상반기 많은 변화가 있었던 만큼. 회사든 스터디든 다양한 사람들의 생각을 들을 기회가 많았던거 같다. 그중 기억에 남아 메모한게 몇개 있다.
    • 한 권 책을 읽기보다는 비슷한 책을 여러개 읽거나, 비슷한 주제의 다양한 아티클을 읽으면 도움이 많이 된다.
    • 같은 내용이어도 다르게 서술하고, 바라보는 측면이 달라서 다양한 책이나 아티클을 읽는게 좋다고 생각한다.
    • 설계 관련 조언
      • 유연성, 확장성을 고려
      • 그런데 확장성에 너무 신경을 쓰면 비즈니스에 영향이 감
      • 재활용성 범위에도 영향이 감
      • Tech Lead가 비즈니스 로직이랑 UI랑 분리하고 싶어하는 부분도 지금 고민의 일환(VAC 패턴) -> 하지만 VAC 패턴도 사용하다보면 단점이 보일거고 다른 패턴이나 설계도 마찬가지
      • 최근 비슷한 코드를 작성한다는 기분이 많이 든다 -> 비즈니스는 패턴이 비슷한게 맞음. 비슷한 패턴을 찾았다는게 적절한 지점을 찾아서 잘하고 있는 것일 수 있음
      • 오히려 버나드님이 playwright 적용한거 처럼 그런 부분에서 재미를 찾는거도 좋음
    • onion 아키텍처는 클린아키텍처와 동일
      • 순수함수 → 비순수함수를 호출하는 형태로 하다보면 자연스럽게 onion 아키텍처가 된다.
      • 근데 순수함수 비순수함수 경계나누는게 쉽진 않을거 같다.

  • 해보고 싶은거

    • 부족한게 많아 하고싶은게 많다.
      • 새로운 과업에서 추후 내재화까지 고려한 디자인설계가 가능한지 알아보고 싶다.
      • next.js, graphql 스터디
    • fix-it week 때 지도 부분을 좀 더 다듬어 보고 싶다.
    • 전사 설계 리뷰도 받아보고 싶은 마음이 드는 동시에 부족한 점이 많아 겁도 난다.

Next

프론트엔드 테스트

All rights reserved.