부스트캠프 웹·모바일 8기 그룹프로젝트 3주차 회고

 

검색 기능, 설계를 몇 번이나 바꿨다

이번 주에는 검색 기능을 맡아서 개발했다. 검색은 단순히 검색어를 입력하고 결과를 보여주는 것이라 생각해서 어렵지 않을 줄 알았다. 하지만 막상 개발을 시작하니 검색어를 입력하기 전, 입력하는 중, 입력하고 난 뒤에 각각 다른 화면을 보여줘야 했다.

처음엔 이걸 하나의 RIB으로 처리하려고 했다. 굳이 나누지 않아도 상태만 바꿔주면 되겠다고 생각했기 때문이다. 그런데 상태별로 다뤄야 하는 데이터와 UI가 늘어나다 보니 하나의 RIB에 너무 많은 책임이 몰리게 되었다. 정작 모듈 분리와 책임 분리를 위해 RIBs를 선택한 것인데 오히려 massive한 RIB이 되어버린 것이다. 내가 RIBs를 쓰는 이유와 정반대의 결과가 나온 셈이라 여기서 설계를 다시 하기로 했다.

그래서 검색을 총괄하는 Container RIB을 두고 상태별로 Sub RIB들을 추가해서 나누는 방향으로 개발했다. 책임이 명확하게 쪼개지니 각 RIB이 무슨 일을 하는지가 분명해져서 좋았다.

하지만 이렇게 나누고 나니 또 다른 의문이 생겼다. 자식 RIB들끼리 데이터를 전달하려면 Container RIB을 거쳐서 전달해줘야 했는데 RIB이 많아질수록 Container를 통해 데이터를 주고받는 코드도 계속 늘어났다. 이게 과연 좋은 개발 방식인가 하는 의문이 계속 들었다. 책임을 나누기 위해 RIB을 쪼갰는데 그 대가로 데이터 전달이 복잡해지는 트레이드오프가 있어서 어느 지점까지 나누는 것이 적절한지에 대한 고민을 계속하게 되었다.

인터페이스와 구현체 나누기

이번 주 또 다른 기술적 고민은 모듈을 나누는 것이었다. 우리는 모듈화를 진행하면서 인터페이스와 구현체의 모듈을 나누기로 했는데 인터페이스만 노출하고 구현체는 숨기려고 하니 이 인터페이스를 어떻게 설계해야 할지가 고민이었다.

인터페이스를 너무 잘게 나누면 사용하는 쪽에서 매번 여러 개를 조합해서 써야 해서 불편했고 반대로 너무 크게 잡으면 구현체가 인터페이스에 끌려다니게 되어서 모듈을 나눈 의미가 옅어졌다. 어느 정도의 크기로 인터페이스를 잡아야 사용하는 쪽도 편하고 구현체도 유연하게 가져갈 수 있을지 계속해서 고민하게 되었다.

아직 정답을 찾았다고 할 수는 없지만 이런 고민을 직접 해보면서 모듈을 나눈다는 것이 단순히 파일을 폴더별로 나누는 것이 아니라는 걸 체감하게 되었다.

빠른 팀원, 느린 나

사실 이번 주는 기술적인 부분보다 마음이 더 힘들었다. 이번 주 내 개발 속도가 많이 느려진 것 같았다. 앞서 말했듯이 검색 기능을 개발하면서 설계를 계속해서 바꿨던 것이 가장 큰 이유였다. 하나의 RIB으로 시작했다가 massive해져서 다시 Container와 Sub RIB으로 나누는 과정을 거치다 보니 같은 기능을 몇 번이나 갈아엎게 되었다. 새로운 기능을 개발할 때 공부해가면서 개발을 하다 보니 사소한 것에도 시간을 많이 쓰게 되었고 그러다 보니 다른 팀원들에게 부담을 주는 것은 아닐까 하는 생각이 들었다.

작업을 분배할 때 내 작업이 시간이 오래 걸릴 것이라는 건 알고 있었지만 생각보다 더 오래 걸렸다. 그렇다 보니 개발 속도가 빠른 팀원이 많은 기능을 개발하거나 프로젝트 셋팅을 도맡아서 하는 일이 생겼다.

여기서 고민이 생겼다. 빠르게 개발이 가능한 사람이 다 도맡아서 개발하는 것이 맞는 것일까 ... ? 당장 프로젝트를 빠르게 진행하는 것만 생각하면 잘하는 사람이 많이 하는 것이 맞겠지만 그렇게 되면 나는 성장할 기회를 잃게 되고 결국 팀 전체로 봐도 좋은 방향은 아니라고 생각했다.

그래서 나는 조금 느리더라도 내가 맡은 부분은 끝까지 스스로 해내되 다른 사람에게 부담을 주지 않도록 조금 더 속도감 있게 개발하자고 다짐했다. 느린 것이 부끄러운 것이 아니라 느린데도 아무것도 하지 않는 것이 부끄러운 것이라 생각하며 이번 주를 마무리했다.