18장. AI와 협업할 때 꼭 지켜야 할 작업 습관

지난 장까지 오면서 우리는 커밋, 브랜치, PR이 왜 필요한지 배웠습니다. 이제 여기에 한 가지가 더 붙습니다. 바로 AI와 함께 일할 때의 습관입니다.

많은 초보자가 AI를 처음 쓰면 이렇게 생각합니다.

"많이 시킬수록 더 빨리 끝나지 않을까?"

겉보기에는 맞는 말처럼 들립니다. 하지만 실제 작업에서는 정반대인 경우가 많습니다. 한 번에 너무 많이 시키면 결과가 길어지고, 어디가 바뀌었는지 흐려지고, 잘못된 부분을 발견하기도 어려워집니다. 특히 초보자에게는 더 그렇습니다.

AI와 잘 일하는 사람은 많이 시키는 사람이 아닙니다. 안전하게 시키는 사람입니다.

이 장에서는 바로 그 안전한 습관을 익힙니다. 작게 시키기, 중간 점검하기, 변경 전에 커밋하기, 민감한 정보는 분리하기, 받은 결과를 바로 믿지 않기. 이 습관들은 화려하지 않지만, 실제로 서비스를 끝까지 완성하게 만드는 힘입니다.

AI는 똑똑한 조수지만, 프로젝트의 책임자는 나다

Claude Code든 Codex든, AI 코딩 도구는 정말 빠릅니다. 파일 구조를 제안하고, 코드도 써 주고, 에러 원인도 함께 추적해 줍니다. 초보자 입장에서는 마치 숙련된 개발자가 옆에서 도와주는 느낌이 들 수 있습니다.

그런데 여기서 꼭 기억해야 할 것이 있습니다.

AI는 작업을 도와주는 조수이지, 프로젝트의 최종 책임자가 아닙니다.

무슨 말일까요? AI는 제안할 수 있고, 생성할 수 있고, 수정할 수 있습니다. 하지만 그 코드가 지금 내 서비스에 맞는지, 기존 기능을 깨뜨리지 않는지, 보안상 괜찮은지까지 끝까지 책임져 주지는 않습니다. 그 판단은 결국 사람이 해야 합니다.

이 말을 너무 무겁게 받아들일 필요는 없습니다. "내가 다 알아야 한다"는 뜻은 아닙니다. 대신 이런 감각을 가지면 됩니다.

AI는 운전대를 잡아주는 존재가 아니라, 내 옆에서 길을 잘 찾게 도와주는 네비게이션에 가깝다.

길을 추천할 수는 있어도, 브레이크를 밟을지 말지는 내가 정해야 합니다.

한 번에 크게 맡기면 왜 위험할까

초보자가 AI와 협업할 때 가장 자주 하는 실수는 작업을 너무 크게 던지는 것입니다.

예를 들어 이런 요청은 위험합니다.

"로그인, 회원가입, 글 작성, 검색, 배포까지 한 번에 다 해줘."

이 문장은 시원해 보이지만 실제로는 문제가 많습니다. 작업 범위가 너무 넓어서, AI가 무엇을 어디까지 바꿨는지 파악하기 어렵습니다. 파일 수가 확 늘어나고, 기존 코드와 충돌할 수도 있고, 중간에 어디서 꼬였는지도 찾기 힘들어집니다.

반대로 이렇게 나누면 훨씬 안전합니다.

• 로그인 화면 UI 만들기

• 로그인 동작 연결하기

• 로그인 실패 메시지 처리하기

• 로그인 후 이동 흐름 점검하기

이렇게 쪼개면 장점이 분명합니다. 무엇이 되었고 무엇이 아직 안 되었는지 바로 보입니다. 문제가 생겨도 범위가 작아서 다시 설명하거나 되돌리기 쉽습니다.

AI는 큰일도 할 수 있습니다. 하지만 큰일을 잘게 나눠 맡길 때 훨씬 더 믿을 만한 결과를 줍니다.

좋은 협업은 '큰 요청'이 아니라 '짧은 왕복'에서 나온다

AI와의 작업은 한 번의 완벽한 요청으로 끝내는 게임이 아닙니다. 오히려 여러 번 짧게 주고받으면서 결과를 다듬는 쪽이 훨씬 현실적입니다.

예를 들어 글 작성 기능을 붙인다고 해 봅시다. 초보자에게 안전한 흐름은 보통 이렇습니다.

먼저 글 작성 페이지에 어떤 입력칸이 필요한지 정리합니다. 그다음 폼 UI만 만듭니다. 이후 저장 버튼 클릭 시 어떤 동작이 필요한지 연결합니다. 마지막에 실패 메시지, 로딩 상태, 입력 검증을 붙입니다.

이 과정은 느려 보일 수 있습니다. 하지만 실제로는 더 빠릅니다. 중간마다 결과를 확인할 수 있기 때문입니다.

한 번에 크게 가는 방식은 처음엔 빨라 보여도, 나중에 엉킨 실타래를 푸느라 시간을 많이 씁니다. 반대로 짧은 왕복을 자주 하는 방식은 중간중간 방향을 바로잡을 수 있어서 전체 속도가 오히려 안정적입니다.

개발에서는 전속력보다 안전한 속도 유지가 더 중요합니다.

작업 시작 전, 먼저 현재 상태를 고정하자

AI에게 중요한 변경을 맡기기 전에 가장 먼저 할 일은 멋진 프롬프트 작성이 아닙니다.

지금 상태를 안전하게 남기는 것입니다.

앞 장에서 배운 것처럼, 변경 전 커밋은 아주 강력한 안전장치입니다. 여기에 브랜치까지 더하면 훨씬 좋습니다. 지금 잘 돌아가는 상태를 남겨 두고 나서 AI와 실험을 시작하면, 마음이 훨씬 편해집니다.

왜냐하면 잘못돼도 돌아갈 곳이 있기 때문입니다.

초보자가 AI와 협업하다가 가장 당황하는 순간은 이런 때입니다.

"분명 고쳐 달라고 했는데, 원래 되던 것까지 안 돼요."

이때 변경 전 커밋이 없다면 정말 난감합니다. 어디까지가 원래 상태였는지 기억도 흐려지고, 손으로 다시 되돌리려다 더 꼬이기도 합니다.

그래서 큰 변경 전에는 이 한 문장을 습관처럼 떠올리면 좋습니다.

지금 상태, 다시 돌아올 수 있나?

이 질문에 자신 있게 "네"라고 답할 수 있으면 그다음이 훨씬 덜 무섭습니다.

AI에게 맡기기 전, 이번 작업의 경계를 먼저 그어라

AI는 빈칸을 잘 채웁니다. 문제는 그 빈칸이 내 의도와 다를 수 있다는 것입니다. 그래서 일을 맡기기 전에는 이번 작업의 경계를 먼저 그어야 합니다.

예를 들어 "글 목록 화면을 다듬어 달라"고 말하면, AI는 스타일만 만질 수도 있고, 구조를 바꿀 수도 있고, 새 컴포넌트를 만들 수도 있습니다. 심지어 라우팅 방식이나 데이터 가져오는 흐름까지 손댈 수 있습니다.

하지만 이번 작업이 정말 스타일 정리만 목적이라면, 그렇게 넓게 바뀌면 안 되겠죠.

이럴 때는 경계를 분명히 말해야 합니다.

이번 작업에서 수정 가능한 파일이 무엇인지, 무엇은 건드리지 말아야 하는지, 새 라이브러리를 추가해도 되는지, 데이터베이스 구조 변경은 포함하지 않는지 같은 선을 미리 정하는 것입니다.

쉽게 말해, AI에게 일을 맡길 때는 "이 안에서만 움직여 주세요"라는 작업 울타리를 쳐 주는 것이 좋습니다.

울타리가 없으면 AI는 열심히 달리지만, 내가 원하던 길과 멀어질 수 있습니다.

결과를 받았을 때 바로 붙여넣지 말자

AI가 코드를 내놓으면 가장 먼저 드는 생각은 대개 이겁니다.

"오, 그럴듯한데? 일단 넣어 볼까?"

물론 직접 적용해 보는 것도 필요합니다. 하지만 바로 믿고 붙여넣는 습관은 위험합니다.

왜냐하면 AI의 답은 그럴듯해 보여도, 지금 프로젝트에 딱 맞는다는 보장은 없기 때문입니다. 파일 이름이 다를 수 있고, 이미 있는 함수와 겹칠 수 있고, 필요 없는 패키지를 끌고 올 수도 있습니다. 심지어 되는 것처럼 보여도 나중에 다른 화면을 깨뜨릴 수 있습니다.

그래서 결과를 받으면 먼저 짧게라도 검토해야 합니다. 이때 초보자가 꼭 확인하면 좋은 것은 아래 네 가지입니다.

• 내가 시킨 범위 안의 변경인가

• 수정 파일 수가 예상보다 지나치게 많지 않은가

• 기존 기능을 깨뜨릴 가능성이 보이지 않는가

• 내가 대략이라도 이해할 수 있는 구조인가

여기서 중요한 것은 완벽하게 이해하는 것이 아닙니다. 최소한 "왜 이 파일이 바뀌는지" 정도는 감이 와야 한다는 뜻입니다.

이해가 안 되면 부끄러워할 필요가 없습니다. 오히려 그때가 다시 물어볼 가장 좋은 순간입니다.

"지금 수정한 파일 각각의 역할을 쉬운 말로 설명해 주세요."

이 한 문장만으로도 AI의 답은 훨씬 친절해집니다.

중간 점검을 자주 해야 나중이 편해진다

AI와 협업할 때 흔한 착각이 하나 있습니다. "한 번 시켰으니 끝날 때까지 기다리자"는 생각입니다. 하지만 실제로는 중간 점검을 자주 하는 편이 훨씬 좋습니다.

예를 들어 UI를 만들고 있다면, 화면이 일단 보이는 시점에서 한 번 확인합니다. 버튼이 눌리는 단계가 되면 또 확인합니다. 서버 연결까지 붙었으면 그다음 확인합니다.

이렇게 하면 문제가 생겨도 "어디부터 이상해졌는지" 찾기가 쉬워집니다.

반대로 여러 단계를 한꺼번에 진행하면, 마지막에 문제가 터졌을 때 범위가 너무 넓어집니다. 화면 문제인지, 상태 문제인지, 서버 문제인지 구분하기 어려워집니다.

중간 점검은 시간을 잡아먹는 절차가 아니라, 나중의 고생을 줄이는 보험입니다.

중간 점검에서는 무엇을 봐야 할까

중간 점검이라고 해서 거창한 테스트를 떠올릴 필요는 없습니다. 초보자라면 먼저 아주 기본적인 것부터 보면 됩니다.

화면이 깨지지 않는지, 버튼이 눌리는지, 이동이 되는지, 에러가 콘솔에 쌓이지 않는지, 기존 페이지가 멀쩡한지 같은 것들입니다.

특히 AI가 만든 결과는 "주요 기능 하나는 되는데, 주변 기능이 미세하게 깨지는" 경우가 종종 있습니다. 그래서 내가 부탁한 기능만 보지 말고, 그 주변도 한 번 살펴봐야 합니다.

예를 들어 로그인 버튼을 붙였다면 로그인 화면만 보지 말고 홈 화면, 목록 화면, 헤더 영역도 다시 봅니다. 검색 기능을 붙였다면 검색 결과만 보지 말고 검색어가 없을 때, 결과가 없을 때도 함께 봅니다.

진짜 서비스는 늘 한 장면이 아니라 여러 장면으로 움직입니다.

"잘되면 끝"이 아니라 "안 될 때도 점검"해야 한다

AI가 만든 기능을 볼 때 초보자는 성공하는 장면만 확인하고 안심하는 경우가 많습니다. 하지만 서비스는 늘 사용자가 예상대로만 움직이지 않습니다.

로그인에서 비밀번호를 틀릴 수도 있고, 글 작성에서 제목을 비워 둘 수도 있고, 검색 결과가 하나도 없을 수도 있습니다. 인터넷 연결이 느릴 수도 있고, 서버에서 에러가 날 수도 있습니다.

그래서 결과를 검토할 때는 성공 장면뿐 아니라 실패 장면도 함께 봐야 합니다.

아주 간단한 질문만 던져도 도움이 됩니다.

• 입력값이 비어 있으면 어떻게 되는가

• 요청이 실패하면 사용자는 무엇을 보는가

• 로딩 중에는 버튼을 여러 번 눌러도 되는가

• 데이터가 없을 때 화면이 어색하지 않은가

이 질문을 하기 시작하면, AI가 만든 코드의 완성도를 훨씬 현실적으로 바라보게 됩니다.

AI에게 코드를 맡길수록 '바꾸지 말 것'도 분명히 말하자

많은 사람이 AI에게 "무엇을 해 달라"는 말은 잘합니다. 그런데 실제로 중요한 것은 "무엇을 하지 말아야 하는지"까지 말하는 것입니다.

특히 초보자 프로젝트에서는 이게 아주 중요합니다. AI는 종종 멋진 구조를 보여주고 싶어 합니다. 새 패턴을 도입하고, 파일을 늘리고, 아직 배우지 않은 추상화를 가져오기도 합니다. 언뜻 좋아 보이지만, 초보자에게는 오히려 이해 부담이 커질 수 있습니다.

그래서 이런 금지선이 필요합니다.

• 새로운 라이브러리는 추가하지 않기

• 기존 폴더 구조를 크게 바꾸지 않기

• 데이터베이스 구조는 건드리지 않기

• 디자인 전체 리뉴얼은 하지 않기

• 이번 작업 범위를 넘는 기능은 넣지 않기

이런 제약은 AI의 능력을 묶는 것이 아닙니다. 지금 단계에 맞게 능력을 쓰게 만드는 장치입니다.

민감한 정보는 절대 대화 속으로 흘려보내지 말자

이 장에서 특히 강조하고 싶은 습관이 하나 있습니다.

민감한 정보는 코드보다 먼저 분리하자.

초보자는 에러를 빨리 해결하고 싶은 마음에 이것저것 그대로 복사해 AI에게 붙여넣는 경우가 많습니다. 그런데 그 안에 비밀번호, API 키, 데이터베이스 접속 정보, 서비스 토큰 같은 민감한 값이 섞여 있을 수 있습니다.

이건 정말 조심해야 합니다.

예를 들어 .env.local 파일 안에는 외부 서비스 키가 들어갈 수 있습니다. Supabase 키, Vercel 관련 값, 비밀 토큰, 메일 발송 서비스 키 같은 것들입니다. 이런 값은 대화창에 그대로 공유하면 안 됩니다.

필요하다면 값 자체는 지우고, 구조만 보여 주세요.

예를 들면 이렇게 바꾸는 것입니다.

NEXT_PUBLIC_SUPABASE_URL=YOUR_URL
SUPABASE_SERVICE_ROLE_KEY=REDACTED

핵심은 "문제 상황을 설명하는 데 필요한 정보"와 "절대 노출하면 안 되는 정보"를 구분하는 것입니다.

AI는 도와줄 수 있지만, 내 서비스의 비밀값까지 대신 지켜주는 금고는 아닙니다.

환경변수는 숨겨야 할 것을 숨기는 기본 습관이다

민감 정보를 분리하는 가장 기본적인 방법은 환경변수를 사용하는 것입니다. 자세한 내용은 뒤의 배포 파트에서 다시 다루겠지만, 지금 단계에서도 감각은 잡아 두는 편이 좋습니다.

환경변수는 쉽게 말해, 코드 안에 직접 적지 말아야 할 값을 따로 보관하는 방식입니다. 예를 들어 API 키나 비밀 토큰을 코드 파일 안에 박아 두는 대신, .env.local 같은 파일에 넣어 두고 필요할 때 불러와 쓰는 것입니다.

왜 중요할까요? 이유는 단순합니다. 코드 파일은 여기저기 복사되기 쉽고, 커밋되기 쉽고, 공유되기 쉽기 때문입니다. 반면 환경변수로 분리해 두면 민감한 값을 더 조심스럽게 관리할 수 있습니다.

아직 완벽히 이해하지 못해도 괜찮습니다. 지금은 이 원칙만 기억하면 됩니다.

비밀값은 코드에 직접 쓰지 않는다. 대화창에도 그대로 붙이지 않는다.

이 습관 하나가 나중에 큰 사고를 막아 줍니다.

에러를 보여줄 때도 필요한 만큼만 보여 주자

에러가 나면 AI에게 로그를 보여주는 것은 아주 좋은 방법입니다. 다만 이때도 아무거나 통째로 붙여넣는 습관은 좋지 않습니다.

너무 긴 로그를 한꺼번에 주면 중요한 부분이 묻히고, 민감한 정보가 섞일 위험도 있습니다. 그래서 먼저 핵심 구간만 추려서 보여 주는 편이 좋습니다.

예를 들어 이런 식이 좋습니다.

에러가 난 시점, 실행한 행동, 콘솔에 나온 핵심 메시지, 관련 파일 이름, 내가 예상한 동작과 실제 동작의 차이를 함께 정리하는 것입니다.

이렇게 주면 AI도 훨씬 정확하게 도와줄 수 있습니다. 반대로 프로젝트 전체 로그를 통째로 붙이면, AI도 필요한 단서를 고르느라 오히려 더 헤맬 수 있습니다.

좋은 디버깅 대화는 정보가 적어서가 아니라, 필요한 정보가 선명해서 잘 됩니다.

AI가 제안한 코드는 '완성품'보다 '초안'으로 보는 편이 좋다

이 관점은 초보자에게 특히 유용합니다.

AI가 준 코드를 완성품으로 보면, 맞는지 틀린지 판단하기 어려워집니다. 하지만 초안으로 보면 태도가 달라집니다. "좋아, 출발점은 생겼네. 이제 내가 확인하고 다듬자"라는 마음이 됩니다.

이 차이는 생각보다 큽니다.

완성품이라고 믿으면 비판적으로 보기 어렵습니다. 반대로 초안이라고 생각하면, 어느 부분이 과한지, 무엇을 빼야 하는지, 지금 프로젝트에 맞는지 더 차분히 보게 됩니다.

특히 초보자일수록 이 시선이 필요합니다. 그래야 AI가 만든 결과에 끌려다니지 않고, 내 프로젝트 기준으로 선택할 수 있습니다.

AI 협업에서는 '설명 요청'이 아주 강력하다

초보자는 종종 코드만 받으려 합니다. 하지만 실제로는 설명을 함께 요구할수록 더 안전해집니다.

왜냐하면 설명을 들으면, 그 변경이 어떤 의도로 들어갔는지 파악할 수 있기 때문입니다. 또한 내가 모르는 개념이 숨어 있으면 그 자리에서 바로 질문할 수 있습니다.

예를 들어 이런 요청은 아주 유용합니다.

• 이번 변경에서 수정한 파일별 역할을 설명해 주세요.

• 왜 이 방식이 필요한지 초보자 기준으로 설명해 주세요.

• 더 단순한 방법이 있다면 함께 제안해 주세요.

• 지금 코드에서 나중에 문제가 될 수 있는 지점을 알려 주세요.

이렇게 물으면 AI는 단순 생성기에서 설명자이자 리뷰어 역할까지 하게 됩니다. 같은 도구를 훨씬 깊게 쓰게 되는 셈입니다.

작업 습관이 흔들리면, AI가 아니라 사람이 먼저 지친다

AI와 협업하다 보면 피곤해지는 순간이 있습니다. 이상한 답이 반복되고, 수정이 길어지고, 파일이 많아지고, 어디서부터 꼬였는지 모르겠는 상태가 됩니다.

이때 사람들은 종종 "모델이 별로인가?"라고 생각합니다. 물론 도구 차이도 있습니다. 하지만 실제로는 작업 습관이 흔들렸을 가능성이 더 큽니다.

한 번에 너무 많이 시키지 않았는지, 중간 점검을 건너뛰지 않았는지, 변경 전 커밋을 안 한 것은 아닌지, 민감한 정보까지 무심코 던지고 있지는 않은지 돌아봐야 합니다.

AI 협업에서 피로의 상당수는 도구의 한계보다 정리되지 않은 작업 흐름에서 나옵니다.

그래서 좋은 습관은 단순히 안전을 위한 것이 아닙니다. 오래 작업해도 덜 지치게 만드는 장치이기도 합니다.

초보자에게 추천하는 가장 안전한 AI 협업 루틴

이제 이 장의 내용을 아주 실전적으로 묶어 보겠습니다. 초보자라면 아래 루틴만 지켜도 훨씬 안정적으로 AI와 협업할 수 있습니다.

먼저 오늘 할 일을 하나만 정합니다. "로그인 버튼 만들기"처럼 한 문장으로 말할 수 있어야 합니다. 그다음 현재 안정 상태를 커밋하고, 필요하면 브랜치를 만듭니다.

이후 AI에게 이번 작업 범위만 설명합니다. 수정해도 되는 범위와 건드리면 안 되는 범위도 함께 말합니다. 답을 받으면 바로 적용하지 말고, 바뀐 파일과 방향부터 확인합니다.

그다음 직접 실행해서 중간 결과를 봅니다. 화면이 보이는지, 버튼이 눌리는지, 기존 기능이 깨지지 않았는지 확인합니다. 이상이 없으면 그 변화만 커밋합니다. 아직 이해가 안 되는 부분이 있으면 설명을 다시 요청합니다.

이 루틴은 요란하지 않습니다. 하지만 바로 이 단순함이 중요합니다. 개발 초보자에게 필요한 것은 번쩍이는 비법이 아니라, 반복 가능한 안전 루틴입니다.

꼭 기억할 작업 습관 다섯 가지

이 장의 핵심을 다섯 문장으로 줄이면 이렇습니다.

• 한 번에 많이 시키지 말고, 작게 나눠 시킨다.

• 중요한 변경 전에는 먼저 커밋한다.

• 중간 결과를 자주 실행하고 직접 확인한다.

• 비밀값과 민감 정보는 대화와 코드에서 분리한다.

• AI의 답은 완성품이 아니라 검토할 초안으로 본다.

이 다섯 가지는 단순하지만, 실제로 서비스가 망가지지 않게 지켜 주는 습관입니다.

AI와 잘 일하는 사람은 결국 안전한 사람이다

이 장을 마무리하며 가장 중요한 감각을 다시 붙잡아 봅시다.

AI와 협업할 때 실력은 단지 코드를 많이 아는 데서만 나오지 않습니다. 오히려 초보자 단계에서는 안전하게 시키고, 안전하게 받고, 안전하게 검토하는 습관이 훨씬 더 중요합니다.

작게 나누면 오해가 줄어듭니다. 중간 점검을 하면 문제를 빨리 찾을 수 있습니다. 변경 전 커밋을 하면 돌아갈 수 있습니다. 민감한 정보를 분리하면 사고를 막을 수 있습니다. 결과를 초안으로 보면 더 차분하게 판단할 수 있습니다.

이 습관들이 쌓이면 AI는 갑자기 덜 위험한 도구가 됩니다. 그리고 바로 그 지점에서, 초보자도 진짜 서비스를 끝까지 만들어 갈 수 있는 자신감을 얻게 됩니다.

다음 부부터는 이제 본격적으로 Claude Code와 Codex를 사용해 개발을 시작합니다. 하지만 그 전에 꼭 기억해 두세요.

AI와 잘 일하는 사람은 많이 시키는 사람이 아니라, 안전하게 시키는 사람입니다.