수백 개, 혹은 수천 개의 Issue가 쌓인 GitHub 저장소(repository)를 열어본 적이 있다면, 아마 저와 같은 기분을 느껴보셨을 겁니다. 대체 어디서부터 시작해야 할까요? 언뜻 보기에 GitHub Issue는 버그 리포트(bug reports), 기능 요청(feature requests), 개선 제안(enhancement proposals), 질문(questions), 그리고 풀 리퀘스트(pull requests)가 끝없이 나열된 목록처럼 보입니다. 이를 하나씩 읽다 보면 금방 압도당하게 됩니다. 제가 개발자 경험(developer experience) 연구를 시작했을 때, GitHub Issue를 수집하는 것이 쉬운 부분일 것이라고 생각했습니다.

제 생각이 틀렸습니다. 진짜 도전 과제는 Issue를 읽는 것이 아니었습니다. 진짜 도전 과제는 그것들을 연구 데이터로 조직화하고, 그 데이터를 유지 관리자(maintainers), 분석을 위한 공동 UX 디자이너(co-UX designers), 그리고 원시 데이터(raw data)를 탐색하고자 하는 엔지니어들이 이해할 수 있도록 만드는 것이었습니다.

몇 달 동안 GitHub 저장소를 분석하며, 연구의 품질은 얼마나 많은 Issue를 수집하느냐보다 데이터를 어떻게 조직화하느냐에 훨씬 더 많이 달려 있다는 것을 깨달았습니다. Issue 링크로 가득 찬 스프레드시트(spreadsheet)는 연구가 아닙니다. 구조화된 데이터셋(structured dataset)이 연구입니다.

나의 첫 번째 스프레드시트는 실패했다

많은 연구자들과 마찬가지로, 저도 단순한 스프레드시트로 시작했습니다.

그것은 다음을 포함하고 있었습니다: Issue 제목, GitHub 링크, 오픈 날짜, 종료 날짜, 간략한 요약. 2~3개월 동안 수백 개의 Issue를 기록한 후,

저는 다음과 같은 간단한 질문들에 답해 보려 했습니다.

• 어떤 배포 단계(deployment stage)에서 가장 자주 실패하는가?
• 어떤 사용자들이 가장 큰 어려움을 겪는가?
• 어떤 릴리스(releases)에서 가장 많은 회귀(regressions)가 발생하는가?
• 어떤 문제들이 반복적으로 나타나는가?
• 어떤 워크플로우(workflows)가 엔지니어링 시간을 가장 많이 소비하는가?

저는 그 질문 중 어느 것에도 답할 수 없었습니다. 그와 동시에, 저는 엔지니어 팀에게 제가 무엇을 포착해야 하는지 설명하지 못했고, 연구 데이터(스프레드시트)로부터 질문에 답할 수도 없었습니다. 왜냐하면 그것은 그저 단순한 정보처럼 보였기 때문입니다.

많은 양의 정보를 수집했지만, 분석을 지원할 수 있는 방식으로 정리하지는 못했던 것입니다.

그 순간이 제가 전체 연구 프로세스를 재설계한 시점이었습니다.

스프레드시트 사용자가 아닌 UX 연구자처럼 생각하기

모든 GitHub Issue (이슈)는 단순한 버그 그 이상을 담고 있습니다. 그것은 증거를 담고 있습니다. 각 Issue (이슈)는 다음과 같은 정보를 알려줄 수 있습니다:

• 누가 문제를 경험했는지,
• 어디에서 발생했는지,
• 언제 발생했는지,
• 왜 발생했는지,
• 어떻게 해결되었는지,
• 그리고 어떤 영향을 미쳤는지.

하나의 커다란 "요약 (Summary)" 열을 만드는 대신, 저는 모든 Issue (이슈)를 더 작은 연구 카테고리로 나누기 시작했습니다.

각 카테고리는 서로 다른 연구 질문에 답했습니다. 그것은 설문 조사에서 수집하는 원시 데이터 (raw data)와 유사하게, 질적 및 양적 연구 데이터셋 (qualitative and quantitative research dataset)처럼 보여야 했습니다. 데이터를 정리하고 연구를 위한 구조화된 스프레드시트 (spreadsheet)를 만드는 방법을 단계별로 설명하겠습니다.

1단계: 커뮤니티 활동 정리하기

첫 번째 섹션은 GitHub 메타데이터 (metadata)를 포착합니다. 모든 Issue (이슈)에 대해 다음과 같은 정보를 기록합니다:

• Issue (이슈) 제목
• Issue (이슈) 유형
• 라벨 (Labels)
• 상태 (Status)
• 생성 날짜
• 종료 날짜
• 해결 시간 (Resolution time)
• 연결된 Pull Request (PR)
• 짧은 요약
• 메인테이너 (Maintainer) 및 엔지니어 대화 요약

이를 통해 커뮤니티 활동, 응답 시간, 메인테이너 업무량, 이슈 트렌드, 릴리스 주기 (release cycles), 그리고 프로젝트 건강도 (project health)를 분석할 수 있습니다.

2단계: 개발자 식별하기

GitHub Issue (이슈)가 "저는 플랫폼 엔지니어입니다"라는 말로 시작하는 경우는 드뭅니다. 대신, 기술적 문맥 (technical context)을 통해 사용자의 역할을 추론해야 합니다.

예를 들어:

• 플랫폼 엔지니어 (Platform Engineer)
• DevOps 엔지니어 (DevOps Engineer)
• ML 엔지니어 (ML Engineer)
• 소프트웨어 엔지니어 (Software Engineer)
• 데이터 사이언티스트 (Data Scientist)
• 사이트 신뢰성 엔지니어 (Site Reliability Engineer)

저는 또한 Issue (이슈) 자체에서 얻은 뒷받침하는 증거도 함께 기록합니다.

수백 개의 이슈 (Issue)가 분류되면 패턴이 나타나기 시작합니다.

어떤 페르소나 (Persona)가 가장 많은 마찰을 겪는지, 어떤 그룹에 더 나은 도구 (Tooling)나 문서화 (Documentation)가 필요한지를 확인할 수 있습니다.

3단계: 워크플로 (Workflow)를 단계별로 분해하기

대부분의 저장소 (Repository)는 복잡한 워크플로를 포함합니다.

모든 것을 배포 (Deployment) 문제로 라벨링 (Labeling)하는 대신, 저는 워크플로를 단계별로 나눕니다.

AI 인프라 연구의 경우, 저의 배포 워크플로는 다음을 포함합니다:

설치 (Installation) → 설정 (Configuration) → 모델 다운로드 (Model Download) → 런타임 초기화 (Runtime Initialization) → 준비 상태 (Readiness) → 네트워킹 (Networking) → 추론 (Inference) → 스케일링 (Scaling) → 버전 업그레이드 (Version Upgrade),

모든 이슈는 장애가 발생한 단계에 매핑 (Mapping)됩니다. 이를 통해 워크플로의 어느 부분이 가장 많은 문제를 생성하는지 즉시 드러납니다.

4단계: 배포와 운영을 분리하기

초기에 제가 저질렀던 실수 중 하나는 모든 것을 하나로 묶는 것이었습니다.

배포 (Deployment) 문제는 운영 (Operations) 문제와 다릅니다.

그래서 저는 다음과 같이 별도의 워크플로를 만들었습니다: 배포 (Deployment), 관측성 (Observability), Day-2 운영 (Day-2 Operations), 유지보수 (Maintenance)

각 워크플로는 고유한 카테고리를 가집니다. 관측성 (Observability)의 경우, 다음과 같은 활동을 기록합니다:

• 로그 (Logs) 확인,
• Kubernetes 이벤트 (Events) 조사,
• 메트릭 (Metrics) 검토,
• 지연 시간 (Latency) 디버깅,
• 근본 원인 (Root Causes) 식별.

유지보수 (Maintenance)의 경우, 다음을 분류합니다:

• 업그레이드 (Upgrades),
• 설정 변경 (Configuration changes),
• 롤백 (Rollbacks),
• 런타임 마이그레이션 (Runtime migration),
• 용량 관리 (Capacity management),
• 스케일링 (Scaling).

이러한 워크플로를 분리함으로써 데이터를 훨씬 더 쉽게 분석할 수 있게 되었습니다.

5단계: 기술적 컨텍스트 (Technical Context) 캡처하기

기술적 컨텍스트 (Technical Context)가 없으면 패턴은 사라집니다. 모든 이슈에 대해 저는 다음과 같은 정보를 캡처합니다:

• 제품 버전 (Product version),
• Kubernetes 버전 (Kubernetes version),
• 런타임 (Runtime),
• 모델 제품군 (Model family),
• 배포 유형 (Deployment type),
• 인프라 (Infrastructure),
• 스토리지 백엔드 (Storage backend),
• GPU 또는 CPU 사용량 (GPU or CPU usage)

이를 통해 다음과 같은 질문에 답할 수 있습니다:

"특정 릴리스(release) 이후에 업그레이드 이슈가 증가하는가?"

"GPU 배포가 CPU 배포보다 더 빈번하게 실패하는가?"

"특정 런타임(runtime)이 다른 런타임보다 더 많은 네트워킹 이슈를 생성하는가?"

6단계: 연구 질문(Research Questions)을 중심으로 스프레드시트 설계하기

제가 시도한 가장 큰 변화는 이것이었습니다:

질문하는 방식을 바꾼 것입니다.

**"이 이슈에는 어떤 정보가 포함되어 있는가?"**라고 묻는 대신,

**"이 데이터셋을 통해 어떤 연구 질문(research questions)에 답하고 싶은가?"**라고 묻기 시작했습니다.

스프레드시트에 새로운 열(column)을 추가하기 전에, 먼저 연구 질문을 설계했습니다. 그런 다음, 수집하는 데이터가 실제로 그 질문에 답하는 데 도움이 되는지 확인하기 위해 모든 스프레드시트 카테고리를 해당 질문들과 대조하며 교차 검증했습니다.

예를 들어, 연구 질문 중 하나가 "어떤 배포 단계에서 개발자가 가장 많은 어려움을 겪는가?"라면, 배포 워크플로(deployment workflow), 실패 단계(failure stage), 개발자 목표(developer goal), 배포 요약(deployment summary)을 위한 열이 필요했습니다. 만약 "어떤 개발자 페르소나(developer persona)가 가장 많은 마찰을 경험하는가?"를 이해하고 싶다면, 개발자 역할(developer role), 숙련도(experience level), 뒷받침하는 증거(supporting evidence)를 위한 열이 필요했습니다. 마찬가지로, 버전별 문제를 분석하고 싶다면 KServe 버전, Kubernetes 버전, 런타임(runtime), 그리고 업그레이드 정보(upgrade information)를 위한 열이 필요했습니다.

스프레드시트의 모든 새로운 열은 하나 이상의 연구 질문을 뒷받침함으로써 그 존재 이유를 증명해야 했습니다. 만약 어떤 열이 연구 질문에 답하거나 의미 있는 통찰(insights)을 생성하는 데 기여할 수 없다면, 저는 그것을 삭제했습니다.

이 간단한 검증 프로세스를 통해 저는 단순히 데이터를 수집하는 것이 아니라, 증거(evidence)를 수집하고 있음을 확신할 수 있었습니다. 시간이 흐르면서 스프레드시트는 단순한 GitHub 이슈 목록에서 질적 분석(qualitative analysis)과 양적 분석(quantitative analysis)을 모두 지원할 수 있는 연구용 데이터셋으로 진화했습니다.

결과

데이터가 정제되고 정리되자, 모든 것이 바뀌었습니다.

수백 개의 이슈를 일일이 다시 읽는 대신, 저는 다음과 같은 일을 할 수 있었습니다:

• 반복되는 패턴 식별 (identify recurring patterns),
• 개발자의 고충 (pain points) 측정,
• 버전 간 비교,
• 워크플로우 병목 현상 (bottlenecks) 식별,
• 페르소나 (personas) 분석,
• 대시보드 (dashboards) 생성,
• 정량적 지표 (quantitative metrics) 생성,
• 주제별 코딩 (thematic coding) 수행,
• 그리고 증거 기반의 권장 사항 (evidence-based recommendations) 도출.

스프레드시트는 질적 및 양적 분석 (qualitative and quantitative analysis)을 위한 토대가 되었습니다.

마치며

GitHub 이슈를 정리하는 것이 흥미롭게 들리지 않을 수도 있지만, 이는 개발자 경험 (developer experience) 연구에서 가장 가치 있는 단계 중 하나입니다.

구조화된 데이터 (structured data)가 없다면, 수백 개의 이슈는 그저 개별적인 대화로 남을 뿐입니다.

구조화된 데이터가 있다면, 그것들은 증거가 됩니다.

여러분이 UX 리서처 (UX researcher), 오픈 소스 메인테이너 (open-source maintainer), DevRel 엔지니어 (DevRel engineer), 또는 기여자 (contributor)이든 관계없이, GitHub 이슈를 정리하는 데 시간을 투자하는 것은 향후 모든 분석을 더 빠르고, 정확하며, 실행 가능하게 (actionable) 만들어 줄 것입니다.

GitHub 이슈를 단순한 버그 (bugs)로 생각하지 마세요.

개발자들이 여러분의 제품을 실제로 어떻게 경험하는지 말해주기를 기다리고 있는 연구 참여자 (research participants)로 생각하세요.