비개발자도 GitHub을 써야 할까요?

GitHub이 뭔지부터 짧게

GitHub이라는 이름은 많이 들어 봤지만, 개발자들만 쓰는 곳이라고 생각하는 분이 많아요. 저도 처음엔 그랬어요. 그런데 AI로 무언가를 만들기 시작하면 비개발자에게도 꽤 쓸모가 있어요. 먼저 무엇인지부터 짧게 적을게요.

개발자는 여기에 코드를 두지만, 꼭 코드만 두는 곳은 아니에요. 설계 문서, 기획서, 과업 목록처럼 내가 만든 문서도 같이 둘 수 있어요. 문서를 고칠 때마다 무엇이 언제 바뀌었는지 기록이 남고, 필요하면 예전 모습으로 되돌릴 수 있어요.

비개발자에게 왜 필요할까요

• •백업: 내 컴퓨터에만 있는 문서는 컴퓨터가 고장 나면 같이 사라져요
• •다른 컴퓨터에서 이어 가기: 집과 사무실, 노트북과 데스크톱을 오가도 같은 자리에서 시작해요
• •함께 만들기: 개발자나 코딩 에이전트가 같은 문서를 읽고 바로 시작해요
• •되돌리기: 고치다가 망가져도 바뀐 기록이 남아 있어 예전 판으로 돌아갈 수 있어요

특히 쓰던 AI 도구에 퍼플프린트를 연결해 쓰면, 설계 문서는 내 작업 폴더에 남아요. 내 폴더에 있다는 건 좋은 점이지만, 그 폴더가 이 컴퓨터 하나에만 있다는 뜻이기도 해요. 원격 저장소까지 있어야 백업이 되고, 다른 기기와 다음 세션, 개발 에이전트가 같은 자리에서 이어 갈 수 있어요.

저장소를 만드는 숙제는 코치가 대신해요

"GitHub에 가서 저장소를 만들고 주소를 알려 주세요"는 비개발자에게 여섯, 일곱 단계짜리 숙제예요. 가입하고, 메뉴를 찾고, 설정을 고르고, 주소를 복사하고, 다시 붙여 넣고. 그래서 퍼플프린트 코치는 이걸 시키지 않고 대신 해요. 내게 남는 건 로그인 승인 한 번이에요. 이건 내 계정을 지키는 보안 장치라 없앨 수 없어요.

코치는 이 순서로 시도해요.

• •이미 원격 저장소가 있으면 확인만 하고 아무 말 없이 넘어가요
• •GitHub 명령 도구가 이미 로그인돼 있으면, 비공개 저장소를 만들고 지금까지의 문서를 올려요
• •로그인이 필요하면 브라우저에서 승인 한 번을 요청하고, 끝나면 이어서 만들어요
• •명령 도구가 없으면 설치도 코치가 직접 해요
• •다 안 되면 원격 없이 그냥 진행하고, 나중에 다시 권해요

마지막 줄이 중요해요. 설치나 로그인이 길어지거나 실패해도 설계는 멈추지 않아요. 백업은 거드는 일이지, 설계를 막는 관문이 아니에요. 내 컴퓨터 안의 기록은 먼저 남겨 두고, 원격은 다음에 다시 시도해요.

언제 만들자고 하나요

첫 단계가 끝나 첫 설계 문서가 생긴 직후에 한 번 제안해요. 잃을 게 처음 생긴 순간이고, 다른 컴퓨터에서 이어 가려면 그때부터 저장소가 있어야 해서예요. 왜 필요한지 한 줄로 말하고 제안하고, 지금은 그냥 이어 가자고 하면 그대로 하던 단계를 계속해요. 같은 단계 안에서 다시 권하지 않아요. 그때 넘겼다면 마지막 단계 점검에서 한 번 더 물어요.

비공개가 기본이에요

코치가 만드는 저장소는 늘 비공개예요. 공개로 할지 따로 묻지 않아요. 물으면 고민할 자리가 하나 더 생기고, 그 자리에서 실수로 공개되면 되돌리기 어렵기 때문이에요. 나중에 공개하고 싶으면 그때 바꾸면 돼요. 저장소 이름은 새로 짓지 않고 프로젝트 폴더 이름을 그대로 써요.

공개로 바꿀 때는 한 번 훑어보세요. 고객 이름이나 연락처, 서비스 비밀번호나 키 같은 값이 문서에 들어 있지 않은지요. 공개 저장소는 누구나 볼 수 있어요.

저장소에 둘 것과 두지 말 것

• •두면 좋은 것: 설계 문서, 과업 목록, 화면 시안, 코드
• •두지 말 것: 서비스 비밀번호와 키, 고객의 이름과 연락처, 결제 정보

비공개 저장소라도 비밀번호나 키는 올리지 않는 게 원칙이에요. 저장소는 나중에 공개로 바뀌거나 다른 사람을 초대할 수 있어서, 한 번 올라간 비밀값은 기록에 남아 지우기 어려워요. 개발을 시작할 때 코딩 에이전트에게 "비밀값은 저장소에 올리지 말고 따로 보관해 줘"라고 한 번 말해 두세요.

"커밋"이라는 말이 나오면

퍼플프린트 코치와 개발 단계를 진행하면 "커밋했어요"라는 말을 자주 듣게 돼요. 코치는 의미 있는 작업이 끝날 때마다 묻지 않고 커밋해요. 기록과 되돌리기를 위한 거라 승인받을 일이 아니에요. 대신 그 기록을 원격 저장소에 올리는 일은 "올릴까요?" 하고 한 번 확인해요.

실수로 망가뜨렸을 때

문서를 고치다 이상해졌거나, 에이전트가 만든 코드가 어제보다 나빠졌다면 당황하지 않아도 돼요. 커밋 기록이 남아 있으면 "어제 저녁 판으로 되돌려 줘"처럼 말로 부탁하면 돼요. 어느 판으로 돌아갈지 모르겠다면 "최근에 바뀐 것들을 보여 줘"라고 먼저 물어보세요. 바뀐 기록을 보며 고를 수 있어요.

팀원이나 개발자를 부르려면

개발을 맡길 사람이나 함께 일할 팀원이 생기면, 저장소에 그 사람을 초대하면 돼요. 비공개 저장소는 초대한 사람만 볼 수 있어요. 받는 사람은 설계 문서와 인계 문서, 과업 목록을 저장소에서 바로 읽고 시작하니, 처음부터 다시 설명하지 않아도 돼요. 내가 정한 결정이 문서로 함께 넘어가는 거예요.

다른 컴퓨터에서 이어 가려면

저장소를 만들면 코치가 한 번 알려 줘요. 다른 컴퓨터에서는 그 컴퓨터의 AI 도구에 "저장소 주소를 받아서 퍼플프린트로 이어가자"라고 하면 돼요. 그 컴퓨터에 퍼플프린트 연결이 아직 없다면 연결 안내도 같이 알려 줘요. 쓰는 AI 도구에 여러 기기에서 따라오는 메모 기능이 있다면, 이 한 줄을 거기에 남겨 둘지도 물어요.

웹 코치에서는 이렇게 연결해요

브라우저 웹 코치로 쓰는 분은 GitHub 계정을 연결해 저장소를 붙일 수 있어요. 코치는 붙인 저장소만 쓸 수 있고, 그 밖의 저장소는 서버가 막아요. 쓰기는 "쓰기 허용"으로 붙인 곳에만, 그리고 매번 승인 카드에서 "좋아요"를 누른 것만 해요. 새 비공개 저장소를 만들어 설계 문서를 내보내는 것도 같은 방식이에요.

하이퍼 리뷰도 GitHub 저장소를 연결해 점검할 수 있어요. 이때 점검은 고른 저장소만 읽어요. 이미 만든 서비스의 코드와 문서가 저장소에 있다면, 따로 붙여 넣지 않아도 그대로 점검받을 수 있어요.

꼭 GitHub이어야 하나요

꼭 그렇지는 않아요. 비슷한 저장소 서비스는 여럿 있어요. 다만 퍼플프린트 코치가 저장소를 대신 만들어 주는 길과 웹 코치의 저장소 연결, 하이퍼 리뷰의 저장소 점검은 GitHub 기준이에요. 그래서 처음이라면 GitHub이 가장 손이 덜 가요. 이미 회사에서 다른 서비스를 쓰고 있다면, 그쪽에 올려 달라고 코딩 에이전트에게 따로 말하면 돼요.

막히면 이슈로 물어봐요

창업자 1,000명 직접 돕기도 이 방식을 써요. 리포트를 보고 방향을 같이 잡은 뒤에는, 막힐 때마다 공개 저장소의 이슈로 물어보시면 돼요. 같은 자리에서 막힌 다른 분도 그 답을 같이 볼 수 있어요. 공개라서 리포트 공유 링크나 아이디어 원문, 고객 정보는 이슈 대신 메일로 보내 주세요.

제가 비개발자의 GitHub이라고 불렀던 이유

4월에 저는 퍼플프린트를 "비개발자의 GitHub"이라고 소개했어요. GitHub은 코드를 두는 곳을 넘어 개발자 문화의 중심지가 됐어요. 공유하고, 복제하고, 토론하고, 함께 고치는 흐름이 있었기 때문이에요. 비개발자가 무언가를 만드는 문화에도 그런 바탕이 있어야 한다고 생각했어요.

그때 그린 그림은 이랬어요. 공감 표시, 다른 사람의 설계 과정을 복제해 내 것으로 시작하기, 피드백과 공개 토론, 프로젝트 개요, 빌더 프로필 같은 것들이에요. 결과물 한 번이 아니라, 끝까지 간 설계와 그 대화 과정이 나누는 단위가 되는 거예요.

솔직하게 지금 상태도 적을게요. 이 그림에서 실제로 있는 건 설계 문서를 저장소에 남기는 것, 공개 저장소의 이슈로 묻고 답하는 것 정도예요. 다른 사람의 설계 과정을 복제하거나 빌더 프로필을 공개하는 기능은 아직 없어요. 그래도 방향은 같아요. 아직 개발자가 아닌 사람이 처음 만드는 사람이 되는 과정을 담는 바탕을 만들고 싶어요.