꼬박 하루가 걸렸던 작업이었지만, 간살인 이유는 내가 한게 사실 없다.
이렇게 Refactoring을 하게 된 경위는 팀원들이 각각 개발한 기능들을 합치게 됐기 때문인데,
1. FFmpeg 안드로이드/IOS 가동
2. 동시 재생/녹화 기능
3. 편집 및 콜라주
우선은 팀장님께서 각자 개발한 기능들을 동일한 라이브러리에서 작동하게 만들어두셨다.
이 사진은 우리 팀장님이 막 합쳐놓았을 때의 구조다.
그래서 파일 하나하나가 걸작이다.
겹치는 컴포넌드도 없고, styled 컴포넌트도 아니며, 얘네들을 묶은 것은 단지 네비게이터 밖에 없었다.
알 수 있는 것은, '아, 모든 기능이 여기서 돌아가긴 하는구나.'
사실 제일 중요한 거긴 하다.
아무튼 팀장님께서 어렵게 합쳐놓으신 것을 리팩토링하기로 했다.
처음에는 기능 연결 위주의 리팩토링이었고, 그 다음은 컴포넌트 분리와 통합이었다.
이건 이제 기능 위주의 리팩토링이 끝났을 때의 구조다.
여기의 소스 코드들 역시 개판이었다. 오로지 기능을 엮기 위해서 분리했기 때문이었다.
기능은 어떻게 엮었냐면
1. 동시 재생/녹화 스크린으로 가서 영상 업로드 및 녹화가 끝나면
2. 편집 페이지로 이동해서 편집할 수 있게 하고
3. 콜라주 버튼을 누르면 FFmpeg를 사용하여 최종 편집을 한다.
일전에 포스트한 nest 관련 글이 아마 기억날 수도 있다.
이미 FFmpeg은 서버에서 동작하도록 구현했는데, 왜 IOS랑 AOS에서 동작하도록 바꿨지? 할 수도 있다.
'클라이언트 사이드에서 인코딩을 하는 것이 좋지 않을까'라는 피드백을 받았기 때문이다.
서버에서 인코딩하게되면 비용 및 서버 요청 큐 관리가 복잡하게 될 것이라 하셨다.
그래서 클라이언트 사이드에서 인코딩하는 방향으로 틀었는데, 웹 클라이언트 사이드에서 구현하면 클라이언트가 웹을 켜두어야 하기 때문에, 폰에서만 하는게 최적의 선택이라는 결론이 났다.
즉, 클라이언트 휴대폰 자원을 사용하는 방향으로 돌렸다.
아무튼 기능을 엮은 후에도 여전히 위와 같은 상황이었다.
(기능 엮는 데는 꼬박 하루에서 이틀 정도 걸린 것 같다.)
기능 구현이 끝나고나서는 컴포넌트 리팩토링에 들어갔다.
모든 파일을 gemini한테 먹이고 토해내게했다.
근데 이게 생각보다 까다로워서 꼬박 하루가 걸렸다.
그리고 이것이 결론이다.
뭔가 속이 후련하다.
오랫동안 못치웠던 방을 깔끔하게 청소하는 기분이랄까
생?각보다 많이 줄어들지는 않은 것 같기도 하고...
하지만 styled는 너무나도 반갑다.
그리고 AI는 padding-vertical을 대체 어디서 주워들은 걸까?
