제목
3개월 공들인 코드가 레거시가 되지 않으려면: 완벽주의를 버리고 '속도'로 살아남는 법
서론: 나는 왜 쓰레기 코드를 열심히 짰을까
솔직히 고백하겠습니다. 스타트업 재직 시절, 저는 '장인 정신'이라는 허울 좋은 핑계에 빠져 있었습니다. 서비스의 핵심 로직을 짤 때, 확장성을 고려한다며 온갖 디자인 패턴을 적용하고, 아직 들어오지도 않은 100만 트래픽을 걱정하며 오버 엔지니어링을 일삼았습니다. 결과는 어땠을까요?
3개월을 꼬박 밤새워 만든 기능은 비즈니스 요구사항이 바뀌면서 단 2주 만에 폐기되었습니다. 그때의 허탈함은 이루 말할 수 없었습니다. "코드는 자산이 아니라 부채"라는 말이 뼈저리게 다가왔던 순간입니다.
최근 흥미로운 뉴스를 하나 접했습니다. 천문학계의 거대한 프로젝트인 '에릭 & 웬디 슈미트 관측소 시스템(The Eric and Wendy Schmidt Observatory System)'에 관한 이야기입니다. 백엔드 개발자가 웬 별 관측 이야기냐고요? 이들이 프로젝트를 진행하는 방식이 우리 개발자들이 '생존'하기 위해 취해야 할 전략과 소름 돋게 닮아있기 때문입니다.
본론: 개발 기간을 수십 년에서 수년으로 단축하는 법
이 프로젝트의 핵심은 명확합니다. 기존 천문대가 구축에 '수십 년'이 걸렸다면, 이들은 그것을 '수년' 단위로 단축하겠다는 것입니다. 어떻게 가능했을까요? 바로 모듈식 설계(Modular Design)와 빠른 개발 주기(Rapid Development)입니다.
1. 거대한 모놀리식(Monolithic) 사고방식 버리기
우리는 흔히 시스템을 처음부터 완벽하게 설계하려 합니다. 하지만 슈미트 관측소 팀은 '위험을 감수하는 기술 혁신'을 통해 개발 주기를 극적으로 줄였습니다. Argus Array나 LFAST 같은 프로젝트들이 그 예시입니다.
개발 현장도 마찬가지입니다. 저는 과거에 데이터베이스 스키마 하나를 확정하는 데 일주일을 썼습니다. 완벽하다고 믿었지만, 결국 운영 단계에서 컬럼은 계속 추가되고 변경되었습니다. 처음부터 완벽한 RDB 설계를 고집하기보다, 유연한 NoSQL을 섞어 쓰거나 비즈니스 로직과 저장소를 느슨하게 결합하는 식의 접근이 훨씬 효율적이었습니다.
'완벽한 하나'를 만들기보다, '빠르게 교체 가능한 모듈'을 만드는 것. 이것이 변화가 극심한 IT 생태계에서 살아남는 첫 번째 열쇠입니다.
2. 나만의 코드가 아닌, 모두의 데이터로 (Open Data)
이 관측소 시스템의 또 다른 특징은 '개방형 데이터 및 소프트웨어'입니다. 전 세계 연구자들이 접근할 수 있도록 데이터를 열어둔다는 것이죠.
개발자로서 우리는 종종 '코드 소유권'에 집착합니다. 내가 짠 복잡한 로직을 나만 이해하고 있을 때, 묘한 안도감을 느끼기도 합니다. "내가 없으면 회사가 안 돌아가겠지?"라는 착각입니다. 하지만 이건 회사를 위협하는 리스크일 뿐만 아니라, 개발자 본인을 '레거시의 감옥'에 가두는 행위입니다.
대기업으로 이직 후 가장 크게 느낀 점은 문서화와 코드 리뷰의 중요성입니다. PR(Pull Request) 단계에서 동료들이 내 코드를 이해하지 못하면 머지(Merge)조차 되지 않습니다. AI 도구(Cursor나 Copilot)가 내 코드를 잘 읽을 수 있도록 주석을 달고, 문서를 남기는 행위가 결국 나를 자유롭게 만듭니다. 데이터와 로직을 투명하게 공개해야 병목 없이 프로젝트가 굴러갑니다.
3. 실패를 전제로 한 아키텍처
슈미트 사이언스 팀은 '규모의 경제'를 활용한다고 말합니다. 이는 값비싼 장비 하나에 의존하는 것이 아니라, 비용 효율적인 여러 장비를 연결해 리스크를 분산한다는 뜻으로 해석됩니다.
서버 아키텍처에서도 마찬가지입니다. 단일 장애 지점(SPOF)을 없애기 위해 우리는 MSA(Microservices Architecture)를 도입하거나, 서킷 브레이커(Circuit Breaker)를 심습니다. "절대 죽지 않는 서버"를 만드는 것은 불가능합니다. 대신 "죽어도 금방 살아나는", 혹은 "일부가 죽어도 전체는 돌아가는" 시스템을 만들어야 합니다.
결론: 우주를 보는 눈, 코드를 보는 눈
슈미트 관측소 시스템은 천문학의 '개발 속도'를 혁신했습니다. 우리 개발자들도 마찬가지여야 합니다. 1년 뒤에 완벽한 시스템을 내놓는 것보다, 당장 내일 돌아가는 MVP(Minimum Viable Product)를 내놓고 피드백을 받아 수정하는 것이 훨씬 가치 있습니다.
여러분이 지금 붙들고 있는 그 코드, 혹시 '완벽함'을 위해 릴리즈를 미루고 있지는 않나요? 과감하게 모듈화하고, 빠르게 배포하고, 동료들에게 그 내용을 공개하십시오.
별을 보는 기술이든, 서버를 짜는 기술이든, 결국 중요한 것은 '얼마나 빨리 가치를 전달하느냐'에 달려 있습니다. 부디 저처럼 3개월짜리 예쁜 쓰레기를 만드는 시행착오를 겪지 않으시길 바랍니다.
