당신은 추상화를 싫어하지 않는다
Source: Dev.to
주말이 시작되기까지 한 시간이 남았고, 마지막 티켓 하나만 처리하고 나면 어떤 액션‑플랜이든 즐길 수 있을 것 같습니다.
그때 눈에 띈 건 겉보기엔 무해한 작업: “사용자 이름 표시에서 중간 이니셜 추가”. 웃음이 나옵니다. 쉬운 일. 입가심. 승리의 한 바퀴.
티켓을 할당하고, New에서 Active로 바꾸고, IDE가 뜨는 동안 오늘 여기 있지 않겠다는 기분 좋은 공상에 빠집니다.
그런데 검색 결과가 한 줄씩 천천히 나타나기 시작하고, 그때 당신의 공상이 썩어갑니다:
IUserNameStrategy
UserNameContext
UserNameDisplayStrategyFactory
StandardUserNameDisplayStrategy
FormalUserNameDisplayStrategy
InformalUserNameDisplayStrategy
UserNameDisplayModule당신의 웃음은 이제 웃음과 울음 사이의 목이 메이는 소리로 변합니다.
“대체 무슨 일이 벌어지고 있는 거지?” 라며 맥박이 빨라지는 걸 느낍니다.
“누군가가 Refactoring.Guru를 성경처럼 읽고 코드베이스를 배운 모든 패턴으로 세례했거나, 혹은 Netflix‑인접 모놀리스를 탈출한 노련한 엔터프라이즈 베테랑이 TypeScript 실력을 끌어올리려는 중이겠지. 왜냐면 이런 사소한 기능에 이렇게 많은 리다이렉션을 만들 개발자는 없을 테니까… 맞죠?”
그 작고 나선형의 작업은 엔지니어링 서클 전반에 걸친 지속적인 논쟁의 완벽한 축소판입니다: 추상화가 도움이 되는 시점과 방해가 되는 시점은 언제인가?
최근에 Adam — The Developer가 쓴 유머러스한 글 You’re Not Building Netflix: Stop Coding Like You Are 를 우연히 발견했습니다. 여러 면에서 공감이 가지만, 그 비판은 결국 잘못된 대상을 겨냥하고 있습니다.
Adam은 서문에서 조롱하는 코드의 더 완전한 버전을 보여주고, 그 추상화 더미의 장황함과 난해함을 기업 패턴을 남용하는 사례의 출발점으로 삼아 비판합니다. 문제는 불만 자체가 틀린 것이 아니라, 잘못된 가해자를 지목했다는 점입니다. 즉, 숲을 보지 못하고 나무만 보는 실수를 저지른 것이죠.
왜 추상화가 중요한가
추상화는 근본적이며 필수적입니다. 소프트웨어의 기본 입자, 즉 원자와 분자를 이루는 쿼크와 렙톤과 같습니다. 오늘날 우리는 그 기본 요소들을 결합해 수백만 명이 사용하는 복합체와 장치를 만들죠. 추상화가 없었다면, 우리는 점점 늘어나는 전류 흐름 속에서 무기력하게 방황했을 것입니다. 특수하게 단조된 암석을 가공해 번개를 가두고 생각하게 만든 장인 마법사들처럼 말이죠.
하지만 그 힘을 어떻게 쓰느냐가 중요합니다. 화학이 좋은 비유가 됩니다. 식품 화학자들은 수십 년 동안 산업 부산물을 안정제, 질감제, 방부제 등으로 재활용하는 방법을 연구해 왔습니다. 그 작업 중 상당수는 인상적이고 혁신적이지만, 때로는 편리함을 가장한 창의적인 폐기물 처리에 불과합니다: 단기적으로는 멋진 해킹이지만 장기적으로는 지속적인 문제를 남깁니다.
개발자도 같은 함정에 빠질 수 있습니다. 새로운 기술이나 패턴, 혹은 영리한 트릭을 배우면 다음 해에는 그것을 가능한 모든 곳에 쏟아붓게 됩니다. 우리는 항상 더 나은 프로세스를 발견하는 것이 아니라, 같은 제품을 다시 포장하고 그것을 진보라고 부르는 경우가 많습니다. 이런 상황에서는 문제를 해결하는 것이 아니라, 미래 유지보수자가 우리 이름을 저주하게 만들 새로운 문제를 제조하는 겁니다.
개발자는 동시에 설계자, 엔지니어, 정비공, 운전자가 되어야 합니다. 특정 이슈를 해결하는 방법을 아는 것은 좋지만, 그 문제가 해결된 뒤에는 그 지식이 다음 문제를 푸는 빌딩 블록이 되어야 합니다. 같은 해결책을 매일 반복해서 유지한다면, 우리가 만든 것은 결코 해결책이 아니었습니다. “완료”라는 꼬리표가 붙은 서서히 타들어가는 유지보수 부담이었을 뿐이죠.
추상화는 복잡성을 줄이기 위해 존재할 뿐, 복잡성을 늘리기 위해 존재하는 것이 아닙니다. 목적은 인지 부하를 경감하고, 책상 위의 세부 사항을 들어올려 문제의 형태를 명확히 보는 데 있습니다. 1999년의 깜빡이는 녹색 CRT에서 튀어나온 듯한 장황하고 반복적인 코드가 기계어를 오래 바라보며 데이터 흐름에서 머리카락 색을 구분할 수 있는 저자에게는 인상적일지 몰라도, 팀 전체나 시스템에는 도움이 되지 않습니다. 추상화는 실제로 해결하고자 하는 문제와 일치할 때 비로소 제 역할을 합니다. 여기서 많은 개발자가 완전히 건너뛰는 부분이 바로 문제 자체에 맞춰 소프트웨어를 모델링하는 것입니다.
문제를 해결하기 전에 문제를 보기
시스템—어떤 시스템이든, 일시적인 스크립트라도—을 만들 때 가장 먼저 해야 할 일은 그 존재 이유를 이해하는 것입니다. 어떤 문제를 해결하려는 건가? 그 문제가 이전에 해결된 적이 있는가? 있다면, 현재 상황에서 기존 솔루션이 왜 충분하지 않은가? 이러한 차이를 이해하는 것이 모든 다른 작업이 놓일 기반이 됩니다.
저는 주택 소유자로서 이 교훈을 뼈저리게 배웠습니다. 우리 집은 청소년 시절에 말을 대면 저를 땅에 묶어두던 오래된 집이었습니다. 몇 년 전 거의 전면 리모델링을 했고, 딸이 태어난 뒤 새로운 문제들이 떠올랐습니다. 구조 엔지니어를 부르니, 기초 슬래브가 들썩이고 있었습니다. 조사 결과 원인으로 밝혀진 것은 원래의 주철 하수관이 위아래 모두 갈라져 압력 변화와 침하 문제를 일으킨 것이었습니다.
수리 작업은 결코 작지 않았습니다. 바닥을 모두 뜯어내고, 베이스보드를 교체하고, 석고보드를 수리하고, 파손된 관을 고치고, 전체 구역을 다시 칠하고, 트림을 다시 설치하고, 파일을 설치하고, 기초 폼을 주입하고, 인맥을 활용하고, 주말을 거의 다 잃었습니다. 그럼에도 불구하고 현재 시장 가격의 동등한 집을 사는 것보다 훨씬 저렴했습니다.
교훈: 거의 전부가 완전한 손실은 아닙니다. 구조물이 절망적으로 보여도, 파편 속에 거의 항상 회수할 가치가 있는 자산이 있습니다. 대안을 모두 소진했는지 확신이 서지 않는 한, 무턱대고 부수어서는 안 됩니다.
시스템을 완전히 버리고 새로 시작하기 전에, 현재 가지고 있는 것을 평가하세요. 무엇이 부서졌고, 무엇이 건전하며, 무엇이 단순히 보강이 필요한지 파악하십시오. 소프트웨어도 집과 마찬가지로 특정 부위가 특정 이유로 부패합니다. 그 이유를 이해하는 것이 개조와 재창조를 구분하는 열쇠입니다.
침대 옆 탁자 문제
같은 원리는 더 작은 규모에도 적용됩니다. 이미 완벽히 기능하는 집과 가구를 가지고 있는데도, 아직 없는 침대 옆 탁자를 원한다면 선택지는 명확합니다:
- 기존 침대 옆 탁자를 찾는다 – 오픈‑소스 베팅.
- 구입한다 – 예산과 제조업체가 정의한 품질에만 제한됨.
- 직접 만든다 – 기술, 상상력, 그리고 톱밥에 대한 인내심만이 한계.
목표가 개인적인 만족이나 실험이라면, 당연히 직접 만들면 됩니다. 하지만 목표가 수익을 창출하거나 제품을 지원하는 것이라면, 이제 당신은 단순한 취미 목공이 아니라 기업 소프트웨어 영역에 들어선 것입니다.
기업 소프트웨어를 구축할 때는 시스템을 위에서 아래로 바라보면서, 동시에 아래에서 위로 설계해야 합니다. 이러한 전체적인 시각은 추상화가 도움이 되는 렌즈인지, 불필요한 간접 계층인지 판단하는 데 큰 도움이 됩니다.