고정 헤더 영역
상세 컨텐츠
본문
정말 오랜만에 블로그에 글을 쓴다.
마지막 글이 8월이었고, 그마저도 4월 이후로 하나였다.
원래는 상반기와 하반기 회고록을 따로 작성하려고 했으나, 미루고 미루다 보니 결국 실패했다.
학기와 병행하는 것은 정말 쉽지 않은 것 같다.
정신을 차려보니 2022년이 일주일도 채 남지 않아 더는 미룰 수 없어서 드디어 회고를 쓰기로 결심했다.
그러고 보면 다른 분들의 회고를 읽어보기만 했지 직접 하는 회고는 처음이라 어떻게 진행할지 감이 안 오긴 하는데, 아무튼 내 블로그니까 내 마음대로 회고를 하려고 한다.
올해 구매 목록
1. 로지텍 MX VERTICAL 버티컬 무선마우스
아무래도 학생이다 보니 디자이너를 구할 수 없는지라 프로젝트에서 디자인까지 해야 하는 경우가 많은데, 피그마나 포토샵으로 디자인을 할 때 손목이 슬슬 아팠다. 물론 디자인을 열심히 해서가 아니라 그 전 날 새벽까지 게임을 한 게 문제였겠지만 그래서 보급형 버티컬 마우스를 찾아보다가, 이왕 쓸 거면 건강에 돈 아끼지 말고 제대로 된 걸로 오래 쓰자는 생각으로 구입하였다.
왼쪽에 있는 것은 가방에 넣고 다니다가 혹시라도 흠집이 날까 봐 별도로 구입한 파우치다.
사진에서는 가려져있는데, 마우스 상단 말고도 엄지손가락을 놓는 부분에 매크로 등록이 가능한 버튼이 두 개 있다. 여기에 맥북 창(Desktop) 이동을 등록해놓으면 아주 기깔나게 쓸 수 있다.
확실히 손목이 편하다는 느낌을 받았고, 무소음이 아니라서 아쉬웠는데 이걸 구입한 지 얼마 지나지 않아서 로지텍에서 무소음 버티컬 마우스를 출시했다. 조금만 참을걸..
2. 키크론 K2 Retro
이 회고에서는 따로 언급 안할 거지만 손목을 해결하고 나니 목이랑 등이 점점 쏠리면서 뭉치는 느낌을 많이 받아 맥북 거치대를 구입하였다.
막상 거치대를 구입하니까 그 상태로 타자를 칠 수가 없다는 것을 깨달았다.
정말 어쩔 수 없이 (씨익) 휴대용 블루투스 키보드를 하나 장만하였다.
Mac과 호환이 뛰어나고, 휴대하기 나쁘지 않은 키보드다.
청 / 갈 / 적축만 판매해서 적축으로 시켰고, 적축도 생각보다 많이 시끄러워서 저소음 갈축을 따로 구입해 스위치를 바꿔 끼웠다.
한 가지 후회하는 점은 이게 기본 K2 모델에서 LED를 빼고 가격을 낮춘 제품인데, 역방향 스위치는 그대로였어서 체리 프로파일의 키캡을 낄 수 없다는 점이다. 물론 아예 안 되는 건 아니지만 한번 껴보니 간섭이 체감됐다. 이럴 거면 그냥 LED 있는 제품으로 살 걸 싶었다.
아무튼 무선 마우스, 무선 키보드, 거치대의 조합은 최고였다. 물론 이 글은 무릎 위에 맥북을 올려놓고 쓰고 있다.
3. Macbook M1 Pro 16 (21년형)
생각해보니 이 친구도 올해 만난 친구라 부랴부랴 추가했다.
올해 초까지 잘 사용해온 삼성 노트북이 충전기를 꽂아도 충전 속도보다 배터리 닳는 속도가 더 빠를 정도로 수명을 다해 원만한 합의 끝에 맥북을 구입하게 되었다. 주변에서 Windows -> Mac으로 바꾸면 처음에 많이 불편하다고 그랬는데, 안드로이드에서 iOS로 갈아탈 때에도 별로 불편함에 없었어서 그런지 이번에도 불편함을 느끼지 못했다. 오히려 엄청난 속도와 부드러운 UX에 감격했다.
무슨 학부생이 맥북을 체감하냐고 하겠냐마는 작년에 바꾼 데스크탑이 VSCode에서 Git을 사용할 때 처음에 비해 엄청 느려져서 불편했고, 특히 피그마가 조금만 규모가 커져도 실행 불가였는데 맥북에서는 너무 부드럽게 잘 됐다.
4. 도서
학교 교재를 제외하고 총 두 권의 책을 구입했으나, 부끄럽게도 아직 읽지 못했다. 딥다이브는 JS 공부 목적으로 가끔 궁금할 때 꺼내 읽으려고 구입하였고, 함께 자라기는 주변에서 협업할 때 도움이 많이 됐다고 추천을 많이 해줘서 구입하였다. 그렇게 시간 날 때 읽겠다고 다짐했다가 결국 못 꺼내보았다. 설 연휴 때 읽으면 좋을 것 같아서 그때 읽으려고 한다.
상반기 회고
본격적인 회고를 해보자면, 올해 초에는 네이버 부스트캠프를 수료한 지 얼마 되지 않은 상태라 기존 프로젝트들을 점검하거나, 새로운 것에 도전해 보았다. 또한 상반기는 1학기라고 볼 수 있는데, 3-1까지 들었기 때문에 4학년 과목 밖에 들을 수 없었는데 부스트캠프하느라 한 학기를 쉬었다 왔더니 학교에서 3학년이라고 못 듣게 하는 바람에 강제로 교양들과 함께 경제학과 전공인 회계 원리랑 경제학원론을 들어야 했다. 나름 프로젝트를 할 여유도 있어서 나쁘지 않았던 것 같다.
모디모아(MODIMOA)
작년에 진행하다가 팀원들이 각자 바빠져서 중지했던 프로젝트인데, 겨울 방학을 맞이해 이를 전반적으로 리팩토링하고 모바일 뷰만 구현했던 것을 데스크톱으로 확장하는 등의 작업을 했다.
그런데 이 프로젝트를 진행하던 도중, 이 작업물을 좋게 봐준 선배님이 우리에게 외주를 해보지 않겠냐고 연락이 와서 이 프로젝트는 완성되지는 못한 채 다시 한번 내팽개쳐졌다.
기술적으로는 써보고 싶은 것이 있으면 써보자! 와 불편한 것은 직접 해보고 느껴보자! 가 컨셉이었어서 FE 기준으로 Presenter & Container 패턴을 적용하고 상태 관리 라이브러리로 Redux를 사용했는데, 방치된 김에 다음에 다시 진행할 때에는 해볼 건 해봤으니 디자인 패턴부터 싹 갈아엎어보기로 했다.
그래빗(Grabit)
부스트캠프에서 어쭙잖게 경험한 것을 바탕으로 학교 동기들이 이미 진행하고 있던 프로젝트에 PM을 맡아보았다. 사실은 PM이 정확히 어떤 일을 하는지 잘 알지 못했어서 어떻게 하면 팀원들이 협업을 더 잘할 수 있을지에 대한 고민을 위주로 기여했던 것 같다.
처음에 참여했을 때 작년부터 진행했던 프로젝트치곤 기획부터 제대로 정리되어있지 않았고, 남아있는 문서는 일주일마다 작성된 회의록이었다. 그래서 그 회의록을 모두 읽어보면서 어떤 프로젝트인지에 대한 이해를 했고, 그를 바탕으로 백로그를 작성해 프로젝트 일정을 짜기 편하게 했다.
문서를 정리한 이후에 보인 문제는 FE와 BE의 작업 속도 차이였다. 개인적으로 프로젝트 작업 효율을 위해서는 BE가 작업 속도가 더 빨라야 한다는 주의라서 과감하게 FE 팀원들에게 2주 동안 개발에는 손대지 않고 기획 및 디자인을 점검하게 하였고, 그동안 BE만 개발을 진행하도록 해서 작업 속도 차이를 뒀다. 확실히 2주 이후에 FE도 같이 개발할 때 몰입이 잘 되는 것 같다는 느낌을 받았는데, 동시에 개발했다면 결과가 어떻게 바뀌었을지는 사실 잘 모르겠다.
이후에는 UX 위주로 개선하면 좋을 것 같은 부분들을 제시하는 방식으로 참여했고, 일정을 조율해서 데드라인을 정하긴 했으나 이 프로젝트도 팀원들 각자의 졸업 프로젝트 & 취준 등의 사정이 겹치면서 멈추게 되었다.
GSDC UOS Github 뱃지
Next.js 문서를 읽다 보니 서버처럼 사용할 수 있는 것 같아서 공부해볼 겸 만들게 되었다. 다만 재미를 위해 스탯 같은 요소를 넣고 싶었는데, 소속 인원들의 인적 사항을 관리하는 DB를 따로 운영하지 않다 보니 스탯이라고 할 게 기술 블로그에 얼마나 글을 많이 올렸는 지밖에 없었다. 그마저도 일일이 크롤링해서 계산해서 최종적으로 svg를 만들어 반환하므로 아주 절망적인 성능을 갖고 태어나게 되었다. 성능에 대해서는 DB를 도입하는 등 충분히 개선할 부분이 있어서 이슈로 남겨놓고 일단 마무리하였다.
나름 주변 사람들에게 관심은 받았으나 디자인도 다른 Github 뱃지들에 비하면 영 마음에 들지 않아서 아쉬운 부분이다.
지인 외주(?)
전공이 전공이다 보니 대부분의 동기들이 취업 준비를 하거나 취업한 지 얼마 안 된 상태였다. 취업을 하면 신입들을 대상으로 온보딩 프로젝트를 하게 하는 기업들도 있었는데, 직무가 BE인데 온보딩 프로젝트가 풀스택인 경우가 있어서 FE를 지원해주게 되었다.
해당 기업에서 외부에서 템플릿을 구해서 사용해도 된다고 했기 때문에 도와주었다. 오히려 온보딩 프로젝트하는 분들 다 같이 공유했다고 해서 뿌듯하기도 했다.
외주
앞서 언급했던 선배님의 도움으로, 세 곳(개인 외주 1 + 팀 외주 2)과 미팅을 했다. 용돈 벌이보다는 경험이 중요하다고 생각했기 때문에 비용은 신경 쓰지 않았다. 그중 한 곳만 계약을 했는데, 남은 두 곳이 불발된 이유는 외주를 맡기신 쪽에서 기획에 갑자기 AI가 도입됐다든지 등으로 우리 능력 밖으로 규모가 커졌기 때문이다. 물론 학생의 입장에서 도전해볼 수는 있겠지만, 그것은 우리의 입장일 뿐이고 그분들에게는 실제 사업이기 때문에 부담스러운 면이 컸다. 남은 한 곳은 순수 FE 개발이라 가벼운 마음으로 하게 되었다. 퍼블리셔님이 따로 있다고 해서 디자인도 건드릴 필요 없다고 생각했다.
물론 현실은 처음에 했던 상상과 많이 달랐다. 퍼블리싱된 작업물에는 jQuery가 껴있기도 했고, bootstrap 형식이 통일 돼서 사용된 게 아니라 이곳저곳에 부분적으로 껴있었다. 디자인 파일은 xd로 공유되었는데 여기저기에 뜻을 알 수 없는 메모들이 있고, 시나리오 진행 순서가 명확하게 나타나있지 않은 상태였다. 퍼블리싱과 디자인이 일치하지 않는 부분도 있어서 껍데기만 작성하는 데에도 많은 애를 먹었다. 퍼블리싱 파일들을 styled-components로 마이그레이션 하려다가, 작업을 최소화하고자 sass를 도입해 html과 css는 복사 - 붙여 넣기 하는 정도로 진행하고 캐러셀 같은 부분은 직접 구현하는 방향으로 작업했다.
외부 API 연동을 해야 하는 상황도 있었는데, 처음 받은 API 문서가 안드로이드 기준이라서 React 기준으로 다시 요청해서 받는 데에도 한참이 걸렸고, 다시 받아온 문서도 React Native라서 또다시 요청해 겨우 REST API 문서를 받았다. 사실 이마저도 문서에 있는 API가 작동을 안 하는 게 있거나, 문서에 쓰여있는 것과 데이터 형식이 다른 등 최신화가 되어있지 않아서 연동하기 쉽지 않았다. 하나의 API에 body에 무엇을 적어서 보내냐에 따라 API의 기능이 구분된다는 점도 꽤 특이했다.
FE 개발로 계약했으나, API를 고쳐야 하거나 추가하고 싶으면 BE 코드를 직접 수정해야 했다. 코드가 PHP고, Git이 아닌 FTP로 접근해야 해서 순탄치 않았고, 서버가 공지 없이 중간에 바뀌거나 DB가 초기화되기도 했다.
개발하면 개발할수록 기획의 모순과 허점이 너무 많이 보였다. 따라서 그럴 때마다 기획의 수정을 건의했고, 돌아오는 대답은 해당 부분의 수정이 아니라 다른 부분의 기획이 바뀐 채로 그 부분을 작업해달라고 요청이 오는 등 소통이 어려웠다.
계속 이렇게 이상한 부분만 개발하다가 이대로 2학기로 넘어가면 참여가 어렵다고 어필을 했는데, 그럼에도 진전이 되지 않고 그대로 2학기로 넘어가자 10월 이후로 자연스럽게 손을 떼게 되었고 갑작스럽게 코드 수정 권한도 뺏겼다. 우리랑 직접적으로 계약한 분은 사실 이 프로젝트의 BE 개발자신데, 본인이 직접 FE 개발해보다가 문제 생기면 연락 주겠다고 하신 이후로 보류된 상태다.
코딩 테스트 + 과제
감을 잃지 않으려고 여기저기 채용 공고가 있으면 신청해 보았다. 아무래도 졸업까지 1년 이상 남은 상태라 대부분 서류에서 탈락했지만, 코딩 테스트와 과제 전형 이후에 서류 전형으로 이어지는 몇몇 공고에서는 과제까지 통과한 후에 서류에서 탈락하는 결과가 있었다.
그중 한 기업은 과제 전형 이후 면접 일정을 잡자는 연락이 와서 졸업 관련 사정 설명을 했더니 취소된 경우도 있었다. 아무래도 과제 전형을 하다 보면 그 기업의 코드 스타일 같은 것을 간접적으로 느낄 수 있어서 좋은 경험이었던 것 같다.
하반기 회고
하반기는 사실 작년에 네이버 부스트캠프를 하느라 빠진 3학년 2학기를 메꾸기 위함으로 전부 학업에 투자했다.
미스터 대박 디너 서비스
소프트웨어 공학 과목의 팀 프로젝트였다. '미스터 대박'이라는 가상의 회사가 디너 배달 서비스를 개발하고 싶어서 우리에게 요구 사항을 전달한 것으로 가정하고, 주어진 기획서를 보고 개발했다. 다만 실제 외주와 다르게 고객과 기획에 대한 소통이 불가능하므로 애매하다고 느껴지는 부분은 그냥 우리가 알아서 판단해서 결정해야 했다. FE 개발과 디자인을 맡았는데, 디자인을 그동안 시도해본 적 없던 글래스모피즘을 도입해보기도 하고, 모바일과 데스크톱 뷰를 나누어서 개발하니까 많이 빡빡했다. 처음에는 모든 페이지를 반응형으로 하려다가 도저히 일정을 맞추지 못할 것 같아서 사용자의 종류에 따라 어떤 페이지는 모바일만 지원하는 식으로 나누는 것으로 타협했다.
본인도 그렇지만 아무래도 다들 개발 경험이 부족하기도 하고, 학기와 병행해야 하기 때문에 일정 관리가 정말 어려웠다. BE를 맡았던 팀원이 완벽주의적인 성향이라 버그가 남아있더라도 일단 시간이 부족할 테니 FE에서 API를 붙이면서 같이 해결하면서 하자고 설득해보았는데 끝끝내 마감 3일 전쯤에 API 폭탄을 맞게 되었고, 그렇다고 모두 다 제대로 동작하는 것도 아니었어서 마감일까지 밤을 새우면서 열심히 붙여봤는데 결국 모든 기능을 구현하지 못했다. 마감일에 교수님 앞에서 최종 시연을 본인이 하기로 했었기 때문에 어떻게 잘 얼버무리면서 성공적으로 마무리하긴 했다.
이 프로젝트의 패인은 일정과 규모 관리의 실패라고 생각했다.
이상적으로는 마감일 일주일 전에 모든 기능 구현이 끝나고 마지막 일주일 동안 버그 픽스를 하면 되겠다는 생각이었는데, 학과 내에서도 3학년 2학기가 원래부터 바쁘기로 소문나있는 학기라 일정을 맞추는 것은 좀처럼 쉽지 않았다. 애자일을 도입할 수 없는 상황이었고, 시간을 최대한 맞춰서 일주일에 1~2회 정도 회의를 했는데 그마저도 개발 위주의 이야기보다는 보고서 작성 위주로 흘러갔다. 그 이유는 교수님이 보고서에 집착하시는 분이셨는데, 보고서에 들어가는 내용들이 UML 위주인데 SPA 형태의 프로젝트와 맞지 않았기 때문이다. 나중에서야 깨달은 것은, 교수님이 의도하신 프로젝트는 템플릿을 활용한 SSR이었던 것 같다. 애초에 기획서에 기술 요구사항이 음성인식 밖에 없었고 그 부분은 언급되지 않았기 때문에 예상하지 못했던 문제였다.
두루뭉술한 기획서 때문에 규모가 커진 것도 큰 문제였다. 본인도 디자인부터 FE 개발까지 혼자 진행했지만 거의 일정에 딱 맞출 정도였고, 상대적으로 경험이 적은 팀원들은 더 벅찼을 것이다. 팀원들에게 각자 제일 편할 수 있게 규모를 짜서 하라고 말만 했을 뿐, 처음에 팀원이 그려온 ERD에 복잡하게 얽혀있는 관계를 봤을 때 개선점을 찾아주긴 했지만 가장 편한 대로 하라고 했던 것이 나의 잘못 중 하나라고 생각한다. 규모를 줄이고 좀 더 프로젝트 관리에 집중했어야 하는데, 맡은 부분을 하기만도 많이 바빴다. 처음에는 만만하게 생각해서 기술적인 도전으로 react-query와 framer-motion을 공부해서 적용하려고 했으나 시간에 쫓겨 구글링 해서 찾은 예제를 그대로 쓰는 정도로 그쳤다.
FE와 BE 중 한 곳이 모든 작업을 완료했더라도 나머지 한 곳이 완전하지 않으면 결국 다 보여줄 수 없음의 허망함과 프로젝트 관리의 중요성을 다시 한번 느끼게 되었다.
Mel-BTI
소프트웨어 응용 과목의 팀 프로젝트로, 데이터 분석 알고리즘을 이용하는 것이 교수님이 내주신 프로젝트 주제다. 서비스를 완성하는 것이 아니라, 과정과 결과만 보여주면 되는 거라서 웹 개발보다는 데이터 분석 위주였다. 다만 본인은 머신러닝에 대한 지식이 전무했기 때문에 프로젝트에 대한 아이디어와 데이터 전처리, 프로토타이핑 정도를 맡았고, 머신러닝 쪽은 다른 팀원들이 주도해 주었다.
현재 이 프로젝트에 대한 첨부할 수 있는 결과물이 발표 자료 밖에 없어서 잠깐 프로젝트를 소개해보자면, 나만의 플레이리스트를 구성하면 그것에 따라 MBTI처럼 Mel-BTI라는 것을 분석해주는 것이 우리의 주제였다. 데이터셋은 카카오 아레나에서 진행한 멜론 데이터 분석 대회에서 공개한 것을 사용해 플레이리스트 태그와 곡들의 관계를 학습시키는 방향으로 진행하였고, 유사한 태그들끼리 군집화를 해서 위 사진과 같이 최종적인 Mel-BTI를 보여준다. 외국에서 음악 취향과 성격의 관련성을 분석한 논문이 있어서 그를 참고해 도출했다.
프로토타입은 실제 우리가 학습시킨 모델로 계산할 수 있는 결과들을 바탕으로 구성하였고, 위 사진에 있는 데이터는 실제 결과를 바탕으로 시각화한 모습이다. 아무래도 웹 공부만 했던 나에게는 신기한 경험이었고, 그렇다고 무임승차가 되지는 않고 싶어서 내가 할 수 있는 부분을 최대한 활용해서 열심히 참여하려고 노력했던 것 같다.
react-holiday-time-bar
BE인데 기업 백오피스 서비스를 개발하고 있는 지인이 있는데, 연차 신청과 관련해서 시간대를 선택할 수 있는 GUI가 필요하다길래 라이브러리 형태로 만들어보았다. 라이브러리를 만드는 것은 처음이었는데, 생각보다 고려해야 하는 부분이 많았고 여러모로 신기했다. npm 기준 다운로드 횟수가 어느새 1천 회를 돌파했다. 아무래도 이름을 너무 그럴듯하게 지어서 지나가다가 다운로드하여보시는 것 같다. 외국에 사는 학생이 영어로 된 README도 적어달라고 issue를 올리는 일도 있었다. 사실 처음부터 README를 영어로 적을까라는 생각도 했다가 내가 한국 사람인데 왜 영어로 적어야 하냐는 생각으로 한글로 적었던 거라서 이런 일이 있을 줄은 예상치 못했다. 그래서 메인 README는 한글로 두고 README-EN을 작성하는 것으로 타협했다. 정작 이걸 요청한 지인은 다른 프로젝트가 바빠서 도입도 못해봤다고 한다. 😅
FEConf
운 좋게 티켓팅에 성공해서 지난 10월 8일에 열린 FEConf에 다녀왔다.
발표들도 너무 재밌었고, 부스에 계신 분들도 너무 유쾌했다. 어차피 유튜브에서 다시 보기를 볼 수 있지만 현장에서 보는 것은 그 분위기나 집중도가 달랐고, 무엇보다 학교 강의는 실무랑 거리가 멀어서 재미없었는데 여기서 오로지 FE 관련 이야기들만 들으니까 이보다 좋을 수가 없었다. 일단 굉장히 많은 굿즈를 받아서 좋았고 언젠가는 나도 저 무대에 꼭 서고 싶다는 생각이 들었다.
너무 좋았어서 내년에도 열리면 티켓팅할 생각이다.
GDSC Job Fair
올해 8월부로 GDSC UOS를 졸업하게 되었다. 멤버로 남아있었어도 됐지만 Alumni가 되면 조금 더 자유로울 수 있기 때문에 졸업을 선택했고, 졸업자들 대상으로 Job Fair가 열려서 Google for Startups Campus에 다녀왔다. 스타트업들 소개 위주였기 때문에 부스들을 돌아다니면서 현직자 분들과 잠깐잠깐씩 얘기했다. 아무래도 공개된 장소니까 깊은 얘기는 할 수 없었고, 어떤 기술을 사용하고 있는지와 채용 형태 정도를 위주로 여쭤보고 다녔다. FEConf는 혼자 다녀서 조금 쑥스러웠었는데, 여기는 GDSC 활동을 같이 했던 사람들이랑 함께 다녀서 오히려 덜 쑥스럽고 자유롭게 궁금한 것을 질문했다.
오늘, 한 줄
바쁜 폭풍이 모두 끝나고 연말에 시작하게 된 개인 프로젝트다.
올 한 해 동안, 외주를 하거나 이미 하던 것을 이어서 하거나 정해진 주제에 대해서 프로젝트를 진행하느라 정작 새로운 아이디어가 떠올라도 할 시간이 없어서 따로 메모만 해두었다가 드디어 하나씩 꺼내기로 했다. 오늘, 하나라는 큰 프로젝트 이름 아래에서 작은 토이 프로젝트들을 여러 개 할 예정이고, 그 첫 번째로 오늘, 한 줄이라는 프로젝트를 기획해 팀을 구성했다.
PO(Product Owner) 임과 동시에 FE 개발을 맡았고, 이 프로젝트에서는 미스터 대박을 개발할 때 알게 된 framer-motion이라는 라이브러리를 이용해 간단하지만 화려한, 그러면서도 UX를 해치지 않으면서 재미있는 애니메이션들을 넣는 것에 집중할 예정이다.
기술 회고
작년에 네이버 부스트캠프를 했을 때에는 최대한 라이브러리를 사용하지 않고 직접 구현하는 것에 집중했다면, 올해는 다양한 프로젝트들을 해보면서 다양한 라이브러리를 사용해 보았다. 부스트캠프를 하기 전에는 기능이 조금만 복잡해 보이면 무분별하게 라이브러리를 찾았지만 지금은 안목이 조금 생긴 것 같달까라는 생각을 해본다. 그렇게 올해 사용해 본 라이브러리 중 개인적으로 인상적이었던 라이브러리들을 느낀 점과 함께 소개해볼까 한다.
Next.js
지금까지 한 프로젝트들은 대부분 React로 개발했다. 그러다가 Next가 하도 핫하다길래 찍먹(?)이나 해보자는 생각으로 잠깐 봤었다. 확실히 서비스의 목적이 wiki와 같은 정보 전달이라면 SEO 측면에서 유리하다는 생각이 들었고, 성능도 많이 우수해 보였다. 그렇지만 우리가 하는 프로젝트들은 정보 전달보다는 주로 재미 위주이기 때문에 Next까지 도입해야 하는지 그 필요성은 크게 못 느꼈고, 컴포넌트 간에 props를 넘겨주는 거나 디렉토리 구조를 고정해야 하는 Next만의 방식이 생소하고 불편했다. 그래서 정말 찍먹(?)만 했는데, Next.js Conf 2022에서 발표한 모습이 많이 바뀐 Next.js 13 버전을 보고 미리 열심히 안 해두길 잘했다는 생각이 들었다(?).
Vite
프로젝트를 Webpack으로 몇 번 구성해보니까 사전 작업이 너무 많고 복잡했다. CRA가 있지만 Dependency 이슈도 있고, 결국에는 eject(craco라는 대안이 있긴 하지만)로 이어지기 때문에 불편함을 느끼던 찰나에 Vite라는 친구가 상승세길래 한 번 써볼까 싶어서 써봤다가 매력에 빠지게 되었다. Parcel도 써보았는데 Vite가 조금 더 안정적이고 세계가 큰 것 같은 느낌이었고, 확실한 것은 써보니까 Webpack으로 다시 돌아가고 싶지는 않았다. Webpack은 어차피 매 번 비슷하게 구성할 것인데 Boilerplate를 철저히 만들어놓는 게 아니면 작업이 오래 걸리는 게 불편한 점이었다면, 다른 번들러들은 이거를 알아서 해줬다. 그렇다고 프로젝트가 무거워지거나 할 수 있는 것에 제한을 받는다는 느낌도 없어서 하반기에는 모두 Vite로 작업했던 것 같다. Vue에 최적화됐다고 들었는데, React에 적용해도 불편하지 않았다.
번들러에 대해서는 7월에 GDSC 멤버들과 함께 간단히 정리한 게 있는데 [ 여기 ] 에서 확인할 수 있다.
yarn berry
yarn의 v2 이상의 버전을 berry라고 부르는데, node_modules를 떼내고 패키지의 중복 설치를 방지하면서 시간과 공간 모두 단축할 만큼 상당히 강력했다. 작년에 Webpack으로 프로젝트를 구성했을 때에는 CI / CD를 적용했을 때 빌드 시간이 너무 오래 걸리는 문제가 생겨 webpack-bundle-analyzer 같은 라이브러리들로 패키지들을 일일이 분석해 해결했었는데, 이러한 걱정을 할 필요가 없어진 것이다. 올해 대부분의 프로젝트들을 Vite + yarn berry로 구성했는데, 이곳저곳에서 시간을 상당히 단축할 수 있어 굉장히 만족스러운 조합이었다.
React Query
올해 2월에 [ 우아한 테크 세미나 ] 에서 처음 본 이후로, 당시에는 이런 게 있구나만 확인하고 넘어갔었다. 왜냐하면 Recoil에 있는 selector만으로도 캐싱 및 React Suspense 사용이 가능하고, Axios나 fetch에서 예외 처리를 구현할 수 있다고 생각했기 때문이다. 그러다가 사용해보게 되었는데 개인적으로 과장을 좀 보태자면 React에 있는 컴포넌트 생명 주기라는 개념 위에서 비동기는 기름처럼 둥둥 떠있다고 생각될 만큼 어색한 부분이 있었는데, React Query가 그 사이를 잘 연결해준다는 느낌을 받았다. 확실히 비동기를 동기처럼 사용할 수 있다는 점은 개발하는 사람 입장에서도, 코드를 읽는 사람 입장에서도 충분히 강점이라고 생각한다.
사용하기 시작한 지 얼마 되지 않았기 때문에 아직까지는 완벽하게 활용하지 못하지만, 써보면서 파악해나갈 계획이다. 특히 전역 상태 관리에 있어서는 계속 사용해 온 Recoil이 너무 강력하기 때문에 둘 다 써보면서 장단점을 비교해 봐야겠다.
Framer Motion
올해 접한 라이브러리 중 가장 충격적인 라이브러리였다.
처음에는 단순히 JS가 직접 DOM을 조작하는 것으로 보여서 그럼 그렇지라는 마음으로 문서를 읽었으나 읽어볼수록 개발자 분들이 최적화 관련해서 신경을 많이 썼다는 게 느껴졌고, CSS 문법을 거의 그대로 사용할 수 있어서 크게 어색하지도 않았다. React와도 연계가 잘 된다고 느꼈던 게, 생명 주기에 맞춰 페이지 전환 애니메이션까지 지원하기 때문에 많은 매력을 느꼈다. 표현할 수 있는 애니메이션의 범위도 상당히 넓어서 앞으로 대부분의 프로젝트에 도입할 것 같다.
디자인 회고
디자인에 있어서도 조금 성장했다는 것을 느꼈다. 예전에는 누가 봐도 하기 싫은데 억지로 했나 싶은 느낌이었다면, 그래도 봐줄 만할 정도로 감각이 생겼다는 느낌을 받았다.
미술에 대한 감각이 하나도 없었던 내가 이렇게 만들 수 있었던 이유는 Dribble이라는 플랫폼이 가장 컸던 것 같다. 디자이너들이 작업물을 올려놓는 플랫폼인데, 그곳에서 여러 디자인들을 찾아보면서 레이아웃을 어떻게 잡는지 느낌을 익히려고 노력했다. 그다음으로는 유튜브 채널 중에 디자이너 분이 시청자의 디자인을 리뷰해주는 채널이 있는데, 나였어도 충분히 실수했을 것 같은 부분들에 대한 피드백을 보면서 많이 배운 것 같다.
지인들과의 약속이 있을 때 약속 장소에 일찍 도착하면 근처 서점에서 책을 꺼내보며 기다린 적이 종종 있었는데, 그것의 영향도 있었던 것 같다. 아무래도 개발 관련 서적들보다는 UI / UX 관련 서적이 잠깐 꺼내서 읽기 좋았고, 그중에 하나를 꼽자면 'UX/UI의 10가지 심리학 법칙'이라는 책이 꽤 인상 깊었다. 디자인이라고 하면 항상 예쁜 것이 최고이고 최대한 많은 정보를 전달할 수 있어야 한다고 생각했었는데, 사람들의 심리를 얼마나 잘 파악해서 디자인에 반영하는지가 굉장히 중요하다는 것을 최근에야 알게 되었다. 이는 나중에 구입해서 제대로 읽어보려고 했는데, 얼마 전에 학교 도서관에 있는 것을 봐서 빌려 읽을 생각이다.
회고를 마치며
이렇게 돌이켜보니 사실 올 한 해는 제대로 한 일이 아무것도 없었다. 프로젝트들은 중간에 중단되어 깨끗하게 끝난 게 하나도 없었고, GDSC를 8월에 졸업한 이후 다른 대외 활동도 하지 못했다.
변명을 해보자면 프로젝트의 경우 누군가 도중에 취업을 하게 되면 흐지부지되는 경향이 강했다. 당연한 이야기지만 학부생은 매 학기마다 강의를 들으면서 중간에 중간고사, 기말고사가 껴있는 일정을 따라가는 반면, 취업을 한 사람은 회사 내의 프로젝트 일정을 따라가기 때문에 학교는 방학이더라도 회사에는 바쁜 프로젝트가 잡혀있는 상황이 일어나 점점 팀원끼리 일정을 맞추기 힘들어지면서 멀어져 갔다. 그래서 아예 학부생들로만 구성하거나, 이미 취업한 사람들과 프로젝트를 하는 게 속 편하다는 생각이 들었고, 프로젝트 일정도 최대한 짧게 가져가는 것이 좋다고 생각했다. 개발 시간을 늘리는 것보다는 아예 기획부터 규모를 작게 하고 한 두 가지의 목표만을 명확하게 잡아서 하면 일정을 짧게 가져갈 수 있을 것이다. 그렇게 탄생한 게 오늘, 하나이기도 하다.
어쩌면 그러면서 올 한 해 가장 후회되는 일은 외주라고 할 수 있다. 가장 많은 시간과 노력을 들인 만큼 새로 경험한 것도 많았지만, 기획이 명확하지 않은 상태에서 개발을 한다는 것은 정말 모순적인 일이었고, 냉정하게는 시간 낭비였다. 소통을 하다 보니 우리에게 외주를 맡긴 분도 갑이 아니라는 것을 알게 되었고, 본인도 벅차셨는지 우리에게 그보다 더 윗사람을 직접 연결해주면서 일이 점점 틀어졌다. 다단계의 그것과 같이 얽힌 관계에서 진짜 갑의 요구를 말단인 우리가 직접 들어줄 의무는 없다고 생각했는데, 어느 순간부터 직접 연결되면서 요청 사항을 곧바로 듣고 있었던 것이다. 처음에는 힘들더라도 이렇게라도 해서 빨리 이 프로젝트를 끝내자는 생각으로 버텨봤는데, 주객전도가 되면서 기획의 모순되는 점들을 이렇게 수정해야 한다고 우리가 설득을 하고 있는 상황까지 되면서 너무 많은 스트레스를 받게 되었다. 지금은 반강제로 손을 떼고 있는 상태지만, 다시 할 걸 생각하면 상당히 막막하다.
작년, 네이버 부스트캠프에서 멘토님들께 나는 아직 졸업까지 많이 남아서 바로 취업할 수 없는데 이 과정이 끝나고 나면 어떻게 하면 좋을지 여쭤봤었는데 그때 한 멘토님이 "학교 돌아가셔서 프로젝트 학살하시면 됩니다 ㅎㅎ"라고 답해주신 게 기억에 남는다. 그런데 막상 돌아와 보니 그게 말처럼 쉬운 일이 아니었고, 조금의 여유도 없이 최선을 다해 몰아치다가 정신을 차려보니 학기가 끝나있었다. 다행히 성적은 열심히 한 만큼 잘 나온 것 같다.
회고를 짧게 쓰려고 했는데 생각보다 한 일도 많고 이야기하고 싶은 것도 많아서 일주일째 이 글을 마무리하지 못하고 있다. 그만큼 일 년은 긴 시간이라고도 할 수 있겠다. 어쩌면 실수와 실패가 많아 아쉬운 2022년이었지만 그만큼 배운 것도 많았기 때문에 내년을 기대해볼 수 있을 것 같다. 오는 2023년은 아무래도 학교를 졸업하는 해이기도 하기 때문에 더욱 의미 있는 해가 되면 좋겠다는 바람을 끝으로 올해 회고를 마친다.
댓글 영역