🧘🏻 재사용가능한 컴포넌트에 대한 회고

비효율에 대한 반성

변화가 잦은 스타트업 특성상 비즈니스 요구사항이 추가, 변경, 삭제되는 경우를 자주 경험하였다.

이럴 때마다 코드를 열심히 뜯어보며 요구사항에 맞추어 재작성하였다. 일부 컴포넌트만 변경하면 되는 경우도 있었고, 시간 관계상 비슷하지만 '조금' 다른 컴포넌트를 만들어 코드의 중복을 만들기도 하였다.

이렇게 두 번 일하는 상황이 너무나도 비효율적이라 생각하고 더 탄탄한 기획을 요구하거나 개발에 착수하기 전 기획에서 부족한 부분이 있나 꼼꼼히 체크해보기도 하였다.

처음에는 이러한 이유에 대한 책임이 충분히 고려하지 못한 기획에 있다고 생각했다.

하지만 그건 비즈니스에 대해 고민하지 않은 짧은 생각이었다. 내부적으로 아무리 탄탄한 기획을 갖추더라도 비즈니스는 외부의 영향을 받을 수 밖에 없다. 외부의 니즈를 만족시켜야하고 상황을 고려해야하기 때문이다.

그러면 이젠 어떻게 해야하는가에 대해 고민을 해봤다. 예측하기 어려운 상황에 대해 모든 것을 통제하려고 하기보다 그러한 상황에 알맞게 모양이 변하는 것이 필요하다 생각했다.

그러기 위해서는 유연함을 갖추어야하고 프론트엔드 엔지니어 관점에서는 유연한 UI, 유연한 컴포넌트 설계를 해야한다는 것에 필요성을 느꼈다.

유연한 컴포넌트란 무엇인가에 대해 스스로 고민하고 여러 방식으로 시도도 해보았지만, 이미 선배 개발자들의 값진 경험을 참고해보는 것도 좋겠다고 생각하여 레퍼런스를 찾아보았다.

역할과 책임

역할과 책임(Role & Responsibility)은 소프트웨어 팀에서의 기본 원칙이다. 각각의 구성원이 할 일과 그에 따른 책임을 명확히 정의하고 이를 수행함으로써 팀의 성과를 높이는 것이 목적이다. 즉, 역할은 구성원이 수행해야 할 일을, 책임은 그 일을 수행함으로써 발생하는 결과와 그에 대한 책임을 의미한다.

역할: 해야하는 일
책임: 역할을 수행하여 발생한 결과

역할과 책임을 분명히 해야하고 중요한 이유는 무엇일까? 예를 들어, 물류 소프트웨어를 만드는 팀에서 배송상태에 따라 구매자에게 상태를 알려주는 기능을 새롭게 개발한다고 하자. 만약 해당 기능을 일관성 없이 여러명에서 작성한다면, 불필요한 리소스가 들어갈 수 있으며 어떤 코드의 작동이 원치 않는 사이드 이펙트를 발생 시키는 것이 우려된다.

반대로, 누가 어떤 부분을 담당해야 하는지, 어떠한 결과를 만들어 내야하는 지가 명확하다면 서로에게 영향을 미칠 위험성이 줄어들며, 어떤 부분에서 원치 않는 작동을 한들 책임을 그 역할을 맡은 쪽에서 처리하면 되기 때문에 빠른 개선에 좋다.

물론 팀원들 간의 공유가 실시간으로 이루어진다면 전자의 경우도 어느정도 해결될 수 있겠지만, 우리는 회사의 규모가 1000명이 넘는 경우와 같이 더 극단적으로 생각해볼 필요가 있다. 이러한 경우는 사실 상 모든 팀원의 공유 상태를 일치 시키는 것이 불가능하다. 하지만, 후자의 경우는 팀의 규모와 관계 없이 역할과 책임만 분명히 하고, 수행만 잘 한다면, 조금 더 통제하기 용이한 상태로 만들어 준다.

컴포넌트에 적용해보기

이것을 컴포넌트에 적용한 경우가 있어 살펴보았다.

프론트엔드 프로그래밍에서는 크게 외부 리소스를 패칭하는 역할, 그 리소스를 요구상황에 맞추어 화면에 렌더링 시키는 역할 마지막으로 사용자 조작을 통해 상태 값(UI, data 등)을 바꾸는 역할로 나눌 수 있다.

처음에는 모든 구현이 한 곳에서 관리되는 것에서 시작해보자

// --- 생략 ---
const CommonComponent = () => {
	const [todoList, setTodoList] = useState([]);

	const deleteTodo = () => {
		// 유저가 클릭한 todo를 삭제하는 로직 실행
	}

	useEffect(()=> {
	// 1. 외부 리소스를 끌어오는 역할
	(async()=> {
			const fetchedTodoList = await fetchTodoList();

			setTodoList(fetchedTodoList);
	})()
	},[])

	return (
		<ul>
			// 2. 리소스를 화면에 알맞게 노출하는 역할
			{todoList.map((todo)=>
				<li key={todo.id}>
					<h3>{todo.title}</h3>
					<p>{todo.paragraph}</p>
					<input checked={todo.checked} />
					// 3. 유저와 인터랙션을 통해 상태를 변경하는 역할
					<button type='button' onClick={deleteTodo}>삭제하기</button>
				</li>)
			}
		<ul>
	)
}

export default CommonComponent;

간단히 보기위해 투두 리스트를 예로 들었지만, 솔직히 이 정도 되는 규모에서는 이런식으로 하나의 공간에서 모든 기능을 담당하는 것이 어찌보면 더 효율적일 수 있겠다. 데이터가 화면에 뿌려지고, 어떤 유저 인터랙션이 있는 지 한 눈에 보이기 때문이다. 하지만, 초기 비즈니스 요구사항은 이렇게 쉽게 해결되더라도 서비스가 고도화되면 될 수록 서로 간의 이해 관계가 엮여 아는 사람만 아는로직이 되어버린다.

나만 해도 로직이 얽혀 버그가 발생하는 지점을 찾기 어려웠다던지, 한 컴포넌트에 복잡성을 누적시켜 다른 팀원이 파악하기 어렵고, 나 자신도 손 대려면 날 잡아야하는 결과를 만든 적이 있다.

누구나 다룰 수 있다는 것은 그 만큼 파악이 용이하다는 것이다. 이렇게 하기 위해서는 간단한 구현 사항도 초기에 역할과 책임을 적용시켜 파악이 가능하게 해야한다고 생각한다.

앞으로 필요한 것

그러기 위해서는 기존 컴포넌트를 리팩토링해야 할 필요성이 있다고 생각된다. 그러나 이것에는 하나의 중요한 조건이 따른다. 바로 리팩토링한 코드가 기존 동작을 유지하고 버그를 발생시키지 않는다는 것을 증명해야 한다는 것이다. 리팩토링 후 일일히 이전 동작과 동일한 지 체크하는 것은 너무나 큰 리소스 낭비이다.

이를 위해 리팩토링과 품질 관리에 신경쓰는 개발 팀에서는 테스트 코드를 작성한다. 그렇게 되면 어떤 외부 변화에 맞추어 코드를 바꾸더라도 테스트만 통과하면 적어도 이전에 발생하던 버그는 발생시키지 않는 것이 증명되기 때문에 안정성이 보장된다. 또한, 테스트 코드를 통해 어떤 비즈니스 요구사항이 있는 지 파악이 되면서 개발 문서의 역할도 한다고 한다.

역할과 책임을 적용한 컴포넌트에 대해 생각하고 적용시키다 보니 자연스럽게 테스트 코드에 대한 필요성과 관심이 생겼다. 유연한 컴포넌트로 서비스를 구현하고 테스트 코드를 작성한 상태에서 비즈니스 상황의 변화를 가정하고 리팩터링을 연습하는 데에 시간을 들여보는 것이 좋겠다.

참고글

• 변경에 유연한 컴포넌트
• 팀의 성공을 위해 역할과 책임을 정립하는 4가지 방법 • Asana