최소한의 기능으로 다시 시작하기

 

어제 저녁, 게시글 목록을 불러오는 프로세스를 리팩터링하고 있었다. 게시물 썸네일 하나를 구성하는 여러 리소스의 내용들을 프론트엔드에서 리소스 각각에 맞는 API를 호출해 내용을 따로따로 가져오고, UI 컴포넌트에서 출력하기 전 각자의 게시물에 맞는 내용으로 조합시키려 했다.

 

아래와 같이 게시물, 이미지, 운동 경기, 운동 장소, 포지션에 해당되는 리소스를 호출하는 API를 불러오는 페이지 컴포넌트가 만들어졌다.

 

xport default function PostsPage() {
  const postStore = usePostStore();

  useEffect(() => {
    postStore.fetchPosts();
    postStore.fetchImages();
    postStore.fetchGames();
    postStore.fetchPlaces();
    postStore.fetchRoles();
  }, []);

  const {
    posts, images, games, places, roles,
  } = postStore;

  // TODO: 게시글 클릭 시 게시글 상세 페이지로 링크 연결

  return (
    <Posts
      posts={posts}
      images={images}
      games={games}
      places={places}
      roles={roles}
    />
  );
}

 

상태를 관리하는 Store를 각 리소스의 Store를 모두 개별적으로 만들어서 상태를 관리할지, PostStore 하나에서 관리하게 할지 결정하는 데 도움을 받고자 질문을 올렸다.

 

예상하지 못했던 답변이 돌아왔다.

 

 

질문 게시판에 Store 구조와 함께 리소스 분리에 관련해서도 대해서도 올린 질문의 답을 보면서 지난 2주 간의 진행과정이 떠올랐다.

 

나는 분명 처음부터 복잡한 구조의 로직을 구현하려 했고, 설계 문서를 작성하지 않았다. 계층적으로 모델이 형성되었고, 테스트 코드가 지나치게 비대해졌다. 하나의 기능도 처음 짰던 화면대로 만들어지지 않았다. 사용자 스토리를 다시 작성하고 게시물 리스트를 호출하는 요청 로직에 너무 많은 부하를 몰아주지 않고 싶어서 리소스로 구분해서 호출을 하게 해보려 했다.

 

문제의 핵심은 거기에 있지 않았다. 핵심 가치에서 벗어난 기능들이 여전히 많이 있으면서 크기는 비대한, 그렇지만 잘 설계되지 않은 모델에 기능이 여전히 의존하려 하고 있었다.

 

 

밤과 아침을 보내면서 고민을 했다. 언젠가는 엎어야 할 구조이긴 했지만, 나는 과연 만들어져 있는 코드 대부분을 지우고 프로젝트 4주차에 들어서는 시점에 사실상 처음부터 다시 시작할 수 있을까, 무서웠다. 트레이너님과 동료분과 이야기를 나누고, 아샬님의 답변을 곱씹어보면서 내가 내린 결정은, 경로의존성을 쳐내는 것이었다.

 

API를 합치는 것만큼이나 내게 필요했던 것은 게시글 목록이 '최소한으로' 진짜 들고 있어야 하는 가치가 뭔지 고민했다. 백엔드로부터 들고 오게 하던 그 많던 데이터들 중 기능을 너무 복잡하게 만들고, '최소한의' 핵심이 아니라고 생각되는 건 다 쳐내보았다. 사용되지 않는다면 모델조차도 모두 없애보았다.

 

 

얼마 되지 않던 8개의 모델들 중 4개의 모델이 사라졌다. (User는 Person으로 대체되었다.)

기존에 작동하던 다른 기능들도 모두 없애고, 사용자 검증을 위해 다시 사용될 수 있는 인가 Interceptor는 형태만 남겨놓고 동작은 하지 않도록 했다.

 

7 스토리 포인트를 사용해 게시물 목록을 조회하는 최소한의 기능을 '구현했다'. 프로젝트를 시작한지 4주 만에 처음으로 구현했다고 말할 수 있는 기능이 만들어졌다.

 

 

그 다음 작업은 무엇을 진행해야 할까, 사용자 스토리가 사실상 다시 쓰이고 있어 작업 Task의 작업을 가져오기가 애매했다. 믿고 의지하는 동료분께 한번 더 도움을 구했다.

 

'리스트를 조금 더 키워볼까요, 아니면 상세 보기를 간단하게 만들어보는 게 좋을까요?'

'이 애플리케이션의 핵심이 뭔가요?'

'운동 신청이요. 수강신청처럼.'

'그럼 신청을 할 수 있어야겠네요.'

'신청은 상세 보기로 들어가서 하게 하려고 했는데...'

'하지만 가장 핵심은 신청이라고 하지 않았나요?'

'음... 리스트 제목만 있어도 신청은 할 수 있겠네요..?'

 

 

 

왜 아샬님이 저렇게 말씀하셨는지 이해가 되었다.

지금처럼 먼저 작성한 사용자 스토리를 고치는 과정에서는 이전에 생각하지 못했던 가치가 찾아질 수 있다. 그 가치는 분명 이전에 만들었던 화면이 제공하려는 가치와는 다를 수 있기 때문이다. 설계를 하는 중에, 구현을 하는 중에 이상함이 느껴진다면, 언제든 이전으로 돌아가서 더 나은 방향을 고민하고 계획을 바꿀 수 있어야 한다.

 

동료분께 이제부터 하려는 MVP의 확장이 미리 만들었던 작업 계획과 충돌하는 것 같음을 말했을 때에도 동료분도 같은 이야기를 해 주셨다. 작업은 유연하게 바꾸면 되는 것이라고.

 

일단은 현재 있는 Todo는 잠시 표시를 해 놓고 Backlog로 옮긴 뒤, 고친 사용자 스토리를 기반으로 Todo를 다시 작성하는 것을 계획하고, 최소한의 신청 기능 구현 동작을 설계해놓는 것으로 오늘의 작업을 마쳤다.

 

 

 

예전에 TIL에 좋지 못한 내용을 계속 올리다 크게 혼난 뒤로 그런 내용은 최대한 올리지 않으려 했지만, 오늘만큼은 참기가 어렵다.

진짜 많이 두렵다.

두려움을 깨기 위해서라도 작은 것부터 달성하는 경험이 절실하다.

그렇기 때문에 동료분이 말해주셨던 '처음에 너무 많은 것들을 하려다 실패하면, 시작하는 것조차 두려워지게 된다.'는 말이 더 와닿는 것 같다.