[회고] 2023년 하반기 - 미련한 사람이 우물을 판다

 

들어가며

언제나 다정하게 가족 옆을 지킨, 환갑이 된 당신을 생각합니다. 

 

당신은 돈을 벌기 위해 왕복 5시간 거리를 출퇴근했습니다. 하루 종일 서서 일하며 백화점 매대에서 소리 내어 이목을 끌어야 했고, 매대에 물품이 빠질 때면, 창고에서 물품을 꺼내와 채워 넣어야 했습니다.퇴근하고서는 밀린 집안일들을 해야 했고, 잠들기 전에는 파스를 이곳저곳 붙이며, 다음 날 아무 일 없다는 듯 새벽같이 출근했습니다. 출근 전 당신은 늘 빼놓지 않고, 혼자 있어도 라면 끓여 먹지 말고 밥 잘 챙겨 먹고 있으라고 밝게 웃으며 인사했습니다.

 

자식이 밥을 굶을까 걱정된 탓인지 당신은 언제나 식탁 위에 반찬들을 올려두고 출근했습니다. 음식이 놓인 식탁 위에는 시간이 갈수록, 반찬 대신 당신이 복용해야 할 약이 늘어만 갑니다. 약만 먹어도 배부를 것만 같은 수북이 쌓이는 약을 볼 때면, 어떤 성실함은 슬픔으로 다가온다는 말의 의미를 다시금 생각하게 됩니다.

 

환한 미소를 지으며 언제나 제 옆을 지킨 당신을 생각하며, 이제는 당신처럼 누군가의 옆을 지킬 수 있는 사람이 되었는지 정리하기 위해 2023년 하반기를 돌아봅니다. 이번 하반기는 성장을 위해 어떤 도전을 했으며, 그 과정에서 어떤 어려움을 극복할 수 있었는지 지난 삶을 돌아보기 위해 글을 적습니다. 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

마른땅에 우물을 파는 일

시간이 갈수록, 팀이 해결해야 할 문제가 많아져만 갑니다. 문제가 많아질수록, 팀 앞에 놓인 문제를 하나씩 해결함으로써 팀을 지킬 수 있는 사람이 되고 싶었습니다. 문제를 해결하면, 다른 문제가 앞에 놓이기에 어쩌면 문제 해결 과정은 밑도 끝도 보이지 않을 때도 있습니다. 그리고 앞에 놓인 모든 문제를 해결했을 때 팀을 지킬 수 있는지도 아직은 알 수 없습니다. 그렇지만 마치 마른땅에 우물을 파는 것처럼, 물이 언제 나올지 알 수는 없지만, 언젠간 물이 나온다는 믿음을 갖고 때로는 미련하게 팀 앞에 있는 문제들을 하나둘씩 해결해 갔습니다. 

 

육아크루의 팀원으로서 어떤 문제를 해결해 갔으며, 이 과정에서 어떤 성장을 할 수 있었는지를 정리해 봤습니다.

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

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

먼저 육아크루의 개발자로서 어떤 문제를 해결했는지 정리해보고 싶습니다.

 

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

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

 

 

1. 결제 PG 연결

시스템을 완벽하게 구축한 상태로 서비스를 운영하면 더할 나위 없이 좋겠지만, 비즈니스를 만들어 가기 위해서는 완벽함보다는 완벽하지 않아도 빠르게 개발하는 것이 중요할 때가 있습니다. 팀 내에서는 육아크루의 '원데이크루' 서비스를 론칭할 때, 이 고민을 동일하게 했습니다. 주어진 시간 동안, 개발팀의 리소스를 최대한 효율적으로 활용하기 위해, 당시 서비스 결제는 모두 무통장 입금만 가능하도록 설계했습니다. 

 

그러다, 원데이크루에 참여하는 유저가 많아지면서, 무통장 입금 결제 방식의 한계를 경험했습니다. 고객 입장에서는 입금 정보를 확인하고, 직접 금액을 송금해야 했는데 이 불편함 때문이었는지 결제를 완료하지 않고 이탈하는 유저가 많아졌습니다. 결제 이탈을 줄이기 위해, 운영팀에서는 무통장 결제를 신청한 유저들에게 입금을 부탁드린다고 안내해야 했는데요. 그 과정에서 운영 리소스가 늘어나고 있었습니다. 문제 해결을 위해 결제 과정을 간단히 진행할 수 있도록 결제 시스템을 구축해야 했습니다.

 

출처: 결제 요청, 인증, 승인... 이게 다 뭔가요? <토스페이먼츠>

 

 

문제 해결을 위해 육아크루 앱에 토스페이먼츠를 연결하여 결제 시스템을 구축했습니다. 토스페이먼츠는 결제 요청과 승인 과정을 따로 두어 데이터 정합성을 보장한다는 측면에서 다른 PG사보다 큰 장점이 있었고, 공식 문서도 잘 갖추어져 있었습니다. 토스페이먼츠 도입을 위해 주문, 결제 과정을 어떻게 구현할 것인지, 결제 정보를 어떻게 검증할 것인지 분석하여 팀 내에 적용했습니다. 기능 개발을 통해 고객의 결제 이탈률을 17% 줄일 수 있었습니다. 

 

결제 과정에서 결제가 실패했을 경우 트랜잭션을 어떻게 처리할 것이며, 결제가 실패할 경우 모니터링을 어떻게 할 것인지, 만약 유저가 결제를 취소할 경우 환불 처리는 어떻게 처리해야 할지 등과 같은 개발에 관한 자세한 내용은 추후에 글로 정리해 보려 합니다.

 

만약 서비스가 발전함에 따라 결제 트래픽이 미친 듯이 증가하여, 결제 서버와 데이터베이스를 여러 개 사용해야 하는 경우, 다중 트랜잭션을 어떻게 제어할 수 있을지 의문이 들곤 합니다. 이 문제를 해결하려면 어떻게 해야 할지는 다음 숙제로 남겨두려 합니다.

 

 

 

 

2. 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 명령어 한 번만 입력하면, 원하는 서버를 곧바로 증설할 수 있었습니다. 이를 통해 인프라 관리에 필요한 시간이 확 줄어들게 되었고, 인프라가 어떻게 구성되어 있는지 코드로 확인할 수 있기 때문에 히스토리를 파악하는데도 훨씬 효율적인 환경을 구축할 수 있었습니다.

 

 

 

 

 

3. CloudFront 도입

 

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

 

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

 

 

 

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

 

 

더 이상 미룰 수 없다. CDN 도입.

 

 

 

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

 

 

출처: 인프런 아키텍처 2023 ~ 2024

 

 

 

 

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

 

 

 

 

그래서 CloudFront를 보다 잘 활용하기 위해 위 링크를 여러 번 돌려보며 공부했고, 그 결과 CloudFront를 육아크루 서비스에 도입할 수 있었습니다.

 

 

 

 

 

 

 

4. 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로 변경하는 작업을 하고, 이렇게 작업했을 때 얼마나 성능이 개선됐는지 확인해보려 합니다.

 

 

5. Private ALB 도입

문제 상황

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

 

 

출처: 인프런 아키텍처 2023 ~ 2024

 

 

 

 

동욱 님과의 대화를 통해 인프런에서는 서버 내부에서 사용하는 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의 성능을 개선시킬 수 있었고, 이는 곧 사용성 개선으로 이어졌습니다.

 

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

 

 

 

 

6. 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 자원을 활용하도록 구성했습니다. 만약 인프라 담당자 계정을 활용하는 팀원의 노트북이 해킹당했을 경우, 보안 위협 사고를 한 번 더 막을 수 있다는 점에서 큰 의의가 있었습니다.

 

 

 

 

 

7. 채용 공고 개선

동욱 님에게 개발뿐 아니라, 좋은 팀원을 모셔오기 위해서는 채용 과정을 어떻게 개선시켜야 할까 질문했습니다. 동욱 님께서는 채용공고를 잘 작성할 것을 강조하셨는데요. 팀에 합류하면, 어떻게 일하게 될지 예측 가능하게 구성해야 한다고 말씀 주셨고, 우리 팀은 어떤 팀인지를 공고에 명확하게 표현해야 한다고 말씀 주셨습니다.

 

 

 

 

 

 

 

저희 팀에서는 현재 소중한 팀원을 모시기 위해 노력하고 있는데요. 기존에 작성된 채용 공고를 살펴봤을 때, 우리 팀에 합류하면 어떻게 일할 수 있을지, 우리 팀은 어떤 팀인지 예측되지 않을 것 같다고 생각했습니다. 그래서 채용 공고를 개선하는 작업을 진행했습니다.

 

 

 

 

 

 

 

 

 

채용 공고를 위와 같이 개선했습니다. 우리 팀은 어떤 팀이며, 우리 팀에서는 어떻게 일하는지, 어떤 협업 문화를 갖고 있는지 정리했습니다. 현재 다이노즈 팀에서 함께하는 팀원들은 어떻게 성장하고 있는지를 정리했고, 마지막으로 우리 팀은 문제 해결을 위해 어떤 마음가짐을 갖고 있는지를 정리했습니다. 이렇게 정리함으로써 우리 팀에 합류하면 어떻게 일할 수 있을지, 우리 팀은 어떤 팀인지를 채용 공고에 보다 잘 표현할 수 있었습니다.

 

 

[채용중] 플러터 개발자 (경력 1년 이상) | Built with Notion

 

 

채용 공고를 살펴봐 주시면서, 저와 함께, 저희 팀과 함께 불확실함을 확실함으로 바꾸는 경험을 하고 싶은 분들이 계시다면 간단한 커피챗도 가능하니 위 링크에 작성된 메일 주소로 연락 부탁드립니다! 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

안개 바다 위의 방랑자

육아크루 팀에 합류한 지 1년이 지났습니다. 1년 동안 크고 작은 문제를 해결해 가며 성장할 수 있었지만, 문제 해결 과정에서 때로는 두려운 감정이 들기도 했습니다. 

 

작은 조직에 있을수록, 스스로 성장해야만 조직이 겪고 있는 문제를 해결할 수 있다고 생각합니다. 팀에는 시니어 개발자가 존재하지 않기 때문에 누군가 팀의 문제를 대신 해결해 주겠지라는 기대를 할 수 없었습니다. 때로는 만약 내가 성장하지 못한다면, 서버 장애에 대응할 수 없을 수 있게 되고, 서버 장애가 멈추지 않음에 따라 유저가 이탈해 버릴 수 있다는 두려운 마음이 들기도 했습니다. 이런 불확실성, 두려움을 느꼈을 때 한 작가의 작품 하나를 보곤 했습니다.

 

 

 

 

카스파 다비드 프리드리히, <안개 바다 위의 방랑자>

 

 

 

 

개인적으로 카스파 다비드 프리드리히의 ‘안개 바다 위의 방랑자’라는 작품을 좋아합니다. 전경에 서 있는 여행자는 끝이 보이지 않는 안개로 가득 찬 산과 바다를 온몸으로 마주합니다. 우린 얼굴이 보이지 않는 여행자의 뒷모습을 바라볼 뿐이지만, 여행자의 뒷모습에서 불확실함이 가득한 안개 바다를 향해 나아갈 준비를 하기 위한 결의를 다지는 모습이 보이기도 합니다. 

 

 

 

 

 

 

 

 

엄마들을 위한 No.1 육아맘 커뮤니티 서비스를 만들려면, 안개 바다 위의 방랑자와 같이 어쩌면 무궁무진한 불확실성을 온몸으로 마주해야 할 것입니다. 만약 불확실함과 두려움을 마주할 때가 온다면, 앞으로도 온몸으로 불확실함과 두려움을 상대하려 합니다. 다행스럽게도 팀 앞에 놓여있는 문제들을 해결하기 위해, 팀원들이 함께 움직이고 있습니다. 

 

만약 힘들고 포기하고 싶을 때가 온다면 지금도 나와 같이 불확실함을 확실함으로 바꾸기 위해 노력하고 있는 팀원들을 생각하려 합니다. 혼자가 아니라는 믿음으로, 주저앉지 않고 앞으로 나아갈 수만 있다면 반드시 내 앞에 놓인 문제들을 해결할 수 있는 능력을 갖추게 될 거라 믿습니다.

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

출처: 유퀴즈

마치며

육아크루 팀에서 1년 넘게 일하며, 저는 누군가에게 도움이 되는 일을 할 때 업무의 퍼포먼스가 월등히 높아진다는 것을 깨달았습니다. 2024년에는 팀에 도움이 되기 위해 치열하게 노력한 결과, 사랑하는 팀을 지킬 수 있었다고 자신 있게 말할 수 있는 사람이 되고 싶습니다. 누군가 제 삶을 바라봤을 때, 이 사람은 문제 해결에 진심인 사람이구나 알 수 있도록 '삶으로 말하는 사람'이 되고 싶습니다.

 

 

 

 

 

이 글을 통해, 문제를 해결하는 과정에서 두려움을 용기로 바꿀 수 있도록, 팀의 문제를 해결할 수 있도록 영감을 주신 동욱 님에게 감사드린다고 말씀드리고 싶습니다. 그리고 저보다 더 저를 믿어주시고, 응원해 주시는 팀원분들에게도 감사드린다고 전하고 싶습니다. 언제나 다정하게 제 옆을 지키고 있는 당신처럼, 치열하게 성장하여 팀을 지킬 수 있는 사람이 될 수 있도록 2024년에도 마른땅을 미련하게 파보려 합니다.

 

2023년, 올 한 해도 제가 누군가에게 도움이 될 수 있었길 바라며. 2024년 상반기에는 안 되는 이유보다 될 수 있는 방법을 찾는 사람이 되겠다는 다짐을 하며 이번 하반기 회고 글을 마무리하겠습니다. 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

참고 링크

이미 늦은 것 같아 시작을 망설이고 있나요? 😣

CloudFront OAI(origin access identity)를 통해 S3 버킷 콘텐츠에 대한 액세스 | DevelopersIO

aws-vault 사용법: AWS의 인증 정보 안전하게 사용하기

누구나 브랜드가 된다, 셀프 브랜딩 시대 – 제일기획 매거진

형 구하고 세상 떠난 동생, 가슴에 묻고 그렸다 [성수영의 그때 그 사람들]

결제 요청, 인증, 승인… 이게 다 뭔가요?

[그림 해석하기 혹은 추리하기] It's time for adventure!⑤ ‘Caspar David Friedrich’ - 문화매거진