로그인은 됐다. AI가 만든 앱을 그대로 써도 될까?

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를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.