에이전틱 코딩은 채팅과 무엇이 다른가

버그는 로그인 화면 밖에 숨어 있었습니다

이 서비스는 개발 환경과 HTTPS 운영 환경에서 서로 다른 세션 쿠키 이름을 씁니다. 운영용 이름에는 호스트 보안 접두사가 붙습니다. 인증 콜백은 공용 이름 계산 함수를 호출해 올바른 쿠키를 저장합니다. 하지만 관리자 경로를 지키는 미들웨어에는 예전 개발용 이름이 문자열로 남아 있습니다.

브라우저에서 관찰되는 장면은 단순합니다. 인증 콜백은 200이고 응답 헤더에도 운영용 세션 쿠키가 들어 있습니다. 곧이어 관리자 결제 화면 요청은 302로 로그인 화면을 가리킵니다. 인증 공급자나 비밀번호가 아니라, 쿠키를 쓰는 코드와 읽는 코드가 서로 다른 이름을 보는 것이 원인입니다.

채팅은 받은 조각을 잘 설명하지만 저장소를 대신 확인하지 않습니다

채팅 창에 302 로그만 붙이면 쿠키 만료, SameSite 설정, 콜백 주소, 미들웨어 순서처럼 가능한 원인을 넓게 받을 수 있습니다. SameSite는 다른 사이트에서 넘어온 요청에 쿠키를 보낼지 정하는 브라우저 규칙입니다. 개념을 배우거나 조사 순서를 잡는 데는 유용하지만, 콜백과 미들웨어 코드를 함께 건네지 않았다면 어느 파일에 이름 차이가 있는지는 알 수 없습니다.

두 코드 조각을 모두 제공하면 채팅도 불일치를 찾아낼 수 있습니다. 다만 사람이 관련 파일을 먼저 찾아 골라야 하고, 제안한 수정이 실제 테스트에서 실패하는지까지는 별도로 확인해야 합니다. 이 방식의 결과물은 좋은 가설이며, 저장소에서 확인된 결론은 아닙니다.

자동완성은 손이 빠르지만 시야는 현재 편집에 가깝습니다

미들웨어 파일을 열고 쿠키 조회 줄을 수정하기 시작하면 자동완성은 두 이름을 차례로 읽는 코드를 제안할 수 있습니다. 당장 로그인 루프는 사라질 가능성이 큽니다. 그러나 이전 이름을 계속 허용하면 폐기하려던 쿠키도 인증에 사용되고, 쿠키 이름을 한곳에서 관리하려던 설계도 다시 흩어집니다.

사람이 이미 원인과 올바른 공용 함수를 알고 있을 때 자동완성은 가장 경제적입니다. 반대로 “왜 운영에서만 실패하는가”부터 찾아야 한다면, 빠른 한 줄 제안이 잘못된 방향으로 가는 속도까지 높일 수 있습니다.

에이전트에는 수정 요청보다 조사 계약을 먼저 줍니다

이 사건에서는 쓰기 권한을 바로 열 이유가 없습니다. 재현 조건, 읽어야 할 범위, 금지할 외부 효과와 성공 조건을 한 번에 주면 에이전트가 무엇을 확인해야 하는지 선명해집니다.

증상: 운영 설정에서 로그인 성공 뒤 /admin/billing이 /login으로 302 됩니다.

먼저 코드를 수정하지 말고 다음을 확인하세요.
- 인증 콜백이 쿠키를 쓰는 위치
- 관리자 미들웨어가 쿠키를 읽는 위치
- 개발/운영 환경에 따른 쿠키 이름과 옵션
- 이 흐름을 재현하는 기존 테스트

허용: 저장소 읽기, 검색, 테스트 실행
금지: 운영 접속, 비밀값 조회, 외부 인증 공급자 설정, DB 변경, 배포

반환: 관찰 증거, 원인 가설, 최소 수정안, 실행한 검증, 남은 미검증 영역

검색과 실행 결과가 추측을 한 가지 원인으로 좁힙니다

에이전트는 먼저 쿠키 이름이 등장하는 위치를 찾습니다. 콜백은 공용 이름 계산 함수를 쓰지만 관리자 미들웨어만 개발용 이름을 직접 읽는다는 차이가 드러납니다. 그다음 운영 조건을 흉내 낸 기존 인증 테스트를 실행합니다. 응답에는 운영용 쿠키가 있고 다음 요청은 개발용 쿠키를 찾다가 302를 반환합니다.

여기서 중요한 관찰은 “쿠키가 없다”가 아닙니다. 쿠키는 정상적으로 발급됐지만 소비자가 다른 이름을 요청했습니다. 이 차이를 확인했기 때문에 SameSite를 느슨하게 하거나 보안 접두사를 제거하는 우회책을 버릴 수 있습니다.

최소 수정은 보안 설정을 낮추지 않고 이름의 원천을 하나로 만듭니다

수정 대상은 미들웨어 한 곳입니다. 두 이름을 모두 허용하지 않고, 콜백과 같은 공용 함수를 사용합니다. 이어서 개발 환경과 운영 환경을 각각 고정한 회귀 테스트를 추가합니다.

// before
const token = request.cookies.get('app_session')?.value;

// after
const cookieName = sessionCookieName(process.env.NODE_ENV);
const token = request.cookies.get(cookieName)?.value;

// regression cases
expect(sessionCookieName('development')).toBe('app_session');
expect(sessionCookieName('production')).toBe('__Host-app_session');

관찰 결과는 “수정했다”보다 구체적이어야 합니다

수정 전에는 운영 조건의 관리자 경로 테스트가 302 로그인 이동으로 실패했습니다. 수정 후에는 같은 쿠키로 관리자 결제 화면이 200을 반환했고, 쿠키가 없을 때 로그인 화면으로 보내는 기존 테스트도 그대로 통과했습니다. 개발용 쿠키 경로 역시 유지됐습니다.

이 정도면 저장소 안에서 원인과 회귀 방지는 확인됐습니다. 그러나 실제 운영 도메인의 HTTPS, 프록시 헤더와 외부 인증 콜백까지 확인한 것은 아닙니다. 따라서 결과에는 “운영 배포와 실제 계정 로그인은 미검증”이라고 남아야 합니다. 에이전트가 테스트를 통과시켰다는 사실과 운영 복구가 끝났다는 판단은 같은 말이 아닙니다.

세 도구를 고르는 기준은 문제의 반경입니다

한 줄의 문법, 반복되는 변환, 이미 정해진 함수 호출이라면 자동완성이 적합합니다. 설계 대안을 비교하거나 오류 메시지의 뜻을 배우려면 채팅이 가볍습니다. 라우트, 미들웨어, 설정, 테스트처럼 여러 위치의 관계를 읽고 실제 명령으로 확인해야 한다면 에이전트를 선택할 이유가 생깁니다.

에이전트도 무조건 계속 진행시키지 않습니다. 재현이 운영 개인정보나 비밀값을 요구할 때, 외부 인증 공급자의 설정을 바꿔야 할 때, DB 스키마 변경이나 배포가 필요할 때는 멈춰야 합니다. 처음 정한 범위를 벗어난 파일에서 원인이 의심될 때도 증거와 다음 선택지를 보고하고 승인을 기다리는 편이 맞습니다.

이 사례에서 남는 선택

로그인 루프처럼 원인이 여러 계층에 걸친 문제는 에이전틱 코딩의 장점을 잘 보여줍니다. 관련 파일을 스스로 찾고, 실패를 재현하고, 가설과 관찰이 맞지 않으면 되돌아갈 수 있기 때문입니다. 하지만 범위, 권한, 완료 증거를 정하는 일은 여전히 사람에게 남습니다.

도구를 고를 때는 “AI가 코드를 쓸 수 있는가”보다 세 가지를 보면 됩니다. 수정 위치를 이미 아는지, 결과를 명령으로 검증할 수 있는지, 잘못된 행동의 영향 범위를 제한할 수 있는지입니다. 이 세 질문 중 앞의 두 답이 불분명할수록 자동완성보다 에이전트가 유리하고, 마지막 답이 불분명할수록 에이전트에는 읽기 권한만 주어야 합니다.

이 버그를 Claude Code 세션으로 시작하는 법

다음은 실측 로그가 아니라 인증 저장소에 맞춰 바꿔 쓰는 세션 예시입니다. 먼저 계획 모드에서 읽기만 허용합니다.

cd /path/to/project
claude --permission-mode plan

AGENTS.md, 인증 콜백, 관리자 미들웨어, 인증 테스트를 읽으세요.
운영용 쿠키를 쓰는 곳과 읽는 곳을 연결하되 수정하지 마세요.
허용 도구: Read, Glob, Grep
Edit와 Bash는 검토 전 승인하지 않습니다.
반환 형식: 읽은 파일 / 관찰 증거 / 원인 가설 / 최소 수정 / 검증 / 미확인 영역

쿠키 이름 불일치가 확인되면 수정 범위가 한 줄로 줄어듭니다

관찰표에 “콜백은 `__Host-app_session`을 쓰고 미들웨어는 `app_session`을 읽음”이 남았다면 수정 대상은 미들웨어와 회귀 테스트뿐입니다. 이 두 파일만 공용 쿠키 이름 함수로 맞추고, 운영 접속·공급자 설정·DB·배포는 변경 목록에 나타나지 않아야 합니다.

완료 설명보다 변경 차이를 먼저 봅니다

아래 명령은 프로젝트에 맞게 조정하는 예시입니다. 테스트 뒤 보안 접두사를 제거하거나 예전 쿠키를 함께 허용한 우회 수정이 없는지 확인합니다.

npm test -- auth
git diff -- middleware tests/auth
git status --short

이 세션을 멈추거나 재개할 조건

운영 로그의 개인정보, 실제 계정, 외부 인증 설정이 필요하면 중단합니다. 같은 로그인 반복 이동을 계속 조사할 때만 세션을 재개합니다. 데이터 권한이나 로그인 화면 개편처럼 목표와 권한이 달라지면 현재 관찰을 남기고 새 세션에서 시작합니다.