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을 단일 페이지 애플리케이션으로 전환하면 가능하지만, 대규모 리팩터링이 필요해 단기나 중기 목표로는 적합하지 않습니다.

현실적인 목표는 여러 개의 SPA 경험으로 옮겨 가는 것입니다. 사용자 흐름을 이루는 페이지 클러스터 를 정의하고, 그 클러스터를 Rails 라우팅에서 클라이언트 측 라우팅을 쓰는 단일 페이지 애플리케이션으로 옮기는 방식입니다. 이렇게 하면 관련 컨텍스트를 HAML에서 한 번만 불러오고, 추가 데이터는 경로에 따라 API에서 가져올 수 있습니다. 클러스터의 예로는 다음 페이지를 들 수 있습니다.

  • Issues 페이지
  • Issue boards 페이지
  • Issue details 페이지
  • New issue 페이지
  • 이슈 편집

이 페이지들은 모두 동일한 컨텍스트(프로젝트 경로, 현재 사용자 등)를 공유합니다. 이슈별 파라미터(이슈 iid)로 데이터를 더 가져와 결과를 클라이언트에 저장할 수 있으므로, 같은 이슈를 다시 열 때 API를 추가로 호출하지 않아도 됩니다. 이렇게 하면 이슈를 오가는 사용자 경험이 매끄러워집니다.

클러스터 사이를 이동할 때는 여전히 Rails 라우팅을 사용할 수 있습니다. 이러한 이동은 클러스터 내부 이동보다 상대적으로 드뭅니다.

현재 상태

  • 2023년 12월 기준: (상태)
  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:
  • 퍼실리테이터:

마일스톤 및 일정

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

과제 및 의존성

  • (주요 과제)

성공 지표

  • (예상 지표)

재사용 가능한 컴포넌트#

현재 범용으로 재사용하는 컴포넌트는 주로 두 곳에 두고 있습니다.

  • GitLab UI
  • vue_shared 폴더

GitLab UI는 문서화가 잘 되어 있고 컴포넌트도 충분히 추상화되어 Vue 애플리케이션 어디서든 재사용할 수 있습니다. 반면 vue_shared 컴포넌트는 다소 정돈되지 않았고, 특정 컨텍스트에서만 쓸 수 있는 경우가 많으며(예: 기존 Vuex 스토어에 묶여 있음) 중복도 있습니다(노트용 컴포넌트가 여러 개입니다).

vue_shared를 점검해 GitLab UI로 옮길 수 있는 것과 없는 것을 가려내고, 기존 컴포넌트를 리팩터링해 중복을 없애고 재사용성을 높여야 합니다. 이상적인 결과는 애플리케이션에 특화된 컴포넌트를 애플리케이션 폴더로 옮기고, 재사용 가능한 "스마트" 컴포넌트는 공유 폴더나 라이브러리에 두어 재사용 가능한 기능마다 구현이 하나만 존재하도록 만드는 것입니다.

vue_shared 같은 최상위 폴더의 캡슐화는 프론트엔드 패키지 경계에 설명된 규칙으로 강제합니다.

현재 상태

  • 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.4
원문 보기

요약

이 문서는 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을 단일 페이지 애플리케이션으로 전환하면 가능하지만, 대규모 리팩터링이 필요해 단기나 중기 목표로는 적합하지 않습니다.

현실적인 목표는 여러 개의 SPA 경험으로 옮겨 가는 것입니다. 사용자 흐름을 이루는 페이지 클러스터 를 정의하고, 그 클러스터를 Rails 라우팅에서 클라이언트 측 라우팅을 쓰는 단일 페이지 애플리케이션으로 옮기는 방식입니다. 이렇게 하면 관련 컨텍스트를 HAML에서 한 번만 불러오고, 추가 데이터는 경로에 따라 API에서 가져올 수 있습니다. 클러스터의 예로는 다음 페이지를 들 수 있습니다.

  • Issues 페이지
  • Issue boards 페이지
  • Issue details 페이지
  • New issue 페이지
  • 이슈 편집

이 페이지들은 모두 동일한 컨텍스트(프로젝트 경로, 현재 사용자 등)를 공유합니다. 이슈별 파라미터(이슈 iid)로 데이터를 더 가져와 결과를 클라이언트에 저장할 수 있으므로, 같은 이슈를 다시 열 때 API를 추가로 호출하지 않아도 됩니다. 이렇게 하면 이슈를 오가는 사용자 경험이 매끄러워집니다.

클러스터 사이를 이동할 때는 여전히 Rails 라우팅을 사용할 수 있습니다. 이러한 이동은 클러스터 내부 이동보다 상대적으로 드뭅니다.

현재 상태

  • 2023년 12월 기준: (상태)
  • 진행 상황: (진행 상황 간략 설명)

담당 팀

  • 태스크 그룹:
  • 퍼실리테이터:

마일스톤 및 일정

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

과제 및 의존성

  • (주요 과제)

성공 지표

  • (예상 지표)

재사용 가능한 컴포넌트#

현재 범용으로 재사용하는 컴포넌트는 주로 두 곳에 두고 있습니다.

  • GitLab UI
  • vue_shared 폴더

GitLab UI는 문서화가 잘 되어 있고 컴포넌트도 충분히 추상화되어 Vue 애플리케이션 어디서든 재사용할 수 있습니다. 반면 vue_shared 컴포넌트는 다소 정돈되지 않았고, 특정 컨텍스트에서만 쓸 수 있는 경우가 많으며(예: 기존 Vuex 스토어에 묶여 있음) 중복도 있습니다(노트용 컴포넌트가 여러 개입니다).

vue_shared를 점검해 GitLab UI로 옮길 수 있는 것과 없는 것을 가려내고, 기존 컴포넌트를 리팩터링해 중복을 없애고 재사용성을 높여야 합니다. 이상적인 결과는 애플리케이션에 특화된 컴포넌트를 애플리케이션 폴더로 옮기고, 재사용 가능한 "스마트" 컴포넌트는 공유 폴더나 라이브러리에 두어 재사용 가능한 기능마다 구현이 하나만 존재하도록 만드는 것입니다.

vue_shared 같은 최상위 폴더의 캡슐화는 프론트엔드 패키지 경계에 설명된 규칙으로 강제합니다.

현재 상태

  • 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 완료 예정

과제 및 의존성

  • (주요 과제)

성공 지표

  • (예상 지표)