jongp.me

2019 회고록

January 05, 2020

들어가며

2020년이 되었다. 원래 계획이라면 2019년도에 회고록을 작성을 마무리하는 것이었으나, 미루고 미루다 보니 2020년이 되었다. 연말에 이직으로 인한 인수인계, 기타 약속 등 많았다고 하면 핑계겠지.

두 번의 이직 결정

2월

처음으로 프론트엔드 직군으로 이직하게 되었다. 모든 것이 새로웠고 재미났다. 기존에 해왔던 기술과 전혀 다른 기술을 사용하여 일하게 된 것도 신기했고, 정말 좋은 개발자들과 함께 일할 수 있어서 재밌었다. 함께 일했던 모든 개발자에게 배울 점이 많았다. 문서 작성 방법, 문제에 접근하는 방법, 다른 개발자와 대화하는 방법 등을 배울 수 있어 좋았다. 하지만 적응하기까지 시간이 굉장히 오래 걸렸다. 지금까지 내가 사용해왔던 문법, 규칙 등과 전혀 다른 방식이었다. ES6에 대한 적응, 리액트 적인 사고방식, 다양한 라이브러리를 사용하는 방법 등. 그 시간은 꾸준하게 개인프로젝트를 하면서 반복하면서 적응하려고 노력했다.

장점으로 근무 조건이 좋았다. 자율출퇴근제도의 달콤함을 알아버렸다. 일하다가 잘된다 싶으면 집중해서 일을 끝내고 다음 날 혹은 그 다음 날 늦게 나오거나 일찍 퇴근하는 등 업무 시간을 조절하면서 일할 수 있었다. 또한, 훌륭한 사수 덕에 늦게 입문한 프론트엔드 개발에서 지름길을 찾을 수 있었다. 인생에서 중요한 터닝포인트에 귀인을 만난 것 같았다. 함께 작업한 내용, 코드 리뷰를 진행하면서 더 빠르게 성장할 수 있었다.

프론트엔드 개발자로 커리어를 시작함에 있어 정말 좋은 회사였다.

12월

프론트엔드 직군으로 두 번째 회사로 이직하게 되었다. 입사일은 19년 1월 2일이었지만, 입사를 결정한 것이 18년 12월 8일이었던 것으로 기억한다. 또 다른 도메인으로 이직하는 것이 나중에 문제가 될 수도 있겠다는 생각을 했지만, 이직을 결심하게 된 것은 기존의 프로젝트를 리액트로 컨버팅 한다는 얘기를 들었기 때문이다. 처음부터 시작한다는 것이 나를 굉장히 설레게 하였다. 지금까지 다닌 회사에서는 이미 만들어진 서비스에서 추가 기능을 구현하거나, 유지보수를 하는 것이 주된 업무였기 때문이다. 이러한 이유가 이직을 결심하게 하였다. 1년을 채우지 못한 것은 아쉽지만, 기회가 왔을 때 잡는 것도 필요하다고 생각했기에 이직을 결심했다.

스터디

스터디를 시작했다. 가온아이에서 함께 일했던 분 중에 프론트엔드 쪽 공부를 하고 싶어 하는 분들과 모이게 되었다. 프론트 쪽으로 이직을 생각하고 계시거나 회사에서 리액트를 사용하게 된 분 등 다양한 사연이 있었고, 최대한 내가 실무에서 쓰던 내용 등을 알려주고 싶었다. 그렇게 시작한 스터디에서 내가 몰랐던 내용, 소홀하게 했던 내용 등을 공유하면서 나도 발전하고 있음을 느꼈다.

React

혼자 공부하면서 익혔던 리액트는 정말 기초적인 부분임을 깨달았다. 토이프로젝트에서 겪을 수 없는 다양한 문제들이 실무에서는 발생했다. 또한, 혼자 하고 싶은 것만 골라서 하는 개인프로젝트와 다르게 기획자의 의도에 맞게 개발하기 위해선 항상 새로운 것을 알아야 했다.

훌륭한 사수 덕분에 리액트에 대한 내용을 많이 배우며 일할 수 있었다. 리액트 혹은 개발을 하면서 특정 로직을 구현할 경우 조언 등을 구하며 진행할 수 있었다. 프론트엔드 개발자로 사수와 나 두 명이 전부였기에, 리팩토링 혹은 새로운 내용을 개발할 때 어떤 패턴을 사용할 것인지 향후 우리 서비스에 어떤 것이 더 도움될 것인지 등의 이야기를 나눌 수 있어서 좋았다.

하지만 아직 알아야 할 개념들이 많다. 코드스플리팅이나 서버사이드랜더링의 경우 개념만 알고 구현된 내용을 보기만 했을 뿐 직접 구현한 적이 없다.

AWS

가온아이에서는 EC2 서비스 하나만을 사용했었다. 그때는 AWS에 어떤 기능들이 존재하는지도 몰랐고, ssh를 통해 EC2에 접속해서 web server를 설치 후 서비스를 배포해서 사용했다. 하지만 플루토스디에스에 입사하면서 그동안 내가 AWS를 제대로 알지 못했다는 것을 알게 되었다.

올해 회사 및 토이프로젝트를 통해 스스로 설정하거나 한 번이라도 스쳐 간 기술들은 아래와 같다.

  • AWS에서 endpoint를 만들어 내부 VPC, Lambda 등을 보다 편리하게 사용할 수 있게 해주는 API Gateway
  • Serverless를 구성할 수 있게 도와주는 Lambda
  • Lambda 등 AWS 서비스의 로그를 확인하게 해주는 CloudWatch
  • NoSQL DB인 DynamoDB
  • 파일 저장 혹은 static 배포를 위한 S3
  • cdn 역할을 해주는 CloudFront
  • 서비스의 사용자 풀을 관리하게 해주는 Cognito, 인증 절차를 보다 편리하게 해주는 Amplify
  • 서비스 이용자들의 권한을 관리해주는 IAM
  • 가상머신을 만들어 주는 EC2
  • 서비스를 보다 배포하고 모니터링 등의 관리를 해주는 Elastic Beanstalk
  • 암호화에 필요한 KMS 및 Key를 관리해주는 Secret Manager
  • Github처럼 코드의 형상관리를 해주는 CodeCommit
  • 코드의 자동 배포 CI/CD를 위한 CodePipeline, CodeDeploy

내가 알고 있는 내용이 정확하게 맞는지 모르겠으나, 이러한 기술들이 있음을 알게 되었다. 과거 이력서에 EC2만 사용했으면서 AWS를 활용할 줄 안다고 써놨던 나의 패기가 대단했음을 느꼈다.

이번에 이직한 회사에서는 현재까지 AWS를 사용하지 않는다고 한다. 그 부분이 아쉽기는 하지만 꼭 AWS를 써야 서비스를 제공할 수 있는 것이 아니므로 무조건 필요하다고 생각하진 않는다. 하지만 AWS가 서버를 빠르게 구성할 수 있게 도와주기 때문에 개인프로젝트에서는 꾸준하게 사용해 볼 생각이다.

Document

문서를 보고 하는 개발이 서툴렀다. 당연히 그럴만했다. 과거의 나는 전자정부프레임워크 JSP jQuery라는 정해진 스펙에서 개발을 진행했다. 새로운 기술을 추가하는 것도 좋아하지 않던 회사였다. 문서를 볼 일도 없었고, 다른 사람이 만든 라이브러리를 사용한 때도 거의 없었다.

눈 뜨면 바뀌는 버젼, 새로 업데이트되는 미들웨어, 우리 서비스를 더욱 좋게 만들어줄 라이브러리 등 문서를 보지 않으면 아무것도 할 수 없었다. 글 읽는 것을 별로 좋아하지 않던 사람이라 새로 업데이트되는 내용을 읽는 것도 힘들었다. 직접 타이핑을 해야 개발을 한다고 느껴졌다. 하지만 문서를 제대로 읽지 않고 사용하는 것은 시간을 낭비하는 것이었다.

과거의 나는 새로운 것을 배우려면 무조건 책부터 구매했고, 개발하면서 에러가 났을 경우 구글에서 검색해서 나오는 스택오버플로우를 의존했다. 앞에 말한 것이 나쁘다는 것은 아니다. 하지만 내가 사용하는 프레임워크, 라이브러리 등의 설명은 직접 만든 사람들이 작성한 공식문서에 제일 정확하게 나와 있다는 사실을 알게 되었다. 이 사실을 깨달은 이후 읽기 힘든 영어로 되어있더라도, 공식문서를 한 번은 살펴보고 개발하는 것이 좋다는 생각을 하게 되었다.

2020 목표

  • Javascript concept 완벽 이해
  • Vue, Svelte등을 슬슬 만저보기
  • 오픈소스 하나 만들어서 배포하기
  • React Native 프로젝트
  • 이직한 회사의 도메인 이해

JongGyun Park
Written by JongGyun Park.About Me
github