7월 회고를 굉장히 늦게 작성하게 되었다... 팀원분들과 함께 해외 워크샵을 다녀오면서 다양한 경험을 하기도 했고, AI를 어떻게 쓰면 좋을지, 주말에 이것 저것 사용해보는 등 기존과 다른 고민들을 하다보니 7월에 대한 정리가 늦었다. 한달간의 고민과 작업들을 돌아보고 이미 다가버린 8월, 다가올 9월은 어떻게 보내볼지도 적어보려한다.
시작된 숨은 환급액 찾기 다이어트 프로젝트
6월 말 부터 계획했던 작업을 본격적으로 시작했다. 6월 회고에서 작성했던 것 처럼 제품 전체에 대한 구조화, 모듈화를 기반으로 제품을 모듈 단위로 구분했다. 그에 따라 정리된 스텝은 이어하기, 스크래핑, 추가 수집, 공제, 결제, 신고 6가지로 분류를 했고, 각 도메인을 구분한 단위 내의 세부적인 작업들을 정의하고 일정을 정리했다.
7월은 사실상 이어하기가 거의 메인 작업이었다. 신고 상태에 따라 다음 스텝을 진행하게 하는 것은 리텐션과 유저 경험에 아주 중요한 요소였고 고객의 상태가 어디인지 판단하기 위해 13개의 API가 필요한 상황이었기 때문에 각 스텝에 맞게 이동할 수 있는 하나의 API를 백엔드 개발자분과 정의해 점진적으로 마이그레이션
을 진행했다.
//before
const [{ a1, a2, a3 }, { b1, b2 }] = await Promise.all([fetchA(), fetchB()])
if (a1 || b1) {
return "스크래핑"
}
if (a2 && !a3 && b2) {
return "추가수집"
}
//after
const { userStatus } = await 통합_이어하기_API()
if (userStatus === "스크래핑") {
return "스크래핑"
}
점진적 마이그레이션을 위해서 우선 기존의 13가지와 전환할 하나의 API 총 14가지 API를 호출한 다음, 각 상태를 판단하는 필드들의 유저 상태와 하나로 정리한 API가 1대1로 잘 매칭되는지 보고 다를 경우 로그를 남겨서 안정적으로 마이그레이션을 진행할 수 있었다. 백엔드 개발자분의 좋은 아이디어 덕분에 상당히 안정적으로 옮길 수 있었고, 매주 미팅 시간에 센트리로 로그를 같이 분석하면서 세밀한 유저 케이스들을 보고 수정해갈 수 있었다.
const [{ a1, a2, a3 }, { b1, b2 }] = await Promise.all([
fetchA(),
fetchB(),
통합_이어하기_API(),
])
if (a1 || b1) {
if (!userStatus === "스크래핑") {
Log("스크래핑이 아님")
}
return "스크래핑"
}
if (a2 && !a3 && b2) {
if (!userStatus === "추가수집") {
Log("추가수집이 아님")
}
return "추가수집"
}
7월까지는 스크래핑과 추가수집 퍼널에 대한 이어하기 마이그레이션을 완료했고, 세부적으로는 스크래핑 내부에 있던 추가수집 퍼널을 분리하는 작업도 진행했다. 해당 과정에서 아직 브릿지에만 적용되어 있는 SSR을 전체적으로 적용할 경우 브릿지 화면들이 생겼을 때 보다 빠르게 전환이 가능하게 개선이 가능하겠다는 생각도 들었다.
현재까지 일정대로 잘 진행되고 있는 상황이고, 8월까지 잘 마무리한 후에 전체적인 소회를 담은 회고도 9월에 작성해보려 한다.
인컴 홈페이지 배포 파이프 라인 구축
7월에는 새롭게 인컴 홈페이지를 오픈하게 되었다. 해당 구현 작업은 다른 프론트 개발자분께서 진행해주시고, 인프라 세팅작업을 담당해서 함께 진행하게 되었다. 사실 인프라, AWS에 대한 경험이 너무 없었기 때문에 많이 걱정했지만 열심히 인프런 강의와 자료들을 보면서 CSR로 된 프로젝트를 배포할 때 파이프라인 구성을 완료할 수 있었다.
간단하게 구현과정을 적어보면 CSR의 경우 빌드된 결과물을 S3에 올리는데 이때 CloudFront
로 CDN을 구현해 캐싱을 진행하게 된다. 여기서 조금 더 고민해야할 부분은 바로 어느 버전의 빌드 결과물
을 보여줘야할 지에 대한 부분이다. 만약 새롭게 배포한 결과만 올린다면 큰 문제는 없지만, 배포 후 장애로 롤백이 필요하거나, 다양한 버전에 대한 테스트 환경을 구성해야할 때가 필요할 수 있다. 이러한 버전 관리를 위해 CDN과 S3 사이에 어떤 버전으로 랜딩할지를 위한 Lambda
가 필요하게 된다.
이렇게 구현된 인프라를 바탕으로 깃허브에 배포될 때마다 빌드 결과물을 새롭게 S3에 올리고 새로운 버전이 올라왔으므로 CDN의 캐시무효화를 하는 깃허브 액션을 구성하게 되면 간단한 CSR 배포 파이프라인이 완성되게 된다.
잘 모르는 분야라 굉장히 두렵기도 했고 일정에 대한 압박감도 있었지만, 다행히 여러 자료들이 있었고 claude code와 티키타카를 하며 열심히 배워서 적용할 수 있었다.
이렇게 한번 인프라와 플랫폼 업무에 대한 경험을 쌓고 나니 많은게 달라보였다. 흔히 보던 "www.google.com"을 검색했을 때 생기는 일이라는 면접 문제가 조금 더 잘 이해가 될 수 있었고 인프라간의 연결관계, 인프라를 코드로 관리하기 위한 테라폼 등 다양한 새로운 지식들에 대해서 알게 되었다.
실질적인 문제로 토스 앱 내에서 타팀과 함께 작업해야하는 부분에서 스킴이 잘못되어 리다이렉션이 필요할 때 인프라단 람다 설정을 통해 장애를 빠르게 해결하기도 했다. 만약 경험이 없었다면 담당 사일로에 전달드리고 마냥 기다릴 수 밖에 없었을텐데 빠르게 대처할 수 있는 좋은 기회가 되었다.
아직 부족하지만 조금씩 역할을 확장하고, 조금 더 다양한 작업을 할 수 있도록 계속해서 인프라 쪽도 관심을 가지고 공부해보려 한다.
돌아보는 7월의 액션아이템과 8월 액션아이템
7월에 해보려 했던 작업은 아래와 같았다.
- AI를 통해 히스토리 문서화 해보기
- CSR페이지 SSR 마이그레이션을 위한 인증 공유 체계 구축
인증 공유 체계는 구현했지만 현재 전체적인 인증 관련 작업이 마이그레이션을 앞두고 있어서 해당 작업은 조금 더 추가 작업이 필요해 9월에 마이그레이션이 끝난 후 본격적으로 작업해보려한다. AI를 통해 히스토리 문서화는 간단히 진행할 수는 있지만, 까먹어서... 진행하지 못했다.
8월은 아래와 같은 액션 아이템을 진행해보려 한다.
- 숨은 환급액 찾기 다이어트 프로젝트 완료하기
- AI를 통한 히스토리 문서화 해보기
8월이 얼마 남지 않은 상황에 액션아이템을 만들다 보니 조금 머쓱하지만 우선 숨은 환급액 찾기 다이어트 프로젝트를 잘 완수하는 것을 목표로 하려 한다. 계획했던 것을 잘 수행하고, 그안에서의 가치를 잘 전달하는 것까지를 목표로 9월에 전사 위클리에서 발표까지 해보려 한다.
AI를 통해 히스토리 문서화는 작업과정에서 필요한 내용들을 정리하고 그것을 다시 학습시키면서 좋은 선순환을 만들기 위한 초안을 제시해보려한다. CLAUDE.MD나 .cursorrule과 같은 설정을 조금 더 관심가지고 업데이트 해보려한다.
늦었지만 작성한 7월 회고, 얼마남지 않은 8월이지만 다음 회고는 조금 더 풍부하게 작성할 수 있을 것 같다. 글을 쓰면서 요즘 기술에 대한 글에 대한 작성이 뜸해졌다는 것을 느낀다. 새로운 AI기술이 너무 많이 나오고, 한편으로는 내가 지금 공부하는게 크게 의미 있을까?
회의감이 들기도 했다. AI가 나보다 잘할텐데 라는 생각에서 시작된 무기력함이었지만 사용하면 사용할 수록 내가 모르면 요청을 할 수 없다는 것, 내가 똑똑해야 AI를 잘 쓸 수 있겠다
는 생각으로 정리하게 되었다. 내가 요즘 겪는 문제가 뭔지, 조금 더 효율화할 수 있는게 뭔지 계속해서 나에게 관심을 갖고, 내 일상에 관심을 가지고 해결하며, 나누는 것을 목표로 해보려 한다. 8월에는 그런 요소들도 같이 간단하게 작성하거나 만든 후기도 담아보면 좋을 것 같다.