당신의 서버가 11줄짜리 코드에 목숨을 저당 잡힌 이유

금요일 오후 4시. 개발자들에게는 ‘배포 금지 시간’이라는 암묵적인 룰이 지배하는 시간대다. 하지만 꼭 그럴 때 사건은 터진다. 당신은 커피 한 잔을 들고 여유롭게 터미널 창을 바라본다. 그저 라이브러리 업데이트 로그나 확인하려던 참이었다. 그런데, 그 빨간색 텍스트가 뜬다.

Error: Cannot find module 'left-pad'

처음엔 오타인 줄 알았을 거다. 다시 엔터를 친다. 똑같다. 인터넷에 연결되지 않았나? 아니, 슬랙 알림은 잘만 울리고 있다. 등줄기에 식은땀이 흐르기 시작하는 건 바로 이 지점이다. 내가 짠 코드가 틀렸다면, 디버깅을 하면 된다. 로직이 꼬였다면 풀면 되고, 오타가 났다면 고치면 된다. 그건 ‘통제 가능한 불행’이다.

하지만 이번엔 다르다. 당신의 코드는 완벽하다. 문제는 당신이, 그리고 당신의 회사가, 나아가 전 세계의 내로라하는 IT 기업들이 믿고 의지했던 ‘기반’이 증발해버렸다는 사실이다. 누군가가 지구 반대편에서 Unpublish 버튼을 누른 순간, 당신이 가진 수십억짜리 시스템은 그저 껍데기가 되어버렸다.

이것이 현대 소프트웨어 개발이 마주한 가장 서늘한 공포다. 우리는 거인의 어깨 위에 서 있다고 자부했지만, 알고 보니 그 거인은 언제든 어깨를 털고 떠날 수 있는 변덕쟁이였으며, 우리는 그 위에서 젠가 놀이를 하고 있었던 셈이다. 내가 짠 코드 때문에 에러가 나면 억울하지나 않다. 내가 수정할 수 있으니까. 하지만 내 시스템의 생사여탈권이 얼굴도 모르는, 이름도 낯선 어느 개발자의 기분에 달려 있다는 것을 깨닫는 순간, 개발자는 기술적 무력감(Technical Impotence)을 느낀다.

의존성 지옥(Dependency Hell): 나의 운명을 남에게 맡긴 대가

소프트웨어 개발은 더 이상 ‘건축’이 아니다. 그것은 ‘쇼핑’에 가깝다. 우리는 기능을 구현하기 위해 코드를 짜는 시간보다, 그 기능을 이미 구현해 놓은 패키지를 검색하는 데 더 많은 시간을 쓴다. npm install. 이 명령어는 마법의 주문 같았다. 치기만 하면 인증 모듈이 뚝딱, 데이터 시각화 도구가 뚝딱 생겨났다. 효율성의 극치였다.

하지만 그 효율성의 청구서는 가장 잔인한 방식으로 날아온다. 당신이 설치한 그 패키지는 또 다른 패키지를 의존하고, 그 패키지는 또 다른 패키지를 의존한다. 거미줄처럼 얽힌 이 의존성 그래프(Dependency Graph)의 가장 밑바닥에, 고작 11줄짜리 코드가 깔려 있다. 문자열 왼쪽에 공백을 채워주는, 어느 컴퓨터과 1학년도 짤 수 있는 그 간단한 코드 말이다.

우리는 왜 그것을 직접 짜지 않았을까? 귀찮아서? 아니, ‘검증된 남의 코드’가 내가 지금 짠 코드보다 안전할 것이라는 맹목적인 믿음 때문이었다. 이것이 바로 ‘의존성 지옥’의 입구다. 당신은 편의를 얻는 대신 통제권을 지불했다. 당신의 애플리케이션은 당신의 것이 아니다. 그것은 수천 명의 낯선 타인들이 기여한 코드 조각들의 위태로운 집합체다.

그중 한 명이라도 마음이 바뀌거나, 계정이 해킹당하거나, 혹은 그저 실수로 파일을 지운다면? 당신의 운명은 그들의 손가락 끝에 달려 있다. 이것은 마치 내 집을 지을 때, 기둥은 A사에서 빌리고, 지붕은 B사에서 빌리고, 바닥은 C사에서 빌려온 것과 같다. 어느 날 C사가 “이제 바닥 렌탈 사업 안 합니다”라고 하며 바닥을 회수해 간다면, 당신은 공중에 뜬 채 추락할 수밖에 없다.

분산된 책임, 아무도 책임지지 않는 구조

오픈소스는 아름답다. 공유와 협력, 집단 지성. 실리콘밸리가 사랑하는 단어들이다. 하지만 이 아름다운 정원에는 치명적인 독초가 숨어 있다. 바로 ‘책임의 부재’다.

모든 오픈소스 라이선스에는 대문자로 박힌 면책 조항이 있다. “AS IS”. 변경 금지라는 말이 아니다. 있는 그대로 전달만을 허용한다는 의미다. 문제가 생겨도, 당신의 회사가 망해도, 원작자는 책임지지 않는다. Left-pad 사태 당시 개발자 Azer Koçulu를 비난한 사람들은 이 점을 간과했다. 그는 애초에 당신들의 비즈니스를 지탱해 줄 의무가 없었다. 그는 그저 취미로 코드를 올렸을 뿐이고, 그걸 가져다 쓴 건 당신들이다.

기업들은 수억 원의 연봉을 받는 엔지니어를 고용해 놓고, 정작 핵심 기능은 무료 오픈소스에 의존한다. 문제가 터지면? 누구를 고소할 것인가? 넷플릭스가 멈췄다고 해서 Azer에게 손해배상을 청구할 수 있을까? 불가능하다.

이것은 ‘분산된 책임’이 낳은 비극이다. 모두가 조금씩 기여하지만, 아무도 전체를 책임지지 않는다. 기업은 오픈소스 메인테이너가 영원히 그 자리에 있을 것이라 착각하고, 메인테이너는 기업들이 알아서 대비책을 세웠으려니 생각한다. 그 사이 공간에서 시스템은 붕괴한다. 당신의 상사가 “누구 책임이야?”라고 물었을 때, “인도에 있다는 방구석 개발자 아난드요”라고 답해야 하는 상황. 그 참담함은 겪어보지 않은 사람은 모른다.

"잘 돌아가니까 건드리지 마"가 낳은 기술 부채의 습격

개발팀에는 불문율이 있다. “If it works, don’t touch it.”(잘 돌아가면 건드리지 마라). 레거시 코드는 신성불가침의 영역이다. 하지만 이 격언이야말로 기술 부채를 키우는 가장 강력한 배양액이다.

우리는 외부 라이브러리를 가져와 쓰면서, 그 내부가 어떻게 생겼는지 들여다보지 않는다. 블랙박스다. 그냥 입력값을 넣으면 출력값이 나오니까 쓴다. 그렇게 몇 년이 지난다. 라이브러리는 업데이트되지 않고, 보안 취약점은 쌓여가고, 의존하는 하위 패키지들은 하나둘씩 사라지거나 변경된다.

Left-pad 사태는 갑작스러운 사고가 아니었다. 그것은 우리가 오랫동안 외면해 온 ‘게으름’이 한꺼번에 터져 나온 것이다. 11줄짜리 함수를 직접 작성해서 프로젝트 안에 넣어두는 ‘내재화(Internalization)’ 과정만 있었어도, 이런 일은 없었다. 하지만 우리는 그 10분의 수고를 아끼기 위해, 10년의 리스크를 짊어지는 선택을 했다.

이것은 금융 위기와 닮았다. 부실한 서브프라임 모기지(저질 코드)들이 겹겹이 쌓여 파생상품(거대 패키지)으로 둔갑하고, 그 위에서 투자은행(빅테크 기업)들이 춤을 췄다. 기초 자산이 흔들리자 모든 것이 무너졌다. 우리는 코드를 짠 게 아니라, 폭탄 돌리기를 하고 있었던 것이다.

인터넷이 끊기면 개발도 멈추는 시대의 무력감

과거의 개발자들은 플로피 디스크에 컴파일러를 담아 다녔다. 인터넷이 없어도, 무인도에 갇혀도 전력만 있다면 코딩을 할 수 있었다. 지금은 어떤가? npm install이 안 되면, pip install이 안 되면 프로젝트 세팅조차 불가능하다.

비행기에서 코딩을 해본 적이 있는가? 와이파이가 끊기는 순간, 당신의 화려한 IDE(통합 개발 환경)는 메모장으로 전락한다. 문서(Documentation)도 온라인에 있고, 라이브러리도 온라인에 있고, 심지어 내 코드 저장소도 온라인에 있다.

이 ‘연결에 대한 중독’은 개발자를 나약하게 만들었다. Left-pad 사태 때, 전 세계 개발자들은 패닉에 빠졌다. 해결책은 간단했다. 그냥 그 함수를 직접 짜서 넣으면 됐다. 하지만 다들 ‘패키지 매니저가 고쳐주기만을’ 기다렸다. 스스로 도구를 만들 줄 모르는 장인이 되어버린 것이다. 도구가 손에서 떨어지자, 그들은 아무것도 할 수 없는 무력한 존재가 되었다.

이것은 단순한 불편함의 문제가 아니다. 국가 간 인터넷 관문이 차단되거나, 특정 국가의 IP가 밴(Ban) 당하는 지정학적 위기 상황에서, 우리의 소프트웨어 산업은 그 즉시 올스톱될 수 있다는 경고다. 자립할 수 없는 기술은 기술이 아니라 ‘종속’이다.

벤더 락인(Vendor Lock-in)보다 무서운 커뮤니티 락인

우리는 오라클이나 마이크로소프트 같은 거대 기업에 종속되는 ‘벤더 락인’을 경계해 왔다. 그래서 오픈소스로 도망쳤다. 하지만 거기엔 더 무서운 ‘커뮤니티 락인’이 기다리고 있었다.

벤더는 돈을 받기 때문에 계약서라도 쓸 수 있다. 멱살을 잡을 대상이라도 명확하다. 하지만 커뮤니티는 실체가 없다. 유행이 지나면 개발자들은 썰물처럼 빠져나간다. 어제까지 핫했던 프레임워크가 오늘 아침엔 ‘관리되지 않음(Deprecated)’ 딱지가 붙는다.

Left-pad 사태는 그나마 양반이다. 악의적인 해커가 방치된 인기 라이브러리의 관리자 권한을 얻어 채굴 코드를 심거나, 백도어를 열어두는 ‘공급망 공격(Supply Chain Attack)’은 이제 일상이다. 무료라는 이유로 너도나도 검증되지 않은 코드를 대문에 걸어두었다. 그리고 그 대문의 열쇠는 닉네임만 아는 누군가가 쥐고 있다. 이것이 공포가 아니면 무엇인가?

진정한 기술적 자유는 '고립'을 감수하고서라도 핵심 코어를 내재화할 때 온다

이제 인정하자. 우리는 너무 멀리 왔다. 효율성이라는 미명 아래, 우리는 스스로 서는 법을 잊었다. 404 Not Found의 공포를 끝내는 확실한 방법은 단 하나다. 다시, 직접, 만드는 것이다.

모든 것을 처음부터 만들라는 이야기가 아니다. 하지만 적어도 당신의 서비스가 멈추면 회사가 망할 정도의 치명적인(Critical) 기능이라면, 그것은 남의 손에 의존해서는 안 된다. 외부 라이브러리를 쓰더라도 코드를 뜯어보고, 로컬에 복사하고, 우리만의 저장소에 백업해야 한다. 외부망이 끊겨도 우리 회사의 빌드 서버는 돌아가야 한다.

진정한 기술적 자유는 ‘편리한 의존’이 아니라 ‘불편한 통제’에서 온다. 비효율을 감수하라. 바퀴를 다시 발명하는 것을 두려워하지 마라. 당신이 직접 깎은 그 바퀴만이, 험한 도로에서 펑크가 났을 때 당신이 직접 고쳐서 다시 달릴 수 있는 유일한 바퀴가 될 것이다.

통제권을 되찾아라. 그것이 엔지니어로서 가져야 할 마지막 자존심이다.

3줄 요약

1. 고작 11줄짜리 코드 삭제로 전 세계 시스템이 마비된 것은 현대 개발 생태계가 맹목적인 '외부 의존성' 위에 세워진 사상누각임을 증명한다.
2. 개발자들은 효율성을 핑계로 코드의 소유권과 통제권을 포기했으며, 이로 인해 책임 소재가 불분명한 '디지털 소작농' 상태로 전락했다.
3. 진정한 기술적 생존과 자유를 위해서는 핵심 기능의 내재화와 '불편한 통제'를 감수하는 장인 정신의 회복이 시급하다.