생각 조각 1~3. 기술부채, 컨텍스트, 쿼리스트링

기술 부채는 빠르게 기능을 구현해야 한다는 압박감, 의사 결정 변경, 데이터 구조 변경 그리고 시간이 흐름에 따라 자연스레 발생하기 때문에 기술 부채 없이 서비스 한다는 것은 사실상 불가능 하다고 생각해요.

기술 부채를 어떻게 다루고 해소해야 하는 지에 대해 많은 글들과 경험이 공개되어있는데, 이 또한 '기술 부채를 해소해야 한다' 라는 전제 하에 '해소를 위한 리소스 사용을 보장' 받거나, '기술 부채를 최대한 천천히 쌓아야 한다'라는 전제 하에 '개발 공수가 지연되는 것을 이해'받아야 가능한 내용들이 많았어요. 그렇다는 것은 팀 단위나 조직 단위, 혹은 의사결정권자에 대한 설득과 합의가 필요하다는 뜻이겠죠.

기술 부채가 누적되어간다면, 정작 중요할 때 가지 못하게 만들 수 있습니다. 신규 사업, 신규 플랫폼 출시, 신규 기능... 살아남고 커지기 위해 끊임없이 새로운 무언가를 발굴하는데, 정작 기술 부채로 발목이 잡혀 좋은 타이밍을 놓치게 된다면 회사의 성장 곡선도 수그러들 수 있습니다. 늘어가는 운영 이슈와 유지보수성 업무로 대부분의 개발 리소스가 사용된다면, 어떻게 새로운 것을 만들어 낼 수 있을까요?

개발자는 혁신과 개선, 자동화를 좋아하는데 기술 부채는 개발자의 사기를 저하시키기도합니다. 이는 특히 '내가 작성한 코드'나 '내가 만든 기능'과 '나'를 동일시 할수록 심해질 수 있습니다. 최근 동료 개발자 분과의 대화 중 '새로 구축하는 프로젝트는 개발자한테 복지다.'라는 이야기를 했는데, 그 복지를 경험해 본 사람으로써 공감이 되는 말입니다.

하나만 포기하면 되겠지, 라는 생각에 하나를 포기하면 다음에 또 하나를 포기하게 되고, 그렇게 포기할 것들만 늘어갑니다. 사방팔방에서 다양한 이유로 어려움이 생기겠지만, 마케팅이 숫자를 신경쓰고, 디자인이 UX를 신경쓰고, PM이 일정을 신경쓰는 것처럼 개발자라면 기술 부채에 대한 신경을 써야하지 않을까 생각해봐요.

개인적으로는 적당한 기술 부채는 레버리지 투자처럼 최대한의 효율로 성장할 수 있는 방법이기 때문에, 기술 부채가 무조건 나쁘다고 생각하지 않고 상황에 맞는 판단이 중요하다고 생각해요. 그렇기 때문에 더 어려운 것이지만, 그렇다고 빚이 많은 걸 좋아하는 사람은 없을 거라고 생각해요.

얼마 전 주말, 라디오를 듣는데 넌센스 퀴즈를 보내 준 청취자 분들 중 웃음 도둑으로 선정되신 분들께 선물을 드리는 콘텐츠를 진행하고 있었습니다. 어떤 사람들이 웃음 도둑일까요?

DJ의 이야기를 듣다 웃음 도둑에는 두 종류가 있었다는 것을 알게 되었습니다.

1. 웃음을 만드는 웃음 도둑

2. 웃음을 없애는 웃음 도둑

어떤 뉘앙스인지 느낌이 오시나요? 상대를 웃겨서 웃음을 훔치는 도둑과 상대로부터 웃음의 존재를 훔쳐서 웃지 못하게 만드는 도둑인 것입니다.

서비스를 개발하며 의사소통을 하다보면 같은 단어에 대해 서로 다른 컨텍스트로 사용할 때가 있습니다. 이 간극이 처음에는 미미하지만 프로젝트가 진행될수록 의사소통 비용을 증가시키는 주범이 됩니다.

특히 중의적인 의미가 담긴 단어나 특정 도메인에서 사용되는 단어일 수록 이런 경향은 더욱 커집니다. 개발자들에게도 도메인에 대한 경험을 요구하는 것은, 이런 과정의 커뮤니케이션 비용을 아낄 수 있는 것도 한 몫 할 것입니다.

개인적으로 저는 논의하는 과정에서 상대의 말을 다시금 정리하며 되묻거나, 제가 하는 말의 뜻을 같이 설명하는 방식으로 컨텍스트를 맞추기 위해 노력하는 편입니다. 어떨 때는 특정 개념에 대해서 같이 정의를 내리기 위해 노력하기도 합니다.

내가 확실히 아는 단어라도 상대와 다른 의미로 이해할 수 있으므로, 프로젝트의 초기에는 컨텍스트를 맞추기 위해 비용을 쓰는 것을 아까워하거나 귀찮아하지 않아야 합니다. 이는 분명 나중의 많은 비용을 아껴줄 수 있습니다.

최근 신규 프로젝트를 진행하며 이에 대해 더 여실히 느끼고 있는데, 신경을 써도 부족할 때가 많네요.

P.S. 제가 들은 라디오는 MBC FM4U '4시엔 윤도현입니다'에 게스트 DJ로 존박님이 오셨을 때입니다.

검색 기능에는 타입, 기간, 키워드 등... 서비스에 따라 많은 필터 기능이 필요할 수 있습니다. 혹시 이 필터 상태를 저장하기 위해 useState를 사용하고 계신가요? 필터 별 useState를 선언하거나, 객체를 만들어서 하나의 useState로 관리할 수도 있겠죠. 어쩌면 hook을 활용해서 재사용하고 있을 수도 있습니다. 하지만 많은 상황에서 그건 필요하지 않을 수 있습니다.

URL QueryString을 상태 저장소로 이용하면 됩니다. URL QueryString을 쉽게 제어할 수 있는 hook을 만들고, 필터 상태를 설정하는 컴포넌트에 key값을 전달합니다. 이 컴포넌트는 전달받은 key값을 사용해서 QeuryString의 값을 사용하고 제어하며, 리렌더링 될 것입니다.

이렇게 구현된 컴포넌트는 URL과 통신하는 독립적인 단위가 되어 쉽게 재사용될 수 있습니다. 특히 CMS나 많은 데이터를 조회하고 다루는 서비스에서 빠르게 재사용될 수 있다는 것은 매우 큰 장점입니다.

URL을 상태 저장소로 사용함으로써 특정 필터가 설정된 조회 페이지에 바로 접근할 수도 있습니다. 사용자는 북마크 등을 통해 활용할 수 있으며, 서비스 내에서도 유연하게 리다이렉트 시킬 수 있게 됩니다. SEO적으로는 Canonical URL을 통해 대표 URL을 지정해 줄 수 있습니다.

프런트엔드 개발자에게는 URL이라는 저장소가 있습니다. 컴포넌트 간 상태를 효율적으로 관리하기 위해 전역 Store를 사용하는 것처럼 이 부분도 효과적으로 사용될 수 있습니다. 사용자에게 숨겨져야 하는 데이터가 아니라면 말입니다.

이는 요즘 렌더링이 효율적으로 발전해서 과거처럼 페이지가 바뀔 때마다 새로 모든 데이터를 불러오지 않기 때문에 가능해졌다고 생각하며, 필요하다면 History Stack을 관리하는 방안에 대해서 생각하는 것도 좋을 것 같습니다.