개발 팀이 편안한 환경에서 장기적인 성과를 낼 수 있도록 노력해왔습니다. Development 가장 코드 양이 많은 JavaScript, Python을 중심으로 Convention 확립에 노력했습니다. JavaScript, TypeScript Node.js 프로젝트에 전역적으로 적용할 수 있는 ESLint Sharable Config 를 https://github.com/sehyun-hwang/eslint-config-nextlab 에서 오픈소스로 관리하고 있습니다. Python에서는 Type checking과 Linting을 동시에 구동하기 위해서 mypy를 Child process로 실행하는 pylint plugin을 제작한 적이 있으며, 최근에는 ruff linter와 black formatter를 사용하고 있습니다. 다양한 언어로 이루어진 Monorepo에 대한 Convention을 관리하기 위해서 MegaLinter 와 그것의 Github Action 을 도입했습니다. Building 이미지 처리 등의 특수한 기능이 있는 컨테이너들에 대해서는 불필요한 컴파일러와 인터프리터를 제거하는 Multi-stage build 를 수행했습니다. alpine 기반의 컨테이너로 컨테이너의 이미지 크기를 줄여 빌드 시간 단축, 배포 속도 개선, 취약점 개선 등의 효과를 얻었습니다. 복수의 Dockerfile을 이용한 Container build, 빌드 캐시 관리 등 High-level build 기능을 구현해주는 buildx bake 를 도입했습니다. Makefile을 이용해 직접 별도로 컴파일해야 하는 C++ 프로젝트나 표준적이지 않은 프로젝트의 개발-빌드-테스트-배포 과정을 관리합니다. 빌드를 위한 인프라를 관리할 필요가 없고 동시에 작업을 병렬적으로 진행할 수 있는 Serverless CI를 추구합니다. AWS CodeBuild GitHub Action Testing Test runner가 테스트 케이스들을 병렬적으로 수행하는 데 문제가 없도록 하는 정석적인 객체 지향 코드를 작성합니다. 서비스 코드에 Side effect가 없고 부분 별로 역할 구분이 명확해야 테스트 코드에서 class를 상속받아서 테스트 케이스를 작성할 수 있었습니다. vitest , pytest 로 테스트 케이스를 작성할 수 있습니다.

어떻게 보면 당연한 관습들을 풀어서 글로 남겼습니다. Routines IAM Production 환경에서는 Lambda execution role 과 EC2 IAM role 등의 IAM temporary credential 기능을 활용합니다. 리소스에게 부여된 권한들은 해당 리소스의 동작에 대한 명세이기도 하다고 생각하고 있으며, Service role에 Least privilege rule을 최대한 준수했습니다. 프로젝트 별로 User group을 만들고 개발자들에게 개발에 필요한 권한을 부여합니다. GitHub CLI SSO , AWS CLI SSO 등의 SSO 서비스를 사용해 개발자가 개발에 필요한 권한을 획득할 수 있도록 도입 중입니다. Secrets Management ...

AWS에서 어떤 서비스를 써보셨나요? 라는 질문에 답하기 힘들어서 적은 페이지 Skills Infra Python, Node.js 등의 언어로 작성된 코드가 구동되는 EC2 instance의 type과 FarGate, Lambda 등 Serverless 서비스의 spec을 선정할 수 있습니다. 비용 절감 Lambda와 Container에 ARM architecture를 우선적으로 검토합니다. EC2 Spot instance 와 Fargate Spot capacity provider 등 짧은 생명 주기를 가진 인프라를 이용합니다. EBS, EFS, S3 등 적절한 종류의 Storage를 선택하고 EC2 등의 인프라에서 사용할 수 있습니다. AWS Backup plan & lifecycle 을 지정해 EBS , EFS , RDS 등에 대해서 주기적으로 Backup을 수행하고 삭제할 수 있습니다. Monitoring Monitoring experience 페이지의 CloudWatch 부분 을 참조해주세요. ...