Intro
우리 회사 서비스의 핵심기능인 통화 기능을 드.디.어 리팩토링 할 시간이 주어졌다.
기존에 있던 코드가 오래 됐기도 했고, 기능 개선 & 오류 대응이 필요했던 상황이었던 차,
겸사겸사 시간을 내어 진행하게 되었다. 통화 기능을 처음부터 만들어본건 이번이 처음이라
부담감이 있었지만, ‘이 또한 지나가리’ 란 생각으로 이악물고 극복한 이야기를 써보려한다.
어디로 가야하죠?
통화 기능 리팩토링이 들어가기 초기 단계에 개발팀 쌤들과 회의..
시작부터 갈림길을 마주했다.
- 기존 프로토콜에서 가능한선까지 유지보수를 하자!
- 리소스가 투입 될거면, 조금 더 모던한 구조로 재구성 하자!
치열한 공방전...
서비스의 핵심 기능이다보니, 보수적 의견도 있었고, 진보적인 의견도 있었다.
두가지 의견 모두 나쁜 의견은 없었다. 어떤 선택이 최소한의 리소스로 최선의 선택인지를 판단했어야 했다.
여러분들이 위 상황이라면 어떤 판단을 내렸을지 한번 같이 고민해보는것도 좋을것 같다.
시작은 미약하나 그 끝은 창대하리라
콜롬버스는 신대륙을 발견하기 위해 여행을 떠나기로 마음을 먹었다.
시작은 가벼운 마음으로 시작되었다.
그저 물 흐르듯이 스무쓰(th) 기존의 통화 코드부터 파악하기 시작했다.
++;
목적을 알 수 없는 코드 & 약타입으로 작성되어 파라미터로 인해 타입 추정 불가,
메서드 안에 메서드( or 프로바이더) 안에 메서드( or 프로바이더) 호출...
타고 가다보면 길을 잃기 쉽상이었다..
누굴 욕하고 탓하기보단, 이 난관을 어떻게 극복해나갈지 걱정이 앞섰다.
한참을 보다 내린 결론은.. ‘이거 못 살린다.’ 였다.
주어진 시간과 리소스안에서 내 역량으론 리팩토링은 불가능하다고 판단되었다.
서비스 입장에서 타협할건 무조건 타협하는 입장인데, 이건 타협이 안됐다.
결국 아쉬움을 뒤로한체, 처음부터 다시 작성했다.
신호 받기
일단의 기존 통화 신호를 받는부분부터 분기되어있었다. ( aos 는 fcm 으로 ios 는 apns 로 ) 그래서 이부분을 일단 fcm 으로 통합해줌으로 코드의 통일성을 지켜주었다.
(이부분이 추후에 엄청난 재앙을 가져올줄은 꿈에도 몰랐다..)
통화 알림 띄우기
이제 fcm 으로 들어온 통화 신호를 각 플랫폼에 맞게 알림을 띄워줘야했다.
이부분도 기존에 ios 에서는 callkit 을 사용했고, aos 는 LocalNotification 을 이용해 처리를 했다.
native 를 작성해야할것같은 쌔한 느낌이 엄습해오는 가운데..
구원 투수 등장 (사실상 두번째 재앙 등장)
flutter_callkit_incoming | Flutter package
전화 UI 를 각 네이티브 별로 잘 작성해놓은 라이브러리가 있었다.
하지만 그대로 사용하기엔 우리 서비스와 조금 안맞는곳이 있어, 부분적으로 손보긴 했지만,
그래도 바퀴를 통째로 만드는 수고는 덜게되었다.
(라고 하지만 이 라이브러리드 프로모션 서비스에서 이용하기에는 빈틈이 너무 많았다…)
전화 받기
기존의 통화 프로토콜은 WebRTC방식을 이용해 서비스를 구축하고싶었지만,
기존에 레거시에선 외부 RTC 서비스를 이용하고있어서.. 아쉽게도 코드 몇줄로 호다닥 넘어가버렸다.
(내 궁극의 목적은 이부분을 직접 구현하는것이다..)
신경 꺼줄래
기존의 통화 프로토콜에는 서버쪽에서 통화방 & 각 프론트의 상태를 너무나도 깊히 관여하고있었다.
아마 어떤 히스토리가 있었던것 같은데 ( 이유 없는 코드는 없으니까..),
그 덕분에 프론트에서도 목적을 알 수 없는 코드들이 덕지 덕지 붙어 있었고,
종종 알 수 없는 상황들이 연출되기도 했다.
( 원하지 않는 상황에서 통화가 종료되거나, 통화가 제대로 연결되지 않는 불상사가… )
그래서 이번기회에 서버 개발자쌤과 회의끝에 서버쪽에서의 통화방 개입을 최소화 하기로 결정했다.
( 갑작스런 상황에서 통화 참여자의 연결이 끊어진다던가,
연결이 불안정 한다던가 하는 상황들 모두 프론트쪽에서 처리하고,
프론트에서 판단 못하는 상황만 서버쪽에서 처리 해주기로 했다 )
로그 남기기
당연한 얘기지만, 개발할때 개발자들은 시나리오대로만 테스트 한다. 온실속 화초처럼..
그리고 개발 완료후 테스트를 거치는데, 진짜 상상도 못할 시나리오로 기괴한 테스트가 시행된다.
( 같이 일하시는 분중에 한분 계신데, 그분 별명이 ‘파괴자’ 이다. 거의 노코드 해커 같은 느낌. )
테스트후, 자식같은 앱이 처참히 발리고 돌아오는 모습을 보면, 뭔가 마음이 아프다.ㅎ
위 단계를 몇번 거치고 어느정도 번듯한 앱이 되면 이제 실제 배포를 하게 된다.
배포 환경은 정말 전쟁터다. 예측 불가능한 수 많은 시나리오들이 존재한다.
물론 개발 단계에서 이 모든걸 대처하면 좋겟지만, 사실상 불가능한일이다.
그래서 이런 불상사를 대비하기위해 로그를 남기는데,
자잘한 애러들
자잘한 애러들이라고 하기엔, 너무나도 핵심 기능에 영향을 주는것들이 많았다.
aos 에서는 스피커 모드로 고정이 된다던가,
ios 에서는 통화중 알람이 온후 audio session 에 문제가 생긴다던가,
FSI( Full Screen Intent ) 가 디버그땐 잘 되다가, 빌드후 배포시 안뜬다던가..
진짜 자잘한 애러가 너…무많아서 원인 파악만 하루 꼬박 걸린게 대부분이다.
이런 부분에서 생기는 어쩔 수 없는 덕지덕지 붙은 코드에는 꼭 주석을 남겨주었다.
미래의 나를 위해…
결론
배포를 한후, 통화 기능 브랜치의 첫 커밋을 확인하니 약 6개월 전으로 나왔다.
(물론 6개월동안 다른 기능 추가 & 자잘한 UI 수정 으로 배포가 이루어졌지만..)
정말 인고의 시간을 통해 많은 것들을 배웠다.
기존 코드 & 통화 구조를 개선하면서 기존에 존재했던 여러 애러들을 맞닥드렸고,
이 상황에서 누구의 잘잘못을 따지며, 무조건 적으로 누구를 고쳐야 한다는것보다,
그 상황에서의 최선의 답을 도출해 내는것이 개발자가 해야하는것이 아닐까 생각한다.
또 이번 리팩토링중 너무나도 많은 히스토리에 의해 작성된 주석이 없는 코드들을 보며,
다시한번 코드의 목적성을 뚜렷하게 나타내거나, 그 목적을 나타낼 수 없는 코드일경우
주석을 남겨야 한다는것을 너무너무 절실하게 느꼈다.
2편에서 폭풍재앙이 밀려온다..
