2021년 회고

cadenzah·2022년 1월 1일
1

Life & Daily

목록 보기
2/3

하반기 들어 트위터를 다시 시작했는데(주로 개발 정보 눈팅용), 피드를 쭉 내리다가 우연히 이런 글귀를 보았다.

세상에서 가장 흐린 먹물도 가장 좋은 기억력보다 낫다.
- 중국 속담

스스로 하여금 너무나 찔리는 문구여서 올해는 기필코 (개발새발로라도) 회고를 하리라 굳게 다짐하게 되는 것이다.

작년 이 맘때 쯤에도 회고를 해야지 마음먹고 쓸 거리를 생각하다가, 생각하다가, 생각하다가... 그렇게 1년이 또 흘러버렸던 것 같다. 그래서 이번에는 그런 것 없이 정말 즉흥적으로 회고를 써보려고 마음 먹었다. 무언가 논리적이고 정리된 글을 쓰는 것이 아닌, 한해를 마무리하고 새해를 맞이하는 입장에서 있는 그대로 느끼는 그 감정의 실타래를 쭉 정리한다는 느낌으로.

입사하고 1년,

시간이 너무나 빠르게 흐른다. 작년에 취준할 때에도 시간은 그냥저냥 잘 흘렀지만, 회사에 들어와 OJT를 진행하고, 팀에 배치되고, 하나둘 일감을 받아 처리하고 업무 Comm.을 진행하는 날들이 쌓이다보니 시간은 예전보다도 훨씬 더 빠르게 흐르는 것처럼 느껴졌다.

소소하게 혼자 무언가를 만들거나, 기껏해봐야 서너명이(그것도 같은 전공자끼리) 모여서 과제용 프로젝트 정도나 하는 것이 전부였던 내가, 한 팀에 소속되어서 다양한 담당자들과 연락을 나누며 큰 코드 베이스를 건든다는 것은 너무나 긴장넘치는 일이었다. 메일은 이렇게 써야 하는건지, 문의는 이런 식으로 드리면 되는 건지(+이런 것까지 물어봐도 되는건지?), 코드는 이렇게 짜도 충분한 건지... 하나하나가 낯선 것이 참 많았고, 조심조심 일을 처리해나갈 때마다 조마조마할 때가 많았다.

차근차근 일을 해나갈 수 있었던 데에는 팀원분들의 도움이 너무나 컸다. 모르는 것이 있을 때마다, 사소한 것부터 난해한 것까지, 바로 해답이 나오지 않으면 같이 찾아보는 등 적극적으로 도와주셨던 덕분에 무사히 업무들을 해나갈 수 있었다. 특히, 처음 업무를 진행하는 입장에서 놓치거나 누락되는 것들이 있을 때마다 챙겨주신 덕에 일이 수월했던 경우도 많이 있었다. 이 시간을 빌어 또 한번 감사함을 느껴본다.

한편, 그렇게 도움을 받거나 친절한 안내를 받을 때마다 다시금 스스로를 돌아보게 된다. 나는 다른 팀원들, 다른 담당자들에게 친절하고 적극적인 구성원이었을까? 또는, 내가 유사한 상황에서 도움 요청을 받았을 때 적절한 도움을 드릴 수 있도록 마음의 준비 또는 코드 베이스에 대한 이해가 갖춰져있을까? 나름대로 적극적으로 응대하고자 노력을 했었다고 생각은 하지만, 부족한 점 또한 있었을 것이라 곱씹어보며, 다음 해에는 더 나은 모습으로 성장해있기를 기원해본다.

몸으로 배우는 개발 프로세스

여러 사람들이 함께 참여하여 기능을 완성하는 경험을 4분기 들어서 처음으로 제대로 해볼 수 있었다. (아주 제대로...) 나중에 다시 이 글을 읽어보면 '지극히 당연한 것들을 왜 그때는 제대로 못해서 실수 연발이었을까?' 싶은 말들이겠지만, 반성의 의미이자, 나중이 되더라도 항상 마음에 새겨야 하는 금언으로서 아래에 적어본다.

  • 기획서는 꼼꼼하게 검토해야 한다. FE는 높은 빈도로 기타 BE 서비스와 연동되는 경우가 많으므로 API의 연동 로직, 반환값 등이 시나리오에 따라 제대로 구현되었는지 확인해야 한다.
    • 내가 맡은 개발 일감을 완료했더라도, 내 일감이 연동되는 다른 서비스가 아직 준비되지 않았거나 누락되었다면 완료가 아니다. 검토 중 미진한 것이 보인다면, 해당 서비스 담당자에게 확인하거나(개발 일정 등) 기획자에게 공유해야 한다.
  • 기획서 검토는 궁극적으로 "이걸 이렇게 저렇게 하면 지금 기준으로 구현 가능할 것 같다 / 현재 형상 및 API 가지고는 구현 안 된다" 등을 명확히 파악하는 것이어야 한다.
    • 검토 중 구현 방향에 대하여 명확한 파악이 어렵다면(사용할 데이터를 어디서 어떻게 연동할지 / 기존에 구현된 유틸리티가 있다면 이를 어떻게 활용하는지 등) 바로 주변에 질문하자. 같은 팀 팀원이든, 연관 BE 담당자이든.
    • 현재 API, 구조 상으로 구현이 어렵다면 BE 담당자와 논의하여 규격을 수정하거나, 신규 API를 만드는 등의 의사결정이 필요하다.
    • API를 이미 BE에서 선행 검토하였고 구현 완료되었더라도 그것이 기능 구현에 충분한지 스스로 검토하고, 불명확한 점이 있다면 담당자에게 문의해야 한다. FE 구조상 충분하지 않거나, 시나리오상 누락된 부분이 있을 수 있기 때문이다.
  • 기획자/디자이너가 모든 부분을 챙기지 못할 수 있다. 검토/개발 중에 (사소한 것이라도) 의문점이 생긴다면 빠르고 구체적으로 공유하여 확인받자. 불투명한 것이 있어서는 안 된다.
  • BE는 실제 서버 로직 개발에 더하여, FE에서 사용할 수 있는 데이터 추가까지 완료되어야 비로소 (검증이 가능한) 개발 완료 상태가 된다. 구현이 모두 완료되었다면, 데이터 편성 담당자에게 작업을 요청해야 한다.

지금 다시 읽어봐도 너무나 당연한 것들이고, 이걸 왜 이렇게까지 적어놨을까 싶지만, 처음엔 나도 잘 할 줄 알았지...ㅠㅠ

백날 React만 해보다가 Vue를 쓰게 되었을 때

입사하기 전까지만 해도 Vue는 정말 1도 모르고 React만 다루어왔기에, 처음 팀에 배치되었을 때 기술 스택을 확인하고 우선 당황스러운 마음이 들었다. JS는 나름 어느정도 자신이 있었지만, 한번도 써보지 않은 것을 앞으로 쭉 사용한다고 생각하니 막막함이 앞섰다.

개인적으로 Vue는 React에 비교했을 때 매우 정형화된 패턴의 코드를 유도하는 라이브러리라고 생각한다. 하나의 로직을 짜는 데에도 React라면 각양각색의 패턴이나 방식이 있겠으나, Vue의 경우 로직의 목적에 따라 여러 컴포넌트 옵션 중 하나를 선택하여 구현하도록 유도하는 것처럼 느껴졌다. 그래서 주요 문법을 숙지하고만 있다면 요구 사항을 구현할 때 고민할 지점이 줄어들어 명쾌하게 코드 작성이 가능하고, 결과적으로 컨벤션이나 패턴 등도 문법이 맞추어 한정시키므로 협업 비용도 줄어드는 것 같다.

React의 유연함과 Vue의 정형성은 서로 장/단점이 있을 것이다.

게다가 나의 경우는 React를 했던 경험이 어느 정도 있었기에 Vue의 러닝 커브 자체가 그렇게 가파르지 않게 느껴졌다. 두 라이브러리 모두 각각의 특장점이 있지만, View를 다루는 라이브러리로서 겹치는 공통 분모도 너무나 많았기에... 왠지 모르게 Vue를 공부하면서 React도 다시 복습하는 기분이 들어 참으로 재미있는 경험이었고, 가장 많이 쓰이는 두 라이브러리를 직접 비교해볼 수 있는 기회였어서 좋았다.

시간을 아낀 만큼 우리 서비스의 코드 베이스를 파악하는 데에 꽤 많은 시간을 투입할 수 있었고, 파면 팔수록 우리 서비스는 흥미로운 프로젝트라는 생각이 들었다(이건 1년이 흐른 지금도 마찬가지). 제법 오랫동안 운영되어온 레거시에 대한 고민, 흔하지 않은 서비스 형태 아래에서 요구사항들을 구현하기 위한 여러 테크닉들, 성능을 최대한 끌어올리기 위한 다양한 최적화 기법들, 협업 개발을 위한 다양한 패턴과 시스템들, ... 코드를 보면 볼수록 팀에 계신 선배 개발자 분들로부터 가르침과 비법을 전수받는 느낌이어서 때론 경건함과 존경스러움도 들었다.

앞으로도 일감 해나가는 과정에서도 끊임없이 코드 베이스를 다시 살펴보게 될텐데, 항상 새롭게 배우는 것이 또 나올 것이라 감히 추측해본다.

함수형에 대한 관심

여름 쯤이었나, 유튜브를 보다 우연히 보게 된 세션 영상이 하나 있었다. 조금 시간이 된 영상인데, 지금 봐도 감탄이 나오고 그때도 그랬다.

기존에도 어쨌든 Promise와 async/await도 잘 사용해왔고, 단순 루프보다는 map/filter/reduce를 더 선호해왔기에 알게 모르게 함수형을 써왔다고 주장할 수도 있겠으나... 함수형이라는 체계를 직접 인지하고 적용하는 것은 또 다른 문제이다. 선언적인 코드가 읽기 좋고 디버그하기도 좋다는 말은 FE를 처음 배울 때부터 종종 들었던 말이기에 스스로 그렇게 쓰도록 노력도 해왔으나, 그 기반이 되는 함수형에 대한 것은 진지하게 생각해보지 않았다. 그때그때 별 생각없이 상황껏 코드를 썼고 (어쨌든 항상) 코드는 잘 돌아갔으니까.

그런데 위 영상을 보고 함수형 패러다임의 놀라운 매력에 푹 빠져버린 나는 위 영상을 여러번 되돌려보며 함수형에 대한 흥미를 키워나가기 시작했다. 이후 짬을 내어 여러 글들을 찾아보고, 다른 영상도 찾아보고 한 끝에 결국 책까지 사며 함수형 프로그래밍에 제대로 입문하기로 결심하게 되었다.

쉽게 설명되어있어 입문하기 정말 좋은 책이었다. 다만 개념을 설명할 때 다소 명료하지 않게 구렁이 담 넘어가듯 설명하고 퉁 치는 경향이 있어, 그때그때 검색해보면서 보완해야 했다. 그리고 오탈자가 좀 있다보니 읽다보면 이게 맞는건지 오타인지 헷갈리는 경우가 종종 발생한다. 근데 이해가 안 되어 오타인가 싶은 부분은 항상 보면 오탈자 명단에는 없다(아놔).

막상 함수형 언어를 맛보고 나니 느낀 점은, 인지하지 않고 있었을 뿐 JS 개발을 하면서 함수형 프로그래밍을 제법 어느 정도 적용해오고 있었다는 점이었다. 지금 시점에서 일상 속에서 내가 더 기울일 수 있는 함수형 관련된 노력이라면, 똑같은 코드를 짜더라도 좀 더 함수형으로 사고하고 반영하도록 습관을 들이는 것 정도? 그리고 함수형의 이점을 누릴 수 있도록 도구나 방식을 도입해보는 것 정도? (테스트라든가)

Go 스터디

작년 말, 그러니까 2020년 말에 신년 계획으로 세웠던 것 중 하나가 '새로운 언어를 하나 배워보자'였다. 그리고 그 후보가 Rust와 Go 이었는데, 둘 중 고민하다 정했던 것은 결국 Rust였다. 특별한 이유가 있었던 것은 아니었고, Go는 당시 주변에서 많이들 하고 또 커뮤니티도 활성화된 느낌이었어서 오히려 안 유명하고 덜 사용되는 듯한 Rust에 끌렸던 것 같다.

그렇게 상반기가 흐르고 둘 중 아무 것도 안 다뤄보고 있을 때, Go 스터디에 우연한 기회로 참여하게 되었다. 스터디 이름도 거창하게 'Linux Programming with Go' 였는데, Go를 하는 것도 흥미로웠지만 리눅스 관련 내용도 오랜만에 복습/공부해볼 수 있을 것 같았다.

진행 결과는? 상당히 빡셌다. 스터디 멘토가 정해주는 주제들 중 하나를 선정하여 매주 15~20분 정도의 세미나를 진행해야 했다. 세미나 주제도 운영체제 관련부터 Go의 문법, 내부 구현 등까지 다양했기에 매주 제법 밀도있는 준비를 해야 원활하고 알찬 세미나 진행이 가능했다. 멘토까지 총 5명의 사람들이 스터디를 했는데, 놀랍게도 모든 사람들이 세미나 준비를 정성스럽고 알차게 해와서, 결코 허투루 할 수가 없었다. 그래서 남은 것도 참 많았다. Go라는 언어에 대하여 많이 배울 수 있었고, Go가 가볍다고들 하는데 왜 그런지도 알 수 있었고, Go로 다양한 과제도 해볼 수 있어 흥미로웠다.

아쉬운 점은 역시 시국이 시국이니만큼 스터디 참가자들끼리 Zoom으로밖에 만날 수가 없었다는 것이다. 다행히 12월 초 잠깐 거리두기 단계가 풀렸을 때 모여서 술 한잔 할 수 있었지만, 그마저도 그 중에 한명은 종강하자마자 입대, 또 한명은 1월 중순에 입대하는지라 너무나 안타까운 상황이었다.

두분 모두 몸조심히 다녀오시길. 그리고 멘토님 고생하셨습니다.

'경제 활동'의 감각

제대로 경제 활동을 하게 되고, 저축도 조금씩 시작하면서 예전에 비하면 돈을 쓰는 데에 망설임이 줄어들었다. 참으로 감사한 일이다. 보고 싶은 것, 해보고 싶은 것, 가지고 싶은 것, 맛있는 것, 이런 것들을 위하여 돈을 쓰는 데에 걱정없이 돈을 쓸 수 있음으로 인하여 여가와 풍요로움, 자유가 월등히 개선되었다. 특별한 날이라면 조금 더 고급스러운 식사를 할 수 있게 되었고, 연휴라면 차를 빌리고 숙소를 구하여 여행을 떠날 수도 있게 되었고, 감사한 일이 있다면 선물을 준비하여 좀 더 마음을 표현할 수도 있게 되었다.

당연한 노동의 대가라고 생각할 수도 있겠지만, 이렇게 돈을 쓸 수 있게 됨에 감사함을 느낀다. 그리고 이렇게 잘 자리잡을 때까지 주변에서 응원하고 지원해준 소중한 분들께도 감사하다.

책을 끝까지 읽어야 하는데...

사놓기만 하고 쌓아둔 책들이 있어 안타깝고 부끄러운 마음이 든다. '나중에 읽어야지' 하고 옆으로 띄워놓은 탭이 수십개 쌓인 내 아이폰 Safari를 보는 느낌과 너무 겹친다...

과연 내년 회고를 쓸 때 쯤이면, 읽다 만 책들을 다 읽게 될지? 자가 점검을 위하여 아래 목록을 작성해본다.

  • GoF의 디자인 패턴: Chapter 3 생성 패턴까지 완료; 가을 정도까지 짬짬이 읽었는데 아직 반절도 못 읽음
  • 함수형 자바스크립트: 완료
  • 가상 면접 사례로 배우는 대규모 시스템 설계 기초: 7장까지 완료; 연휴에 보려고 충동구매했는데 반절정도 읽은듯
  • Introduction to Relational Database Theory: 3장까지 완료; TypeORM 찾아보다가 어쩌다보니 찾아 읽게 되었는데, 논리학이나 관계형 DB 관련 내용 정리하기 좋아 어쩌다보니 정독중
  • 그 외 사놓고 펴지도 않은 책들 서너 권...

그리고 이젠 되도록이면 E-book 사자. 책장에 자리가 없다...

올해에는...

익숙해지는 과정이란 쉽지 않다. 특히, 스스로의 역량에 대한 객관적인 메타인지가 아직 충분하지 못한 상황에서는 하나하나의 판단이 굉장한 스트레스로 다가왔다. 그래서일까, 작년을 돌이켜보면 다소 위축되는 모습, 긴장감에 우물쭈물하는 경우가 많았다.

그래도 다행히 지켜보면서 도움 주시는 주변 동료들, 머릿속이 어지러울 때마다 의지할 수 있는 사람들이 있었기에 무탈하게 한 해를 마무리할 수 있었다. 또 한편으로는, 차근차근 업무를 해내는 경험을 통하여 자신감을 얻을 수 있었다. 다가오는 2022년에는, 나의 실력에 조금 더 확신을 가지고, 적극적이고 능동적인 자세로 업무에 임하고 싶다. 그러다보면 조금 오버스러울 수도 있고, 실수를 또 하게 될 수도 있겠지만, 괜찮을 거다. 실수한 건 수정하면 되고, 실수한 데에서 배우면 되겠지. 점점 더 나아지고 발전할 것이다.

꾸준하게 건강을 챙기자

시국 탓도 있겠지만 앉아서 일하는 직업 특성상 운동을 도외시하자 순식간에 살이 불어났다. 게다가 이제는 살도 잘 안 빠지고, 체력적인 부담도 바로 체감되는 것을 경험할 수 있었다. 거기다가 허리 아픈건 덤이다...

운동 정말 싫어하는 나이지만... 운동을 시작했고, 식단 조절도 다시 시작했다. 다시 빠지고 또 찌는 한이 있더라도 어느 정도는 체중/체력 관리를 할 필요가 있다고 느껴졌다. 이제는 선택이 아닌 필수다...

미디어 소비를 늘리자

명실상부 미디어 업계 종사자인데, 정작 미디어 소비는 잘 하지 않는 주의이어서 반성한다. 맨날 Youtube만 보지 말고(심지어 Premium도 안 쓴다), 자사 서비스나, Netflix 드라마도 챙겨봐야겠다.

아, 원래 MCU는 봐왔었기에 Disney+는 챙겨볼만 할 것 같다. 지난주에 로키와 완다비전을 몰아서 봤는데 꿀잼이었다. 어서 닥스2 나왔으면...

2개의 댓글

comment-user-thumbnail
2022년 1월 21일

비슷한 생각을 많이 했던거같아서 신기하네요 ㅎㅎ
GoF의 디자인 패턴, 가상면접사례로 배우는 대규모 시스템 설계 기초.... 다 읽어야지 하면서 미루고있던 책들인데 글 보고 다시 읽어야겠다는 생각을 하고 갑니다. 저도 이제 ebook을 사야겠어요...

1개의 답글