개발자로 일하며 가장 뼈저리게 느낀 진리 중 하나는 '코드는 부채(Liability)'라는 사실입니다. 아무리 화려한 기능을 구현해도, 유지보수 비용이 높다면 그건 자산이 아니라 빚일 뿐이죠. 10년 전, 저는 이 단순한 사실을 간과한 대가를 혹독하게 치러야 했습니다.
당시 저는 한 커머스 스타트업의 초기 멤버로 백엔드와 어드민 페이지를 담당하고 있었습니다. 마케팅 팀의 요구사항은 단순했습니다. "상품 상세 페이지를 블로그처럼 예쁘게 꾸미고 싶어요. 워드(Word)에서 복사해서 붙여넣기만 하면 그대로 나오게 해주세요."
저는 그 요구가 지옥으로 가는 급행열차 티켓인 줄도 모르고 덥석 받아들였습니다. 비즈니스 로직에 대한 깊은 고민 없이, 당시 유행하던 무거운 자바스크립트 기반의 위지윅(WYSIWYG) 에디터를 덜컥 도입했죠. 화면상으로는 그럴싸했습니다. 마케팅 팀은 환호했고, 저는 제 기술적 선택이 옳았다고 착각했습니다.
재앙은 3개월 뒤에 터졌습니다.
모바일 앱 개편을 위해 API를 재설계하던 중, DB에 저장된 상품 상세 데이터를 열어본 저는 경악을 금치 못했습니다. 데이터베이스의 content 컬럼은 그야말로 쓰레기장이 되어 있었습니다. 마케팅 담당자가 MS Word에서 무심코 복사해 온 텍스트에는 MsoNormal 같은 정체불명의 클래스명과 수천 줄의 인라인 스타일(Inline Style), 닫히지 않은 span 태그들이 뒤엉켜 있었습니다.
이른바 '태그 수프(Tag Soup)' 상태였습니다. 이 데이터는 웹에서는 간신히 보였지만, 모바일 앱에서는 레이아웃을 완전히 깨뜨렸습니다. 더 심각한 건 보안이었습니다. 검증되지 않은 HTML 태그들이 섞여 들어오면서 XSS(교차 사이트 스크립트) 공격 취약점에 그대로 노출된 상태였죠. 5만 건이 넘는 상품 데이터를 일일이 파싱해서 정화(Sanitize)해야 하는 상황. 저는 꼬박 2주 동안 밤을 새우며 정규표현식과 씨름해야 했습니다. 화려한 기능 뒤에 숨겨진 기술 부채가 원금 상환을 요구하며 제 목을 조여온 순간이었습니다.
그 처절한 실패 이후, 제가 정착한 해답은 놀랍게도 가장 원시적인 기술이었습니다. 바로 마크다운(Markdown)입니다.
최근 아닐 대시(Anil Dash)가 쓴 글을 읽으며 저는 그때의 기억을 다시 떠올렸습니다. 마크다운은 2002년, 존 그루버(John Gruber)라는 한 괴짜가 만들었습니다. 그는 애플(Apple)이 망해가던 시절, 오직 텍스트만으로 웹 콘텐츠를 생산하기 위해 이 형식을 고안했습니다. 당시 블로깅 툴들은 HTML을 직접 다루거나, 저처럼 끔찍한 에디터를 사용해야만 했으니까요.
마크다운의 철학은 명확합니다. "쓰는 사람에게는 읽기 쉽고, 기계에게는 변환하기 쉬워야 한다."
이 단순한 원칙이 마크다운을 전 세계 표준으로 만들었습니다. 개발자들의 README.md 문서는 물론이고, 노션(Notion), 옵시디언(Obsidian), 슬랙(Slack), 디스코드(Discord)까지. 심지어 지금 우리가 열광하는 ChatGPT나 Claude 같은 거대언어모델(LLM)이 뱉어내는 출력값의 기본 형식도 마크다운입니다.
왜일까요? 마크다운은 '표현'과 '내용'을 분리하기 때문입니다.
제가 10년 전 저질렀던 실수는 데이터(Content)와 디자인(Presentation)을 한 덩어리로 DB에 구겨 넣은 것이었습니다. 반면 마크다운은 순수한 텍스트 데이터만을 저장합니다. 디자인은 렌더링하는 시점에 CSS로 입히면 그만입니다. 이렇게 저장된 데이터는 10년 뒤, 20년 뒤 어떤 새로운 플랫폼이 등장해도 100% 호환됩니다. 특정 벤더나 에디터 라이브러리에 종속되지 않는, 진정한 의미의 '자산'이 되는 것입니다.
요즘 주니어 개발자분들을 보면 화려한 프론트엔드 프레임워크나 최신 에디터 라이브러리 도입에만 열을 올리는 경우가 많습니다. 하지만 저는 묻고 싶습니다. 당신이 저장하고 있는 그 데이터, 정말 안전합니까? 에디터 라이브러리 버전이 바뀌거나 서비스가 종료되어도, 당신의 데이터는 살아남을 수 있습니까?
기술은 변하지만, 텍스트는 영원합니다. 우리는 종종 복잡한 문제를 해결하기 위해 더 복잡한 도구를 도입하려 합니다. 하지만 역사가 증명하듯, 가장 강력한 솔루션은 언제나 가장 단순한 형태를 띠고 있습니다.
오늘 작성한 당신의 코드가, 그리고 설계한 데이터 구조가 누군가에게 갚아야 할 부채가 되지 않기를 바랍니다. 화려한 겉모습보다는 본질인 '데이터'를 지키는 것, 그것이 엔지니어의 진짜 실력일 테니까요.
