프롭 드릴링

화면을 컴포넌트로 쪼개는 것은 프론트엔드의 기본입니다. 화면을 이루는 재사용 가능한 코드 단위이고, 값은 부모가 자식에게 넘겨 주는 방식으로 흐릅니다. 넘기는 값을 프롭이라고 부릅니다.

문제는 값이 있는 자리와 쓰이는 자리가 멀어질 때 생깁니다. 페이지덱의 문서 목록 화면이 그랬습니다. 로그인한 사용자 정보는 화면 맨 바깥에서 한 번 받아 오고, 그 정보가 실제로 쓰이는 곳은 문서 카드 안쪽의 작성자 표시입니다. 사이에 목록 틀, 목록, 카드, 카드 머리글 네 단계가 있는데 그중 어느 것도 사용자 정보를 쓰지 않습니다. 그냥 받아서 아래로 넘깁니다.

태오가 작성자 이름 옆에 프로필 사진을 함께 띄우려 했을 때 이 구조의 값이 드러났습니다. 화면에 한 줄 추가하는 일인데 파일 여섯 개를 고쳐야 했습니다. 중간 네 단계에 새 프롭을 선언하고 넘기는 코드와 타입 선언까지 고쳐야 했기 때문입니다. 정작 그 네 단계는 사진을 쓰지 않습니다.

프롭 드릴링은 이 상태를 가리키는 이름입니다. 고장이 아니라 구조가 자라며 생기는 증상이고, 이름이 있으면 무엇을 고치자는 말인지 한 단어로 통합니다.

원인은 값이 위에서 아래로만 흐르는 규칙에 있습니다. 부모가 자식에게 넘기고 자식은 부모의 값을 직접 꺼내 갈 수 없습니다. 이 규칙 자체는 장점입니다. 화면에 뜬 값이 어디서 왔는지 따라 올라가면 반드시 한 군데로 이어지고, 값이 바뀌는 자리도 하나입니다.

값을 치르는 쪽은 중간 단계입니다. 값 하나가 네 단계를 지나면 네 곳에서 받아 다시 넘기는 코드를 쓰고, 값이 하나 늘 때마다 같은 일을 네 번 더 합니다.

증상은 셋으로 나타납니다.

1. 쓰지 않는 값을 받는 컴포넌트가 생깁니다. 목록 틀이 사용자 정보를 받는데 그리지 않는 식입니다. 그 값이 무엇인지 알 필요가 없는데도 이름과 타입을 알아야 합니다.
2. 부품을 다른 화면에서 다시 쓰기 어려워집니다. 카드를 다른 화면으로 옮기면 거기서도 사용자 정보를 위에서부터 내려 줘야 합니다. 재사용하려고 쪼갠 부품이 특정 화면 구조에 묶입니다.
3. 같은 타입 선언이 여러 파일에 흩어집니다. 타입스크립트를 쓰면 단계마다 같은 모양을 다시 적게 되고, 모양이 바뀔 때 고칠 자리가 그만큼 늘어납니다.

몇 단계부터 문제로 볼지는 정해져 있지 않습니다. 실무에서는 두 가지를 같이 봅니다. 단계가 넷을 넘고, 그 중간 단계들이 값을 쓰지 않는 경우입니다. 두 단계쯤은 오히려 명시적이라 값이 어디로 가는지 코드만 보고 알 수 있습니다.

이 말이 가장 자주 나오는 자리는 코드 리뷰입니다. 합치기 전에 동료가 코드를 살펴보는 절차인데, 값 하나를 추가한 변경에서 관계없는 파일 다섯 개가 함께 바뀌어 있으면 이 이름이 나옵니다. 지적하는 쪽도 받는 쪽도 무엇을 말하는지 바로 압니다.

두 번째는 리팩터링 범위를 정하는 자리입니다. 동작은 그대로 두고 구조만 개선하는 작업인데, 손볼 곳을 고를 때 이 증상이 있는 경로를 먼저 봅니다. 해결 수단은 셋이고 비용 순서대로 꺼냅니다.

1. 구조를 다시 짭니다. 값을 쓰는 부품을 이미 값을 가진 자리에서 만들어 아래로 통째로 넘기면, 중간 단계는 그것이 무엇인지 모르고 자리만 내줍니다. 새 도구를 들이지 않아도 되어서 먼저 시도합니다.
2. 값을 꺼내 쓸 통로를 둡니다. 한 번 올려 둔 값을 그 아래 어디서든 직접 꺼내 쓰게 만드는 장치이고, 중간 단계가 사라지는 대신 부품이 그 통로에 묶입니다.
3. 상태 관리 도구를 들입니다. 화면이 기억해야 하는 값을 한곳에 모아 다루는 방식인데, 여러 화면이 같은 값을 쓸 때부터 제값을 합니다.

세 번째는 새 부품을 만드는 자리입니다. 여러 화면에서 쓸 부품은 처음부터 값을 덜 받게 설계합니다. 사용자 정보를 받는 카드가 아니라 작성자 표시를 넘겨받는 카드로 만들면 다른 화면으로 옮길 때 그 구조를 따라갈 필요가 없습니다.

"이거 프롭 드릴링이 네 단계예요. 중간에서 안 쓰는데 다 받고 있습니다."

값을 쓰지 않는 단계가 여럿 끼어 있다는 지적입니다.

"한 줄 추가인데 파일이 여섯 개 바뀌었네요."

변경 범위가 기능 크기와 맞지 않는다는 뜻입니다.

"이건 합성으로 풀죠. 전역까지 올릴 값은 아닙니다."

구조를 다시 짜는 쪽으로 해결하고 도구를 들이지는 말자는 제안입니다.

태오가 앞의 프로필 사진 문제를 고친 방법은 구조를 다시 짜는 쪽이었습니다. 사용자 정보를 네 단계로 내려 보내는 대신 작성자 표시 부품을 목록 바깥에서 미리 만들어 카드에 자리만 내주게 바꿨습니다. 중간 세 단계에서 사용자 관련 프롭이 전부 사라졌습니다.

그다음에 프로필 사진을 추가할 때 고친 파일은 작성자 표시 부품 하나였습니다. 같은 요청에 걸린 시간이 이틀에서 30분으로 줄었고, 이 차이가 리팩터링을 설득하는 근거가 됐습니다.

프롭 드릴링을 늘 없애야 할 것으로 보는 경우가 가장 많습니다. 이름이 문제처럼 들리니 자연스러운 오해입니다. 하지만 한두 단계를 내려 보내는 것은 정상이고 오히려 읽기 쉽습니다. 값이 어디서 와서 어디로 가는지 코드에 그대로 적혀 있기 때문입니다. 이것을 없애려고 모든 값을 위로 올려 아무 데서나 꺼내 쓰게 만들면 반대쪽 문제가 생깁니다. 화면에 뜬 값이 어디서 바뀌었는지 찾을 수 없고, 부품 하나를 다른 프로젝트로 옮길 때 그 통로까지 함께 따라옵니다.

도구를 들이면 사라진다고 보는 것도 흔합니다. 상태 관리 도구를 넣으면 프롭을 넘길 일이 없어질 것처럼 보이지만, 도구는 여러 화면이 함께 쓰는 값만 맡습니다. 카드가 열렸는지, 입력칸에 무엇이 적혀 있는지 같은 값은 그 부품 안에 두는 것이 맞고, 그 값은 여전히 부모에서 자식으로 넘어갑니다. 도구를 들인 뒤에도 프롭을 넘기는 코드가 남아 있는 것이 정상입니다. 모든 값을 도구에 넣은 프로젝트는 화면 하나를 고칠 때마다 전체 값 목록을 열어 봐야 하는 상태가 됩니다.