[사내이슈] - 첫 커머스 이슈 대응기

서론

 

항해 시작과 함께 진행한 이직 수습기간을 정신없이 마치고 메인 결제 관련 기능 작업을 진행하게 되었습니다.

 

어떻게 시기라는 게 이렇게 딱 맞는지, 항해를 진행했던 시기에는 바쁘게 일을 처리하는 상황이 없었는데 고맙게도 딱 끝마치고 나니  그동안 하지 못 했던 일들이 몰려온듯한 느낌이었네요

 

개인적인 이슈 관리는 노션에 진행하고 있었지만, 처음으로 메인 기능을 많이 고치게 되는 계기가 되어서 이를 적어보게 되었습니다.

 

이번에 맡게 되었던 개발 건은 기존 결제 기능에서 새롭게 추가된 기능을 녹여내기 위해 파라미터를 추가하여 저장하는 작업인데요,

사실 겉으로 보기에는 별 게 없는 작업이고 신규 개발 건이면 내 입맛대로 만들 수 있는 작업이기도 합니다.

 

다만, '주문/결제'라는 이 키워드 하나로 그 내포되어 있는 기능은 굉장히 복잡해지게 되는데, 서비스 자체도 오래되다 보니 레거시 코드도 정말 많았죠. 이런 구조 안에서 새롭게 추가 되는 기능을 녹여내는 일은 생각보다 쉽지 않았습니다.

 

결제 프로세스 중에 어떤 단계에서 진행할 것인가?

 

우선, 새롭게 추가되는 기능을 위해 파라미터를 추가할 때, 이 파라미터를 기존에 사용하는 어떤 API에 추가적으로 작성하는 것이 맞을까? 하는 단계부터 고민을 하게 되었는데, 최대한 기존 기능에 문제를 일으키지 않으면서 깔끔한 구조로 작성하기 위해 팀원들과 많은 고민을 진행했었습니다.

 

자, 이제 개발 진행

 

이제 어디에 기능을 녹여낼지 고민을 마치고 개발을 시작하면 되는데요, 여러 PG사를 사용하고 있고 PG사마다 비슷하지만 다른 비즈니스 로직을 제공하는 터라 중복 코드가 많이 생기게 되었습니다.

 

그동안에 클린코드나 아키텍처 관련 공부도 많이 하고, 배우기도 많이 배웠지만 항상 새로운 레거시는 어렵게 느껴졌고 서로 다른 PG사 코드 내에 새롭게 만들어지는 중복 코드들은 이번에도 저를 괴롭혔습니다..ㅎㅎ

 

그래도 그동안에 배우고 써 먹었던 개념과 기술들이 헛되지 않은 것 같아 많은 도움이 되었네요

 

해치웠나..??

 

우선 서버 개발의 기한은 12월 23일까지고 빠르게 배포되어야 하는 기능이라 QA 기간도 하루 정도밖에 안 되는 기간인데, 저는 지난 3개월 전부터 피치못하게 잡혀있던 아버지 환갑 여행이 20일 저녁부터 잡혀있었죠..

 

그래서 20일 저녁까지 서버 개발을 완벽히 진행하고 프론트쪽과 맞춰보는 작업을 위해 19일 오전 서버 스펙을 전달하게 되었는데요,

이 생각이 저만 생각한 이기적인 생각이라는 것을 너무 늦게 알아버렸습니다.

 

서버 작업이 완료되면 API만 붙이면 되겠지! 라고 생각하여 20일 오전부터는 개발 환경에서 E2E로 UI로 테스트가 될줄 알았지만, 다들 바쁜 시기다 보니 서버쪽 테스트만 마치고 안절부절하면서 여행 내내 노트북을 상시소지하고 다니게 되었죠..

 

 

이전 회사에서 바랬던 휴일에 이슈처리하는 개발자의 삶

 

이전 회사에서 물경력으로 고민을 많이 했었기에, 서비스 장애 처리를 휴일에 하는 정말 바보같은 꿈을 꿨었습니다. 새해소망으로 기도했던만큼 일에 대한 간절함을 느꼈었죠

 

이번에 금요일에 생각했던 테스트를 완벽히 진행하지 못 하고 휴가를 갔던 만큼, 무게감이 정말 많이 느껴지기도 했습니다.

23일 월요일 오전 프론트 개발 환경 배포가 완료되자 마자 QA가 진행됐고, 아니나 다를까 맞춰보지 못 했던 부분에서 에러가 발생하게 되었고 QA의 원활한 진행을 위해 삿포로 배경으로 카페에서 운치있는 개발을 통해 비장하게 대응했죠!

 

 

 

진짜 해치웠나..?

 

중간중간 QA 이슈 대응을 통해 무사히 QA도 마치면서 릴리즈 환경까지 테스트를 마친 후, 나름대로 안도하면서 귀국하게 되었습니다.

25일 성탄절 동안에 미비되었던 작업을 확인하고, 26일 출근하여 드디어 안정적인 서비스 배포를 준비하게 되었습니다.

 

첫 번째 이슈발생

 

10시 50분 기점으로 프론트와 백엔드 배포가 진행되었고, 모든 것이 끝났지만 혹시모를 장애대응은 항상 해야하기 때문에 데이터독 모니터를 통해 지켜보고 있어여야지.. 라고 생각하면서 배포가 완료되는 순간...!!

 

슬랙 오류 알림으로 실시간 오류가 떨어지는 것을 확인했고, "아.. 이것이 이용자가 많은 커머스의 싱크 오류구나.."라는 것을 느끼며 배포 싱크로 인한 오류 대응을 위해 오류 거래 건에 대한 보정을 위한 기록을 진행했습니다.

 

두 번째 이슈발생

 

문제는 두 번째 이슈에서 발생했는데요, QA 진행 간에 주문서 진입과 결제 프로세스도 원활히 테스트가 진행됐었기에 전혀 느끼지 못 했었던 암/복호화 문제가 갑자기 터지게 되었습니다.

 

 

해당 이슈는 새로 추가된 기능 때문에 주문서 스냅샷을 재정하는 과정에서 기존 암호화 값을 복호화 후 다시 암호화하지 않고 저장해서 발생한 이슈였는데요, 짧은 시간 동안 다량으로 발생한 이슈를 빠르게 처리하기 위해 진땀이 빠졌네요..

 

나는 어떻게 장애를 대응했는가

 

이번 커머스 이슈 대응에 있어서 항해 마지막 주차에 올바른 장애 대응을 위한 고민과 보고서를 작성했었습니다. 해당 과정이 이번 장애 대응에 도움을 주었는데,

 

우선 내가 많은 기능에 대해 맹신하지 않고 의심하며 수시로 모니터링해야겠다는 마인드로 시작했습니다. 또한, 로그를 잘 기록해놓은 덕에 이슈가 발생한 로그를 보면서 어떤 값이 어떻게 보정이 되어야 하는지를 수치적으로 기록할 수 있었죠.

 

그럼 이제 이슈가 발생한 시각에 대한 보정이 끝났으니, 장애 처리는 끝인가? 라고 생각할 수 있지만 앞서 얘기했듯이 내가 만든 코드를 맹신하지 않기 때문에 일주인 간 상시로 모니터링을 진행했습니다.

 

이슈 대응 완료

 

연말까지 일주일 동안 대응한 덕에 이후로 결제 기능에서 크리티컬한 이슈는 발생하지 않았고, 무사히 첫 메인 개발을 완료하게 되었습니다.

 

3-4년 개발을 진행하면서 SI처럼 신규 프로젝트만 진행했었고, 서비스를 하더라도 하루 이용자가 많지 않았던 터라 이번 이슈는 정말 뜻 깊은 시간이었던 것 같습니다.