C. 그럼 저도 커밋하고 푸시할게요~!
문과생이 일주일 만에 터미널과 친구가 되기까지
외부 미팅 후 예쁜 삼청동 카페에서 일하던 날
대표님이 말했다.
“아, 이제 퇴근하자. 커밋하고 푸시해야지.”
작업하던 Claude Code 창을 바라보며
나도 말했다.
“그럼 저도 커밋하고 푸시할게요~!”
말이 끝나자마자, 우리 둘 다 동시에 빵 터졌다.
개발자들의 언어가 어느새
내 손과 입에 자연스럽게 붙고 있었다.
불과 몇 달 전만 해도
이 단어들을 개발자와 일할 때 들어본 수준이지
제대로는 몰랐던 문과 출신 PM이었는데 말이다.
그런 내가 지금은 매일 클러드코드에 '커밋하고 푸시해 줘'라고 입력하고
커밋과 빌드와 배포의 차이를 깨달으며 프로덕트를 만든다.
어두컴컴한(?) 터미널과 친해지기
프로덕트 엔지니어로 직무를 전환한 뒤
가장 먼저 마주한 벽은 터미널이었다.
처음 터미널을 열었던 순간은 아직도 생생하다.
검은 화면, 흰 글자, 깜빡이는 커서.
잘못 입력하면 뭔가 큰일이 날 것 같은 비주얼
…
“cd”, “ls”, “mkdir”, “pwd”
기본 명령어조차 입력할 때 오타가 나고,
열심히 외워도 막상 까만 창 앞에서는
다시 노트를 뒤적였다
특히 3일 차가 가장 괴로웠다.
‘왜 내가 이걸 이렇게 못 하지?’
싶은 생각이 계속 들었지만
다행히 딱 7일 만에 그 벽이 무너졌다.
일주일쯤 지나자
cd workspace + claude
좀 더 지나고는 cd work + tap + claude
지금은 z work + claude
익숙한 단축키처럼 명령어들이
손에 자연스럽게 붙기 시작했다.
‘아! 그냥 이것도 하나의 툴이었구나’
처음엔 터미널이 너무 낯설고 무서웠는데
곰곰이 생각해 보니
이 감정은 처음 느껴보는 게 아니었다.
처음 프리미어 프로를 배울 때도 그랬다.
타임라인이 뭔지, 렌더링이 뭔지…
모든 게 낯설었다.
오디오 콘솔 앞에 처음 앉았을 때도 마찬가지였다.
수십 개의 페이더와 버튼 사이에서
“1번 마이크 올려야 하는데 3번을 올리면 어쩌지?”
그 불안감 때문에 진짜로 실수도 했다.
피그마, 엑셀, SQL도 다 똑같았다.
그렇다면 개발 툴 역시 비개발자 입장에서
용어와 화면이 낯설어서 무서운 것이지,
어려워서 못할 건 아니었다.
(근데 뭔가 유난히 어려워 보이는 건 있다 ㅎㅎ)
작업 툴은 언제나
‘모르는 상태 → 어색한 상태 → 손에 익는 상태’
이 세 단계를 거치는 것 같은데
바이브 코딩에서는 AI가 코드를 쓰기 때문에
터미널과 클러드코드도 하나의 도구일 뿐이다.
그리고 많은 분들이 겁내는 것과 달리
로컬(내 컴퓨터)에서 작업하는 걸로는
프로덕트를 망치지 않는다(!!)
그 코드가 머지되고 배포되어 나갔을 때가 문제지...
commit & push 했는데
왜 배포가 안 된 거야?
하루는 작업을 마치고 기분 좋게 퇴근했는데,
다음 날 보니 내가 만든 기능이 하나도 반영되지 않았다.
처음엔 당황했고, 그다음엔
'극복했다고 생각했던 개발 울렁증 다시 시작인가?'
싶은 마음도 들었다.
“어제 커밋도 했고 푸시도 했는데…
도대체 뭐가 문제지?”
파이어베이스로 넘어가 출시 상태를 확인하자
빌드 에러가 한두 개도 아니고 가득 쌓여 있었다.
순간 멘붕이 왔다.
특히 영상 편집할 때는 가끔 에러가 나거나 작업이 날아갈 때가 있어서
혹 어제 작업한 내역이 다 사라졌을까봐 불안했다.
하지만 여기서 물러서면
내가 터미널 & Claude Code를
극복했다고 할 수 없지!
그래서 클로드코드에게 말했다.
“빌드 에러 났어. 뭐가 문제야?”
Claude Code:
“에러 코드를 가져오세요.”
나는 에러 로그를 몽땅 긁어서 넘겼다.
그러자 클러드코드는
A, B, C 원인을 하나씩 찾아내고,
자동으로 고치고 고치고 고치고…
나는 그걸 확인하고
다시 푸시 → 푸시 → 푸시
이런 식으로 결국 문제를 해결했다.
개발자에게 묻지 않고, AI에게 물으면서 말이다.
(이 날 이후로 firebase 빌드, 출시창을 종종 확인하면서 작업을 하는 습관이 생겼다!)
덕분에 다시 한번 개념을 짚고 넘어갈 수 있었다.
커밋(commit)
→ 내 로컬(내 컴퓨터)에서 변경 사항을 스냅샷처럼 저장하는 것
푸시(push)
→ 그 스냅샷들을 원격 저장소(GitHub 등)로 업로드하는 것
빌드(build)
→ 코드를 실제 실행 가능한 형태로 변환하는 과정
(Firebase Hosting은 배포 전에
반드시 빌드를 통과해야 한다)
배포(deploy)
→ 빌드된 결과물을 실제 서비스 환경(Production)에 올리는 것
그동안 나에게 헷갈리던 개념들이 에러 해결과 함께
한 번에 확 와닿았다.
영역의 경계가 사라지며, 문과생도 앱을 만들 수 있는 시대
앞으로의 세상은 더 이상
“이건 디자이너만 할 수 있어”
“이건 개발자 영역이야”
라는 말이 크게 의미가 없을 것이다.
이미 비전공자도 Nano Banana, Midjourney로
이미지를 만들고
작곡 지식 없어도 Suno로 노래를 만들고
영상 지식 없어도 Runway로 편집하고
개발자가 아니어도 Claude Code로 앱을 만든다
전문성의 깊이는 여전히 중요하지만
시작을 막는 장벽은 거의 사라져 간다.
며칠 전 AI 데이터 사이언스 분야
석박사 과정을 밟고 있는
컴공 출신의 교회 동생과 얘기를 했는데
대학원 학습 플로우도 많이 바뀌었다고 한다.
이전엔 개념을 완전 흡수하고 시작했다면
지금은 하면서 계속 지식을 추가하는 형태로.
스타트업의 애자일한 개발 모델처럼
애자일한 학습 + 직접 해보는 것이
AI 시대 나의 한계를 무너뜨리는 핵심이 될 것 같다.
“근데 이게 내 실력인가? 내가 만든 거라고 해도 되나?”
코드를 쓸 줄 모르는데도
카카오 로그인도 붙이고, 알림톡도 붙이고
프로덕트를 0 to 1으로 완성하는 과정에서
마음이 불편한 지점이 있었다.
‘기초 없이 붕 떠 있는 상태에서
결과만 나오는 것 같은데… 괜찮은 걸까?’
하지만 이 질문 자체가
AI 시대에는 더 이상 유효하지 않은
‘과거 방식’의 사고이다.
과정을 들여다보면
AI는 그저 코드를 쓰는 손을 대신하는 도구일 뿐,
어떤 문제를 해결할지 정의하고
무엇을 만들지 결정하고
품질을 판단하고
맥락을 넣고
최종 방향을 잡는 일은
온전히 내 몫이다.
근데 이게 어쩌면
AI 시대의 ‘새로운 능력 그리고 실력’일 수도!
개발자도 아니고, 완전한 비개발자도 아닌그 어딘가의 Product Engineer
물론 프로덕트 엔지니어라고 내가 갑자기 엄청난 개발 스킬을 갖게 된 것은 아니다.
며칠 전 Claude Code에게 물어보니
나는 ‘AI 개발 툴을 PM/디자이너처럼 활용하는 타입’이라고 한다.
처음엔 역시 엔지니어라기엔 부족하구나라고
해석했는데 곧 그 말이 정확하다는 걸 깨달았다.
애초에 단기간에 개발 지식을 폭발적으로 쌓는 것은 불가능하다.
중요한 건, AI를 통해 내가 내 역량을 뛰어넘는 결과물을 만들어내고 있다는 사실이었다.
“당신은 개발 툴을 PM/디자이너처럼 사용하고 있어요.”
생각해 보니, 그게 바로
AI 시대 협업의 새로운 형태가 아닐까?
개발자는 개발자의 전문성을 가지고
AI를 활용하고
PM은 PM의 전문성을 확장하는 방식으로
AI를 사용하고
디자이너는 디자인 감각을 기반으로
AI를 활용하는 것
각자의 전문성을 유지한 채
AI를 중심으로 새로운 방식의 협업이 가능해지는 시대.
나는 그 변화를 가장 먼저 체험하고 있다.
