로스트 테크놀로지를 아카이빙 하는 의미

문명의 방주가 필요한 이유

앞서 쓴 로스트 테크놀로지 관련 글들에서 사실 F-1 엔진이 로스트 테크놀로지가 된 것은 그것의 상위호환 엔진 기술이 없어서라기보다는, 그것과 관련된 인력과 암묵지가 사라져서 실전된 것임을 강조했다. 여기서 오해를 하지 말아야 하는 부분은 F-1 엔진이 사장되는 과정이 그저 경제적 논리에 의해서만 이루어진 것이라 단정하는 것이다. 지금은 당연하게 생각하는 산업과 기술이라고 해도, 꾸준한 관심과 관리가 없다면 결국 사라지게 된다.

예전에 박사 과정 시절, 나는 몇 천 줄짜리 코드를 작성하며 특정한 나노입자 콜로이드 시스템의 동역학을 모델링하는 연구를 한 적이 있다. 한꺼번에 몇 천 줄을 작성한 것은 아니고, main은 2-3천 줄, 나머지 sub function들이 몇 백 줄씩 달려있는 구조였다. 나는 코딩을 할 때 최대한 자세하게 주석을 달아두려 애쓰는데, 나 자신의 장기 기억을 못 믿기 때문이기도 하다. 몇 개월 후에 그 코드를 다시 보면 도대체 내가 왜 이러한 루틴을 만들었는지, 변수 명을 왜 이렇게 정했는지, 왜 두 함수를 연결하는 것을 당연하게 만들어 놨는지 나 스스로도 이해가 되지 않는 경우가 꽤 있었기 때문이다. 그렇게 자세하게 주석을 달아두며 코드를 작성해 놨어도, 몇 년 후 비슷한 분야의 연구를 위해 예전의 코드를 들여다봤는데 제대로 파악되지 않은 line이 몇 개나 있었다. 겨우겨우 기억을 더듬어서 복구하긴 했지만, 분명 만들어졌어야 할 그림이 제대로 안 나오는 것을 보며 안타깝고 후회되는 감정이 있었다. 그 안타까움은 단순히 코드에 주석만 자세히 달아둔다고 능사는 아니라는 것이었다. 언제든 다시 활용하기 위해서는 가급적 주석과 함께 날짜와 프로젝트명이 정확하게 명시된 연구노트를 따로 관리할 필요가 있다는 생각을 했다. 그 이후에는 다양한 코딩을 하고 프로그램을 개발할 때면 가급적 기술 메모와 연구 노트를 만들어 두었고, 2중 3중으로 클라우드와 서버에 자료를 백업해 놓기도 했다. 그렇게 해도 결국 나중에 필요해서 다시 찾으려 하면 못 찾는 경우도 생겼고, 재현된 코드는 생각대로 돌아가지 않는 경우도 생겼다.

로스트 테크놀로지는 이러한 케이스들이 겹치면서 발생한다고 생각한다. 만약 이러한 연구를 나 혼자 한 것이 아니라 여러 명이 팀으로 같이 했고 팀 단위에서 코드 리뷰를 하고 또 문서를 남겨 두고, 다양한 언어로 포팅해놓고, 웹에서든 서버에서든 늘 돌아가게 dependency를 관리해 두었다면 재현이 안 되거나 실종되는 케이스는 크게 줄어들었을 것이다. 물론 그 팀 자체가 없어지고 팀이 관리하던 리소스가 사라진다면 말짱 헛것이겠지만, 어쨌든 개인 단위에서 관리할 때보다는 훨씬 secure 할 것이라 생각한다. 어떤 기술이 중요하고, 언제든 다시 쓰일 가능성이 있다면, 실전되지 않도록 끊임없이 관리하고 감독하는 것은 정말 중요하다. 그것은 더 상위호환 기술이 있다든지, 돈으로 해결할 수 있다든지 하는 단순하고 근시안적인 생각과는 전혀 다른 이야기다. 작은 종이 쪼가리 하나, 하드 구석 어딘가에 처박혀 있는 메모 하나가 그 실전 기술의 핵심을 잇는 요소가 될 수도 있다.

F-1 엔진 기술이든, 컴퓨터 프로그램이든, 금속 소재 기술이든, '당연하게' 복기되거나 재현되거나 대체되는 것은 없다. 철저하게 기술적 문서로 아카이빙이 되어 있어야 하고, 주기적인 테스트를 했어야 하고, 현실에서 활용할 수 있는 주변 기술이 뒷받침되어야 한다. 그러려면 그 분야의 백그라운드 산업이 살아 있어야 하고, 그 산업에는 전문 인력들이 종사하고 있어야 하며, 그 인력들이 일할 수 있는 환경이 유지되어야 한다. 내가 말하고 싶었던 부분은 바로 그런 것이다.