아스

✅ 오늘 배운 것

오늘도 마저 어제 하던 FCM 알람 기능을 적용하려고 한다. 어제 코드로 보았을 때는 백엔드 쪽에서는 알림을 잘 보내고 있는데 프론트엔드 쪽에서 그 알림을 화면에 띄워주는 부분이 되지 않는 것 같아서, 다시 공식문서를 보면서 내가 놓친 부분이 있는지를 보았다.

다시 보니 프론트에서 특히 앱이 foreground 상태일 때는 Notification이 아예 표시되지 않도록 되어 있었다. 그렇다면 알림은 잘 수신되는데 단순히 화면에서 나타나지 않는 게 아닐까 싶어서 onMessage() 메시지 핸들러 안에 로그를 찍어보았다. 그랬더니 로그가 찍히고 있었다. 

즉 메시지는 잘 도착했는데 Notification 타입의 메시지는 앱이 Foreground 상태일 때 표시되지 않는 것이 기본값이므로 표시되고 있지 않았던 거였다. 하지만 나는 앱이 Foreground 상태가 아닐 때 메시지가 표시되었으면 좋겠고 이를 테스트하고 싶었다. 그래서 앱을 잠시 백그라운드 상태로 만들고 다시 알림을 보내보았다. 그랬더니 메시지가 백그라운드에서 수신되었다는 알림 자체는 왔다. 다만 화면에 표시되지 않았다. 이는 Quit 상태일 때도 마찬가지였다. 

아마도 메시지 핸들러가 호출은 잘 되는데 별도로 알림을 띄우라는 코드가 없으니 안 띄우고 메시지 핸들러만 호출되는 것이라고 생각했다. 알림을 띄우는 것과 관련된 다른 라이브러리가 있길래 추가로 이 라이브러리를 사용하면 좋을 것 같았다. 

npm install --save react-native-push-notification

✅ 오늘 배운 것

오늘은 우선 구글 플레이스토어 콘솔에서 배포가 잘 되고 있는지 확인했다. 다행히 아직까지는 오류가 난 것이 없어서, 당장 세 명이 뛰어들 만한 급한 이슈는 없다고 판단했다. 

어제 잘 돌아가는 것을 확인한 서버를 일단 켜 두자. 프론트엔드와 백엔드 서버 모두 켜 두었다. 

일단 디자인은 잠시 미뤄둔 상황이다. 그리고 구글 플레이스토어의 앱 배포도 아직까지는 문제가 없다. 물론 다운로드 수가 20을 넘어야 하지만, 그건 차차 사용자 수를 모으면 되는 상황이므로 현재의 문제는 아니다. 그렇다면 이 상황에서 뭘 우선으로 해야 할까? 일단 앱이 배포된 다음에는, 사용자를 모으는 것이 우선이다. 사용자를 모으려면 우선은 앱이 정상 작동을 해야 하고, 고도화 기능(알람과 하위투두 고도화)이 필요하며, 틈틈이 홍보도 해야한다. 

논의 끝에 팀원 한 명은 앱의 정상 작동을 위해 버그를 고치는 일, 다른 한 명은 하위 투두 고도화를 위해 DB 및 모델을 설계하는 일, 그리고 나는 알람을 맡았다. 계속 미뤄지게 된 알람 이슈를 작업하게 된 것이다. 

사실 이미 작성된 로직이 있었어서, 해당 로직이 잘 작동하는지 확인을 하면 되었다. 문제는 결과값 자체는 잘 보내진다고 나오는데 에뮬레이터 기기에 알림이 오지 않는다는 점이었다. 

원인을 추측해 보자면 해당 토큰값이 에뮬레이터의 FCM 토큰값이 아니거나, 코드에 있는 Messaging 또는 Notification 객체가 제대로 동작하지 않았을 수 있겠다. 

우선 첫 번째 추측의 경우, 프론트에서는 다음과 같은 코드로 기기의 FCM 토큰을 가져오고 있었다. 이는 RN 공식문서에도 나와있는 방법이므로 이게 틀릴 가능성이 꽤 낮았다. (사실 만약 틀렸다고 하면, 깃헙 이슈를 보면서 어떻게 해야 하는지를 또 일일이 찾아봐야 해서 그게 아니길 바란다.)

import messaging from '@react-native-firebase/messaging';
const token = await messaging().getToken();

... 라고 생각했었는데, 알고보니 프론트에서 다른 브랜치로 작업을 하고 있었다. 즉 백엔드에서 맞는 기기로 알림을 보내도 프론트엔드에서 그 메시지를 받아서 표시해주는 로직이 동작해야 화면에 알림이 표시되는데, 그 로직을 작성해놓은 브랜치가 아니었던 것이다. git checkout과 git rebase(앱이 동작하지 않는 문제가 dev 브랜치에서 고쳐진 상태였기 때문에 rebase도 같이 했다)을 하고 다시 시도해 보았다. 여전히 되지 않았다. 

백엔드에서는 로직 중간에 오류가 없는 것으로 보아 프론트엔드의 알림을 받는 부분에 문제가 있을 것이라고 추측했다. 짚이는 부분 하나는 프론트에 현재 알림이 오면 그걸 그대로 화면에 나타내주는 코드가 없다는 거였다. 또한 헷갈렸던 부분은, 메시지를 보내거나 받을 때 디바이스의 FCM 토큰만 알면 별도로 채널 등의 정보를 따로 지정하지 않아도 무사히 해당 FCM 토큰을 가진 디바이스에서 메시지를 받을 수 있는지 의문이 들었다. 

다시 RN firebase 공식문서와 fcm django 공식문서를 보자. 공식문서를 보면서 여러 문제점을 찾았다. 첫 번째는 fcm-django에서 메시지를 보내려면 fcm-django에서 정의한 FCMDevice라는 모델을 사용해야 한다. 정확히는 해당 모델의 send_message 라는 메소드를 통해서 메시지가 보내진다. 그런데 그 부분이 코드에서 빠져 있었다. 아마도 디바이스 토큰 값은 정확했을 텐데 메시지가 제대로 전송되지 않은 것 같았다. 

그러면 이전에 임의로 정의해두었던 Device 모델 대신에 FCMDevice 모델을 사용해야 한다. 이를 위해서 해당 코드가 있는 구글로그인 로직의 일부를 바꿔주었다.

기존의 Device 모델에서 get_or_create 메소드를 통해 device_token(앞서 프론트에서 보내는 device token 값)의 값을 가진 Device 인스턴스가 있으면 이를 불러오고 없으면 만들어 주었다. 이번에도 마찬가지로 FCMDevice에서 get_or_create 메소드를 사용하려고 했는데, 그러려면 device_token 값을 어떤 필드에 저장해야 할지를 알아야 했다. 

fcm_django.models에 관련 모델들이 모두 정의되어 있었다. 우리가 사용하려는 FCMDevice는 AbstractFCMDevice를, AbstractFCMDevice 모델은 Device 모델을 상속받고 있었다. 그래서 이 FCM 토큰 값을 어디다 넣으라는 건가 싶었는데, 공식문서에 친절히 registration_id 필드에 넣으라고 나와있었다.

기존의 Device 모델에서 FCMDevice 모델로, 그리고 일부 필드값만 바꿔주었다. 

FCMDevice.objects.get_or_create(
    user=user, registration_id=device_token
)

그리고 'python manage.py showmigrations' 명령어로 확인해 보니 fcm_django 라이브러리와 관련된 모델 변경 사항이 아직 마이그레이션에 반영되지 않은 상태였다. 이것도 반영해 주었다. 

이렇게 기본 로직을 변경하고, 다시 프론트 에뮬레이터를 켜서 구글로그인을 한 번 실행해 주었다. 그래야 FCMDevice 모델에 해당 에뮬레이터의 토큰 값이 들어가기 때문이다. 그리고 나서 기존의 메시지를 보내는 로직을 다시 바꿔주었다. 

def send_push_notification(token, title, body):
    message = messaging.Message(
        notification=messaging.Notification(
            title=title,
            body=body,
        ),
    )
    device = FCMDevice.objects.filter(registration_id=token).first()
    try:
        device.send_message(message)
    except Exception as e:
        # sentry capture exception
        return PUSH_NOTIFICATION_ERROR
    return PUSH_NOTIFICATION_SUCCESS

이렇게 바꿔 주었고 메시지를 보내는 로직을 실행시키니 success라고 떴다. 그런데 여전히 에뮬레이터에서는 알림이 표시되지 않아서, 이번에는 프론트 쪽에 문제가 있을 가능성을 두고 프론트 코드를 고쳐봐야 할 것 같다. 

✅ 궁금한 점

1. kafka-python 등의 kafka를 python에서 사용하기 위한 라이브러리가 있는 걸로 알고 있다. 문득 우리 서비스에서 kafka-python과 같은 라이브러리가 필요할 일이 있을지 궁금해졌다. 

2. FCMDevice의 send_message 로직은 어떻게 되어 있을까?

✅ 오늘의 러닝 인증

✅ 오늘 배운 것

오늘 오후 2시까지는 팀원들과 논의해서 새 앱 디자인을 정하고, 이후 개인 시간에는 FCM 알림을 붙여보려고 한다. 2시부터 4시까지는 소마 메이커스 특강이 있었고, 원래는 2시에 AI가 추천해줄 하위 투두를 어떻게 보여줄지에 대한 디자인은 정하지 못했었다. 그런데 너무 고맙게도 팀원들이 특강을 듣고 있는 동안 해당 디자인에 대해서 정하고 논의를 해 줘서, 이제 새 앱 디자인은 거의 정해졌다고 봐도 무방하겠다. 

남은 것은 FCM 알림이다. 오늘 '인프런이 성장하면서 변화해온 아키텍처'가 강연 주제였는데, 인프런이 조직 및 비즈니스 상황 변화에 따라 어떤 결정을 했는지도 알 수 있었지만 중요한 인사이트는 '회사의 비즈니스나 조직 상황에 맞는 적정 기술을 추구하는 것'이라는 생각이 들었다. 그리고 회사에서도 현재 자신이 어떤 상황인지(어떤 리소스가 얼마나 있는지)를 알고 그에 맞는 결정을 내리는, 즉 적정 기술을 추구하는 개발자를 조직에서도 당연히 선호하겠다는 생각을 했다. 발상의 전환을 준 강연이었다. 

아무튼! 그래서 원래는 FCM 알림을 백그라운드 푸시알림으로 구현하는 것에 대해서 원래는 이게 트래픽이 많아지면 비효율적인 방법이 아닐까, 아니면 원래 알림과는 맞지 않는 취지 아닐까(실제로 그렇기는 하다)... 등등 여러 생각이 들었었다. 그런데 그러면 그건 그때 가서 고민하면 되는 게 아닐까? 라는 방향으로 생각이 바뀌었다. 일단 구현해보자. 

우선 구현을 하려면 프론트엔드의 앱이 제대로 동작해야 했다. develop 브랜치로 체크아웃한 뒤 한번 확인해봤다. 어떠한 이유인지는 모르겠지만, 프론트에서 로컬 서버를 호출하고 있는 것으로 보였다. 

이 문제도 해결되어야 하긴 한데, FCM 알람과 직접적인 연관은 없는 문제이므로 우선 백엔드도 로컬 서버를 띄워두기로 했다. 이번에는 또다른 에러가 났다. 전혀 상관 없는 에러인데, 문제는 이걸 해결하지 않으면 알림 테스트를 못 한다는 것이었다...! 그래서 해결해야 하는 상황이다. 아니면 다른 버그 이슈를 하나 파고 해당 이슈에 dependency를 걸어두는 것이 낫겠다. 즉 원래는 FCM 알림 이슈 해결 후 커스텀을 하려는 계획이었는데, 버그 해결 후 FCM 알림 이슈 후 커스텀을 하게 되었다. 

알고보니 이 문제는 다른 브랜치에서 해결 중이었는데 머지가 되지 않은 상황이었다. 해당 브랜치를 머지한 다음 .gitignore 파일에 올리지 않은 파일을 따로 Firebase에서 받아서 올려두니 잘 동작하였다. 

✅ 궁금한 점

✅ 오늘 배운 것

어제 나름의 시도를 했는데 아직 서버를 HTTPS로 띄우지 못해서, 추가적으로 무엇을 더 할 수 있을지를 알아보았다. 두 가지로 추가로 체크할 사항이 있었다. 첫 번째는 SNI 설정을 통해 하나의 서버가 여러 도메인에 대해 여러 개의 인증서를 제공하도록 해야 했다. 왜냐하면 현재 서브도메인으로 등록된 개발 서버는 HTTPS로 잘 연결되는 상황인데 프로덕션 서버만 HTTP로 연결되는 상황이라, 서버에서 각 도메인에 맞는 인증서를 제공해야 했다. 

이를 확인하려면 로드밸런서에 SNI 설정이 잘 되어있는지를 확인해야 했다. 즉 'SNI용 리스너 인증서'가 설정되었는지를 확인했다. 어제 등록한 인증서가 나와 있었다. 

두 번째는 ACM 인증서가 현재 도메인을 지원하고 있는지였다. 사용하고 있는 ACM 인증서에 가서 '도메인' 쪽을 보았더니, 앞에 와일드카드(*)가 붙은 도메인을 전부 지원하고 있었다. 

그렇다면 다시 문제의 원인을 생각해 보자. 문제가 있을 만한 부분은 Route53, ACM 인증서, ELB의 리스너 등이다. 그런데 서브도메인은 잘 연결되고 그냥 도메인이 잘 연결되지 않는다면, 둘 다 공통적으로 사용하고 있는 ACM 인증서에는 문제가 없을 확률이 높다. 즉 Route53과 ELB의 리스너에 문제가 있을 확률이 높다. 

우선 ELB의 리스너 쪽을 보았다. 개발서버의 ELB 리스너와, 프로덕션 서버의 ELB 리스너를 보고 하나씩 설정을 비교해보기로 했다. '보안 정책'의 필드 부분에서 다른 부분이 있었다. 

프로덕션 서버에서 사용하는 설정을 개발 서버와 똑같이 맞춰주었다. 프로덕션 로드밸런서의 보안 그룹도 개발 로드밸런서의 보안 그룹과 동일한 것으로 바꿔 주었다. 여전히 되지 않았다. 

그랬는데 팀원들과 얘기하던 와중 프로덕션 서버의 HTTPS 리스너에서 사용하는 인증서에는 인증서에 와일드카드(*)가 포함되어 있었는데, *.domain.com은 domain.com을 포함하지 않냐는 얘기가 나왔다. 찾아보니 *.domain.com은 domain.com을 포함하지 않았다! 즉 지금까지 ACM에서 사용하던 SSL/TLS 인증서는 전부 서브도메인이 있는 URL에서만 유효한 인증서였던 것이다. 

그래서 새로 ACM에서 domain.com에 해당하는 인증서를 만들어주고, 해당 인증서를 HTTPS 리스너에 할당해 주었더니 문제가 바로 해결되었다!! 

이제 안심하고 context switching을 해 보자. 다음은 디자인을 새로 해야 한다. 

✅ 오늘 배운 것

어제 작업 중이던 이슈를 오늘은 마쳐 보려고 한다. Route53이나 EC2 로드밸런서 설정에서 문제가 있을 것이라고 생각해서, 여러 블로그들을 보면서 설정을 비교하고 조금씩 바꿔보던 작업을 하고 있었다. 멘토님께서는 AWS에서 HTTPS 인증서를 받을 수 있고, 로드밸런서(ALB)에 그렇게 받은 HTTPS 인증서를 추가하면 될 것이라고 말씀해 주셔서 이 부분을 참고해보면 좋겠다. 찾아보니 비슷한 경우의 블로그도 또 발견했다. 

내가 궁금했던 부분은, 왜 구매한 도메인 자체는 HTTP 연결만 가능하고, 그 앞에 서브도메인으로 dev나 test를 붙인 개발 서버나 테스트 서버는 HTTPS로 접근이 가능한지였다. 추측으로는 개발과 테스트 서버는 Route53에서 CNAME 타입으로 레코드를 생성하기 때문에 A 타입으로 레코드를 생성하는 프로덕션 서버와는 IP 주소로 연결되는 방식이 다르다고 생각했다. 

블로그에서 시도한 방법을 보았을 때, 단계는 크게 6단계로 나뉘는 것으로 보였고 나는 1-5단계는 다 적용이 되었다고 생각했다. 

1. ACM 인증서 생성하기

2. Route53에서 새 호스팅 영역 생성하기

3. 도메인을 구매한 사이트에서 설정한 DNS 레코드 값을 Route53에 설정해 주기

4. ELB 생성하기

5. ELB 로드밸런서의 DNS 주소를 Route53에서 새로 생성한 레코드에 적용하여 ELB와 Route53 연결하기

6. ELB 리스너에서 HTTP 리스너를 HTTPS로 리다이렉션 시키기

6단계의 경우, 4단계에서 만든 로드밸런서의 상세 정보를 보면 리스너가 2개 있다. HTTPS 리스너와 HTTP이 리스너이다. 여기서는 HTTPS를 통해서만 로드밸런서에 접근하고 싶기 때문에, HTTP로 접근했을 경우 이를 리디렉션 시켜 주어야겠다. 

HTTP 리스너의 편집 버튼을 누르고, 다음과 같이 'URL로 리디렉션'을 클릭해 주자. 

이렇게 하고 검색창에 도메인 이름을 그대로 입력해 주었다. 원래는 HTTP로 연결되어서 경고로 안전하지 않은 연결이라고 떴었다. 이번에는 자동으로 HTTPS로 리디렉션이 된다. 문제는 여전히 HTTPS 연결이 허용되지 않는 것으로 보였다. 즉 URL 앞에 HTTP나 HTTPS를 명시하지 않거나, HTTP로 명시해도 HTTPS로 리디렉션은 잘 되는데, 그냥 Route53 호스팅 영역 자체에서 HTTPS 연결을 허용하지 않는 것 같았다. 이 부분이 빠진 것 같았다. 

그런데 정확히 내가 어떤 부분을 놓치고 있는 것인지 헷갈려서 정리가 필요했다. 

정리하자면 총 네 단계가 있었다. 

1. ACM에서 SSL/TLS 인증서 발급받기

2. ALB에 인증서 적용하기

3. 보안 그룹에 인바운드, 아웃바운드 트래픽이 허용되는지 확인하기

4. Route53에서 도메인 설정하기

참고로 이미 ACM에 인증서도 있고, ALB에 인증서도 적용되어 있고, 보안 그룹을 확인해보니 인바운드와 아웃바운드 트래픽도 허용된 상태였다. Route53에서 A 레코드도 ALB의 DNS 주소로 연결되어 있었다. 그래서 이 중에서 뭔가 예상과 다르게 된 부분이 있을 것이라고 추측했다. 

2번 과정을 자세히 보니 ALB에 ACM에서 발급받은 인증서를 추가하는 것은 맞는데, 리스너 규칙을 적용해 줘야 한다는 말이 있었다. 찾아보니 'SNI용 SSL 인증서 추가'라는 버튼이 보였다. SNI는 뭔지 몰랐는데 SSL 인증서 추가라는 말이 있어서 눌러주었다. 그리고 ACM에 기존에 등록되어 있는 인증서를 추가해주었다. 

그런데 여전히 되지 않는다..! 

✅ 궁금한 점

1. 왜 문제 해결 전 상황에서 도메인은 HTTP 연결만 되고, 서브도메인은 HTTPS도 가능했을까?

2. Route53에서 CNAME과 A타입 레코드의 차이는 무엇일까?

3. 도메인을 발급받은 사이트(내 경우에는 porkbun)와 Route53 서비스의 역할은 각각 무엇인가?

4. 로드밸런서의 정확한 정의가 뭘까

5. ACM 서비스는 왜 필요하고 무엇인가

6. 로드밸런서에 리스너를 추가한다는 것이 무슨 의미인가?

✅ 오늘의 러닝 인증

✅ 오늘 배운 것

오늘 처리할 이슈는 SZ-299(서버 안정화 이슈)와 SZ-264, SZ-272(FCM 알람 이슈)이다. 더 급한 것이 서버 안정화 이슈이므로 이것부터 해 보겠다. 서버 안정화에는 여러 이슈가 많은데 이걸 다 하겠다는 의미는 아니었다. 이 중에서도 HTTP를 사용하는 현재 서버가 HTTPS를 사용하도록 하는 것, 그리고 서버에 '/auth/android' API 변경사항이 반영되지 않는 문제가 제일 커서(아마도 무언가가 롤백되어서 반영되지 않는 것 같다), 이 부분을 수정하면 될 것 같다. 

우선 관련 포스트를 좀 참고해 보았다. 여기서는 자기가 도메인을 구매한 사이트에 가서 SSL/TLS 인증서를 받으라고 했다. 나는 porkbun이라는 사이트에서 도메인을 구매했으므로, 해당 사이트로 들어갔다. 중간에 porkbun 사이트에서 보안 강화를 위해 지문 등록이랑 2FA(two factor authentication)를 하라고 해서 그것까지 해 줬다. 

그리고 다른 블로그를 더 찾아보니, 구체적으로 AWS Route53 서비스를 사용해서 서버를 HTTP에서 HTTPS를 사용하도록 바꿔주는 방법에 대해서 구체적으로 설명하고 있었다. 

그런데 내용대로 해 봤는데 안 되는 부분이 있어서, 내가 중간에 어떤 부분을 생략했는지도 모르겠다. 일단은 더 자료를 찾아봐야겠다. 구글링 하면서 다른 블로그도 찾았는데, 이 부분을 반영해 봐야겠다. 

✅ 궁금한 점

1. 2FA가 정확히 뭘까?

2. 해당 과정을 잘 정리해 보자...

✅ 오늘의 러닝 인증

✅ 오늘 배운 것

저번 포스트에서 프론트의 앱 배포를 빨리 실행하기 위해서 에뮬레이터를 새로 설치하고 hypervisor를 깔고... 등등 이런 방법들을 시도했었다. 사실 hypervisor를 까는 것은 너무 간 이야기였다. 그 윈도우 OS에서 또 에뮬레이터를 깔고 실행을 시켜야 했기 때문에, 만약 에러를 재현하는 데 성공해도 그 윈도우의 에뮬레이터 단에서 에러를 디버깅하고 해결해야 했다. 

그래서 멘토님께 조언을 구하던 중, 문득 '그렇다면 최소 요구 API 버전을 올리면 되는 거 아닌가?' 라는 생각이 들었다. 현재 최소 요구 버전은 23인데, 우리 팀은 다 33 이상에서만 테스트를 하고 있었다. 그렇다면 32 버전에서의 에러도 어떻게 보면 모를 수밖에 없었던 것이다. 이렇게 하면 해당 안드로이드 버전에서의 오류는 무시가 가능하다. 다만 걱정되는 부분은 일단 버전을 올려버리면 해결되는 것이 맞는지, 그에 대한 단점은 없을지였다. 

그런데 정말 다행히, 왜인지는 모르겠지만 우리를 애먹게 하던 안드로이드 버전 오류가 구글 플레이스토어를 다시 보니 해결되어 있었다. 그래서 해당 고민은 더 이상 하지 않아도 되었다. 

그리고 프론트 앱 배포에 필요한 테스터 20명도 모집했다. 이제 14일간 비공개 테스트 결과를 기다리면 된다. 

그러면 이제 원래 하던 이슈들을 보면 되는데, 생각해보니 현재 프론트 서버에서 배포 버전에서는 프로덕션 서버에 요청을 보내고 있었는데, 막상 프로덕션 서버에 몇 가지의 문제가 있었다. 

첫 번째는 main 브랜치로 코드를 반영할 때 워크플로우가 실패한다는 점, 두 번째는 안드로이드 클라이언트 ID를 요청하는 API가 프로덕션 서버에 반영되지 않았다는 점, 세 번째는 프로덕션 서버에서 HTTPS 대신 HTTP를 사용한다는 점이 문제이다. 마지막으로 네 번째는 이렇게 프로덕션 서버에 어떤 API가 있는지를 /swagger URL을 통해 알 수 있었는데, 그 URL이 프로덕션 서버에는 나오지 않는 문제였다. 

우선 첫 번째 문제의 경우 이전에 develop 브랜치에서 ECS에서 사용하는 태스크 정의 파일을 JSON 파일 템플릿에서 동적으로 환경변수를 주입하도록 바꿔 주었는데, 그 부분이 문제인 것 같았다. 정확히는 해당 템플릿에서 ECS 개발 클러스터에 대한 고유한 정보가 포함되어 있어서, 이를 main 브랜치를 통해 프로덕션 서버에서 ECS 태스크를 생성하려고 했을 때 '해당 이름의 컨테이너는 없다'는 에러가 난 것이었다. 

그래서 기존에 사용하던 ecs-task-def.json 파일 말고 프로덕션 서버 배포 시 사용하는 템플릿으로 ecs-task-prod-def.json 파일을 하나 더 만들어주었더니 해당 문제는 해결되었다. 

이제 두 번째 이슈를 해결해야 했다. 왜 main 브랜치에도 안드로이드 클라이언트 ID값을 반환하는 API가 잘 정의되어 있는데 막상 프로덕션 서버에는 없다고 나오는 것일까? 아마도 깃허브 워크플로우 자체는 정상적으로 실행되었지만 이후에 ECS에 의해 롤백되었을 가능성이 있겠다. AWS ECS의 프로덕션 클러스터의 서비스>이벤트에서 롤백과 관련된 로그를 찾을 수 있었다. 

그렇다면 왜 롤백되었을까? 해당 서비스의 태스크로 들어가서 로그를 보자. 정확히는 CloudWatch에서 해당 시각에 실행된 태스크의 로그를 보니 답을 찾을 수 있었다. 단순 typo 때문에 생긴 오류였다. 고치고 다시 깃헙 워크플로우를 실행시켰다. 

그리고 서버가 HTTP를 사용하여 통신하는 문제를 고치기 위해서 방법을 찾아봤다. AWS의 ACM이나 CloudFront 같은 새로운 서비스를 사용하라고 나와서 제법 복잡하다고 느껴졌다. ACM은 AWS Certificate Manager의 약자인 듯 해서 여러가지 인증서를 관리하는 서비스라고 이해했고, CloudFront는 '글로벌 콘텐츠 전송 네트워크'라고 나와있어서 사실 무슨 서비스인지 와닿지는 않았다. 

✅ 오늘 배운 것

1. 특정 안드로이드 API 버전에서 나는 에러는 어떻게 해결할까?

2. 최소 안드로이드 API 버전을 올리는 것이 '옳은' 선택일까? 다른 장단점은 없을까? 

3. 안드로이드 API에서 타깃 버전과 최소 요구 버전의 차이는 무엇일까?

4. ACM과 CloudFront는 정확히 무슨 역할을 하는 서비스일까? 

✅ 오늘의 러닝 인증

컨디션 난조(편두통)로 오늘 인증은 패스하겠습니다ㅜㅜ

✅ 오늘 배운 것

오늘은 별도로 개발 일을 하지는 않았다. 대신 앞으로 어떻게 하면 좋을지를 생각해 보았다. 

우선 앞으로의 취준과 프로젝트의 경우, 멘토링을 하면서 생각해 보니 일단 프로젝트를 최대한 고도화 시키고, 나중에 소마가 끝나고 나서 해당 프로젝트를 스프링으로 옮겨도 좋겠다고 생각했다. 다행히 내가 소마 끝나기 전에 꼭 취업을 해야 하는 상황은 아니기 때문에, 우선은 스프링 사이드 프로젝트를 잠시 중단하자. 그리고 내년 상반기까지를 1차 목표로 잡자. 

또 생각해 보면 소마라는 샌드박스 같은 좋은 환경에 있을 때 어떻게든 성과를 내고 뭔가가 확정이 되면 좋겠다는 생각이 들어서 더더욱 여러 가지를 한 번에 병행하려고 했던 것 같다. 물론 모든 걸 완벽하게 병행할 수 있으면 좋았겠지만 내가 한 번에 할 수 있는 것은 한계가 있기 때문에 우선순위를 잘 생각해야 할 것 같다. 

그리고 이런 샌드박스 환경이 끝나면, 뭔가 내가 추진력을 잃을까봐 걱정이 되고 불안했던 것 같다. 그래서 11월 안에 승부를 보려고 했던 것 같다. 물론 되면 너무 좋겠지만, 내가 11월 안에 취업이 안 된다고 이후에도 취업이 안 되는 것은 아니기 때문에 이것 역시 불안해서 그랬던 것 같다. 그렇다면 소마가 끝난 뒤에 만약 취업이 확정되지 않은 상황에, 어떻게 하면 소마에 있었을 때처럼 덜 불안해하면서 추진력을 이어갈 수 있을까? 일단 생각나는 것은 꾸준히 블로그 쓰는 거랑 운동인데 또 다른 방법이 있을까? 아니면 팀원들이나 다른 연수생들과 뭔가 스터디를 이어가는 방법도 있으려나? 나중에 멘토님들께 조언을 구해봐야겠다. 

우선 소마가 끝나기 전까지는 소마 프로젝트의 배포와 고도화 기능 개발, 그리고 기술 고도화를 하는 데 신경을 써야겠다. 그러면서도 원서를 틈틈이 계속 넣을 것이다. 여기서 관건은 코딩 테스트와 면접 준비이다. 여기에는 분명히 시간이 들어간다. 그리고 여기에 대해서 팀원 모두가 합의한 공동의 룰을 정해야겠다는 생각이 든다. 일단 내가 생각한 룰은 다음과 같다. 

1. 주 최대 15시간만 취준에 쓰기

2. 어디에 원서를 썼는지는 공유 안 해도 되지만, 코테나 면접 일정 등 다음 스텝이 정해지면 일정을 공유해 주기. 그리고 특히 면접의 경우 전 2일 동안은 면접 준비에 모두 할애할 수 있도록 해 주기(이건 다른 소마 친구한테 들었던 룰인데 괜찮아 보여서 가져와봤다)

면접 준비의 경우에도, 기본 CS 지식을 물어보는 경우와 프로젝트와 관련된 기술 경험을 물어보는 경우가 조금 나뉜다고 생각했다. 하지만 이를 한 번에 준비할 수 있다고 생각했다. 내가 생각한 것은 '자기가 아는 걸 정리해보는 것'이다. 예전에 영어학원에서도 백지 공부법으로 이번에 배운 걸 다 백지에 적게 하는 시험이 있었는데 그게 생각났다. 처음에 자기 프로젝트가 뭐고 뭘 했는지를 스스로 설명해 본 다음, 그 안에서 분명 질문이 나올 만한 포인트가 있을 것이다. 

이 부분으로 한번 내가 아는 지식을 정리하면 코테랑 면접 준비가 될 것이고, 매일 한 문제씩 코테를 풀면서 코테 준비도 될 것이다. 그리고 나머지 시간을 프로젝트에 투자해 보면 어떨까? 내일 팀원들과도 얘기를 나눠봐야겠다. 

✅ 궁금한 점

1. 11월 이후 소마가 끝나면 또 어떻게 추진력을 갖고, 덜 불안해하면서 프로젝트와 취준을 이어갈 수 있을까? 

2. 면접 준비와 CS 지식 준비를 위와 같은 백지 공부법으로 준비해보는 건 어떨까? 갑자기 생각난 아이디어인데 실제로 효과나 잘 적용될 수 있을지 궁금하다. 

✅ 오늘의 러닝 인증