아침에 깃허브 화면을 열었더니 노란 배너가 하나 떠 있었다. “브랜치가 새로 푸시됐다”는 안내였는데, 나는 그걸 보자마자 “어, 뭔가 머지를 안 하고 넘어간 게 있나 보다” 하고 혼자 불안해졌다. 비개발자 입장에서는 노란색이든 초록색이든 일단 눈에 띄는 배너가 뜨면 “해결해야 할 일”처럼 느껴진다. 🙂
처음엔 단순하게 생각했다. “PR(Pull Request)을 안 만들어서 저런 게 뜨는 거구나, 그럼 만들면 되겠지.” 그래서 AI에게 스크린샷을 보여주고 “이건 우짜지?” 하고 물었다. AI는 친절하게 “초록색 Compare & pull request 버튼을 누르고, base는 main, compare는 그 브랜치로 맞춘 다음 만들면 된다”고 순서를 알려줬다. 여기까지는 평소 하던 패턴이라 별생각 없이 “진행해”라고 했다.
그런데 실제로 PR을 만들려고 하니 깃허브가 바로 거부했다. “공통 조상이 없다”는 에러 문구였다. 이게 뭔 소린가 싶었는데, AI가 git 명령어 몇 개를 돌려서 확인해보니 상황이 분명해졌다. 문제의 브랜치는 애초에 main에서 갈라져 나온 게 아니라, 완전히 별도로 시작된 “orphan 브랜치”였다. 쉽게 말하면 같은 집안 족보가 아니라 처음부터 다른 뿌리에서 자란 나무 같은 거였다.
이 부분은 전에 문자 2개가 동시에 오면 하나가 사라지던 이유에서도 비슷하게 막혔던 기억이 있어서, 그때 적어둔 메모를 다시 펼쳐봤다.
확인해보니 더 재미있는 사실이 나왔다. 그 브랜치에는 코드가 하나도 없고, 매일 자동으로 생성되는 카드뉴스 이미지 파일 수십 개만 쌓여 있었다. 반면 main 브랜치는 코드 파일이 천 개가 넘었다. 즉 그 브랜치는 “작업용 결과물을 매일 쌓아두는 창고” 역할이었고, main과 합칠 이유가 전혀 없는 구조였다. 커밋 메시지도 전부 “daily: OO일 카드뉴스 초안”으로, 사람이 아니라 자동화 스크립트가 매일 밀어넣고 있었다.
여기서 비개발자인 내가 헷갈렸던 지점은 명확하다. 나는 “노란 배너 = 뭔가 미완성된 일”이라고 자동으로 해석했는데, 사실은 “그냥 알림일 뿐, 꼭 조치가 필요한 건 아니다”였다. AI도 처음 질문에는 “PR 만드는 법”을 성실하게 안내해줬지만, 실제로 git 히스토리를 확인하고 나서야 “이건 만들 필요가 없는 배너”라고 결론을 바꿨다. 겉으로 보이는 알림 문구만으로 판단하지 말고, 실제로 그 안에 뭐가 들어있는지부터 봐야 한다는 걸 이번에 다시 느꼈다. ✨
돌아보면 깃허브의 저 노란 배너는 “새 브랜치가 생겼다”는 사실만 알려주는 중립적인 알림이었다. 그걸 “뭔가 잘못됐다”는 신호로 받아들인 건 내 쪽의 성급한 해석이었다. 특히 자동화 스크립트가 매일 결과물을 쌓아올리는 구조에서는, 그 브랜치 자체가 “보관용 저장소” 역할을 하도록 일부러 설계된 경우가 꽤 있다는 것도 배웠다. 모든 브랜치가 결국 main으로 합쳐져야 하는 건 아니었다.
이번 일로 얻은 교훈은 기술적인 해법보다는 태도 쪽이었다. 화면에 경고성 배너나 빨간 표시가 뜨면 일단 “고쳐야 하는 문제”라고 단정 짓지 말고, 그게 정말 조치가 필요한 신호인지, 아니면 그냥 정보성 알림인지부터 구분해야 한다. 특히 자동화 작업이 많아질수록 이런 “정상적인데 낯선 알림”은 늘어날 수밖에 없다. 비개발자 입장에서는 눈에 보이는 색깔과 느낌만으로 판단하기보다, 한 걸음 물러나서 “이게 실제로 뭘 의미하는지”를 AI와 같이 차근차근 확인하는 습관이 결국 가장 든든한 방어선이라는 걸 다시 한번 느낀 하루였다.
사실 비슷한 일이 처음은 아니다. 예전에도 깃허브 알림 하나에 놀라서 뭔가 큰일이 난 줄 알았는데, 알고 보면 그냥 자동화 스크립트가 정상적으로 돌아가고 있다는 신호였던 적이 몇 번 있었다. 그때마다 느끼는 건 똑같다. “알림”과 “경고”는 다르고, 그걸 구분하는 기준은 색깔이 아니라 그 안에 들어있는 내용이라는 것. 이번에는 다행히 AI와 함께 git 명령어 몇 줄로 금방 확인이 됐지만, 만약 혼자 판단했다면 괜히 멀쩍한 PR을 만들었다가 다시 닫는 수고를 했을 수도 있었겠다 싶다.
또 하나 짚고 넘어가고 싶은 건, 이런 “결과물 전용 브랜치” 구조 자체는 꽤 쓸만한 방식이라는 점이다. 매일 생성되는 이미지나 산출물을 코드 저장소와 분리해서 쌓아두면, main 브랜치 히스토리가 깔끔하게 유지된다. 처음엔 “왜 저렇게 따로 만들었을까” 싶었는데, 막상 구조를 들여다보니 오히려 합리적인 설계였다. 비개발자인 내가 보기에 낯설다고 해서 그게 잘못된 설정이라고 단정할 이유는 없었다.
앞으로는 이런 알림을 받으면 바로 “버튼 누르기”로 넘어가지 않고, 먼저 “이 브랜치가 어디서 왔고 뭘 담고 있는지”를 한 번 확인하는 단계를 넣기로 했다. 손이 조금 더 가더라도, 성급하게 조치했다가 되돌리는 것보다는 낫다는 걸 이번에 다시 배웠다. 결국 AI를 도구로 잘 쓰는 방법도 비슷하다. 첫 답을 그대로 믿기보다, “확인해보니 어땠는지”를 한 번 더 물어보는 쪽이 늘 더 안전했다.