common과 shared 사이

common과 shared.
조금 과거에는 common을 더 넓게 썼고,
최근의 흐름을 보자면 shared를 더 선호하는 것 같다.
그렇게 보고 싶어서(?) 그렇게 보이는 것일지도 모르겠지만,
공개된 코드나 포스팅을 보다 보면 아무래도 그런 쪽에 무게가 실리는 듯하다.

비슷한 뜻 같기도 했고,
실제로 큰 차이 없이 쓰이는 경우도 많았다.
그저 팀이나 프로젝트 취향의 문제라고 생각해도 이상하지 않았다.

그런데 구조를 정리하다 보면 이름은 생각보다 가볍게 끝나지 않았다.
무엇을 어떻게 부르느냐에 따라,
그 아래로 모이는 것들이 달라졌기 때문이다.

common이라는 이름은 편하다.
공통으로 쓰는 것들을 넣어두면 될 것 같고 설명도 어렵지 않다.
처음에는 실제로 그런 역할을 한다.
여러 화면에서 함께 쓰는 컴포넌트, 유틸, 타입, 상수 같은 것들이 자연스럽게 모인다.

문제는 구조가 조금만 자라기 시작할 때 생긴다.
진짜로 여러 곳에서 함께 쓰는 것들뿐 아니라,
어디에 둬야 할지 애매한 것들까지 common으로 흘러 들어온다.
아마 common이 자꾸 비대해지는 순간은 대개 비슷할 것이다.
결국 “아 몰라 common으로 넣어”가 작동하는 순간 말이다.
그러다 보면 common은 공통 영역이라기보다, 판단이 미뤄진 결과들이 쌓이는 곳에 가까워진다.

반면 shared라는 이름은 기준을 조금 더 분명하게 요구한다.
이것이 정말 여러 기능 사이에서 공유되는 것인지,
특정 기능에 더 가까운 것은 아닌지,
지금도 여전히 공통 자원으로 둘 이유가 있는지를 한 번 더 확인하게 만든다.

중요한 건 단어의 유행이 아니다.
common보다 shared가 더 세련돼 보여서가 아니라,
shared라는 이름이 구조에 질문을 남기기 때문이다.
왜 이것이 여기에 있어야 하는지,
정말 여러 기능이 함께 쓰는 자원인지,
아니면 아직 제자리를 찾지 못한 채 놓여 있는 것인지를 다시 보게 만든다.

개발에서 이름 하나로 의견 차이가 나고,
네이밍이 늘 어렵다고 느껴지는 것도 어쩌면 비슷한 이유 때문인지 모른다.
그것은 단순히 말을 고르는 일이 아니라,
무엇을 어떻게 분류하고 이해할지를 정하는 일이기 때문이다.
겉으로 보면 사소해 보여도,
막상 그 단어를 놓는 순간 머릿속에서 탁탁 걸리는 이유가 있다.

그래서 이런 문제를 단지 취향의 차이나 괜한 고집 정도로 다뤄버리는 시선을 만나면 조금 짜증이 난다. 내가 붙잡고 있는 것은 말의 표면이 아니라, 그 이름이 만들어내는 분류 기준과 구조의 결이기 때문이다.

common과 shared는 그중 하나의 예시일 뿐이다.
개발을 하다 보면 이렇게 비슷해 보여도 같은 이름으로 덮어두기에는 어딘가 자꾸 걸리는 것들이 많다. 그리고 아마 그래서, 어떤 것들은 충분히 다르게 불릴 필요도 있는 것 같다. 이름을 나눈다는 건 말을 늘리는 일이 아니라,
차이를 지워버리지 않겠다는 쪽에 더 가깝다.

한때는 이런 것들도 결국 하나로 통일해야 한다고 생각했던 적이 있다.
이름이 여러 개면 복잡해 보였고,
하나로 맞추는 쪽이 더 정리된 방식처럼 느껴졌다.
그런데 지금 돌아보면,
그것은 차이를 더 정확히 다루기보다 덜 생각하는 쪽에 가까웠는지도 모르겠다.
통일이 항상 정리는 아니었다.

결국 이름은 분류가 되고,
분류는 사고가 된다.
무엇을 어떻게 부르느냐에 따라 같은 범주로 묶이는 것들이 달라지고,
그 기준은 시간이 지나며 구조를 읽는 방식으로 굳어지기 때문이다.
그리고 더 무서운 건,
그렇게 굳어진 뒤에는 그 상태를 더 이상 누군가의 판단 결과로 보지 못하게 된다는 점이다. 원래 그런 구조였던 것처럼 받아들이기 시작하는 순간, 질문은 줄어들고 어색함은 익숙함으로 덮인다.

아토믹 디자인이 조직에서 자주 어긋나는 이유도 비슷한 데 있을지 모른다.
그 분류 체계가 약해서라기보다, 생각보다 다양한 실제 설계 판단을 충분히 받아내지 못하기 때문이다.

처음 접했을 때 아토믹은 꽤 그럴듯해 보인다.
이름도 직관적이고,
UI를 작은 단위에서 큰 단위로 쌓아 올린다는 설명도 이해하기 쉽다.
그런데도 아직까지 아토믹이 계속 회고의 대상이 되는 건,
그 체계가 늘 잘 맞아서라기보다 사람들이 그런 종류의 질서를 계속 원하기 때문인지도 모른다. 복잡한 것을 일단 설명 가능한 단계와 이름으로 정리하고 싶어하는 마음이 있으니까.

하지만 실제 개발 설계는 그보다 훨씬 다양한 축 위에서 움직인다.
기능 책임, 도메인 경계, 데이터 흐름, 소유권, 변경 단위 같은 것들이 함께 얽혀 들어오기 때문이다. 그래서 어떤 팀에서는 atoms와 molecules가 꽤 잘 맞아도, 다른 팀에서는 feature, domain, shared 같은 말이 훨씬 더 많은 것을 설명해주기도 한다.

돌이켜 보면 바뀐 것은 폴더명이 아니었다.
공통이라는 말을 얼마나 넓게 허용할 것인지,
공유된 자원이라는 기준을 어디까지 인정할 것인지,
구조를 어떤 경계 위에서 관리할 것인지에 대한 판단이 바뀐 것이었다.

그래서 common과 shared 사이는 단순한 용어 차이처럼 보이지만, 실제로는 구조를 다루는 태도의 차이에 가깝다. 이름은 사소해 보이지만, 그 사소한 선택이 분류 기준을 만들고, 그 기준은 결국 팀이 구조를 이해하고 다루는 방식까지 바꾼다.