Jekyll에서 Hugo로의 마이그레이션, Asciidoc 사용 시 성능 문제로 좌절
블로그 플랫폼을 Jekyll에서 Hugo로 마이그레이션하려 했으나, 최종 단계에서 실패함
Hugo는 Go 기반의 정적 사이트 생성기이며, Jekyll보다 빌드 속도(Build Speed)가 빠르다고 알려짐
Asciidoc 사용 시 Hugo의 성능 저하 문제 발생, 800개 이상의 Asciidoc 문서 처리 시 10분 이상 소요
Hugo의 Asciidoc 처리 방식과 관련한 성능 문제(Performance Issue)를 사전에 인지하지 못한 점이 실패의 원인으로 분석됨
Jekyll과 Hugo의 기술적 차이점
Jekyll은 루비(Ruby) 기반의 정적 사이트 생성기이며, 플러그인(Plugin)을 통해 기능을 확장할 수 있다. 반면, Hugo는 Go 언어로 개발되어 빠른 빌드 속도(Fast Build Speed)를 강점으로 내세운다.
콘텐츠 구조: Jekyll은 _posts, _pages, _data 폴더를 사용하며, Hugo는 content, static, layouts 폴더를 사용
플러그인 지원: Jekyll은 제너레이터(Generators), 컨버터(Converters), 커맨드(Commands) 등 다양한 플러그인을 지원
단점: Hugo는 제너레이터(Generators)에 상응하는 기능이 없어, 수동 페이지 생성 필요
결과적으로, Hugo는 빌드 속도(Build Speed) 측면에서 유리하지만, Jekyll에 비해 유연성이 부족할 수 있다.
마이그레이션 과정에서의 문제점
Jekyll에서 Hugo로의 마이그레이션 과정에서, 저자는 기존 콘텐츠를 Hugo에 맞게 변환하는 작업을 수행했다. 이 과정에서 Asciidoc 형식의 문서 처리 성능 문제에 직면했다.
Asciidoc 처리 방식: Hugo는 Asciidoc을 위해 외부 엔진인 asciidoctor를 사용
성능 저하: 800개 이상의 Asciidoc 문서를 처리하는 데 10분 이상 소요
원인 분석: Hugo가 Asciidoc을 외부 엔진으로 처리하면서 발생하는 오버헤드(Overhead)
결과적으로, Asciidoc 사용 시 Hugo의 성능 저하를 고려하지 않은 점이 마이그레이션 실패의 주요 원인으로 작용했다.
Hugo 빌드 속도 저하의 기술적 분석
Hugo는 일반적으로 Jekyll보다 빠른 빌드 속도를 제공하지만, Asciidoc 사용 시 성능 저하가 발생한다. 이는 Hugo가 Asciidoc 파일을 처리하는 방식과 관련이 있다.
외부 엔진 사용: Hugo는 Asciidoc 파일을 처리하기 위해 외부 엔진인 asciidoctor를 호출
I/O 병목: 다수의 Asciidoc 파일을 처리하는 과정에서 I/O 병목 현상 발생 가능성
병렬 처리 부재: asciidoctor가 병렬 처리를 지원하지 않을 경우, 처리 시간 증가
결론적으로, Asciidoc 파일의 양이 많을수록 Hugo의 빌드 속도 저하가 심화되며, 이는 Asciidoc 처리 방식의 기술적 한계(Technical Limitation)에서 기인한다.
마이그레이션 실패로부터 얻는 교훈
이번 마이그레이션 실패는 기술적 타당성 검토의 중요성을 강조한다. 저자는 LLM과의 대화를 통해 기술적 타당성을 검토했지만, Asciidoc 처리와 관련된 성능 문제를 간과했다.
사전 검토의 중요성: 마이그레이션 전에 기술적 제약 사항을 충분히 파악해야 함
문서화의 중요성: Hugo의 Asciidoc 처리 방식에 대한 명확한 정보 부재
트레이드오프(Trade-offs) 고려: 기술 선택 시 장단점을 정확히 파악하고, 트레이드오프(Trade-offs)를 고려해야 함
결과적으로, 기술적 타당성 검토를 소홀히 하면 시간 낭비와 프로젝트 실패로 이어질 수 있다.
