2022년 회고 [기술 편]

2021년에 이어 2022년은 많은 기술적 성장이 있었다. 프론트엔드를 위주로 진행하던 기술 스택을 인프라(DevOps) 분야까지 확장했으며, 인프라 분야에 입문하면서 각종 CS (Linux 위주) 와 네트워크 지식을 습득하기 시작했다. 또한, 인프라 분야에서 빌드 성능 최적화에 중요한 컨테이너 가상화와 오케스트레이션 등 다양한 신규 지식 습득을 했던 한 해였다.

 

이 글에서는 정확히 어떤 기술을 공부했고, 그 기술을 통해 어떠한 성장을 이루었는지, 또한 2023년에는 어떤 도전을 할 예정인지 풀어 보려고 한다.

 

---

 

프론트엔드 기술의 변화와 범위 확장

사실 2022년을 통틀어 봤을 때, 내 메인 기술 스택은 프론트엔드가 아니다. 하지만 프론트엔드를 첫 번째 주제로 말하는 것은, '프론트엔드 기술'의 진입 장벽에 관해 먼저 말하려고 한다.

 

약 20년간 프론트엔드는 상대적으로 낮은 진입장벽으로 인해 '누구나 다 하는 기술'이라는 평가를 받아 타 직군 대비 무시를 받는 일이 다분했다. HTML, CSS 만 알면 기본적인 퍼블리싱 작업은 할 수 있었기 때문이다. 물론, 지금도 틀린 말은 아니다. 하지만 근 몇 년간 프론트엔드 시장은 굉장히 큰 변화를 맞이했다. SPA (Single Page Application) 이라는 기술부터, CSR (Client Side Rendering), SSR (Server Side Rendering) 등 프론트엔드 애플리케이션의 성능과 비용 최적화 등을 위한 아주 많은 기술들이 각광받기 시작했기 때문이다. 이러한 기술들을 기본적으로 Node.js 런타임 엔진 (브라우저 밖에서도 JavaScript 기반 프로그램을 실행하는 프로그램) 에서 동작하는 경우가 많으며, 이에 따라 프론트엔드 시장에 자연스럽게 Node.js 기술이 안착하게 되었다.

 

필자의 경우도 기존에는 HTML, CSS 기술 또는 PHP, JSP 안에 마크업을 작성하는 정도만 진행했었는데, React를 접하면서 Create-React-App 을 넘어 TypeScript 와 함께 Next.js 도 적극적으로 활용하고 있다. Next.js 경우 React 와는 달리 프론트엔드 프레임워크이다 보니 처음 접하시는 개발자분들 입장에서는 장벽이 느껴질 수 있겠지만, 필자의 입장에서 보았을 때 Routing 이나 프레임워크에서 제공하는 기능들이 워낙 편리하게 구성되어 있어, 사용에 딱히 불편함을 느끼지는 않았다.

 

 

기획과 디자인

우선 이 주제는 기술에 관한 이야기는 아니다. 하지만 필자가 프론트엔드 개발을 하면서, 본의 아니게 기획과 디자인도 병행하게 되어, 그 스토리를 언급하려 한다.

 

기존에는 기획사나 디자인 업체에서 기획과 디자인을 받아서 해당 디자인을 토대로 프론트엔드 개발을 진행했다. 하지만 리액트를 기반으로 개발을 진행하다 보니 공통적으로 사용되는 컴포넌트는 별도로 분리하여 효율적인 구조를 유지하는 것이 중요하고, 각 컴포넌트마다 props 를 적절히 사용하여 컴포넌트마다 부수적으로 필요한 값이나 컴포넌트들을 적절히 병합하는 것도 중요하다.

하지만 기획사나 디자인 업체에서 받는 산출물들은 디자인 철학이나 개발 편의성을 고려하지 않은 산출물이 많았다. 예를 들면, 동일한 버튼이 여러 개 배치되어 있는 Flex 나 Grid 뷰에 특정 컴포넌트만 크기가 다르다던가, 특정 컴포넌트만 마진 (margin) 이나 패딩 (padding) 값이 다르게 들어가 있는 경우가 있었다. 또 다른 경우로는, 특정 컴포넌트의 구성이 다른 컴포넌트의 구성과 90%는 일치하지만, 10%의 다른 형태의 구조 때문에 그 컴포넌트 자체를 아예 별도로 만들어서 사용해야 하는 경우도 있었다. 이 경우, 10% 의 형태를 props 로 넘겨줄 수도 있었지만, 그 10% 의 변경 사항이 유동적으로 또다시 변경될 수 있는 점도 감안하여 props 가 많아져 코드가 더러워지기 때문이었다.

 

아무튼, 이러한 문제들을 프로젝트를 진행할 때마다 적잖히 느끼고, 그 결과 내 스스로 기획과 디자인까지 진행하기로 결정했다. 결과적으로 보면 내 일을 늘리는 스스로 늘리는 개념의 무리한 결정이었지만, 나의 편의와 추가적인 수입을 위해서는 최선의 결정이었다고 생각한다. 그 결과, 별도의 기획서와 디자이너가 없이도 내 스스로 처음부터 시작하여 프론트엔드 개발까지 진행할 수 있게 되었고, 자연스레 내가 커버할 수 있는 업무의 범위도 확장되는 결과가 되었다.

 

 

플러터 (Flutter)

사실 딱히 해볼 계획은 없었는데, React 를 하다가 네이티브도 해보고 싶어서 React Native를 해볼까 하다가 Flutter 를 접하게 되었다. 하지만 React Native 를 하지 않은 이유는,

• RN 공식 문서보다는 React Native Community를 위주로 흘러가는 분위기여서, 컴포넌트와 기능들에 대한 Long Time Support 가 보장되지 않는다.
• 플랫폼 OS 특성 상 모든 컴포넌트가 각 OS별 네이티브 기능을 100% 지원한다고 보장할 수 없다.
• 왠지 모르겠지만 아직 Release 1.0.0 버전이 없다.
• 등등...

그렇다면, Flutter 를 하는 이유도 있어야겠지.

• Google에서 공식적으로 Support하는 프레임워크이다.
• Material (Android 공식) 또는 Cupertino (iOS 공식) UI 컴포넌트를 기본적으로 지원한다.
• 화면 위에 Canvas를 그리고, 그 Canvas 위에 컴포넌트들을 배치하는 방식이기 때문에 Android와 iOS의 UI적인 차이가 전혀 나타나지 않는다. 실제로 프로덕션 모드로 뽑아 보니 네이티브랑 전혀 차이가 없이 동작한다.
• pub.dev 라는 Flutter 공식 커뮤니티가 있고, Flutter 유튜브 공식 채널에서 pub.dev 에 배포된 좋은 라이브러리들은 정기적으로 리뷰도 해 준다. (npm과 비슷한)

그런 반면... Flutter 에도 단점이 존재한다.

• 플러터 하나(?) 하려고 Dart를 공부해야 한다. 근데 뭐.. 개발자가 새로운 언어에 익숙해지는 걸 두려워하면 안 된다고 생각한다.
• 이것도 결국 커뮤니티 베이스로 돌아간다. 하지만 최소한 React Native 보다는 낫다고 생각한다.
• 컴포넌트 코드의 구조가 조금 신기하다. Child Component가 Parent Component의 width와 height를 따라가고, 그런데 또 Parent Component 의 크기가 정해져 있지 않으면 Child Component 마다 별도로 정의된 속성에 따라 알아서 크기가 잡힌다. 사실 이건 Flutter 의 단점이라기보다는 내 경험 부족이라고 생각하긴 한다.
• Android Studio 에서 Flutter 플러그인의 안정성이 아직 많이 빈약하다. 그래서 Jetbrains 팬이었던 내가 다시 VS Code 를 켰다. 아직 Flutter 지원은 VS Code가 훨씬 낫다.

결론.. 계속 공부해 보자.

 

 

 

인프라 (DevOps)

인프라 영역은 작년 말부터 시작하게 되어 올해에 가장 많은 성장을 만들어낸 분야라고 할 수 있다. 사실 인프라를 전문적으로 시작하기 전에도 카페24 (Cafe24) 나 가비아 (Gabia), 닷홈 (DotHome) 과 같은 단순한 서비스들도 있긴 했었다. 하지만 이런 서비스들의 경우 개발자를 배려한다는 생각은 별로 안 들었고, 일부 서비스는 왜 서비스를 이렇게 운영하는지 모를 정도로 무책임한 기능의 제공 범위와 서비스, 제한된 기능만 제공하여 심지어 개발자가 배포한 서비스를 모니터링하기 위해 콘솔로 해당 인스턴스에 진입하는 행위 자체가 불가한 서비스도 있었다. 물론 그럼에도 호스팅사에서 제공하는 Dedicated Server (독립 서버) 도 있었지만, 호스팅사의 독립 서버를 사용할 바에 클라우드 인프라를 활용하는 것이 훨씬 경제적이고 합리적라고 생각했다.

 

그 결과, 최종적으로 선택한 인프라는 AWS (Amazon Web Services) 였다. 어찌보면 당연한 결과다. 세계 최대 클라우드 기업이고, 수많은 글로벌 기업들이 AWS를 기반으로 서비스하고 있기 때문이다. 물론 다른 기술이라면 니즈에 따라 적합한 기술이 있겠지만, 클라우드는 규모와 가용성, 서비스의 품질이 가장 중요하기 때문에 큰 고민 없이 바로 AWS를 선택했다.

 

글로벌 인프라 중에도 GCP (Google Cloud Platform) 과 Azure (Microsoft Azure), NCP(Naver Cloud Platform), Gabia Cloud 등 많은 서비스가 있지만, AWS가 가장 문서화된 범위가 많고, Region 의 개수가 많아 AWS를 선택하게 되었다. Region과 AZ (Availability Zone) 의 개수는 곧 그 클라우드의 가용성, 안정성과 직결되기 때문이다.

 

 

---

 

내년 목표

 

 

내년에는 인프라 관점에서 더욱더 다양한 서비스를 접하고, 인프라를 더욱더 안전한 환경과 비용 최적화된 환경으로 자유롭게 구축할 수 있도록 더 많은 경험을 쌓아 볼 계획이다.

 

Kubernetes (k8s)

대규모 MSA (MicroService Architecture) 를 기반으로 한 환경에서 오케스트레이션 인프라 (Orchestration Infrastructure) 는 굉장히 큰 역할을 한다. 여러 서비스로 나뉘어져 있는 컨테이너 태스크(Container Tasks) 를 얼마나 효율적으로 관리할 수 있고, 모니터링과 로깅을 통해 서비스의 안정성을 확보하는 능력이 해당 서비스의 가용성을 좌우하기도 한다.

 

AWS 에서는 ECS (Elastic Container Service) 로 기본적인 컨테이너 오케스트레이션 인프라를 제공하고 있고, EKS (Elastic Kubernetes Service) 로 AWS 완전 관리형 k8s 서비스를 제공하고 있다. 타 기업들의 리뷰를 찾아보면 ECS 를 사용하면 EKS 는 굳이 별도로 도입할 필요가 없다는 말이 많은데, 그래도 순수한 Docker 서비스 환경보다는 k8s 베이스의 완전관리형 환경이 컨테이너를 관리하는 데에는 조금이라도 더 편리하지 않을까 하는 생각이 든다.

 

 

IaC (Infrastructure as Code) - Terraform (HashiCorp)

인프라 분야가 급부상하면서, 인프라를 코드로 관리하는 분야도 많이 사용되고 있다. AWS에도 CloudFormation이 있긴 하지만, CloudFormation의 경우 해당 서비스에서만 사용할 수 있는 설정들로 yaml 파일을 구성해야 하고, AWS 서비스 안에서만 사용이 가능하다. 그에 반해 Terraform 의 경우 AWS, GCP, Azure 등 다양한 클라우드를 통합적으로 지원하므로 Terraform HCL (Hashicorp Configuration Language) 를 활용하여 다양한 클라우드 서비스의 운영 환경을 코드로 관리할 수 있다는 장점이 있다.

 

 

Jenkins

CI/CD (Continuous Integration/Continuous Deployment) 에 관한 이야기이다. 물론 AWS에서도 CodePipeline (CodeCommit + CodeBuild + CodeDeploy) 서비스가 있지만, 이는 AWS 에서만 제공되는 서비스이고, GitHub, BitBucket 등 타 서비스와 함께 CI/CD 파이프라인을 운영하는 경우 AWS CodePipeline 에서 모든 파이프라인을 구현하기에는 한계가 있을 수 있다. 현재도 CodePipeline 외에 GitHub Actions 를 사용하고 있고, 추후 안드로이드 자동 배포 파이프라인 구축 등 추가적인 파이프라인을 구성하기 위해 Jenkins 를 추가 도입해 보려고 한다.

 

 

 

Golang, WASM, ArgoCD, WebSocket...

이런 것들도 한번 시도해 보려고 한다.

 

 

---

정리

 

어쩌다 보니 약간 제너럴리스트 (Generalist: 여러 분야를 넓고 얕게 하는 형태) 가 된 느낌도 든다. 그래도 나름 이 업계의 일이 재미있기 때문에 여러 분야를 함께 시도한다는 느낌이 만약 나쁘지는 않다. 오히려 여러 분야를 모두 할 수 있는 인재가 되도록 노력하고 있는 느낌이 든다. 여러 분야를 모두 한다는 것이 어찌 보면 전문 분야가 없다는 관점에서 보면 안 좋은 의미로 다가오기도 하지만, 개인적으로 "여러 분야를 한다는 것이 전문 분야가 없다는 것일까?" 라는 생각을 갖고 산다. 여러 분야를 다 전문적으로 하면 좋은 것 아닌가 하는 생각 말이다.

 

개인적으로 자존감이 높고 워낙 다른 사람들을 의식하지 않고 내 할일 열심히 하고 살아가는 타입이라 이렇게 생각하는 것일 수도 있지만, 지금까지 나의 커리어는 주변 사람들과 굳이 비교하지 않아도 전혀 뒤쳐지지 않고 있다고 생각한다. 과연 프론트엔드와 디자인과 인프라를 함께 관리할 수 있는 사람이 있다면 상상 이상으로 매력적인 인재가 되지 않을까 하는 주관적 만족감 (personal satisfication) 을 가지고 살아간다. 단순히 Hello World 만 찍어보고 넘어가는 것도 아니고, 지속적으로 프로젝트들을 하면서 추가적으로 필요한 영역들을 확장하는 의미의 성장이기 때문이다.

 

아마 내년 이맘때 정도 되면 어느정도 인프라 설계와 관리에 있어서는 자신있게 어필할 수 있게 되지 않을까 생각한다.