AI에게 똑같이 시켰는데 왜 결과가 다른가요?

강사가 입력한 문장을 그대로 따라 했는데 내 화면은 다르게 나올 수 있습니다. 어제 잘되었던 요청을 오늘 다시 했더니 AI가 다른 코드를 작성하기도 해요.

같은 문장을 입력했는데
왜 결과가 다르죠?

내가 잘못 입력했거나 AI가 고장 난 것일까요?

꼭 그렇지는 않습니다. 생성형 AI는 전통적인 프로그램처럼 같은 입력에 항상 하나의 정답만 돌려주는 도구가 아니에요. 가능한 여러 결과 중에서 상황에 맞는 답을 생성합니다.

이런 성질을 비결정성이라고 부릅니다.

AI가 코드를 작성하더라도 사람이 기본 원리와 판단 기준을 알아야 하는 이유는 AI 시대에도 프로그래밍 기초를 배우는 이유에서 먼저 확인할 수 있습니다.

계산기와 생성형 AI는 작동 방식이 달라요

계산기에 2 + 2를 입력하면 언제나 4가 나옵니다.

같은 입력
→ 정해진 규칙
→ 같은 결과

일반적인 프로그램도 조건과 상태가 같다면 같은 동작을 하도록 만듭니다.

생성형 AI는 문장의 다음 부분에 올 가능성이 높은 선택지를 계속 고르면서 응답을 만듭니다. 코드도 하나의 정답을 꺼내는 것이 아니라 요청과 맥락을 바탕으로 새로 생성해요.

같은 요청
→ 가능한 해결 방법이 여러 개
→ 그중 하나를 선택하며 생성
→ 결과가 달라질 수 있음

로그인 페이지 하나도 여러 구조와 디자인으로 만들 수 있습니다. 버튼 색상, 파일을 나누는 방법, 사용할 라이브러리, 오류를 처리하는 방식에 하나의 정답만 있는 것은 아니에요.

“똑같은 요청”이 실제로는 똑같지 않을 수 있어요

사용자가 입력한 마지막 문장이 같아도 AI가 보는 전체 상황은 다를 수 있습니다.

클로드코드(Claude Code)는 지금 보낸 문장만 보는 것이 아닙니다.

• 앞에서 나눈 대화
• 현재 프로젝트의 파일
• CLAUDE.md 같은 프로젝트 지침
• 설치된 라이브러리
• 이미 만든 기능
• 현재 발생한 오류
• 실행 결과와 도구 출력

이 모든 것이 AI가 참고하는 컨텍스트가 됩니다.

마지막 요청은 같음
+ 이전 대화가 다름
+ 프로젝트 파일이 다름
+ 설치된 도구가 다름
→ 실제 입력 조건은 다름

강사의 프로젝트에는 이미 공통 버튼 컴포넌트가 있고, 내 프로젝트에는 없을 수 있습니다. 같은 “신청 버튼을 만들어줘”라는 요청에도 AI가 다른 코드를 쓰는 것이 자연스러워요.

컨텍스트가 AI 작업에 미치는 영향은 컨텍스트 윈도우란 무엇인지 설명한 글에서 더 자세히 볼 수 있습니다.

프로젝트 상태가 조금만 달라도 결과가 달라져요

같은 수업을 따라가도 중간 상태는 조금씩 달라질 수 있습니다.

누군가는 버튼 색상을 한 번 수정했고, 다른 사람은 원래 상태일 수 있어요. 설치 과정에서 라이브러리 버전이 달라졌거나, 이전 오류를 해결하면서 다른 파일이 수정되었을 수도 있습니다.

AI는 현재 프로젝트를 읽고 그 상태에 맞춰 작업합니다.

A 프로젝트
→ 기존 구조에 맞춰 파일 하나 수정

B 프로젝트
→ 필요한 구조가 없어 새 파일 여러 개 생성

결과 파일이 강사와 다르다고 바로 잘못된 것은 아닙니다. 먼저 원하는 기능이 작동하는지와 프로젝트의 기존 구조에 맞는지를 확인해야 합니다.

모델과 도구가 달라도 결과가 달라질 수 있어요

사용하는 AI 모델이 다르면 코드를 작성하는 성향과 문제를 푸는 방식도 달라질 수 있습니다.

같은 모델이라도 업데이트되면 이전보다 지시를 더 잘 따르거나 다른 도구를 선택할 수 있어요. 클로드 채팅, 코워크, 클로드코드처럼 사용하는 제품이 다르면 접근할 수 있는 파일과 도구도 다릅니다.

모델
+ 제품
+ 사용 가능한 도구
+ 권한
→ 작업 방식의 차이

따라서 몇 달 전 영상에서 나온 화면과 지금 화면이 다를 수도 있습니다. 오래된 결과를 정확히 복제하는 것보다 현재 환경에서 목표를 달성하는 것이 중요해요.

클로드 제품의 역할 차이는 클로드 채팅·코워크·클로드코드 비교 글에서 확인할 수 있습니다.

다른 결과가 항상 나쁜 것은 아니에요

AI가 매번 완전히 같은 결과만 만든다면 새로운 상황에 맞게 대응하기 어렵습니다.

현재 프로젝트의 디자인을 읽고 어울리는 버튼을 만들거나, 설치된 라이브러리를 재사용하고, 기존 코드 구조에 맞춰 파일을 배치하는 능력은 생성형 AI의 장점입니다.

결과가 달라짐
→ 무조건 오류

가 아니라 다음처럼 봐야 합니다.

결과가 달라짐
→ 현재 맥락에 맞춘 다른 해결 방법일 수 있음
→ 목표와 기준으로 평가

문제는 결과가 다르다는 사실이 아니라, 좋은 결과인지 판단할 기준이 없는 것입니다.

화면을 똑같이 만드는 것보다 완료 기준을 맞추세요

수업에서 신청 폼을 만든다고 해볼게요. 강사의 버튼은 빨간색이고 내 버튼은 검은색일 수 있습니다. 파일 이름과 코드 줄 수도 다를 수 있어요.

중요한 기준은 다음과 같습니다.

• 이름과 이메일을 입력할 수 있는가?
• 필수 값을 비우면 안내가 나오는가?
• 제출하면 데이터가 저장되는가?
• 중복 제출을 막거나 처리하는가?
• 모바일에서도 사용할 수 있는가?

이처럼 기능이 완료되었다고 판단할 조건을 완료 기준이라고 할 수 있습니다.

강사와 코드가 같은가?
→ 핵심 기준이 아님

원하는 기능과 조건을 충족하는가?
→ 핵심 기준

AI 결과를 안정적으로 관리하려면 “똑같이 만들어줘”보다 성공한 상태를 구체적으로 설명해야 합니다.

요청을 구체적으로 쓰면 차이를 줄일 수 있어요

결과를 완전히 고정할 수는 없지만 AI가 선택해야 하는 빈칸을 줄이면 원하는 방향에 가까워집니다.

로그인 페이지 만들어줘.

보다 다음 요청이 더 구체적입니다.

이메일과 비밀번호로 로그인하는 페이지를 만들어줘.

- 기존 버튼 컴포넌트를 재사용
- 모바일에서 한 줄이 잘리지 않게 구성
- 필수 값을 비우면 각 입력창 아래에 안내
- 로그인 중에는 버튼 비활성화
- 실패하면 서버의 비밀 정보 없이 사용자용 메시지 표시

구현 전에 수정할 파일과 완료 기준을 먼저 설명해줘.

Anthropic의 프롬프트 가이드도 원하는 결과와 맥락을 명확히 제공하고, 구체적이고 측정 가능한 성공 기준을 정하는 것을 권합니다.

핵심은 긴 프롬프트가 아니라 결정해야 할 중요한 조건을 빠뜨리지 않는 것입니다.

예시를 주면 디자인 차이도 줄어들어요

말로만 “깔끔하고 세련되게”라고 하면 사람마다 떠올리는 화면이 다릅니다. AI도 마찬가지예요.

원하는 화면의 스크린샷, 참고 사이트, 현재 서비스의 다른 페이지를 보여주면 선택 범위를 줄일 수 있습니다.

깔끔하게 만들어줘.
→ 해석 범위가 넓음

첨부한 화면의 여백과 카드 구조를 따르되,
현재 프로젝트의 색상과 폰트를 유지해줘.
→ 기준이 구체적

다만 참고 이미지를 주더라도 그대로 복사될 것이라고 기대하면 안 됩니다. 무엇을 참고해야 하는지 함께 설명하세요.

• 전체 레이아웃
• 색상
• 글자 크기
• 간격
• 버튼 위치
• 모바일 구조

한 번에 크게 시키면 결과 차이도 커져요

“쇼핑몰 전체를 만들어줘”처럼 범위가 큰 요청에는 AI가 결정해야 할 내용이 많습니다.

상품 구조
결제 방식
회원 기능
주문 상태
관리자 권한
디자인
오류 처리

결정할 항목이 많을수록 실행할 때마다 다른 선택이 나올 가능성도 커집니다.

기능을 작은 단위로 나누면 매 단계에서 방향을 확인할 수 있어요.

상품 목록 화면
→ 확인

상품 상세 화면
→ 확인

장바구니 담기
→ 확인

주문 정보 입력
→ 확인

작게 나누는 이유는 AI가 코드를 못 써서가 아닙니다. 사람이 결과를 이해하고 수정 방향을 정할 수 있게 하기 위해서예요.

AI와 기능을 얼마나 작게 나눠야 하는지에서 구체적인 기준을 확인할 수 있습니다.

결과가 다르면 다시 생성하기보다 먼저 비교하세요

원하는 결과가 나오지 않았을 때 같은 요청을 반복해서 보내는 경우가 많습니다.

다시 해줘.
다시 만들어줘.
처음부터 해줘.

운이 좋으면 마음에 드는 결과가 나올 수 있지만, 무엇이 문제였는지 알려주지 않았기 때문에 또 다른 방향으로 갈 수도 있어요.

먼저 차이를 구체적으로 말하는 편이 좋습니다.

기능은 작동하지만 내가 원한 결과와 세 가지가 달라.

1. 폼 너비가 너무 넓어.
2. 오류 메시지가 입력창과 멀리 떨어져 있어.
3. 기존 헤더가 사라졌어.

현재 코드를 전부 다시 만들지 말고,
세 가지 차이의 원인을 확인한 뒤 수정 계획을 알려줘.

마음에 들지 않는 결과를 폐기하기 전에 작동하는 부분과 수정할 부분을 나누세요.

다른 결과를 만났을 때 확인할 순서

강의나 예제와 다른 결과가 나왔다면 다음 순서로 확인하세요.

1. 목표가 달성되었나요?

파일 이름이나 코드 줄 수보다 필요한 기능이 작동하는지 봅니다.

2. 프로젝트 상태가 같은가요?

앞 단계가 빠졌거나 기존 파일과 설치된 라이브러리가 다른지 확인합니다.

3. 요청에 빈칸이 많았나요?

AI가 대신 결정한 디자인, 데이터 구조, 권한 규칙이 무엇인지 확인합니다.

4. 완료 기준이 있었나요?

무엇을 만족해야 성공인지 구체적인 조건을 만듭니다.

5. 다시 만들 필요가 있나요?

작동하는 부분을 유지하고 차이만 수정할 수 있는지 먼저 봅니다.

AI에게는 다음처럼 요청할 수 있어요.

예상한 결과와 현재 결과가 달라.

현재 구현이 어떤 방식으로 만들어졌는지 먼저 설명해줘.
요구사항을 충족한 부분과 충족하지 못한 부분을 나눠줘.
전체를 다시 만들지 말고 필요한 부분만 수정하는 계획을 제안해줘.

완전히 같은 결과보다 안정적인 개발 흐름이 중요해요

생성형 AI의 결과를 매번 한 글자까지 같게 만드는 것은 현실적인 목표가 아닙니다.

대신 작업 과정을 안정적으로 만들 수 있습니다.

목표 정하기
→ 완료 기준 작성
→ 작은 단위로 구현
→ 직접 결과 확인
→ 차이를 구체적으로 피드백
→ 작동하는 시점에 commit

이 흐름이 있으면 AI가 다른 코드를 작성하더라도 원하는 방향으로 계속 조정할 수 있습니다.

정리

• 생성형 AI는 같은 요청에도 여러 가능한 결과 중 하나를 생성합니다.
• 마지막 문장이 같아도 이전 대화, 프로젝트 파일, 지침과 도구가 다르면 실제 컨텍스트는 다릅니다.
• 모델과 제품, 프로젝트 상태에 따라서도 작업 방식이 달라질 수 있습니다.
• 강사와 코드가 같은지보다 원하는 기능과 조건을 충족하는지가 중요합니다.
• 구체적인 요구사항과 완료 기준을 주면 결과의 차이를 줄일 수 있습니다.
• 큰 요청은 AI가 대신 결정할 항목이 많으므로 작은 기능으로 나누는 편이 좋습니다.
• 결과가 다르면 다시 생성하기 전에 충족한 부분과 수정할 부분을 비교하세요.

핵심은 다음과 같습니다.

같은 요청
≠ 항상 같은 결과

명확한 목표 + 완료 기준 + 결과 확인
→ 다른 결과도 원하는 방향으로 관리

바이브코딩은 AI에게 완벽한 한 문장을 입력해 정답을 받는 일이 아닙니다. 결과를 확인하고, 차이를 설명하고, 다음 작업을 선택하면서 소프트웨어를 함께 만들어가는 과정입니다.

요구사항과 제약을 실제 프롬프트로 바꾸는 연습은 바이브코딩 가이드 3장에서 이어갈 수 있습니다.