CLA
1.CLA) 공통 타입 관리를 위한 Git Submodule 도입기
이슈 상황 클라 팀에서는 API의 Request,Response에 대한 타입을 프론트엔드와 백엔드 팀원이 각각 다르게 작성하고 있습니다. 주요 문제점은 다음과 같습니다: 백엔드에서 API를 완성한 후 Postman을 통해 프론트엔드에 공유합니다. 프론트엔드는 Pos
2.[AWS] IAM을 사용해 사용자 계정 생성 및 권한 부여하기
현재 팀에서는 AWS 루트 계정을 사용해 AWS 리소스에 접근하고 있었습니다. 그러나 더 안전하게 AWS 리소스에 접근하고 관리하기 위해, AWS IAM을 통해 각 사용자에게 필요한 권한만 부여하는 방식으로 변경했습니다. 이번 글은 IAM을 사용해 사용자 계정을 생성하
3.CLA) Pull Request 및 코드 리뷰를 통한 협업 과정의 개선
클라 팀에 합류하면서 기존의 깃허브 협업 플로우에서 문제점을 인식하게 되었고, 코드 품질을 관리하고 협업을 용이하게 하기 위해 깃허브 협업 플로우를 개선하였습니다. 해당 경험에 대해 이야기해보겠습니다.개발자 작업 시작 ⇒ develop branch에서 작업 진행 ⇒
4.CLA) E2E 테스트 코드 도입 및 CI 환경 구축 with NestJS, Github Action
클라이언트 팀에 합류한 후, 가장 먼저 도입하고 싶었던 부분 중 하나가 테스트 코드였습니다. 코드를 파악하는 과정에서 잘못된 부분을 수정하기 위해 PR을 생성했지만, 내가 수정한 코드가 다른 부분에 영향을 미치거나 예상치 못한 이슈를 발생시키지 않을까 불안했습니다. 때
5.CLA) AWS ECS + Fargate를 이용한 서버 배포 및 GitHub Actions을 활용한 CI/CD 환경 구축
CLA 팀은 기존에 prod용 Front, API 서버만을 운영하고 있었습니다. 이로 인해 두 가지 문제가 있었는데요.프론트엔드 개발자의 불편함: 프론트엔드 개발자는 작업 시, 백엔드 서버를 로컬 환경에서 띄워야 했기 때문에 작업이 번거롭고 불편했습니다.QA 진행의 어
6.CLA) AWS Secrets Manager를 통해 환경변수 관리하기
기존에는 프로젝트, 환경별로 env 파일을 만들고 환경변수는 문서로 관리하고 있었음.환경변수가 추가되거나 업데이트 될 때마다, 코드와 문서 모두 관리를 해야했음.ECS를 통해 배포를 하고 있기 때문에, task-definition 파일이 필요했고 task-definit
7.CLA) 운영 안정성 향상을 위한 AWS 모니터링 환경 및 로깅 체계 구축
평화롭던 하루.무언가를 확인하기 위해 AWS ECS Dashboard에 들어갔는데,특정 프로젝트의 dev 서버가 재시작중이었다.엥??이유를 보자하니, 클라이언트 로직에 문제가 있었다.그래서 백엔드 서버로의 API 요청이 재귀적으로 계속 호출되고 있었고,memory, c