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

들어가며

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 개발자를 모시고 있습니다. 위 글을 보고, 저희 팀을 조금 더 자세히 알고 싶으시다면, 함께 하고 싶으시다면 채용 공고를 확인해주세요!!

참고 링크

누군가의 삶을 섬세하게 조직할 수 있다면

왜 일하시나요?

개발자님들, 가끔 코드를 뚱땅뚱땅 치다가 문득 왜 나는 코드를 작성하고 있지, 왜 개발자가 됐을까 생각하신 적 있으신가요? 문제 해결을 위해 미친 듯이 달리며 코드를 적다가, 문득 왜 나는 코드를 작성하고 있지, 왜 개발자가 되려 했을까 생각했습니다. 어쩌면 일을 함에 있어 방향성을 잃은 것은 아닐까 생각이 들기도 했습니다.

말하는 건축가

에잇, 이왕 이렇게 된 거 번아웃이 오기 전에 방황(?) 한 번 해봐야지 결심하고 예전에 즐겨 보던 영화 한 편을 봤는데요. 영화 ‘말하는 건축가’를 보며, 문득 잊고 지냈던 정기용 건축가를 떠올릴 수 있었습니다.

정기용 건축가의 삶을 통해, 앞으로 어떤 마음가짐을 갖고 일을 해야 할까에 대해 생각을 정리할 수 있었습니다. 제가 얻은 인사이트를 공유한다면, 어쩌면 일의 의미를 잊은 채 일을 하고 있는 당신에게 도움이 될 수 있지 않을까 싶었습니다.

그럼 지금부터, 정기용 건축가의 삶을 알려드릴게요!

삶을 조직할 수 있는 사람

건축가 정기용은, 아이들이 문화적 혜택을 누릴 수 있는 청소년 문화의 집부터 죽은 이들이 머무는 납골당까지, 전북 무주의 주민들을 위한 건축물을 설계했습니다. 그는 건축물을 누가 사용하는지를 고민하며, 건축물을 사용하는 사람의 삶을 섬세하게 조직하기 위해 노력한 사람이었습니다. 정기용 건축가의 건축물을 바라볼 때면, 참 인간적이다라는 생각이 들었는데요. 많은 건축물들 중 인상적이었던 건축물을 소개하려 합니다.

출처: ebs '건축탐구 집'

사회복지학을 전공하며, 봉사활동을 하기 위해 많은 요양원을 가곤 했었는데요. 요양원에 갈 때마다 좀 답답하다는 느낌이 들곤 했습니다. 정기용 건축가가 지은 요양원을 보고 난 후로는, 노인요양원의 건축이 제대로 설계되지 않아서 답답하다고 느낀 게 아니었을까 생각했습니다.

출처: ebs '건축탐구 집'

건축가 정기용은 요양원을 건축할 때도 사용하는 사람의 입장을 생각했습니다. 정기용 건축가는 요양원 설계 당시 내 집처럼 느껴질 수 있게끔 설계하고 싶었다고 합니다. 건물의 첫인상에는 기와를 얹었는데, 어르신들에게 익숙한 기와집으로 보이게끔 했습니다. 지붕 아래는 벽돌을 쌓아서 집을 닮은 외관을 완성했습니다. 병원 같은 대부분의 요양원과는 다르게 건축이 이루어졌습니다.

출처: ebs '건축탐구 집'

요양원의 내부는 높은 층고로 설계했습니다. 높은 천장을 만들고, 앞뒤로 다 트이게 만들어서 시선이 막힌 데가 없게 만들려고 노력했다 합니다. 요양원에 계신 어르신들은 거동이 불편해 주로 실내에 머물게 되실 텐데, 많은 사람이 실내에 모이면 답답한 느낌이 드는데 환한 분위기에서 활동하시면 좋겠다고 이런 공간을 설계했다고 합니다. 여유 있는 공용 공간 덕분에 보행 보조기를 끌거나 휠체어를 끌어도 실내 산책이 가능하게 설계했다고 합니다.

출처: ebs '건축탐구 집'

마치 집의 거실처럼, 공용 공간을 사용하고 바로 자기 방으로 들어갈 수 있도록 설계했습니다. 실제로는 자연채광임에도 전깃불을 켜놓은 것처럼 실내가 밝게 느껴지는 효과가 느껴집니다. 건축가 정기용은 요양원에 거주하는 것이 병실에서 머무는 것이 아닌 집에서 머무는 것처럼 느낄 수 있도록 노력했습니다. 복도를 밝은 거실처럼 느끼고, 천장을 통해 하늘을 보며 쉴 수 있도록 공간을 만들었습니다. 

출처: ebs '건축탐구 집'

어르신들은 가장 많은 시간을 각자의 방에서 지내게 됩니다. 그걸 알고 있었던 정기용 건축가는, 가장 많은 시간을 보내는 방에 종일 환한 빛이 스며들게 했다고 합니다. 자신만의 창이 하나씩 있는 것처럼 설계하여, 작은 창에서 들어오는 빛으로 전체 공간이 다 밝게 느껴지도록 설계했습니다. 

출처: ebs '건축탐구 집'

건축가 정기용의 건축에는 창문 하나에도 디테일이 숨어있었습니다. 작은 창문을 설계하는 데 있어서도 왜 창문이 필요하며, 창문이 있었을 때 어떤 것을 얻을 수 있는지를 무수히 고민한 사람이었다고 생각합니다. 작은 디테일을 모두 신경 쓰기 위해서는 보이지 않는 곳에서 많은 고민을 해야 했을 텐데, 건축가 정기용 선생은 주민들의 삶을 섬세하게 조직하기 위해 어떤 고민들을 해왔을지, 살아계셨다면 꼭 물어보고 싶다고 생각했습니다.

출처: ebs '건축탐구 집'

건축가 정기용은, 잠시 머무는 버스정류장도 삶이 머무는 공간이라고 생각했습니다. 그래서 창이 있고 벽이 있고, 지붕이 있는 집이 탄생됐습니다. 단순히 버스정류장이 차만 기다리는 곳이 아니라 여기 나와서 잠깐 쉬기도 하고 항상 우리 동네에 있는 내 집 같은 느낌의 장소가 되길 바랐습니다. 그는 버스를 기다리는 시간 동안이라도 농촌 어르신들에게 잠시라도 쉴 수 있는 작은 집을 선물했습니다. 

출처: ebs '건축탐구 집'

쇠락해 가는 농촌에 남은 주민들의 삶을 보살피는 일이 공공건축의 역할이라고 믿었던 그는 곳곳에 집이라는 이름을 붙였습니다. 집을 닮은 요양원도 그렇게 탄생했습니다. 공간을 만들더라도, 그 안에 사는 사람들이 어떤 느낌으로 살 것이냐가 굉장히 중요합니다. 그런데 저부터도 언제부터인가, 크고 넓으면서도 고급스러운 공간이 좋은 공간이라는 생각이 들곤 했습니다. 하지만 작은 공간에서 살아가더라도, 같이 살아가는 사람과 행복할 수 있다면, 함께 살아간다는 가치를 느낄 수 있다면. 그런 공간이야 말로 좋은 공간이라고 말할 수 있지 않을까 생각했습니다. 어쩌면 행복은 아파트의 브랜드 혹은 평수에 비례하는 것이 아닌, 누구와 어떻게 살아가는가에 따라 달라지는 것이 아닐까 생각했습니다.

출처: ebs '건축탐구 집'

건축은 근사한 형태의 집을 짓는 것이 아니라 사람들의 삶을 섬세하게 조직하는 일이라고 믿었던 건축가 정기용. 그는 책을 사볼 수 없는 아이들을 위한 도서관, 소외된 농촌지역의 주민을 위한 시설 등 공공 건축에 평생을 바쳤습니다. 무주 프로젝트 또한 그중 하나였습니다. 정작 자신은 소박한 월세방에 살며, 대장암과 싸우던 중, 일찍 우리 곁을 떠났습니다. 그는 비록 떠났지만, 그가 남긴 의미 있는 공간은 여전히 사람의 삶을 섬세하게 바꾸고 있습니다. 그의 삶을 반추하며, 그럼, 나는 개발자로서 누군가의 삶을 섬세하게 조직해 본 적이 있는가 되묻게 됩니다.

영화 '말하는 건축가'의 엔딩 크레딧을 보면서, 그의 언어는 기획자, 개발자에게도 훌륭한 인사이트를 줄 수 있다고 생각했습니다. 

기획자로서, 내가 한 일은 원래 거기 있었던 사람들의 요구를 기획으로 번역한 것이다.
개발자로서, 내가 한 일은 원래 거기 있었던 사람들의 요구를 개발로 번역한 것이다.

언젠가 아무런 목적의식 없이 일을 하게 될 때 정기용 건축가의 삶을 다시금 생각할 수 있는 사람이 되고 싶습니다. 그리고 나도 누군가의 삶을 섬세하게 조직할 수 있는 삶을 살고 싶다고 생각했습니다. 정기용 건축가의 삶을 통해, 앞으로 어떤 마음가짐을 갖고 일을 해야 할까에 대한 나름의 답을 얻을 수 있었습니다.

일의 의미를 잊은 채 일을 하고 있는 당신에게 환기가 되었으면 하는 바람으로, 작은 위로가 되었으면 하는 바람으로 글을 마칩니다.

혹여나 이 글을 쓴 글쓴이는 누구인지 궁금해하실 분들을 위해, 제 소개를 간단히 드리겠습니다.

엄마들의 삶을 섬세하게 조직하기 위해

현재 저는 엄마들의 삶을 섬세하게 조직하고 싶어 다이노즈 팀에 합류하여 육아크루 서비스를 만들고 있습니다.

저희 육아크루는 아이에게도, 엄마에게도 친구가 필요하다고 생각하여, 외로움을 겪는 엄마들이 동네에서 육아 친구를 찾을 수 있도록 돕는 일을 하고 있습니다.

대한민국 엄마 90.5%가 산후우울감을 경험하고, 33.7%는 육아 스트레스와 우울감으로 인해 자살 충동을 느낍니다. 우리의 유저들은 ‘육아크루’에서 연결된 동네 육아친구 덕분에 일상이 달라지고, 우울감이 60~70% 감소된다고 말합니다.

저희 다이노즈 팀에서는 여러 문제를 해결하고 있는데요. 앞으로 다이노즈 팀에서 어떤 문제를 어떻게 해결하고 있는지 조금씩 소개하겠습니다.

긴 글 읽어주셔서 감사합니다.

참고