모든 직군이 GitHub에서 일하게 되기까지

"굳이 해보지 않아도 쉽지 않을 거라는 생각이 드는데요?"

올해 초, 회사 내 모든 문서 관리를 Notion이 아닌 GitHub로 전환 하자고 제안했던 동료에게 제가 했던 말입니다.

GitHub은 분산 버전 관리 시스템인 Git을 기반으로, 엔지니어들이 소스 코드를 클라우드에 저장하고 공유하며 관리할 수 있도록 돕는 세계 최대의 웹 기반 개발자 플랫폼입니다.

"GitHub에 PR 올려주세요."
"코드 리뷰 진행 중입니다."
"브랜치 리베이스 해주세요."

옆자리에서 엔지니어들이 나누는 대화를 들었을 뿐, 제게 GitHub는 개발을 위한 협업 플랫폼이었고 가끔 구현에 관심 있는 디자이너들이 언급하는 정도의 도구였습니다. 그렇기 때문에 GitHub로 회사 내 모든 문서를 관리하자는 제안은, 아무리 AI 시대라고 하더라도 세일즈나 디자인 직군까지 사용하기에는 다소 급진적으로 느껴졌습니다.

예를 들어 팀 회의를 위한 위클리 문서를 Notion으로 작성하는 경우, 문서를 생성하고 템플릿을 불러온 뒤 각 직군이 문서에 들어와 내용을 작성하면 됩니다. 누가 실시간으로 작업하고 있는지도 확인할 수 있고, 댓글을 달거나 직접 수정하는 것도 어렵지 않았죠.

반면 이를 GitHub로 진행한다면 상황은 달라집니다. 회사 문서를 저장한 Repository(저장소)를 내려받은 뒤, 코드 에디터나 AI IDE에서 해당 저장소를 불러와 문서를 작성해야 합니다. 그리고 원본 파일을 보호하기 위해 Branch를 생성해 독립된 사본에서 작업하고, 완료 후에는 GitHub에 PR을 올려 Merge하는 과정을 거쳐야 합니다.

Repository, Merge, PR, Branch… 저에게 그저 점심에 먹는 브런치처럼 들리는 단어에 가까웠습니다. 위클리 문서 한 장을 작성하기 위해 모든 직군이 이런 개념을 이해하고 사용해야 한다는 점은, 꽤나 과도한 방식처럼 느껴졌습니다.

GitHub 전환을 제안했던 동료 역시 이러한 부담을 부정하지는 않았습니다. 다만 그럼에도 불구하고, 사내 모든 문서와 데이터가 GitHub 저장소에 통합되고 AI IDE를 함께 활용한다면 실보다 득이 더 클 것이라는 확신이 있어 보였습니다.

그 주장의 핵심은 다음과 같았습니다.

데이터 축적 → AI 분석 → 인사이트 도출 → 코드 구현

이 모든 흐름이 하나로 연결된다는 점입니다. 실제로 수십, 수백 건의 사용자 인터뷰, 피드백, 미팅 노트는 Notion에 각자 작성되어 문서 형태로 쌓입니다. 하지만 이 문서들을 분석하고 인사이트를 도출하기 위해서는 결국 사람이 하나하나 읽고 논의해야 했습니다.

반면 이러한 기록들이 GitHub에 구조화된 데이터로 축적된다면, AI가 문서 간 공통 패턴을 분석해 '어떤 기능에서 이탈이 많은지', '어떤 불편이 반복되고 있는지'를 빠르게 파악할 수 있습니다. 그리고 이를 바탕으로 우리 서비스에 더 적합한 방향성과 PMF를 AI가 먼저 제안해줄 수 있습니다.

사람이라면 놓칠 수 있는 부분까지 꼼꼼하게 읽어내고 논리적으로 정리한 데이터를 기반으로 PRD나 제품 요구사항을 작성하고, AI IDE를 통해 기획 의도에 맞는 코드나 제품까지 구현해낼 수 있습니다.

결과적으로 GitHub 기반의 업무 방식은 문서 정리, 반복 작성, 데이터 분석과 같은 단순 반복 업무를 줄이고, 시간은 많이 들지만 판단이 크게 필요하지 않은 작업들을 효율적으로 대체할 수 있는 방식이었습니다.

단 하나의 예시만으로 충분히 납득이 가는 주장이었습니다.

이미 PRD 작성이나 프로토타입 구현, 아이데이션 과정에서 AI가 저보다 더 잘하는 부분도 있었고, 속도 면에서는 비교하기 어려울 정도였기 때문입니다. GitHub로 전환해보지도 않은 채 불편함만을 예상하며 시도조차 하지 않는 사이에 시대는 빠르게 변하고 있었고, 일하는 방식과 AI의 발전 속도는 이미 우리가 생각하는 범주를 넘어선 상태였습니다.

그렇게 모든 직군이 GitHub 계정과 권한을 부여받고, AI IDE와 코드 에디터 기반으로 업무 프로세스를 전환한 지 약 한 달이 지났습니다.

당연히 처음에는 모두 적응이 쉽지 않았습니다. 새로운 용어와 개념을 익혀야 했고, 익숙한 툴을 떠나 낯선 환경에서 작업하는 것도 어색했습니다. 하지만 시간이 지날수록 GitHub 기반 업무 방식이 가져다주는 이점이 모든 직군에게 점점 명확해지기 시작했습니다.

처음 우려했던 Notion의 공동 문서 작업 방식과 달리, GitHub로 작성하는 방식은 오히려 더 효율적이었습니다. 돌이켜보면 각자 문서를 동시에 작성하는 경우도 많지 않았고, 각자의 역할에 맞는 내용을 AI가 기존 데이터를 기반으로 더 명확하게 정리해주고 있었습니다. 또한 PR 이후 내용이 겹치더라도 Conflict(충돌)를 해결할 수 있는 방식이 이미 GitHub 안에 존재했습니다.

프로덕트 디자이너로서, 한 달 동안 만들어낸 결과물은 다음과 같습니다. Figma에서만 작업하지 않고, 직접 개발 환경에서 AI와 협업하여 Joint 제품 내 구글 캘린더 연동, 언어 설정, Markdown 파일 미리보기 플로우와 컴포넌트 등을 구현했습니다. 디자이너가 직접 컴포넌트를 구현하게 되면서 QA 과정은 크게 줄었고, 엔지니어들은 그만큼 핵심 개발에 더 집중할 수 있게 되었습니다.

또한 Joint 랜딩 페이지 내 업데이트 노트와 고객 성공 사례 페이지는 기존에 Notion 기반으로 운영하면서 SEO가 잘 반영되지 않아 노출이 제한적이었습니다. 하지만 AI를 활용해 디자인과 구현을 진행한 이후, 랜딩 페이지와 콘텐츠 방문자 수가 눈에 띄게 증가했습니다. 불과 얼마 전까지만 해도 디자이너와 엔지니어가 각자의 영역으로 나뉘어 작업하던 랜딩 페이지가, 이제는 일주일 내로 디자이너 혼자 완성하는 흐름으로 바뀌었습니다.

그 외에도 제품의 PRD와 요구사항 문서를 더욱 정교하고 빠르게 작성할 수 있게 되었습니다. 바쁘다는 이유로 미뤄왔고 파편화되었던 스펙 문서, 업데이트되지 않던 기록들을 항상 최신 데이터로 유지하면서, 수십 건의 문서를 일주일 단위로 작성할 수 있게 되었습니다. 물론 빠르게 진행되는 만큼, '이 방향이 우리 서비스에 맞는가' 를 판단하고 결정하는 과정은 여전히 사람이 맡고 있습니다. 다만 이 판단의 영역 역시 점차 AI에게 학습시키고 위임하고 있어, 앞으로는 그 범위가 점점 줄어들 것으로 보고 있습니다.

이러한 과정을 거치며 Joint 팀은 3월 한 달 동안, AI 활용과 실험을 통해 가장 인상적인 성과를 보여준 팀원을 선정하는 AI Award까지 진행했습니다. GitHub 전환에 가장 먼저 의문을 던졌던 제가, 결과적으로 팀원들의 투표로 1등을 하게 되었는데요. 이 과정과 앞서 말씀드린 업무들이 실제로 어떤 방식과 결과로 이어졌는지는, 다음 글에서 이어서 공유드리겠습니다.