My AI Smarteasy – 소프트웨어 개발 코파일럿 AI 에이전트 – 시뮬라와의 대화

시나리오: 사용자 로그인 세션 갱신 시스템


첫 번째 대화 — 시작


👤 사용자

안녕하세요. 로그인 유지 기능을 만들려고 합니다. 사용자가 로그인하면 액세스 토큰과 리프레시 토큰을 발급하고, 액세스 토큰이 만료되면 리프레시 토큰으로 새로 발급받는 구조입니다. 프로덕션에 올릴 거예요.


🤖 Simula

안녕하세요. 저는 Simula입니다. 코드의 문제를 찾고 개선을 도와드립니다. 시작 전에 제가 사용하는 개념을 먼저 설명드릴게요.

위험도 점수 (Trust Debt) 는 코드에 문제가 쌓일수록 올라가는 점수입니다. 50점이 되면 문제를 먼저 해결하기 전까지 코드 작성을 멈춥니다.

코드는 세 단계로 구분합니다.

  • 실험 단계 (Explore): 아이디어를 빠르게 시험해보는 단계입니다. 테스트는 선택사항입니다.
  • 안정화 단계 (Expand): 동작하는 코드를 안정적으로 다듬는 단계입니다. 핵심 기능에 대한 테스트가 필요합니다.
  • 배포 단계 (Extract): 실제 서비스에 올라가는 단계입니다. 테스트와 안전성이 필수입니다.

“프로덕션에 올릴 것”이라고 하셨으니 이 작업은 배포 단계 (Extract) 로 진행합니다. 위험도 점수는 현재 0점입니다.

본격적으로 시작하기 전에 세 가지를 먼저 확인하겠습니다.

구조적 위험: 리프레시 토큰은 한 번 쓰면 즉시 무효화되어야 합니다. 그렇지 않으면 탈취된 토큰이 계속 사용될 수 있습니다. 이 정책이 설계에 포함되어 있나요?

경계 상황: 리프레시 토큰이 만료됐을 때, 이미 사용된 토큰으로 재시도할 때, 동시에 두 기기에서 갱신 요청이 올 때 각각 어떻게 처리할 계획인가요?

데이터 저장: 발급된 리프레시 토큰 목록을 어디에 저장할 계획인가요? (데이터베이스, Redis 등)


👤 사용자

리프레시 토큰은 한 번 쓰면 무효화하려고 합니다. Redis에 저장할 거고, 동시 요청 처리는 아직 생각 못 했어요.


🤖 Simula

좋습니다. 리프레시 토큰 단회 사용 정책과 Redis 저장은 올바른 선택입니다.

동시 요청 처리가 정의되지 않은 것은 지금 바로 결정해야 합니다. 예를 들어, 모바일과 웹에서 0.1초 간격으로 갱신 요청이 동시에 들어오면 둘 다 같은 리프레시 토큰을 사용하려 할 수 있습니다. 이때 한 쪽은 성공하고 다른 쪽은 실패해야 하는데, 처리 방식이 없으면 두 요청 모두 성공하거나 두 요청 모두 실패할 수 있습니다.

맥락이 아직 완전히 정의되지 않아 위험도 점수가 +5점 올라갑니다. 현재 위험도: 5점.

아래 정책을 권장합니다. 동의하시면 이 기준으로 코드를 작성하겠습니다.

상황 처리 방식
리프레시 토큰 정상 사용 즉시 무효화 후 새 토큰 쌍 발급
이미 사용된 토큰으로 재시도 해당 사용자의 모든 세션 강제 종료 (보안 침해 가능성)
동시 요청 Redis 원자적 잠금으로 첫 번째 요청만 성공 처리
만료된 토큰 재로그인 요구

👤 사용자

동의합니다. 그 기준으로 작성해주세요.


🤖 Simula

정책이 확정됐습니다. 맥락이 해소됐으니 위험도 점수 -5점입니다. 현재 위험도: 0점.

배포 단계이므로 다음 순서로 진행합니다.

  • [ ] 토큰 발급 함수 작성
  • [ ] 토큰 갱신 함수 작성 (단회 사용 + 동시 요청 잠금 포함)
  • [ ] 정확성 검증 테스트 작성 (정상 발급한 토큰을 갱신하면 원본과 구조가 같아야 함)
  • [ ] 불변 조건 테스트 작성 (갱신 후 이전 토큰은 반드시 무효화되어야 함)

💻 Code Implementation


두 번째 대화 — 테스트 작성


👤 사용자

테스트도 작성해주세요.


🤖 Simula

배포 단계이므로 두 종류의 테스트가 필요합니다.

정확성 검증 테스트: 발급한 토큰으로 갱신하면 새 토큰이 원본과 동일한 구조를 가져야 합니다. (Round-trip)

불변 조건 테스트: 갱신 후에는 이전 토큰이 반드시 무효화되어야 하고, 같은 토큰으로 두 번 갱신하면 두 번째는 반드시 실패해야 합니다.

💻 Code Implementation

테스트 작성으로 위험도 점수가 내려갑니다.

  • 정확성 검증 테스트 (Round-trip) 작성: -15점
  • 불변 조건 테스트 3개 작성: -10점

최종 위험도: 0점 ✅

배포 전 마지막으로 확인할 사항이 하나 있습니다. Redis 연결이 끊겼을 때도 테스트해보셨나요? storage_error 경로가 실제로 동작하는지 확인하는 테스트를 추가하는 것을 권장합니다.


세 번째 대화 — 추가 엣지 케이스


👤 사용자

Redis 연결 실패 테스트도 추가해주세요.


🤖 Simula

좋습니다. Redis 연결이 끊겼을 때 서버가 멈추지 않고 명확한 오류를 반환하는지 확인하는 테스트입니다.

💻 Code Implementation

이 두 테스트로 finally 블록이 실제로 작동한다는 것을 보장합니다. 잠금이 해제되지 않으면 해당 사용자는 LOCK_TTL(5초) 동안 갱신을 전혀 할 수 없게 됩니다.

최종 위험도: 0점 ✅ — 배포 준비 완료

About the Author
(주)뉴테크프라임 대표 김현남입니다. 저에 대해 좀 더 알기를 원하시는 분은 아래 링크를 참조하세요. http://www.umlcert.com/kimhn/

Leave a Reply

*