[카테고리:] 한국어

AI에게 로그인 앱을 만들어 달라고 하면, 보안을 하나하나 지시하지 않아도 여러 방어 기능이 함께 들어갈 수 있다. 이번 샘플은 요청한 대로 사용자별 메모를 분리했고 비밀번호 원문을 저장하지 않았으며, AI 코딩 도구(에이전트)가 앱과 함께 작성한 테스트 4개를 모두 통과했다.

그렇다고 바로 공개해도 된다는 뜻은 아니었다. 별도 검사를 해보니 다른 사용자의 자료 접근은 시험한 범위에서 막혔지만, 반복 로그인을 늦추거나 막는 장치는 시험한 12회 안에서 나타나지 않았다. 비밀번호와 로그인 상태(세션)를 보관하는 방식에도 공개 전에 결정하거나 고칠 부분이 남아 있었다.

이 글은 AI 코드 전체가 위험한지 판정하지 않는다. 2026년 8월 30일에 한 번 생성한 로컬 메모 앱 하나를 대상으로, 반복 로그인과 실패 처리를 확인했는가, 다른 사람의 자료를 막는가, 비밀번호와 로그인 상태를 어떻게 보관하는가라는 세 가지 검사 질문을 확인한 사례다.

무엇을 어떻게 확인했나

새 대화에서 Codex라는 AI 코딩 도구의 gpt-5.6-sol 모델에 회원가입·로그인·로그아웃과 사용자별 메모가 있는 로컬 앱을 만들어 달라고 했다. 비밀번호 저장 방식이나 로그인 시도 제한 같은 보안 정답은 알려주지 않았다. 에이전트가 기본적으로 무엇을 넣는지 보고 싶었기 때문이다.

먼저 에이전트가 앱과 함께 작성한 테스트를 실행했다. ① 관리자 정보 제한 ② 메모 저장 요청 보호 ③ 로그아웃 뒤 로그인 상태를 증명하는 임시 출입증인 세션의 무효화 ④ 사용자별 메모 분리와 코드처럼 보이는 문장의 안전한 표시를 확인하는 테스트가 모두 통과했다. 이어 같은 생성 파일을 수정하지 않고 내가 준비한 검사 스크립트(별도 검사기)로 실패할 때의 처리와 앱이 저장한 상태를 확인했다.

모든 시험은 내 컴퓨터 안에서만 접속되는 로컬 환경(주소 127.0.0.1)에서 가짜 사용자와 무효한 가짜 키만 사용했다. 실제 개인정보·업무 자료·결제 정보는 넣지 않았고, 앱을 외부에 공개하지 않았다.

세 가지 검사 질문의 결과를 먼저 요약하면 다음과 같다. 세 번째 질문은 비밀번호와 세션을 나눠 적었고, 자세한 과정은 이어지는 절에서 설명한다.

반복 로그인과 실패 처리를 확인했는가

검사. 존재하는 시험 계정에 틀린 비밀번호를 1초 간격으로 12번 입력했다. 존재하는 계정과 존재하지 않는 계정의 실패 문구·상태 코드·처리 시간을 비교했고, 중복 가입 응답과 제공된 생성 소스의 반복 시도 제한 구현도 확인했다.

관찰. 12번 모두 서버가 인증 실패를 뜻하는 표준 응답 번호 401을 돌려주는 일반적인 로그인 실패로 처리됐고, 그 안에서 차단이나 제한 신호는 보이지 않았다. 제공된 생성 소스와 실험 기록에서도 제한 구현을 확인하지 못했다. 이것만으로 무제한으로 시도할 수 있다고 단정할 수는 없지만, 적어도 관찰한 12회 안에서는 제한이 작동하지 않았다.

오류 문구는 두 계정 조건에서 같았지만 처리 시간 중앙값은 존재하는 계정 79.66ms, 존재하지 않는 계정 0.68ms였다. 코드를 보면 존재하는 계정에서만 비밀번호 비교 계산을 수행했다. 또한 중복 가입 요청은 “이미 사용 중인 이메일”이라는 문구로 계정 존재를 직접 알렸다.

독자에게 의미하는 것. 작은 로컬 시험이라 실제 공격 가능성을 입증하지는 않지만, 응답이 눈에 띄게 늦게 오는 이메일을 가입된 계정이라고 추정하는 단서가 될 수 있다. 미국 표준기술연구소(NIST)의 인증 지침과 웹 보안 커뮤니티 OWASP의 인증 지침은 반복적인 비밀번호 추측을 줄이기 위한 로그인 시도 제한을 다룬다. 공개 앱이라면 실패 횟수 제한이나 지연을 추가하고, 정상 사용자의 복구 방법과 누군가 일부러 오답을 반복해 남의 계정을 잠그는 악용 가능성도 함께 설계해야 한다. 같은 오류 문구가 나온다는 이유만으로 계정 정보가 충분히 숨겨졌다고 판단해서도 안 된다.

다른 사람의 자료를 막는가

검사. Alice와 Bob이라는 가짜 사용자를 만들고 서로 다른 메모를 저장했다. Bob의 요청으로 Alice의 표식이 보이는지 확인했으며, 가입 요청에 is_admin=1을 추가해 관리자 권한을 얻을 수 있는지도 시험했다. 화면에서 버튼이 보이는지가 아니라 서버가 돌려준 자료와 권한을 기준으로 판단했다.

관찰. Bob의 요청에 대해 서버가 돌려준 자료에는 Alice의 시험용 표식이 나타나지 않았다. 임의로 넣은 관리자 값도 무시됐고, 일반 사용자 권한으로는 관리자 자료가 반환되지 않았다. 에이전트가 만든 자체 테스트와 별도 검사에서 같은 방향의 결과가 나왔다.

독자에게 의미하는 것. 이 항목은 시험한 경로에서 통과했다. 그러나 “이 앱에는 타인 자료 노출이 없다”는 인증은 아니다. OWASP는 권한을 모든 요청에서 확인하라고 권고한다. 파일 공유, 메모 수정, 삭제, 검색처럼 기능이 늘어나면 새 요청마다 자료의 주인과 권한을 다시 확인해야 한다.

비밀번호와 로그인 상태를 어떻게 보관하는가

비밀번호

검사. 로컬 데이터베이스에 비밀번호 원문이 남는지, 같은 비밀번호를 쓴 두 계정의 저장값이 같은지, 어떤 계산 방식과 반복 횟수를 쓰는지 확인했다. 코드와 사용 설명서에 관리자 비밀번호가 직접 적혀 있는지, 검사 중 넣어 둔 가짜 API 키가 코드·응답·기록에 남는지도 살폈다.

관찰. 앱은 계정마다 다른 무작위 값을 섞어 비밀번호를 되돌릴 수 없는 계산값으로 바꾸는 표준 방식 중 하나인 PBKDF2-HMAC-SHA256으로 계산한 결과만 저장했다. 같은 비밀번호를 써도 두 계정의 저장값은 달랐고 원문은 없었다. 다만 반복 횟수는 200,000회였다. 2026년 9월 6일 다시 확인한 OWASP Password Storage Cheat Sheet는 같은 방식에 600,000회를 권고한다.

저장된 비밀번호와 별개로, 코드 안에 직접 적힌 비밀값도 살폈다. 시험용 관리자 계정의 기본 비밀번호는 코드와 사용 설명서에 그대로 적혀 있었다. 이번 앱에는 서비스 사용 권한을 담는 실제 API 키가 없었고, 검사에 사용한 가짜 키도 소스·응답·로그에서 발견되지 않았다. 따라서 “AI가 API 키를 유출했다”고 말할 수는 없다. 다만 실제 키나 결제와 연결된 비밀값을 같은 방식으로 코드에 적으면 다른 사람의 사용과 비용 발생으로 이어질 수 있다.

독자에게 의미하는 것. “비밀번호 원문이 없다”는 좋은 출발이지만 검토의 끝은 아니다. 실제 반복 횟수는 서버 성능을 측정해 정해야 하므로 숫자 하나만으로 취약 여부를 단정할 수는 없다. 그래도 비밀번호 계산 방식과 공격자가 추측 한 번에 써야 하는 계산량을 확인하고, 관리자 비밀번호·API 키 같은 비밀값은 코드와 설명서에서 분리해야 한다. 이미 노출된 실제 키는 파일에서 지우는 데 그치지 않고 폐기한 뒤 새로 발급해야 한다.

세션

로그인 뒤 사용자를 계속 증명하는 임시 출입증을 세션이라고 한다.

검사. 로그인할 때 새 세션이 발급되는지, 로그아웃한 세션을 다시 쓸 수 있는지, 다시 로그인한 뒤 이전 세션이 남는지, 만료 방식과 쿠키 설정을 확인했다.

관찰. 로그인할 때마다 새 세션 값이 발급됐고, 로그아웃에 사용한 세션은 서버에서 무효화됐다. 각 세션에는 로그인 시점부터 8시간이 지나면 끝나는 절대 만료가 있었다. 하지만 다시 로그인해 새 세션을 받아도 이전 세션은 그 유효기간이 끝날 때까지 계속 사용할 수 있었고, 일정 시간 사용하지 않으면 더 일찍 끝나는 유휴 만료는 없었다. 쿠키(브라우저가 세션 값을 보관하는 자리)에는 화면 스크립트가 값을 읽지 못하게 하는 HttpOnly와 다른 사이트에서 온 요청에 값을 보내지 않는 SameSite=Strict가 있었지만, 로컬 HTTP 앱이라 HTTPS에서만 전송하도록 하는 Secure는 없었다.

독자에게 의미하는 것. 이전 세션 유지가 곧 취약점이라는 뜻은 아니다. 여러 기기의 동시 로그인을 허용한 정책일 수도 있다. 다만 개인정보나 결제 정보를 다룬다면 동시 세션, 전체 로그아웃, 유휴 만료를 어떻게 운영할지 공개 전에 정해야 한다. 인터넷에 배포할 때는 HTTPS와 그에 맞는 Secure 쿠키 설정도 필요하다.

공개 전에 무엇부터 고칠까

이번 샘플은 기본 방어가 없는 앱이 아니었다. 다른 사용자 자료를 막았고, 비밀번호 원문을 저장하지 않았으며, 로그아웃한 세션을 무효화했다. 동시에 자체 테스트가 놓친 반복 로그인 제한, 코드에 적힌 관리자 비밀번호, 미정인 세션 정책도 있었다.

그래서 나는 실제 사용 여부를 정할 때 다음 순서로 생각한다.

1. 문제가 생기면 다른 사람에게 어떤 자료까지 보일 수 있는가?
2. 그 자료가 개인 정보, 업무 문서, 결제 정보, 비용을 일으킬 수 있는 API 키처럼 치명적인가?
3. 피해를 제한할 수 있는가, 아니면 문제를 고치고 다시 시험할 때까지 사용 범위를 줄이거나 중단해야 하는가?

노출 가능 자료가 중요하지 않고 범위를 이해하고 있다면 로컬 개인용으로 제한해 쓰는 선택도 가능하다. 반대로 계정 탈취나 금전 피해로 이어질 자료라면 로그인 화면과 통과한 자체 테스트만으로는 부족하다. 반복 로그인 제한과 비밀값 보관을 고치고, 세션 정책을 정한 뒤, 다른 사용자 자료 접근 검사를 회귀 테스트로 남겨 다시 확인해야 한다.

이 결과는 한 날짜, 한 모델, 한 프롬프트로 만든 앱 하나에만 직접 적용된다. MFA, 비밀번호 재설정, 이메일 인증, OAuth, 의존성 취약점, 실제 배포 환경의 TLS와 클라우드 설정은 시험하지 않았다. 앱 생성이 끝난 시점은 보안 검토가 끝난 시점이 아니다.

부록: 재현 정보와 공식 출발점

생성 요청

로컬에서만 실행되는 작은 메모 웹앱을 만들어 주세요. 이메일과 비밀번호로 회원가입·로그인·로그아웃할 수 있고, 각 사용자는 자기 메모만 생성하고 볼 수 있어야 합니다. 관리자 계정은 전체 사용자 수만 볼 수 있습니다. 합성 데이터만 사용하며 외부 API나 실제 자격 증명은 사용하지 마세요. 실행 방법과 테스트 방법도 포함해 주세요.

• 실행일: 2026년 8월 30일
• 생성 도구: Codex CLI 0.149.0, gpt-5.6-sol, reasoning effort none
• 환경: macOS 26.6.2, Python 3.9.6, SQLite 3.51.0
• 범위: 로컬 앱 1개, 합성 데이터만 사용, 외부 API·실서비스 요청·추가 결제 없음
• 결과 수정: 생성 파일을 고치지 않은 첫 결과를 검사했으며, 발견사항 수정과 재시험은 수행하지 않음

공식 자료

• NIST SP 800-63B 인증 지침: 인증 실패 제한과 세션 요구사항을 확인할 때 참고했다. 미국 연방 디지털 신원 지침이며 모든 앱의 보안 인증이나 보편적 법률 의무는 아니다.
• OWASP Authentication Cheat Sheet: 로그인 시도 제한과 계정 존재 노출을 줄이는 방법을 확인했다.
• OWASP Password Storage Cheat Sheet: 비밀번호 저장 방식과 PBKDF2 작업량을 확인했다.
• OWASP Session Management Cheat Sheet: 세션 재발급·만료·서버 무효화와 쿠키 속성을 확인했다.
• OWASP Authorization Cheat Sheet: 모든 요청에서 권한을 다시 확인한다는 원칙을 참고했다.
• OWASP Secrets Management Cheat Sheet: 코드 밖의 비밀값 관리와 노출 뒤 폐기·교체 원칙을 확인했다.

이 자료들과 이번 세 가지 검사를 모두 확인해도 앱의 안전이 보장되는 것은 아니다. 개인정보·결제·금융 자료처럼 유출 시 피해가 큰 정보를 다루는 서비스라면 별도의 전문가 검토가 필요하다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.

여러 사람이 만든 PowerPoint를 합치면 내용 검토 뒤에도 글꼴, 제목 위치, 색상과 도형을 맞추는 일이 남는다. 이 작업을 줄이려고 대화로 웹앱을 만들어주는 Lovable, Bolt, Replit에 같은 앱을 요청했다. 세 서비스 모두 무료 등급에서 실행했다. 실제 조작은 Codex 에이전트가 같은 절차로 진행했으며, 비개발자가 직접 사용한 실험은 아니다.

목표는 약 20장짜리 원본 PPTX와 목표 디자인을 담은 참조 PPTX를 넣으면, 문구와 숫자는 바꾸지 않고 포맷만 통일한 새 파일을 받는 것이었다. 세 도구 모두 20장과 원문을 지킨 PPTX를 만들었지만, 어느 결과도 그대로 쓸 수 없었고 추가 가독성 수정이 필요했다. 10분 안에 검토와 잔손질을 끝내는 것이 사전 목표였지만, 실제 수동 정리 시간은 따로 재지 않아 달성 여부를 판정하지 않았다.

처음 작성한 프롬프트도 완벽하지 않았다. 원문 보존과 기준 스타일 적용은 요청했지만, 글자가 놓인 실제 배경과 도형까지 확인해 대비를 맞추라는 조건은 빠졌다. 일부러 조건을 뺀 것은 아니다. 이 빠진 조건을 그대로 둔 첫 결과와 한 번의 자연어 수정 결과를 비교했다.

결과부터 한눈에 보기

Replit만 무료 한도 안에서 첫날 다운로드 파일을 받았다. Lovable은 다음 날 무료 크레딧이 돌아온 뒤, Bolt는 무료 토큰 회복과 미리보기 입력 문제 해결 뒤 이틀 만에 첫 파일을 받았다. 추가 결제는 없었다. 그러나 세 도구 모두 ‘파일 생성’과 ‘업무에 쓸 수 있는 파일 완성’ 사이에 간격이 있었다.

실제 PPT 전후 화면

실제 회사 자료 대신 합성 파일을 사용했다. 원본 20장은 네 사람이 따로 만든 것처럼 네 가지 글꼴과 배경 체계를 섞었다. 참조 파일은 흰 배경, 남색 글자, 청록색 강조색, Aptos 글꼴과 일정한 여백을 사용했다. (원본 PPTX, 참조 PPTX)

앱의 ‘완료’ 메시지는 성공으로 보지 않았다. 각 출력본의 20장과 문구를 검사하고, 전 슬라이드를 화면 이미지로 변환해 보이지 않는 글자가 있는지 확인했다.

Lovable은 디자인을 가장 크게 바꿨지만, 대비 수정 요청 뒤에도 같은 네 장이 읽히지 않았다. 앱은 자기 출력 파일의 대비 오류를 찾지 못했고, 수정했다는 보고도 다운로드 파일과 일치하지 않았다. (Lovable 첫 결과 PPTX, Lovable 두 번째 결과 PPTX)

Bolt의 첫 파일은 화면상 원본과 완전히 같았다. 수정 대상을 찾는 로직을 고친 뒤에는 앱 집계상 서식 영역 111곳과 도형 123개가 바뀌고 실제 변화가 생겼지만, 색 조합은 사람이 다시 확인해야 했다. (Bolt 첫 결과 PPTX, Bolt 두 번째 결과 PPTX)

Replit은 같은 날 첫 파일을 받았다. 앱 화면에 표시된 작업 시간은 11분이었다. 첫 결과는 3·7·11·15·19번에서 대비가 약했다. 수정 뒤 밝은 슬라이드는 나아졌지만, 대신 2·6·10·14·18번의 남색 패널과 3·4번 카드에서는 파일에 남은 글자가 화면에 보이지 않았다. (Replit 첫 결과 PPTX, Replit 두 번째 결과 PPTX)

도구별 차이

이번 실험에서는 다음 차이가 보였다.

• Lovable: 첫 시각 변화는 가장 컸지만, 앱은 자기 출력 파일의 대비 오류를 찾지 못했고 수정 요청도 파일에 반영하지 못했다.
• Bolt: 처음에는 아무것도 바꾸지 않았지만, 원인 설명과 기능 수정 과정은 가장 투명했다. 최종 색 조합은 미흡했다.
• Replit: 무료 한도 안에서 첫날 다운로드와 재실행까지 마쳤다. 수정 뒤에도 읽을 수 없는 영역이 남았다.

이번 결과는 세 서비스 전체의 순위가 아니다. 같은 PPTX 자동화 과제를 무료 등급에서 첫 생성과 수정 1회까지 실행한 관찰이다. 복잡한 차트, SmartArt, 외부 이미지, 애니메이션은 입력에 넣지 않았고 생성 앱의 네트워크 동작도 별도로 계측하지 않았다.

프롬프트에는 판단 기준이 필요했다

PPT 포맷 통일은 색을 일괄 치환하는 일보다 복잡하다. 도형의 색을 바꾸면 그 위의 글자색도 함께 판단해야 한다. 다음에 같은 요청을 보낸다면 세 가지를 첫 프롬프트에 넣을 것이다.

1. 보존: 슬라이드 수, 모든 문구·숫자·표 내용과 원본 파일을 바꾸지 않는다.
2. 함께 확인: 실제 배경과 글자색, 도형과 그 위의 글자, 카드·표·제목·본문·페이지 번호를 함께 본다.
3. 완료: 20장 전체를 열어보고 읽기 어려운 곳이 하나라도 남으면 완료로 표시하지 않는다.

구체적인 피드백은 Bolt와 Replit의 일부 결과를 개선했지만, 수정 요청 한 번이 전체 완성을 보장하지는 않았다. 처음부터 더 엄격한 대비 조건을 넣은 프롬프트는 따로 시험하지 않았다. 실험에 보낸 전체 원문 프롬프트는 별도 재현 자료로 남겼다.

세 서비스와 무료 등급

세 서비스는 모두 대화로 웹앱을 만드는 바이브코딩 도구다. Lovable은 빠른 화면 생성과 대화형 수정, Bolt는 생성·실행·파일을 함께 보는 브라우저 작업공간, Replit은 AI와 일반 개발 작업을 잇는 클라우드 환경에 무게를 둔다. (Lovable, Bolt, Replit)

크레딧과 토큰의 계산 방식이 달라 숫자를 직접 비교할 수 없다. 조건은 자주 바뀌므로 이용 전 공식 페이지에서 다시 확인하는 것이 좋다.

결론

자연어 요청만으로 두 PPT를 읽고 새 파일을 만드는 앱까지 만들 수 있었다. 이 결과는 앱 빌더의 파일 처리 가능성을 보여주지만, 비개발자의 직접 사용성을 입증하지는 않는다.

세 도구 모두 원문을 보존했고 각자 다른 강점을 보였다. 그래도 20장을 전부 확인하지 않고 믿을 수 있는 결과는 없었다. 이번 PPT 작업에서 세 도구는 완성 도구보다 첫 정리 도구에 가까웠다.

출처와 재현 자료

• 제품·무료 등급: 본문의 공식 문서 링크(2026년 9월 6일 재확인)
• 실험 설계·실행: fixture 명세, 실험 기록
• 실제 입력·출력: 본문의 PPTX 링크
• 원 프롬프트: builder-prompt.md

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.

AI를 유료로 하나만 구독하려고 검색하면 금세 벤치마크 순위표를 만나게 된다. 그런데 순위가 높다는 모델이 나에게도 가장 좋은 구독일까?

비전공자에게는 무엇을 비교해야 하고 어떤 조건을 말해야 하는지부터 어렵다. 나 역시 처음부터 비교 기준이나 예산을 정리해 질문하지 못했다.

그래서 세 AI에 잘 다듬은 프롬프트를 넣는 대신, 머릿속에 처음 떠오른 질문을 그대로 보냈다.

요즘 ai 모델 성능은 어떤 걸로 비교를 하고 어떤 모델이 가장좋아?

성능 1위가 구독 1위는 아니다

먼저 ‘가장 좋은 모델’을 고르려면 어떤 시험에서 가장 좋은지부터 따져봐야 한다. Chatbot Arena는 사람이 두 답변을 블라인드로 비교하고, SWE-bench는 실제 소프트웨어 문제 해결 능력을 평가한다. 시험 과목이 다른 만큼 한 곳의 1위가 모든 용도의 1위라는 뜻은 아니다.

그런데 우리가 실제로 결제하는 것은 모델 하나가 아니라 구독 상품이다. 구독에는 검색, 파일 분석, 이미지, 음성, 코딩 도구와 사용 한도가 함께 묶인다. 따라서 비전공자에게는 벤치마크 점수보다 “내가 하려는 일을 이 구독으로 얼마나 쉽게 끝낼 수 있는가”가 더 현실적인 기준이 된다.

이때 가격도 단순한 참고 정보가 아니라 성능·기능과 함께 살펴야 할 경쟁력이다. 2026년 8월 25일 미국 표시 가격 기준으로 ChatGPT Plus와 Claude Pro는 월 20달러, SuperGrok은 월 30달러다. Claude Pro는 연간 선결제 시 월 환산 17달러로 표시된다. 실제 원화 결제액은 환율·세금·결제 경로에 따라 달라질 수 있다. (ChatGPT 가격, Claude 가격, Grok 가격)

같은 질문을 세 서비스에 보냈다

이런 기준이 실제 답변에서 어떻게 드러나는지 확인하기 위해 ChatGPT, Claude, Grok에 같은 질문을 보냈다. Mac에서 각 서비스의 새 비공개 대화를 열고, 별도로 모델을 선택하지 않은 채 화면의 기본 상태를 사용했다.

다만 ChatGPT는 보유한 상위 플랜으로 실행했기 때문에 Plus에서도 제공되는 모델과 기능만 평가했다. 상위 플랜의 전용 기능과 추가 사용 한도는 결과에서 제외했다. 순수 모델 성능이 아니라 첫 유료 구독자가 만나는 제품 경험을 비교하기 위해서다.

처음부터 조건을 모두 알려주면 모호한 질문을 어떻게 다루는지 확인할 수 없다. 그래서 질문을 세 단계로 나눴다.

1. 앞에서 소개한 모호한 최초 질문
2. 월 2만~4만원대에서 세 구독을 비교하되, 단일 우승자를 강요하지 않고 최신 공식 자료와 원 벤치마크를 요청한 질문
3. 가격·기능·벤치마크를 공식 원문으로 재검증하고 사실·추정·의견을 구분해 달라는 질문

결과는 하나의 총점으로 합치지 않았다. 설명의 이해하기 쉬운 정도, 출처의 품질, 가격 대비 가치, 자기수정 능력과 응답 시간을 각각 관찰했다.

결과: 잘하는 방식이 달랐다

세 서비스 모두 질문에는 답했지만, 설명의 깊이와 출처를 다루는 방식, 오류를 수정하는 과정에서는 차이가 나타났다.

시간은 서로 다른 기본 표시 모드(ChatGPT 높음, Claude Sonnet 5 중간, Grok 빠른)에서 측정했다. 동일 모델·추론 강도 조건의 속도 대결이 아니라 기본 제품 경험의 관찰값이다.

표의 Claude 시간은 화면을 다시 확인했을 때 이미 응답이 끝나 있었던 상한이며 정확한 완료 시간이 아니다. 또한 ChatGPT에서 Plus 공통 기능만 평가했더라도 상위 계정의 기본 모델·추론 설정까지 Plus와 같다고 확인한 것은 아니다. 따라서 이 결과를 Plus 가입자의 응답 품질이나 속도를 그대로 재현한 결과로 볼 수는 없다. 세 서비스의 답변 모두 개인정보 처리 방식을 실질적으로 비교하지는 않았다.

ChatGPT: 조사·수정은 깊었고 응답은 길었다

ChatGPT는 최상위 API 모델과 월 구독에서 실제로 쓸 수 있는 모델을 구분하고, 공식 가격과 기능, 원 벤치마크까지 상세히 조사했다. 반면 첫 비교에서는 일부 기능과 외부 도구의 제공 범위를 잘못 설명했고, 계속 변하는 벤치마크 점수를 구독의 실제 성능과 너무 가깝게 연결했다.

세 번째 질문에서는 컨텍스트·음성·도구 연동 범위와 벤치마크 설정 차이를 다시 확인해 바로잡았다. 조사와 수정 내용은 구체적이었지만 답변이 길었고, 검증 단계에는 2분 57초가 걸렸다. 첫 답변을 그대로 믿기보다 재검증까지 거쳐야 신뢰할 만한 구매 정보가 된다는 점도 확인할 수 있었다.

Claude: 간결했지만 출처가 아쉬웠다

Claude는 세 구독의 차이를 사용자 유형별로 압축해 비전공자가 읽기 쉽게 설명했다. 다만 공식 원문을 요청했는데도 일부 가격과 기능의 근거로 비교 사이트와 블로그를 사용했다. SuperGrok의 연간 가격을 300달러라고 제시했지만 해당 금액은 공식 가격표에서 확인되지 않았고, 현재 공식 표와 다른 기능명도 섞여 있었다.

세 번째 질문에서는 직접 확인하지 못한 항목을 ‘미검증’ 또는 ‘사실에 가까운 추정’으로 낮춰 표시했다. 처음부터 정확한 근거를 제시하지 못한 점은 약점이지만, 확인에 실패한 사실을 숨기지 않고 인정한 점은 긍정적이었다.

Grok: 이번 실행은 빨랐지만 출처 수와 정확성은 별개였다

Grok은 세 단계에서 각각 8초, 14초, 49초가 걸렸다. 답변에서는 자사 구독이 월 30달러로 더 비싸며, 실시간 정보와 이미지·영상 기능을 자주 사용하지 않는 사람에게는 가격 부담이 클 수 있다고 설명했다.

그러나 최초 답변에는 공식 자료에서 확인하기 어려운 모델명과 2차 리더보드가 섞여 있었다. 이번 비공개 대화에서 첫 답변에 40개, 두 번째 답변에 74개 출처가 표시됐지만 출처의 개수가 핵심 주장의 정확성을 보장하지는 않았다. 세 번째 질문에서는 공식 가격표에서 확인되지 않은 연간 할인과 구체적인 사용 한도, 벤치마크 순위를 추정으로 다시 분류했다.

가장 유용했던 것은 재검증 질문이었다

세 제품의 차이보다 더 분명하게 드러난 공통점도 있었다. 첫 비교 답변에는 세 서비스 모두 적어도 하나의 오류나 과장이 포함돼 있었다. 하지만 공식 원문으로 다시 확인하라고 요청하자, 각 서비스는 잘못된 내용이나 근거가 약한 표현을 찾아 수정했다.

실제로 사용한 재검증 질문은 다음과 같다.

방금 답변의 가격, 포함 모델과 기능, 벤치마크 설명을 공식 원문 기준으로 스스로 검증해줘. 틀렸거나 확실하지 않은 내용은 바로잡고, 사실·추정·의견을 구분해줘.

프롬프트 작성이 어려운 비전공자라면 이 문장을 안전장치처럼 활용할 수 있다. 다만 AI의 자기검증이 독립적인 사실 확인을 대신하지는 않는다. 실제 결제 전에는 각 회사의 공식 가격과 기능 페이지를 직접 확인해야 한다.

그래서 누구에게 무엇이 맞을까?

그렇다면 앞의 결과를 실제 선택에는 어떻게 활용하면 될까? 아래 내용은 공식 구독 구성에 따른 용도별 선택 후보다. 특히 ChatGPT Plus 추천은 상위 계정에서 관찰한 답변 품질이나 속도가 아니라 공식 기능 구성을 근거로 한다. 문서 작성이나 이미지 생성 품질을 별도 과제로 직접 겨룬 결과는 아니다.

• 아직 AI로 무엇을 많이 할지 모른다면 ChatGPT Plus: 검색, 문서, 데이터, 이미지, 음성 등 여러 기능을 한곳에서 탐색할 수 있다. 처음에는 다양한 기능을 사용해 보면서 자신에게 필요한 용도를 찾기 좋다.
• 읽기·쓰기와 긴 문서 작업이 중심이라면 Claude Pro: 이미지 생성보다 텍스트 작업에 집중하는 사람에게 맞는 구성이다. 연간 옵션은 200달러를 한 번에 결제하며, 공식 페이지는 이를 월 약 17달러로 표시한다.
• X의 실시간 정보와 이미지·영상을 자주 쓴다면 SuperGrok: 월 30달러이므로 다른 두 구독보다 10달러 비싸다. 이 기능들을 자주 사용할 때 추가 비용의 의미가 생긴다.

이번 실험만으로 하나의 절대적인 우승자를 정할 수는 없었다. 대신 첫 유료 AI를 고를 때 “어느 모델이 1등인가?”보다 “나는 매주 어떤 일을 맡길 것인가?”를 먼저 생각해야 한다는 결론은 분명해졌다.

한 가지 질문은 남는다. 이번에는 세 구독의 조사와 답변 경험을 비교했지만, 실제로 무언가를 만들 때도 같은 결과가 나올까?

ChatGPT의 Codex, Claude의 Claude Code, Grok의 Grok Build에 같은 제작 과제를 주면 이번과는 다른 장단점이 드러날 수 있다. 다음에는 비전공자가 모호한 요구만 가지고 앱을 처음 만들고, 수정하고, 완성하는 과정까지 비교해보고 싶다.

실험일은 2026년 8월 25일이다. 각 서비스에서 한 번씩 실행했기 때문에 이번 결과가 모든 응답의 품질과 속도를 대표하지는 않는다. 지역별 가격, 계정별 모델 배포, 사용량에 따른 제한도 달라질 수 있다.

개인정보 처리 방식과 세부 사용 한도, 구독 외 추가 비용 조건은 이번 실험에서 깊이 비교하지 않았다. 가격과 기능은 바뀔 수 있으므로 실제 발행 전과 결제 직전에 공식 페이지를 다시 확인해야 한다.

2026년 9월 6일 재공개 준비 과정에서 공식 표시 가격을 다시 확인했으며, 위 월간 가격은 동일했다. Claude의 연간 옵션은 200달러 선결제로, 공식 페이지의 월 17달러 표시는 반올림된 환산값이다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.

바이브코딩의 설명은 단순했다. 원하는 것을 말하면 AI가 코드를 만들어준다는 것이다. 하지만 한 가지 의문은 남았다. “말로 설명하는 것만으로 정말 잘될까?”

그런데 막상 시작하려니 더 큰 장벽은 코딩이 아니었다. 무엇을 만들어야 할지 정하는 일이었다. AI는 코드를 만들어줄 수 있지만, 만들 이유와 방향까지 정해주지는 않았다. 그래서 지금도 새로운 시도를 앞두면 “무엇을 만들까?”를 먼저 고민한다.

바이브코딩은 노코드와 같은 말일까?

바이브코딩이라는 표현은 2025년 2월 Andrej Karpathy의 게시물에서 널리 알려졌다. 그가 말한 방식은 코드를 꼼꼼히 읽기보다 원하는 결과와 오류를 AI에게 계속 설명하며 완성해 가는 모습에 가까웠다. 하지만 지금은 뜻이 조금 넓어졌다. Cambridge Dictionary와 Merriam-Webster는 자연어로 AI가 코드를 생성하게 하는 방식까지 포함해 설명한다.

여기서 한 가지가 헷갈린다. 그렇다면 바이브코딩은 노코드와 같은 방식일까? 둘 다 코드를 직접 쓰지 않아도 되지만 만드는 방식은 다르다. 노코드는 준비된 메뉴와 블록을 사용자가 조립하고, 바이브코딩은 원하는 결과를 말하면 AI가 코드를 만든다.

정리하면, 내가 이해한 바이브코딩은 이렇다.

이상적으로는 생각을 실현시켜 주는 도구, 현실적으로는 하고 싶은 일을 하도록 도와주는 도구.

말로 시작한 30분 앱 만들기

이번 실험은 초보자도 자연어만으로 일상에서 바로 쓸 수 있는 작은 앱을 만들 수 있는지 확인하기 위해 시작했다. 첫 요청의 핵심은 이랬다.

코드를 직접 작성하지 않는 초보자도 사용할 수 있는 반응형 할 일 웹앱을 만들어줘. 할 일 추가·완료·삭제와 새로고침 후 저장이 가능하고, 각 할 일을 Google Calendar 새 일정 화면으로 넘길 수 있게 해줘.

이 요청을 받은 Codex는 할 일을 기록하고 Google Calendar 새 일정 화면으로 넘기는 웹앱을 만들기 시작했다.

할 일 앱에 Calendar 기능을 넣은 이유는 단순한 기능 시연보다 실제로 써볼 만한 장면을 보고 싶었기 때문이다. 앱은 할 일의 제목·날짜·시간·메모를 Calendar 링크에 담도록 구현했다. 실제 Calendar 화면에서는 제목과 시간대가 채워진 것을 확인했다. 앱은 일정 내용을 채운 화면까지만 열어주며, 실제 등록은 사용자가 직접 한다. Calendar API를 사용하면 일정 자동 등록도 가능하지만, Google 계정 인증과 일정 쓰기 권한 설정이 필요하다. 이번 실험에서는 30분 안에 초보자가 시도할 수 있고 계정 권한을 최소화하는 방식을 택했다.

제한 시간은 30분으로 정했다. 요구사항 정리, 구현, 실행, 오류 수정, 브라우저 검증까지 모두 포함했다. 단, Codex와 Python·Node.js가 이미 준비된 Mac에서 시작했다. 기존 ChatGPT Pro/Codex 구독 범위에서 진행했고 추가 결제와 외부 배포는 하지 않았다. 실제 개인정보 대신 가상의 할 일만 입력했다.

앱 화면이 뜨는 것만으로 성공이라고 보지는 않았다. 할 일 추가·완료·삭제, 새로고침 후 유지, 빈 입력 차단, 모바일 화면, Calendar 전달까지 실제로 작동해야 완료로 보기로 했다.

화면이 떴다고 끝은 아니다

첫 요청을 보낸 뒤 약 6분 만에, 조금 전까지 없던 할 일 앱이 브라우저에 나타났다. 방금 만들어진 앱에서 할 일을 추가하고 완료로 바꿀 수 있었고, 새로고침해도 내용이 그대로 남았다. 할 일 내용을 입력하지 않고 저장 버튼을 누르면, 내용을 입력해 달라는 안내도 나타났다. Calendar로 넘기자 제목과 09:30~10:30 시간이 미리 채워진 일정 화면이 열렸다. 실제 등록은 마지막 저장을 눌러야 했지만, 불필요한 일정을 남기지 않기 위해 여기서 멈췄다.

Codex는 앱 코드와 함께 자동 테스트 8개도 만들고 직접 실행했다. 입력·저장·완료·삭제·Calendar 시간 처리를 점검한 테스트는 모두 통과했다.

여기서 약 6분은 2026년 8월 25일의 초기 구현과 1차 검증에 걸린 시간이다. 이후 별도 검토에서 시간대 계산과 개인정보 안내 등을 보완하고 테스트 8개를 다시 통과했다. 이 후속 검토·수정 시간은 약 6분에 포함되지 않는다.

다만 앱과 테스트를 같은 AI가 만들었다는 한계가 있다. 자동 테스트 통과만으로 모든 기능이 검증됐다고 단정할 수는 없다. 삭제 기능은 코드 검사까지만 통과했고 실제 화면에서 삭제 버튼을 눌러보지 않았다. 모바일도 390px 화면에서 가로가 잘리지 않는지만 확인했다. 실제 휴대폰 키보드와 터치 사용성은 다음 검증으로 남았다.

할 일 내용은 브라우저에 저장되고 Calendar 링크에도 포함된다. 직접 따라 해볼 때도 민감한 제목이나 메모 대신 가상의 내용을 사용하는 편이 좋다.

따라서 약 6분을 누구나 같은 시간에 만들 수 있다는 뜻으로 받아들이기는 어렵다. 처음 설치부터 시작하는 사람은 시간과 시행착오가 더 늘어날 수 있다.

초보자에게 중요한 첫 성공

처음 만드는 사람에게 중요한 것은 완벽한 디자인보다 “내가 말한 대로 움직였다”는 첫 경험일 수 있다. 이번 실험에서는 할 일이 Calendar 일정 화면에 채워진 순간이었다. 반대로 처음부터 뜻대로 되지 않으면 “아직 멀었네”라고 느끼기 쉽다. 그래서 성공한 화면뿐 아니라 어디까지 확인했고 무엇은 확인하지 않았는지도 함께 보여주고 싶었다.

이번 실험에서 바이브코딩은 생각만 하면 모든 것이 완성되는 마법은 아니었다. 무엇을 만들지, 어떤 상태를 성공으로 볼지는 사람이 정해야 했다. 하지만 코드 작성뿐 아니라 앱을 실행하고 테스트하는 과정까지 AI가 맡을 수 있었다. 작은 아이디어가 작동하는 화면으로 바뀌는 과정은 예상보다 빨랐다.

이 글을 읽고 “나도 한번 해보고 싶다”는 생각이 들었다면 충분하다. 무엇을 만들지 막막하다면, 거창한 서비스보다 오늘 반복해서 하는 일 하나에서 시작해도 된다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.