개발을 모르는 디자이너가 GitHub PR을 설계하게 되었을 때
1/ 개발 지식이 없지만 GitHub를 설계해야 한다면, 무엇부터 이해해야 할까요?
PR 제목과 상태만 보이던 기존 흐름에서는 ‘무슨 작업인지’, ‘왜 시간이 걸리는지’ 알 수 없었습니다. 이 한계가 프로젝트 관리자의 효율적 의사결정을 막고 있었고 이는 프로젝트 지연으로 이어졌습니다.
그래서 GitHub PR 내용을 뤼이도로 가져오는 것을 설계해야 했습니다.
하지만 저는 GitHub를 써본 적이 없었습니다.
PR이 정확히 언제 생성되는지, 무엇을 담고 있는지, 개발자에게 어떤 의미인지도 잘 몰랐습니다. GitHub를 써보자니 괜히 이것저것 눌렀다가 개발자분들 작업에 영향을 줄까봐 걱정도 되었습니다.
그래서 이 기능은 단순한 외부 연동이 아니라,
이해하지 못하는 도메인을 어떻게 설계할 것인가에 대한 문제로 다가왔습니다.
2/ GitHub PR은 무엇이고, 왜 필요한가
PR(Pull Request)은 개발자가 작업한 코드를 메인 코드에 반영하기 전,
변경 내용을 공유하고 리뷰를 받는 과정입니다.
- 어떤 코드를 수정했는지
- 왜 수정했는지
- 어떤 논의가 오갔는지
- 누가 리뷰했고, 무엇이 변경되었는지
이 모든 기록이 PR 안에 남습니다.
문제는, 그 맥락이 GitHub 안에만 존재했다는 점입니다.
개발자가 "PR 올렸습니다"라고 슬랙에 공유하면,
기존 뤼이도에서는 제목과 상태 정도만 확인할 수 있었습니다.
- 이 작업이 정확히 무엇을 바꾼 건지
- 리뷰는 어디까지 진행됐는지
- 왜 시간이 걸리고 있는지
결국 개발자에게 직접 물어봐야 했고,
답변마저 비개발자가 이해하기에는 어려웠습니다.
그래서 이번 업데이트에서는 GitHub PR의 모든 정보를 뤼이도 안으로 가져왔고, 그 위에 비개발자 관리자를 위한 AI 요약까지 더했습니다.
GitHub PR에 대한 더 자세한 내용은
아래 버튼을 클릭해 릴리즈 노트를 확인해 주세요.
3/ 기능이 아닌 '맥락'부터 이해하기
UI를 그리기 전, 질문을 던졌습니다.
- 뤼이도 안에 들어갈 PR 내용은 누가 보는가?
- 이 정보는 왜 필요한가?
- 이 중에서 의사결정에 필요한 것은 무엇인가?
답은 명확했습니다.
뤼이도에서 PR 정보를 보는 사람은 개발자가 아니라, 비개발자 관리자였습니다.
실제로 비개발자 대표 인터뷰를 통해 이런 이야기를 들을 수 있었습니다.
"작은 변경이 왜 큰 일이 되는지 영향도를 빨리 알고 싶어요."
"에러가 났을 때, 얼마나 걸리는지 알아야 운영 판단을 할 수 있어요."
그들이 궁금해하는 건 코드가 아니었습니다.
- 이 작업이 어디에 속하는지
- 왜 시간이 걸리는지
- 지금 어디에서 막혔는지
- 다른 기능에 영향이 있는지
- 언제쯤 끝나는지
즉, 맥락과 영향도였습니다.
그래서 저는 PR을 단순한 "개발 기록"이 아니라,
비개발자의 의사결정을 돕는 판단 재료로 보기 시작했습니다.
4/ 설계해야 할 범위 정하기
그 다음 고민은 이것이었습니다.
"GitHub 화면을 그대로 가져올 것인가, 아니면 완전히 재해석할 것인가?"
결론은 둘 다 필요하다였습니다.
a. 그대로 가져온 것
PR 본문, 속성, 댓글 등 개발자의 중요한 맥락은 그대로 가져왔습니다.
이 정보는 GitHub 안에서 이미 검증된 구조이고, 의미가 있는 데이터이기 때문입니다. 개발자 맥락을 훼손하면 오히려 정보가 왜곡될 수 있다고 판단했습니다.
b. 다시 설계한 것
하지만 그대로 가져오면 비개발자에겐 여전히 어렵습니다.
그래서 다음을 뤼이도 방식으로 재구성했습니다.
- PR 상단에 AI 요약 제공 (기술 언어 → 이해 가능한 언어)
- 리뷰어, 담당자, 라벨 정보는 뤼이도의 톤앤매너에 맞게 정리
- 댓글/활동 영역은 기존 작업 상세 페이지와 동일한 구조로 설계
그리고 한 가지 더 고민했습니다.
비개발자 관리자가 PR 본문을 매번 다 읽을 필요가 있을까?
대부분의 경우, PR 본문은 길고 기술적인 설명이 많습니다.
그 내용이 항상 1차적으로 필요한 정보는 아니라고 판단했습니다.
그래서 PR 본문(설명 영역)은 토글 구조를 선택해 접었다 폈다 할 수 있게 설계했습니다. 만약 긴 기술 설명이 항상 펼쳐진 채로 노출된다면 PR 모달은 더 복잡하게 느껴졌을 것이고, 핵심 정보가 오히려 묻혔을 가능성이 큽니다.
먼저 AI 요약과 이슈를 통해 빠르게 맥락을 이해하고,
더 깊이 확인하고 싶을 때만 본문을 열어보는 흐름.
이 화면은 개발자가 아니라, 비개발자 관리자가 보는 화면이기 때문에
정보의 '존재'와 '노출 방식'을 구분하는 것이 중요하다고 판단했습니다.
5/ 거창한 협업이 아닌, 계속 질문하는 과정
사실 이 기능을 도입하는 과정에서 개발자와의 협업은 "협업"이라고 부르기엔 저는 너무 많이 몰랐습니다.
그래서 제가 한 일은 하나였습니다.
계속 질문하는 것.
- 이 필드는 왜 필요한가요?
- 이 상태는 언제 바뀌나요?
- 여기에서 가장 중요한 정보는 무엇인가요?
- 이건 개발자한테만 의미가 있는 건가요?
제가 모르는 것을 인정하고 말씀드리니,
오히려 개발자분들도 더 적극적으로 설명해주셨습니다.
이 과정에서 저는 모르는 영역을 이해하고 그것을 '사용자'에 맞게 설계하는 것을 경험했습니다.
6/ 보이지 않는 이해를 설계하는 일
PR 연동은 겉으로 보면 단순한 외부 연동 기능처럼 보일 수 있습니다.
하지만 이 작업의 본질은 GitHub와 연동시키는 것이 아닌,
개발 내용을를 비개발자의 의사결정 내용으로 번역하는 것이었습니다.
뤼이도는 사용자의 프로젝트 지연을 막기 위해 작업의 맥락이 끊기지 않도록 정보를 연결하는 디테일에 집중합니다.
겉으로 보이는 기능이 아니라,
왜 병목이 생기는지
왜 소통이 길어지는지
왜 판단이 늦어지는지 같은
보이지 않는 근본적인 문제를 해결하려고 합니다.
앞으로도 뤼이도는 팀이 같은 맥락을 기준으로 의사결정하고 실행할 수 있도록 구조를 설계하는 데 집중하고자 합니다.
개발자와 비개발자 모두가 같은 맥락으로 이해하며 프로젝트를 진행할 수 있도록, GitHub PR을 이제 Riido에서 만나보세요.
