InfoGrab DocsInfoGrab Docs

프론트엔드 목표

요약

이 섹션은 GitLab 프론트엔드의 이상적인 상태와 향후 몇 년간의 방향성을 정의합니다. 최신 버전의 Vue를 유지하면 GitLab 프론트엔드가 가장 효율적이고 안전하며 기능이 풍부한 프레임워크 기능을 활용할 수 있습니다.

이 섹션은 GitLab 프론트엔드의 이상적인 상태와 향후 몇 년간의 방향성을 정의합니다. 이 문서는 기술과 팀 역학이 진화함에 따라 지속적으로 업데이트됩니다.

기술#

Vue@latest#

최신 버전의 Vue를 유지하면 GitLab 프론트엔드가 가장 효율적이고 안전하며 기능이 풍부한 프레임워크 기능을 활용할 수 있습니다. 최신 Vue(3)는 향상된 성능과 보다 직관적인 API를 제공하며, 이를 통해 개발자 경험과 애플리케이션 성능을 전반적으로 향상시킵니다.

현재 상태

  • 2025년 11월 기준: GitLab 모노리스는 Vue 2.x를 사용하고 있으며, Vue 3.x를 사용하는 frontend islands를 병행하고 있습니다.

  • 진행 상황: 에픽 참조

담당 팀

마일스톤 및 일정

최신 일정은 에픽을 참조하세요.

과제 및 의존성

  • 마이그레이션 작업에 전담 엔지니어를 투입할 시간 확보

성공 지표

  • 모노리스에서 @vue/compat 사용

상태 관리#

전역 상태 관리가 필요한 경우, Vuex 또는 다른 상태 관리 라이브러리 대신 Apollo를 사용해야 합니다. 마이그레이션을 계획하는 이유와 방법에 대한 자세한 내용은 Vuex에서 마이그레이션을 참조하세요.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

기본값으로서의 HAML#

적절한 경우 Vue 대신 HAML을 계속 사용합니다. Vue를 선택해야 할 시점을 결정하는 방법은 Vue 애플리케이션을 추가하는 경우를 참조하세요.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

jQuery 완전 제거#

2019년에 jQuery를 더 이상 사용하지 않기로 했지만, 완전 제거를 우선순위로 두지 않았습니다. 이 목표는 GitLab 기본 코드베이스에서 jQuery에 대한 모든 참조를 제거하는 것입니다.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

의존성 관리#

최신 주요 버전의 Vue를 유지하는 것과 유사하게, 업그레이드하지 않는 것이 업그레이드의 이점을 능가하지 않는 한 의존성을 최신 버전에 최대한 가깝게 유지해야 합니다. 최소한, 업그레이드 여부를 평가하기 위해 연간 의존성 감사를 실시합니다.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

모범 사례#

확장성 및 성능#

클러스터 SPA#

현재 GitLab은 대부분 Rails 아키텍처와 Rails 라우팅을 따르므로, 경로를 변경할 때마다 페이지가 다시 로드됩니다. 이로 인해 다음 작업들을 수행해야 하기 때문에 로딩 시간이 길어집니다:

  • HAML 페이지 렌더링

  • Vue 애플리케이션이 있는 경우 마운트

  • 이러한 애플리케이션을 위한 데이터 페치

이상적으로는 사용자가 이 긴 프로세스를 거치는 횟수를 줄여야 합니다. 이는 GitLab을 단일 페이지 애플리케이션으로 전환하면 가능하지만, 이는 상당한 리팩토링이 필요하며 단기/중기적으로 달성 가능한 목표가 아닙니다.

현실적인 목표는 사용자 플로를 구성하는 페이지의 클러스터를 정의하고, 이 클러스터를 Rails 라우팅에서 클라이언트 사이드 라우팅을 가진 단일 페이지 애플리케이션으로 전환하는 다중 SPA 경험으로 이동하는 것입니다. 이 방식을 통해 HAML에서 모든 관련 컨텍스트를 한 번만 로드하고, 경로에 따라 API에서 추가 데이터를 페치할 수 있습니다. 클러스터의 예시로는 다음 페이지들이 있을 수 있습니다:

  • 이슈 페이지

  • 이슈 보드 페이지

  • 이슈 상세 페이지

  • 새 이슈 페이지

  • 이슈 편집

이 모든 페이지는 동일한 컨텍스트(프로젝트 경로, 현재 사용자 등)를 가지므로, 이슈별 매개변수(이슈 iid)로 더 많은 데이터를 쉽게 페치하고 결과를 클라이언트에 저장할 수 있습니다(동일한 이슈를 다시 열면 추가 API 호출이 필요하지 않습니다). 이를 통해 이슈 탐색 시 부드러운 사용자 경험을 제공합니다.

클러스터 간 탐색의 경우 Rails 라우팅에 계속 의존할 수 있습니다. 이러한 경우는 클러스터 내 탐색보다 상대적으로 드물 것입니다.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

재사용 가능한 컴포넌트#

현재 일반적으로 재사용 가능한 컴포넌트를 두 곳에 보관하고 있습니다:

  • GitLab UI

  • vue_shared 폴더

GitLab UI는 문서화가 잘 되어 있고 컴포넌트가 Vue 애플리케이션 어디서든 재사용할 수 있을 만큼 추상적인 반면, vue_shared 컴포넌트는 다소 혼란스럽고, 특정 컨텍스트에서만 사용할 수 있는 경우가 많으며(예: 기존 Vuex 스토어에 바인딩되어야 하는 경우), 중복이 존재합니다(노트용 컴포넌트가 여러 개 있습니다).

vue_shared를 감사하고, GitLab UI로 이전 가능한 것과 불가능한 것을 파악하며, 기존 컴포넌트를 리팩토링하여 중복을 제거하고 재사용성을 높여야 합니다. 이상적인 결과는 애플리케이션별 컴포넌트를 애플리케이션 폴더로 이동하고, 재사용 가능한 "스마트" 컴포넌트를 공유 폴더/라이브러리에 유지하여, 모든 재사용 가능한 기능이 단 하나의 구현만 갖도록 하는 것입니다.

현재 개발 중입니다. vue_shared와 같은 최상위 폴더에 캡슐화를 강제하는 방법에 대한 업데이트는 GitLab Modular Monolith for FE를 팔로우하세요.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

PostCSS로 마이그레이션#

SASS 컴파일은 전체 프론트엔드 컴파일 시간의 거의 절반을 차지합니다. 이로 인해 파이프라인이 불필요하게 오래 실행됩니다. PostCSS로 마이그레이션하면 컴파일 시간을 크게 향상시킬 수 있습니다.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

협업 및 도구#

시각적 테스팅#

시각적 테스팅 추가 과정 초기 단계에 있지만, 프레임워크를 확립해야 합니다. 구현이 결정되면, 이 문서를 업데이트하여 세부 사항을 포함할 예정입니다.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

접근성 테스팅#

2023년부터 접근성 테스팅 도구를 결정하기 위해 노력해 왔습니다. 접근성 준수를 보장하기 위한 axe-core 기반의 포괄적이고 다단계 접근 방식을 선택했습니다. 각 도구는 개발 워크플로에서 특정 목적을 수행하며, 함께 작동하여 개발부터 프로덕션까지 완전한 커버리지를 제공합니다.

현재 상태

  • 2025년 11월 기준: 진행 중 (~90%)

  • 진행 상황: 린팅, Storybook 컴포넌트 테스트, Sitespeed를 이용한 모니터링을 구현했습니다. 현재 피처 테스트를 통한 사용자 여정 테스팅을 진행 중입니다.

담당 팀

마일스톤 및 일정

  • GitLab UI 컴포넌트 스펙에 axe-core 검사 추가 - 2025년 5월 완료

  • 평가 계획/프로세스 및 도구를 포함한 접근성 위반 해결 계획 수립 및 구현 - 90% 완료, FY26 말까지 완료 예정

  • 공유 뷰 컴포넌트에 접근성 검사 포함 - 70% 완료, FY26 말까지 완료 예정

  • 피처 스펙의 주요 사용자 여정에 axe-core 검사 추가 - 20% 완료, Q1FY27에 완료 예정

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

프론트엔드 목표

GitLab v19.1
원문 보기
요약

이 섹션은 GitLab 프론트엔드의 이상적인 상태와 향후 몇 년간의 방향성을 정의합니다. 최신 버전의 Vue를 유지하면 GitLab 프론트엔드가 가장 효율적이고 안전하며 기능이 풍부한 프레임워크 기능을 활용할 수 있습니다.

이 섹션은 GitLab 프론트엔드의 이상적인 상태와 향후 몇 년간의 방향성을 정의합니다. 이 문서는 기술과 팀 역학이 진화함에 따라 지속적으로 업데이트됩니다.

기술#

Vue@latest#

최신 버전의 Vue를 유지하면 GitLab 프론트엔드가 가장 효율적이고 안전하며 기능이 풍부한 프레임워크 기능을 활용할 수 있습니다. 최신 Vue(3)는 향상된 성능과 보다 직관적인 API를 제공하며, 이를 통해 개발자 경험과 애플리케이션 성능을 전반적으로 향상시킵니다.

현재 상태

  • 2025년 11월 기준: GitLab 모노리스는 Vue 2.x를 사용하고 있으며, Vue 3.x를 사용하는 frontend islands를 병행하고 있습니다.

  • 진행 상황: 에픽 참조

담당 팀

마일스톤 및 일정

최신 일정은 에픽을 참조하세요.

과제 및 의존성

  • 마이그레이션 작업에 전담 엔지니어를 투입할 시간 확보

성공 지표

  • 모노리스에서 @vue/compat 사용

상태 관리#

전역 상태 관리가 필요한 경우, Vuex 또는 다른 상태 관리 라이브러리 대신 Apollo를 사용해야 합니다. 마이그레이션을 계획하는 이유와 방법에 대한 자세한 내용은 Vuex에서 마이그레이션을 참조하세요.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

기본값으로서의 HAML#

적절한 경우 Vue 대신 HAML을 계속 사용합니다. Vue를 선택해야 할 시점을 결정하는 방법은 Vue 애플리케이션을 추가하는 경우를 참조하세요.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

jQuery 완전 제거#

2019년에 jQuery를 더 이상 사용하지 않기로 했지만, 완전 제거를 우선순위로 두지 않았습니다. 이 목표는 GitLab 기본 코드베이스에서 jQuery에 대한 모든 참조를 제거하는 것입니다.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

의존성 관리#

최신 주요 버전의 Vue를 유지하는 것과 유사하게, 업그레이드하지 않는 것이 업그레이드의 이점을 능가하지 않는 한 의존성을 최신 버전에 최대한 가깝게 유지해야 합니다. 최소한, 업그레이드 여부를 평가하기 위해 연간 의존성 감사를 실시합니다.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

모범 사례#

확장성 및 성능#

클러스터 SPA#

현재 GitLab은 대부분 Rails 아키텍처와 Rails 라우팅을 따르므로, 경로를 변경할 때마다 페이지가 다시 로드됩니다. 이로 인해 다음 작업들을 수행해야 하기 때문에 로딩 시간이 길어집니다:

  • HAML 페이지 렌더링

  • Vue 애플리케이션이 있는 경우 마운트

  • 이러한 애플리케이션을 위한 데이터 페치

이상적으로는 사용자가 이 긴 프로세스를 거치는 횟수를 줄여야 합니다. 이는 GitLab을 단일 페이지 애플리케이션으로 전환하면 가능하지만, 이는 상당한 리팩토링이 필요하며 단기/중기적으로 달성 가능한 목표가 아닙니다.

현실적인 목표는 사용자 플로를 구성하는 페이지의 클러스터를 정의하고, 이 클러스터를 Rails 라우팅에서 클라이언트 사이드 라우팅을 가진 단일 페이지 애플리케이션으로 전환하는 다중 SPA 경험으로 이동하는 것입니다. 이 방식을 통해 HAML에서 모든 관련 컨텍스트를 한 번만 로드하고, 경로에 따라 API에서 추가 데이터를 페치할 수 있습니다. 클러스터의 예시로는 다음 페이지들이 있을 수 있습니다:

  • 이슈 페이지

  • 이슈 보드 페이지

  • 이슈 상세 페이지

  • 새 이슈 페이지

  • 이슈 편집

이 모든 페이지는 동일한 컨텍스트(프로젝트 경로, 현재 사용자 등)를 가지므로, 이슈별 매개변수(이슈 iid)로 더 많은 데이터를 쉽게 페치하고 결과를 클라이언트에 저장할 수 있습니다(동일한 이슈를 다시 열면 추가 API 호출이 필요하지 않습니다). 이를 통해 이슈 탐색 시 부드러운 사용자 경험을 제공합니다.

클러스터 간 탐색의 경우 Rails 라우팅에 계속 의존할 수 있습니다. 이러한 경우는 클러스터 내 탐색보다 상대적으로 드물 것입니다.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

재사용 가능한 컴포넌트#

현재 일반적으로 재사용 가능한 컴포넌트를 두 곳에 보관하고 있습니다:

  • GitLab UI

  • vue_shared 폴더

GitLab UI는 문서화가 잘 되어 있고 컴포넌트가 Vue 애플리케이션 어디서든 재사용할 수 있을 만큼 추상적인 반면, vue_shared 컴포넌트는 다소 혼란스럽고, 특정 컨텍스트에서만 사용할 수 있는 경우가 많으며(예: 기존 Vuex 스토어에 바인딩되어야 하는 경우), 중복이 존재합니다(노트용 컴포넌트가 여러 개 있습니다).

vue_shared를 감사하고, GitLab UI로 이전 가능한 것과 불가능한 것을 파악하며, 기존 컴포넌트를 리팩토링하여 중복을 제거하고 재사용성을 높여야 합니다. 이상적인 결과는 애플리케이션별 컴포넌트를 애플리케이션 폴더로 이동하고, 재사용 가능한 "스마트" 컴포넌트를 공유 폴더/라이브러리에 유지하여, 모든 재사용 가능한 기능이 단 하나의 구현만 갖도록 하는 것입니다.

현재 개발 중입니다. vue_shared와 같은 최상위 폴더에 캡슐화를 강제하는 방법에 대한 업데이트는 GitLab Modular Monolith for FE를 팔로우하세요.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

PostCSS로 마이그레이션#

SASS 컴파일은 전체 프론트엔드 컴파일 시간의 거의 절반을 차지합니다. 이로 인해 파이프라인이 불필요하게 오래 실행됩니다. PostCSS로 마이그레이션하면 컴파일 시간을 크게 향상시킬 수 있습니다.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

협업 및 도구#

시각적 테스팅#

시각적 테스팅 추가 과정 초기 단계에 있지만, 프레임워크를 확립해야 합니다. 구현이 결정되면, 이 문서를 업데이트하여 세부 사항을 포함할 예정입니다.

현재 상태

  • 2023년 12월 기준: (상태)

  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:

  • 퍼실리테이터:

마일스톤 및 일정

  • (주요 마일스톤, 예상 완료 시점)

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)

접근성 테스팅#

2023년부터 접근성 테스팅 도구를 결정하기 위해 노력해 왔습니다. 접근성 준수를 보장하기 위한 axe-core 기반의 포괄적이고 다단계 접근 방식을 선택했습니다. 각 도구는 개발 워크플로에서 특정 목적을 수행하며, 함께 작동하여 개발부터 프로덕션까지 완전한 커버리지를 제공합니다.

현재 상태

  • 2025년 11월 기준: 진행 중 (~90%)

  • 진행 상황: 린팅, Storybook 컴포넌트 테스트, Sitespeed를 이용한 모니터링을 구현했습니다. 현재 피처 테스트를 통한 사용자 여정 테스팅을 진행 중입니다.

담당 팀

마일스톤 및 일정

  • GitLab UI 컴포넌트 스펙에 axe-core 검사 추가 - 2025년 5월 완료

  • 평가 계획/프로세스 및 도구를 포함한 접근성 위반 해결 계획 수립 및 구현 - 90% 완료, FY26 말까지 완료 예정

  • 공유 뷰 컴포넌트에 접근성 검사 포함 - 70% 완료, FY26 말까지 완료 예정

  • 피처 스펙의 주요 사용자 여정에 axe-core 검사 추가 - 20% 완료, Q1FY27에 완료 예정

과제 및 의존성

  • (주요 과제)

성공 지표

  • (잠재적 지표)