달리는 자동차에 바퀴 교체하기

들어가며

2023년 9월 22일 인프런 CTO이신 이동욱님과 약 한 시간 정도 함께 할 수 있는 기회가 있었습니다. 한 시간이라는 시간 동안, 저희의 질문에 막힘없이 답해주시는 동욱님 덕분에 큰 인사이트를 얻을 수 있었습니다. 집에 돌아가면서 동욱님에게, 우리 팀은 한 시간이라는 시간 동안 무엇을 배웠는지 글로 정리해서 공유드리겠다고 말씀드렸는데요. 집에 돌아와 배운 점을 정리하면서, 단순히 배운 점만을 정리하는 것이 의미가 있을까 생각했습니다. 배움으로만 그치지 않고, 배움을 통해 얻은 인사이트를 활용해서 팀 내의 문제를 해결한 후, 동욱님 덕분에 우리 팀은 이런 문제들을 해결할 수 있었다고 말할 수 있는 개발자가 되고 싶었습니다.

이번 기회에 팀에서는 지금까지 어떤 문제를 겪어왔고, 멘토링 이후 팀의 문제를 어떻게 해결했는지 간략히 정리해보려 합니다.

1. Pulumi 도입

문제 상황

저희 팀은 AWS 인프라를 AWS GUI 콘솔을 활용해서 관리하고 있었습니다. 비즈니스가 고도화됨에 따라, 여러 대의 서버를 증설해야 했습니다. AWS 인프라를 수동으로 관리하고 있는 상황에서, 같은 역할을 하는 서버 환경을 여러 대 구축하려면 여러 번의 클릭을 통해 서버를 증설해야 했습니다. 서버를 생성하는 것이 익숙하면 문제가 없겠지만, 매일 같이 서버 인프라를 생성하는 것이 아니기 때문에, 이전에 어떻게 서버를 생성했었는지 기억하지 못한다면 서버를 생성하는 시간이 오래 걸리는 문제가 발생했습니다. 그리고 수동으로 서버를 생성하는 과정에서 서버에 필요한 옵션 값을 누락하기도 했고, 이전 개발자가 어떻게 서버를 생성하고 관리했는지 히스토리를 파악하기도 대단히 어렵다는 문제가 있었습니다.

이 문제를 어떻게 해결할 수 있을까 질문 드렸을 때 동욱님은 Pulumi를 통해 인프라 구성 단계를 효율적으로 구성한 사례를 설명해주셨습니다. 설명을 듣고, 우리 팀도 Pulumi를 활용하여 인프라 계층 전체의 복제가 필요할 때, 손쉽게 복제하기 위해 인프라를 코드로 관리할 수 있는 체계를 만들어야겠다고 판단했습니다. 이를 위해 팀 내에 IaC 환경을 구축했습니다.

많은 팀들이 테라폼을 활용해서 IaC를 관리하는 것을 보고, 테라폼을 활용해서 관리를 해볼까 했지만, 동욱님의 설명을 들으며 Pulumi로 IaC를 관리하는 것을 선택했습니다. 그럼 왜 Pulumi를 선택했는지 정리해보려 합니다.

1. 프로그래밍 언어

첫 번째, Pulumi는 선언형 언어가 아니라서 IDE의 자동 완성 기능을 활용할 수 있다는 점이 큰 장점이라고 생각했습니다. 테라폼은 선언형이라서 설정값을 넣으면 자동으로 인프라가 만들어지는 구조입니다. 하지만 Pulumi는 선언형 언어가 아니고, 프로그래밍 언어로 인프라를 관리할 수 있었습니다. 그렇기 때문에 IDE의 자동완성 기능을 활용할 수 있었고, ESLint, Prettier, 모노 레포 등으로 코드 품질을 관리할 수 있다는 점에서 Pulumi를 활용하는 것이 훌륭한 선택일 수 있겠다고 생각했습니다. 심지어 Jest로 단위 테스트까지 작성할 수 있으니 코드 품질을 더 끌어올릴 수 있겠다고 판단했습니다.

2. 문서 품질

두 번째로, 공식 문서의 품질이 대단히 좋다는 점이 인상 깊었습니다. 테라폼의 경우, 참고할 수 있는 컨텐츠들은 많았지만 IaC를 전혀 모르는 상황에서 공식 문서를 봤을 때 어디서부터 어떻게 적용해야 할지 감이 잘 오지 않았습니다. 하지만 Pulumi를 살펴봤을 때, 공식 문서만 보고도 빠르게 서비스에 IaC를 적용할 수 있겠다고 판단했습니다.

기대효과

Pulumi를 활용하여 현재 생성된 인프라를 코드로 관리할 수 있도록 환경을 셋팅했습니다. 이를 통해 Pulumi 명령어 한 번만 입력하면, 원하는 서버를 곧바로 증설할 수 있었습니다. 이를 통해 인프라 관리에 필요한 시간이 확 줄어들게 되었고, 인프라가 어떻게 구성되어 있는지 코드로 확인할 수 있기 때문에 히스토리를 파악하는데도 훨씬 효율적인 환경을 구축할 수 있었습니다.

2. CloudFront 도입

문제 상황

육아크루 앱 내에서 이미지가 천천히 노출되는 문제가 있었습니다.

육아크루 앱 내에서 활용하는 이미지는 Firebase Storage에 저장하여, 저장된 이미지를 조회하는 형태로 운영했습니다. 사진 데이터를 별도로 캐싱하지 않고 있었기 때문에, 이미지를 조회할 때마다 Firebase Storage에 저장되어 있는 사진 데이터를 다운로드 받아야 하는 상황이었습니다.

이 과정이 처음 개발할 땐 전혀 문제 없었지만, 육아크루를 사용하는 사용자가 많아지면서 Firebase Storage에 저장된 사진 데이터를 많이 다운로드 받아야 했습니다. 이 과정에서 심지어 사진 데이터의 크기가 클수록 다운로드 받는 시간이 오래 걸리곤 했고 Firebase Storage를 사용할 때 과금되는 문제도 함께 발생했습니다.

문제를 해결하지 않는다면, 육아크루를 사용하는 사용자가 많아질수록 더 많은 비용을 지불해야 할 수 있었고, 앱 내에서는 이미지가 천천히 노출되기 때문에 앱 사용성이 좋지 못해 유저가 서비스를 이탈할 수 있는 상황이었습니다. 문제 해결을 위해 CloudFront을 활용해보면 좋겠다고 판단했는데요. 하지만 CloudFront를 단순하게 활용하는 것과 이 기술을 잘 활용하는 것은 다른 문제였습니다. 그래서 CloudFront를 어떻게 하면 잘 활용할 수 있을지 동욱님에게 여러 질문을 드렸고, 그 과정에서 여러 인사이트를 얻을 수 있었습니다.

해결 과정

인프런에서는 CloudFront를 왜, 그리고 어떻게 활용했는지 질문드렸습니다. 인프런에서는 CloudFront를 ALB 앞단에 둠으로써 Path별로 다른 서버에 접근할 수 있도록 분기처리했다는 것을 알았습니다. 단순히 로드 밸런싱의 역할을 하는 것이면, 로드 밸런서를 하나 두면 될텐데 왜 CloudFront를 사용했는지 여쭤봤을 땐, CloudFront를 활용하면 S3, API Gateway 등을 연결함으로써 다양한 서비스로 라우팅이 가능하다는 큰 장점이 있다는 것을 말씀주셨습니다. 그 외에도 CloudFront를 활용하면 여러 장점이 있다는 것을 말씀주셨는데요.

CloudFront를 사용하면 어떤 장점이 있을 수 있는지 아래와 같이 정리했습니다.

1. CDN

CloudFront는 고속 컨텐츠 전송 네트워크 서비스(CDN)로서 전 세계에 전략적으로 배치된 대규모 서버 네트워크를 이용하여 지리적으로 가장 가까운 Edge로부터 Contents를 전송합니다.

Edge Server에서 이미지 데이터를 캐싱하고, 캐싱된 이미지를 조회한다면 매번 이미지 저장소에서 이미지를 조회하지 않아도 되기 때문에 효율적으로 데이터를 전달할 수 있다는 장점이 있습니다.

2. 네트워크 망

CloudFront는 전세계 29개국 65개 도시 166개의 Edge가 전세계 퍼져있는 1200개 이상의 인터넷 서비스 프로바이더와 직접 연결되어 있습니다. 심지어 AWS 글로벌 백본망에 연결되어 있다는 특징이 있습니다. 백본망은 origin에 위치한 리전, Edge 간의 전용회선이고 이중화된 100기가빗이더넷 네트워크로 구성되어 있습니다. 그래서 CloudFront를 활용하면 보다 빠르게 트래픽을 전달할 수 있다는 장점이 있습니다.

예를 들어 S3가 서울 리전에 존재하고, 사용자가 유럽에 있다면 유럽에 있는 사용자가 S3에 있는 이미지를 조회할 땐 public internet을 사용해서 데이터를 전달받아야 하지만, CloudFront를 S3와 연결해서 활용한다면, 이미지를 조회할 때 Backbone 망에서 전달받은 후, cloudfront에서 유럽에 있는 사용자에게 데이터를 pubic internet에서 전달하면 되기 때문에 더 빠르게 데이터를 전달할 수 있습니다.

3. Dynamic Contents Delivery

CloudFront를 활용하면 이미지, 동영상과 같은 데이터 뿐 아니라, 서버에서 받아오는 데이터(동적 데이터)를 사용자에게 전달할 때도 데이터를 빠르게 전달할 수 있다는 특징이 있습니다.

서버에서 데이터를 받아올 때 같은 요청을 하더라도 다른 결과를 받아오는 경우가 많습니다. 예를 들어 게시판에서 게시글 목록을 조회한다고 가정하겠습니다. 만약 유저가 게시판에서 게시글을 새롭게 작성한다면 새로운 게시글 정보가 서버에서 클라이언트로 전달될 것입니다. 이처럼 API 요청을 할 때 매번 응답 결과가 달라지는 데이터를 동적 데이터라고 이야기합니다.

CloudFront에서 동적 데이터를 주고 받을 때 전송 성능을 향상시킬 수 있습니다. 이를 이해하기 위해서는 API의 응답 시간에 대한 이해가 필요합니다.

요청자가 요청을 하면 DNS Lookup을 통해 서버를 찾고, TCP 3 way handshake를 통해 서버에 연결되고 Time To First Byte라는 최초 응답이 오면 비로소 컨텐츠를 다운로드 받게 됩니다.

만약 CloudFront를 사용하고 있지 않은 지금은 위와 같은 형식으로 데이터를 주고 받게 됩니다. 매번 사용자가 서버에 API 요청을 할 때 마다 DNS Lookup을 통해 서버를 찾고, TCP 3 way handshake를 통해 서버에 연결되고 Time To First Byte라는 최초 응답이 오면 비로소 컨텐츠를 다운로드 받게 되는데요. 그럼 하나의 API를 요청할 때마다 400ms의 시간이 걸린다고 가정해보겠습니다.

CloudFront를 활용하면 1번째 사용자의 API 요청에 대한 응답값만 400ms로 전달됩니다. 그리고 2번째 사용자부터는 CloudFront의 TCP 3 way handshake 비용만 추가되고, CloudFront에서는 ELB 서버와 계속해서 연결시켜두고 있기 때문에(Keep Alive Connection) CloudFront 서버와 ELB 서버 간의 TCP 3 way handshake는 생략할 수 있습니다.

그럼 CloudFront와 연결되는 비용만 들기 때문에, 총 30ms (CloudFront 3 way handshake 비용) + index.php 데이터를 주고받는 비용 10ms + CloudFront에서 ELB로 index.php 데이터를 주고 받는 비용 9

0ms가 소요되어 총 130ms의 시간이 소요될 것입니다.

즉 API 응답을 처리할 때 400ms의 시간이 걸렸는데, CloudFront를 사용하면 130ms로 줄어드는 엄청난 성능 향상을 맛 볼 수 있습니다. 심지어 데이터를 전송할 때 Gzip 압축을 통해 데이터의 사이즈를 줄여서 전송함으로써 전송 성능을 더욱 향상시킬 수 있습니다.

4. Gzip 압축

CloudFront를 활용하면 Gzip 압축을 활용할 수 있습니다. Gzip 압축을 활용한다면 데이터를 압축하여 전달하기 때문에 콘텐츠 다운로드 시간을 단축 시킬 수 있고, 데이터를 전송하는 비용을 절감시킬 수 있습니다. Gzip 압축을 활용하면 최대 80%의 속도, 비용을 개선시킬 수 있습니다.

5. Origin 보호

육아크루에서는 여러 대의 ALB를 활용하고 있었습니다. ALB 별로 API가 분산되어 있었습니다. 클라에서 API를 호출하려면, 여러 대의 서버 Origin을 알아야 했습니다. 여러 대의 origin이 외부에 노출되어 있다는 뜻은, 외부에서 공격이 들어올 서버가 많다는 것을 의미했습니다. 하지만 CloudFront를 활용하면 ALB의 origin을 외부에 노출시키지 않아도 된다는 장점이 있었습니다. CloudFront에만 HTTPS를 적용하면, 뒷단에 있는 서버는 http 통신을 하면 되기 때문에 네트워크 비용도 줄일 수 있다는 장점이 있었습니다.

CloudFront의 URL만 알면, CloudFront에 연결된 서버에 접근이 가능했기 때문에, CloudFront은 단일 진입점이 될 수 있었습니다. 그럼 ALB만 사용했을 경우엔, ALB 모두에 WAF를 연결해서 관리해야 했는데 CloudFront에 WAF를 연결하면, 한 곳에만 WAF를 연결하더라도, 뒷 단에 있는 ALB까지 보호받을 수 있기 때문에 효율적으로 보안 설계를 할 수 있다는 장점도 존재했습니다.

위와 같은 장점을 활용하기 위해 육아크루 서비스 내에서 CloudFront를 도입했습니다.

CloudFront, WAF 도입

CloudFront를 도입하기 전, 구성된 아주 간단한 인프라 아키텍처입니다. 사용자는 public 서브넷에 위치한 ALB, Api Gateway에 직접적으로 접근할 수 있었던 환경이었습니다. CloudFront와 WAF 서비스를 도입함으로써 아래와 같이 서버 아키텍처가 구성되었습니다.

위와 같이 구성함으로써 API 통신은 CloudFront로만 할 수 있게 되었고, ALB의 URL을 알아도, 직접적으로 API 호출을 할 수 없도록 보안그룹을 설정했습니다. 이렇게, CloudFront를 구성하면 모든 것이 술술 풀릴 줄 알았지만 여기서 끝이 아니었습니다.

클라이언트는 ALB의 URL을 사용하여 API 호출을 하고 있었는데, 이제는 CloudFront의 URL을 통해 API를 접근해야 했습니다. 그래서 클라이언트 코드에서 API 호출을 하는 URL을 변경해줘야 했고, 서버 내부끼리 호출하는 API도 수정해줘야 했습니다.

기존에는 ALB가 public하게 열려있다 보니, ec2에서 ALB로 API를 직접 접근할 수 있었지만, 이제는 ALB에 직접 접근할 수 없고, CloudFront를 통해서만 ALB에 접근할 수 있도록 구성함으로써 ALB에는 직접적으로 접근할 수 없도록 구성했습니다. 그래서 클라이언트, 서버 코드 중, API를 호출하는 코드를 모두 변경해줘야 했습니다.

URL 변경

서버 내부적으로 사용하는 API 호출 코드는 바로 수정할 수 있었지만, 클라이언트 코드는 곧바로 수정하기 어려웠습니다. 앱 서비스를 운영하고 있다 보니, 코드를 변경해서 신규 앱 버전을 출시하더라도 업데이트가 안된 버전을 사용하고 있는 유저는 ALB로 API를 호출하는 방식으로 동작하는 코드를 사용할 것이었습니다.

모든 유저가 최신 업데이트된 서비스를 활용할 수 있도록 앱 강제 업데이트를 하도록 구성했고, 대부분의 유저가 업데이트가 됐을 때 비로소 ALB에 직접적으로 접근하지 못하도록 보안그룹을 막도록 설정했습니다.

CloudFront OAI 설정

추가적으로, AWS S3에서 이미지를 조회하는 기능을 구성할 때도 큰 이점이 있었습니다. S3에 이미지를 저장할 때 Presigned URL을 활용한다면 직접적인 액세스 접근이 불가능한 S3 버킷에 이미지를 손쉽게 업로드할 수 있습니다. 하지만 S3에 직접적인 액세스가 불가능하기 때문에 S3 버킷에 저장된 이미지를 조회하려면 S3 버킷을 public으로 구성해둬야만 했습니다.

저희는 S3 버킷의 직접적인 액세스를 할 수 없도록 private하게 구성하지만, S3 버킷에 저장된 이미지는 외부에 조회되도록 구성하기 위해 CloudFront OAI를 설정했습니다. OAI를 설정하면 S3가 private하게 구성되어있지만, CloudFront를 통해 S3에 접근하면 이미지가 조회될 수 있도록 환경을 구축했습니다.

이렇게 CloudFront을 마무리할 수 있었습니다.

기대효과

CloudFront를 도입함으로써 팀 내에서는 아래와 같은 성과가 있었습니다.

1. CDN 서비스를 활용함으로써 이미지를 캐싱하는 환경을 구성했습니다. 이미지를 캐싱했기 때문에 앱에서 사용해야 하는 이미지를 매 번 다운로드 받지 않고도 빠르게 데이터를 전달할 수 있게 됐습니다. 이는 곧 서비스 사용성 개선으로 이어졌습니다. 작업 덕분에 Firebase에 이미지를 다운로드 받는 비용을 지불하지 않을 수 있도록 개선했습니다.

2. CloudFront를 거쳐야만 내부 서버 접근이 가능하기 때문에, CloudFront 앞에 WAF를 붙임으로써 보안 측면에서 관리 대상이 확 줄어들었습니다.

3. CloudFront 활용을 통

   해 서버에서 받아오는 데이터를 빠르게 전달할 수 있게 됐고, 이는 곧 사용성 개선으로 이어졌습니다.

개선점

현재는 ALB에 HTTPS가 적용되어 있습니다. 이제는 CloudFront에만 HTTPS가 적용되면 되기 때문에, ALB에 HTTPS를 적용하지 않음으로써 네트워크 통신 시 비용을 더 줄일 수 있지 않을까 생각했습니다. 그래서 추후 ALB의 HTTPS를 HTTP로 변경하는 작업을 하고, 이렇게 작업했을 때 얼마나 성능이 개선됐는지 확인해보려 합니다.

3. Private ALB 도입

문제 상황

육아크루 서버 내부에서만 사용하는 API가 외부에 노출되어 있는 상태였습니다. 비즈니스가 고도화됨에 따라 서버 내부에서만 사용하는 API 통신이 많아지고 있었는데, 서버 간 API 통신을 해야 할때 DNS 서버를 거쳐야만 했기 때문에 추가적인 네트워크 리소스가 들었습니다. 만약 API 중, 외부에는 노출되어서는 안되는 정보를 응답값으로 제공하는 API가 있다면, 이런 API들까지 외부에 노출될 수 있기 때문에 이런 상황은 서비스에 큰 문제를 야기할 수 있다고 생각했습니다.

동욱님과의 대화를 통해 인프런에서는 서버 내부에서 사용하는 API 통신을 처리하는 Private(VPC) Load Balancer를 사용한다는 것을 알 수 있었습니다. private load balancer를 활용하면 외부 DNS를 거치지 않기 때문에 네트워크 리소스가 줄어들고, VPC 내부에서만 트래픽을 주고 받기 때문에 트래픽 비용이 감소한다는 장점이 있었습니다. 마지막으로 외부에 API 인터페이스를 노출시키지 않을 수 있기 때문에 보안적으로도 큰 장점이 있었습니다.

해결 과정

문제 해결을 위해 위와 같이 VPC Private Subnet 안에 존재하는 서버끼리만 API를 호출할 수 있도록 private ALB(internal 서버)를 구성했습니다. 서버 내부에서만 호출해야 하는 API를 모두 Internal 서버로 이관했습니다. 이를 통해 외부에 노출되어서는 안되는 API를 모두 숨김 처리할 수 있었습니다.

Internal 서버의 API를 호출할 땐, Basic 인증 방식을 활용해서 서버 간 최소한의 인증, 인가를 확인할 수 있도록 구성했습니다. 서버 내부에서만 사용하는 사용자 ID, 비밀번호를 활용해서 Base64로 문자열을 인코딩한 후 API를 활용할 서버에 인증 정보를 전달합니다. 인증 정보를 받은 서버에서는 값을 디코딩 후, 서버에서 사용하는 아이디, 비밀번호가 맞다면 API의 값을 응답해주는 방식으로 구성했습니다.

기대 효과

internal 서버를 추가함으로써 서버 내부에서만 사용하는 API 인터페이스를 외부에 노출시키지 않을 수 있었습니다. 그리고 서버 간 통신을 할 때 DNS 서버를 거치지 않아도 됐기 때문에 네트워크 비용을 줄일 수 있었고, 트래픽 또한 분산처리 할 수 있었습니다. 이를 통해 API의 성능을 개선시킬 수 있었고, 이는 곧 사용성 개선으로 이어졌습니다.

이렇게 인프런 멘토링을 통해 얻은 인사이트를 바탕으로 육아크루 서비스를 개선하는 과정을 말씀드렸습니다. 하지만 서비스 개선을 위해서는 해야 할 일이 너무나도 많았는데요. 저희 팀에서 추가적으로 효율화한 내용에 대해 설명드리겠습니다.

4. AWS 보안, 권한 설정 추가 설정

internal 서버를 구축하면서 인프라를 구축할 때 보안을 보다 잘 신경쓰려면 어떻게 해야 할까? 고민했습니다. 이 때 WAF, IAM, GuardDuty 서비스를 보다 잘 활용할 필요가 있겠다고 생각했습니다. 각각의 서비스를 먼저 소개드리고, 어떻게 이 서비스를 활용했는지 함께 설명드리겠습니다.

WAF

WAF란 Amazon CloudFront 배포, Amazon API Gateway API 또는 Application Load Balancer에 전달되는 HTTP(S) 요청을 모니터링할 수 있게 해주는 웹 애플리케이션 방화벽입니다.

AWS WAF을 사용하여 콘텐츠에 대한 액세스를 제어할 수 있습니다. 요청이 허용되는 IP 주소나 쿼리 문자열의 값으로부터 지정하는 조건 등 지정하는 조건에 따라, Amazon CloudFront 배포, Amazon API Gateway API 또는 Application Load Balancer는 요청된 콘텐츠나 HTTP 403 상태 코드(금지됨)로 요청에 응답합니다. 또한 요청이 차단될 때 사용자 지정 오류 페이지를 반환하도록 CloudFront를 구성할 수 있습니다.

WAF를 사용하면 위에 있는 여러 공격 패턴을 자동으로 방어할 수 있습니다. WAF 서비스를 적용함으로써, 육아크루 서버 내에서도 위에 나와있는 공격이 CloudFront 서버로 들어올 경우, 공격을 막을 수 있도록 방화벽을 구성할 수 있었습니다.

GuardDuty

추가적으로 AWS GuardDuty 서비스를 활용하여 AWS 자원에 보안 위협을 주는 공격이 들어올 경우 곧바로 모니터링 할 수 있도록 환경을 구성했습니다.

만약 AWS에 보안적으로 위험하거나, 공격이 들어올 경우 Slack으로 바로 모니터링할 수 있도록 처리했습니다.

IAM

IAM이란 Identity and Access Management의 약자로, AWS 리소스에 대한 엑세스를 안전하게 제어할 수 있는 웹 서비스입니다. IAM을 사용하면 사용자가 엑세스할 수 있는 AWS 리소스를 제어하는 권한을 중앙에서 관리할 수 있습니다.

IAM 서비스를 분석하면서, 사용자별로 AWS 권한이 너무나도 많이 설정된 문제를 발견했습니다. 만약 사용자 별로 AWS credentials이 외부에 유출될 경우, 크나큰 보안 위협으로 다가올 수 있었습니다.

문제 해결을 위해 사내 구성원 중, AWS 자원에 접근해야 하는 팀원이 있다면 사용자를 별도로 발급하고, 사용자별로 정말 필요한 권한만 제공할 수 있도록 사용자의 권한을 대폭 줄였습니다. 그리고 어떤 사용자가 AWS 자원을 어떻게 접근했는지 효율적으로 트래킹할 수 있도록 AWS 리소스 접근 시, CloudTrail을 활용해서 감사 시스템을 구축했습니다. 이를 통해 육아크루의 AWS 자원을 효율적으로 관리할 수 있게끔 설정했습니다.

AWS 인프라 담당자인 팀원의 경우 AWS에 효율적으로 접근하기 위해 다른 팀원들보다 더 많은 권한이 부여되어 있는데요. 인프라 담당자의 AWS IAM 자원이 외부에 공개되어 버린다면, 육아크루 인프라 관리에 큰 위협이 될 수 있었습니다. 그래서 어드민 계정을 사용하는 유저는 aws-vault라는 서비스를 사용해서 AWS 인프라에 접근할 때 마다 2차 인증을 거치도록 환경을 구성했습니다.

aws-vault를 활용하여, AWS 자원을 이용할 떄 마다 비밀번호를 한 번 더 입력하도록 구성했고, 비밀번호를 입력했을 때 특정 시간만큼만 AWS 자원을 활용하도록 구성했습니다. 만약 인프라 담당자 계정을 활용하는 팀원의 노트북이 해킹당했을 경우, 보안 위협 사고를 한 번 더 막을 수 있다는 점에서 큰 의의가 있었습니다.

마무리

시니어 개발자 없이도, 스스로 성장해야만 조직이 겪고 있는 문제들을 해결할 수 있다고 생각합니다. 내가 성장하지 못한다면, 어쩌면 팀이 겪는 문제를 해결할 수 없을지 모릅니다. 그렇기 때문에 팀의 발전을 위해서는 반드시 성장해야만 했습니다. 팀의 많은 문제를 해결할 수 있도록 영감을 주신, 동욱님에게 감사드린다고 말씀드리고 싶습니다.

육아크루를 함께 만들어 갈 개발자를 모십니다!!

육아크루를 함께 만들어갈 Flutter 개발자를 모시고 있습니다. 위 글을 보고, 저희 팀을 조금 더 자세히 알고 싶으시다면, 함께 하고 싶으시다면 채용 공고를 확인해주세요!!

참고 링크