우리 동네 고양이 - part 2

November 25, 2021

“내 이럴 줄 알았어…”

미키는 집에서 야근 중이다. 재택 근무의 장점은 작업의 흐름을 끊지 않고 쭉 이어서 밤까지 달릴 수 있다는 점이다. ~~(장점 맞지?)~~ 물론 거기에 식구들의 원성과 미안한 마음을 보너스로 곁들인… 그래도 오늘은 이것까지는 해야만 할 것 같다. 프론트엔드와 백엔드를 연결해서, 서버로부터 받아온 데이터를 가지고 화면에 보여주도록 할 단계이다. 서버가 보내줄 데이터도 아직은 샘플 이미지에 불과하지만, 그래도 이만큼은 해놔야 고맙게도 백엔드 작업을 척하니 해결해준 W에 대한 응답이 될 수 있을 것이었다.

무식하면 용감하다고, 백엔드를 잘 몰랐던 미키는 그냥 뭐, 해야 하면 어떻게든 대충 만들면 되겠지 하는 생각이었다. 그런데 W가 작업해준 DynamoDB와 Lambda 내용을 보니 그게 아니었다는 생각이 들었다. 분량이 많은 것은 아니었지만, 미키 혼자 맨땅에 헤딩하면서 했으면 많이 고생했을 것 같았다. 딱 적절한 타이밍에 DB 기초 설계와 API 처리 코드가 준비되어서 다행이었다. 자, 이제 내 차례군, 나만 잘 하면 돼. 미키는 생각했다. 그러니 연동만 잘 하면 되는데, 그래 이런 게 한번에 될 리가 없지. 미키는 그럴 줄 알았다는 듯 고개를 좌우로 흔들었다.

AWS에 대해서 모를 때는, 그저 물리적인 서버를 가상으로 만들어주는 서비스 정도로만 생각했다. 하지만 알고 보니 그건 단지 전체 AWS 서비스의 일부분일 뿐이었고(EC2 라는 이름이었다), AWS 안에는 정말 수백 가지의 서비스가 다양한 요구사항에 맞도록 만들어져 있었다. 그리고 그 서비스들은 또 수많은 옵션과 설정값에 따라 동작 방식을 다르게 만들 수 있어서, 잘 모르고 들어갔다가는 너무 많은 선택지들 사이에서 길을 잃게 되기 십상이었다. 미키가 바로 지금 그렇게 허우적거리고 있는 중이었다.

“왜 대답이 없니, 왜. 콜을 했으면 대답을 해야 할 것 아니니…”

AWS Amplify 서비스를 이용해서 전반적인 구성을 하였고, DynamoDB와 Lambda, 그리고 그 앞의 API Gateway가 백엔드의 주요 축이었다. 프론트엔드 쪽에서 고양이 목록 정보를 요청하면 API Gateway가 요청을 받고 serverless Lambda 함수가 실행되어 DynamoDB에 저장된 정보를 훑어서 사진의 URL 등을 모아서 보내주는 식이었다. 고양이 사진들은 S3 버킷에 미리 몇 장 올려둔 상태였다. 그런데 프론트엔드의 POST 메시지에 제대로 응답이 돌아오지 않는 게 문제였다.

사실 이런 건 잘 되어야 하는 일이었다. 오리는 꽥꽥. 돼지는 꿀꿀. 요청에는… 무응답? 잘 될 때는 쉽고 자연스럽고 당연한 것이지만, 안 될 때는 또 그만큼 답답하다. 제대로 된 응답이 만들어지기까지의 여러 과정 중에서 하나만 삐끗해도 실패하는 것이기에 여기저기 다 찔러봐야 하고, 때로는 어디 가서 물어보기에도 좀 창피한 경우도 있고 그렇다.

결국 미키는 그 밤을 활활… 까지는 아니지만 살짝 불살라야만 했다. CloudWatch 들어가서 로그도 살펴보고, Lambda 서비스 안에 있는 테스트도 돌려보고, API Gateway 쪽에 있는 테스트도 점검해보면서. 결국 API Gateway의 Lambda Proxy 설정을 조정하고, Lambda 함수에서 생성하는 응답을 json 형식으로 묶어주고, 숫자 형식으로 다루던 위도/경도 값을 문자열 형식으로 전달해주도록 바꾸는 등의 작업을 한 다음에야 비로소 원하는 결과를 볼 수 있었다. 이제 드디어, 참새는 짹짹. 요청에는 응답.

미키는 그 다음에도 몇 개의 징검다리를 더 건너야 했다. K가 작업해준 Cognito를 통한 사용자 sign up/sign in 프로세스를 붙이는 일도 했다. 회원 가입과 로그인 처리하는 걸 직접 만들려면 상당히 품이 많이 드는 일일 텐데, Cognito 이용하니 비교적 쉽게 그런 걸 할 수 있었다. 그래, 이런 서비스를 다 갖추어놓았으니 AWS가 돈을 버는 것이겠지.

고양이 사진에 들어있는 위치 정보를 뽑아내는 일도 필요했다. 그 일을 해주는 파이썬 라이브러리를 어렵지 않게 찾을 수 있었는데, 문제는 그걸 Lambda 함수에서 실행하는 문제였다. 뒷골목 돌 때마다 마주치게 되는 dependency 문제.

파이썬을 잘 모르는 미키였지만 - 어릴 때 본 책에 나온 ‘왕뱀 퓌톤’ 이란 명칭을 떠올리며 싱겁게 웃기나 하는 정도였다 - 어쨌든 필요한 라이브러리들을 끼워넣어야 했다. 뭐가 없네, 또 뭐가 없네, 하는 에러 메시지들마다 적당히 끼워 맞춰서 의존성 문제를 해결하는 중이었는데, PIL이라는 라이브러리가 문제였다.

이미지 처리를 위해서 쓰는 라이브러리인가본데, 요즘은 그걸 fork한 pillow 라는 걸 쓰는 모양이었다. 근데 그걸 pipenv install 해서는 설치가 잘 안 되고 뭔가 다른 방법으로 해야 하는 것 같았는데, 구글링해보니 어떤 용자가 Lambda Layer 들을 미리 만들어서 그 ARN(Amazon Resource Name)을 공개해놓은 것이 있었다. 그러니까 내가 원하는 라이브러리를 갖고 있는 Lambda Layer를 내 Lambda 함수 아랫단에 끼워넣으면 의존성이 해결되는 것이었다. 여러 개의 Lambda 함수에서 공통으로 사용할 코드를 Layer로 만들면 된다고 배웠는데, 이런 식으로도 사용할 수 있는 것이었군. 어쨌든 방법을 찾아서 다행이다, 미키는 한숨 돌리며 생각했다.

그런데 꼭 이렇게밖에 할 수 없는 걸까? AWS에서 파이썬 쓰는 게 썩 부드럽지는 않군. 미키는 엊그제 개발환경으로 Cloud9을 써볼까 싶어서 한번 시도해봤었는데, 거기서도 파이썬 버전 문제 때문에 그만둔 적이 있었기 때문이다. Lambda 함수에서 생성할 때 기본 지정되는 파이썬 런타임의 버전은 3.8인데, Cloud9에서 t3 AMI(Amazon Machine Image) 지정해서 인스턴스를 생성하면 파이썬 3.7이 들어 있다. 버전을 올려서 사용하고 싶으면 수동 설치하면 되긴 된다는데, 그러려면 먼저 인스턴스의 디스크 용량을 확장해야 한단다. 으… 미키는 거기까지 해보다가 귀찮아서 포기했다.

사실 Cloud9을 쓰게 되면 브라우저 상에서 코딩을 하게 될 텐데, 데스크탑 VS Code의 친숙함에 익숙해진 상태에서 브라우저 환경을 잘 쓰게 될지도 미지수인 상황이었다. 게다가 파이썬 버전을 맞추기 위해 이런 귀찮은 일까지 해야 한다면, 그다지 매력은 없었다. 어떤 서비스를 쓰든 동일한 버전을 사용할 수 있도록 AWS 쪽에서 일괄적으로 관리를 해주어야 불편함 없이 쓸 수 있을 것이었다. 하지만, 개발 언어로서 ‘왕뱀 퓌톤’은 나름 매력적인 간결함을 가지고 있는 것 같았다. 다음에 또 기회가 되면 좀 더 배워서 써봐야겠다고 미키는 생각했다.

자, 이제 보니 그래도 어느 정도 와꾸(?)는 잡혀가는 것 같았다. 그런데, 계속 이런 식으로 작업해도 되는 걸까? 뭔가 중요한 걸 빠뜨리고 있다는 생각이 미키의 뒤통수를 치고 지나갔다. 이걸 지금 나 혼자 하고 있는 게 아니잖아. 셋이 같이 만들고 있는 건데, 누가 열심히 꾸며놓은 인프라 설정을 다른 사람이 새 작업을 하다가 바꿀 수도 있는 거잖아. 그러다가 누가 또 다시 갑자기 원래대로 돌려놓을 수도 있는 거고. 사실 그건 미키 혼자 작업을 한다 해도 마찬가지였다. 현재의 안정된 세팅 상태를 유지하면서, 동시에 새로운 개발 작업을 하려면 어떻게 해야 하지?

말하자면 백엔드의 개발 프로세스를 어느 정도는 제대로 갖춰놓아야 할 필요가 있었다. 실습 시간에 예제 코드 copy & paste 하면서 인프라 꾸미는 것과는 다른 방식이 필요했다. 하루 이틀 만들어보고 날려버릴 연습문제 푸는 게 아니잖아, 미키는 중얼거렸다. 질문 메일을 써야겠군. 다음 번 Office Hour 때 AWS SA 분들이 와서 답을 해줄 수 있도록 메일을 작성했다.

“저기요, 백엔드 인프라 설정을 git 소스 코드에 같이 저장해서 관리하려면 어떻게 해야 하나요? 얼핏 보니 CodeStar 라는 서비스도 있던데 그런 걸 이용하면 할 수 있는 건가요?”

물론 미키가 실제로 저렇게 쓴 건 아니었다. 어쨌든 중요한 포인트를 한발 뒤늦게 짚은 것 같았다. 주어진 프로젝트 기한은 이제 중반을 넘어가고 있었다.

(이어지는 글: 우리 동네 고양이 - part 3)

Links