요약
사이트의 AI 기능이 몇 주째 “아직 연결되지 않았습니다”라고만 답하고 있었다. 원인은 서버 환경파일에 키가 들어 있지 않은 것이었는데, 실제로는 그 한 줄을 넣는 데 하루가 걸렸다. 붙여넣기가 조용히 실패했고, 서버가 옛 코드를 돌리고 있었고, 카드 결제가 보안 프로그램에 막혔고, 키가 들어간 뒤에도 잔고가 0이었다. 마지막에는 상대 서버가 우리 키를 모른다고 했다.
이 글은 그 하루를 “어디까지 됐고 어디서 막혔는지”를 매 단계 실측으로 확인하는 절차로 정리한 것이다. 비밀 값을 화면에 한 번도 찍지 않고 그것을 했다.
왜 이 기술인가
키 한 줄은 쉬워 보인다. 그런데 키는 값이 보이면 안 되는 물건이라, 들어갔는지를 눈으로 확인할 수 없다. 그래서 “넣었다”와 “들어갔다”와 “쓰인다”가 셋 다 다른 일이 된다. 셋을 구분하지 않으면 다음 대화는 “넣었는데 안 된다”에서 한 발도 못 나간다.
또 하나. 서버 관리 권한은 대표가, 코드는 AI가 갖고 있을 때가 많다. 대표는 명령 한 줄을 붙여 실행할 수 있지만 무엇이 나와야 정상인지는 모른다. 그래서 명령마다 “이렇게 나오면 통과, 저렇게 나오면 어디로 돌아가라” 표가 붙어 있어야 한다.
단계별 따라하기
1. 값이 아니라 모양을 확인한다
키가 들어간 줄의 값은 절대 출력하지 않는다. 대신 길이, 아스키 여부, 앞 세 글자만 찍는다. 이 세 가지로 대부분의 사고가 갈린다.
| 나온 것 | 뜻 |
|---|---|
| 길이 0 | 이름만 있고 값이 없다. 붙여넣기가 안 된 것 |
| 아스키 아님 | 안내문의 자리표시자(한글)가 그대로 들어갔다 |
| 앞 세 글자가 다름 | 다른 것을 복사했다 |
실제로 첫 시도는 길이 0이었다. 터미널 편집기에서 마우스 붙여넣기가 무시된 것인데, 화면에는 아무 표시가 없었다.
2. 붙여넣기는 편집기 대신 숨김 입력으로
편집기를 열어 값을 붙이는 대신, “붙여넣고 Enter”를 기다리는 숨김 입력을 쓰고 그 값으로 파일의 해당 줄을 바꾸게 했다. 화면에 안 보이고 명령 기록에도 남지 않는다. 두 번 실행해도 줄이 중복되지 않게 “있으면 바꾸고 없으면 붙인다”로 짰다.
3. 파일 시각과 서비스 시작 시각을 비교한다
파일을 고쳤는데 여전히 옛 답이 오면, 서비스가 파일을 다시 읽었는지가 문제다. 환경파일은 서비스가 시작할 때만 읽는다. 파일 수정 시각과 서비스 시작 시각을 나란히 찍어 앞뒤를 보면 재시작이 됐는지 바로 안다. 이전 글(「설정은 켰는데 왜 안 되나」)과 같은 원리다.
4. 서버가 받아 가는 곳이 최신인지 본다
서버는 코드를 공개 미러 저장소에서 받아 갔다. 그런데 미러는 닷새 전에 멈춰 있었고, 원본에만 있던 “키가 잘못 들어가도 500이 안 나게” 하는 수정이 미러에 없었다. 서버가 아무리 pull을 해도 옛 코드였던 이유다. 반대로 미러에만 직접 고친 파일 두 개도 있어서, 양쪽을 서로 맞춰 놓아야 했다. 배포 경로에 저장소가 둘이면 둘 다 확인한다.
5. 키 자체를 따로 시험한다
우리 서비스 코드를 거치지 않고, 키를 읽어 제공자 API에 직접 한 줄 요청을 보낸다. 값은 명령 안에서 파일로부터 읽히므로 화면에 나오지 않는다. 여기서 나온 답이 “잔고가 부족하다”였다. 키는 맞았고 결제가 안 된 것이다. 서비스 코드만 보고 있었으면 하루를 더 헤맸을 것이다.
6. 결제 화면의 관문은 카드사 것이다
해외 결제에서 카드사가 본인확인 창을 띄우고 보안 프로그램 설치를 요구했다. 이건 AI 서비스 회사가 아니라 카드사 절차라 우회할 수 없다. 순서는 셋이다. 그냥 확인을 눌러 넘어가는지 본다, 안 되면 프로그램을 설치하고 브라우저를 완전히 닫았다 연다, 그래도 안 되면 다른 카드로 먼저 충전하고 나중에 바꾼다.
7. 상대 서버의 “키가 틀렸다”는 세 가지를 뜻한다
협력 조직 엔진에 우리 키를 보냈더니 “키가 없거나 올바르지 않다”고 했다. 이때 키 없이도, 엉뚱한 키로도 같은 문구가 오는지 먼저 본다. 같으면 상대가 우리 키를 “모르는 키”로 보는 것이고, 우리 복사가 맞았다면(1단계 모양 대조) 상대 쪽 등록 문제다. 여기서 우리 쪽 시도를 세 번 넘게 반복하지 않고 멈추고 상대에게 넘겼다.
8. 시험이 다른 결함을 드러낸다
같은 질문 15개를 두 엔진에 던지는 대조 시험을 돌렸더니, 우리 쪽 답 4개가 비어 있었다. 출력 토큰이 정확히 한도에서 멈춘 것이 단서였다. 새 모델은 기본으로 “생각”을 켜고 그 생각도 출력 한도에서 나가기 때문에, 한도가 작으면 생각만 하고 답은 못 낸다. 짧은 상담 답변 경로에서는 생각을 끄고 한도를 늘렸다. 시험이 아니었으면 실제 이용자 화면에서 처음 드러났을 결함이다.
교훈
- “넣었다·들어갔다·쓰인다”는 세 가지 다른 사실이다. 각각을 따로 확인하는 명령을 준비한다.
- 값은 찍지 말고 모양을 찍는다. 길이·아스키·앞 세 글자면 사고의 대부분이 갈린다.
- 붙여넣기는 실패해도 소리가 없다. 편집기 대신 숨김 입력을 쓰고, 넣은 직후 모양을 확인한다.
- 배포 경로에 저장소가 둘이면 둘 다 본다. 서버가 받아 가는 쪽이 뒤처지면 pull은 아무 일도 하지 않는다.
- 서비스 코드를 빼고 키만 따로 시험한다. 그래야 키·잔고·코드 중 어디가 문제인지 갈린다.
- 상대의 “키가 틀렸다”는 우리 복사 오류가 아닐 수 있다. 키 없이 보내 본 문구와 같으면 상대 쪽 등록을 물어라.
- 세 번 막히면 멈추고 넘긴다. 오늘 그 자리가 협력 조직 몫이었다.
참고
- 앞선 글: 「설정은 켰는데 왜 안 되나 — 캐시된 정책과 앱 재시작」, 「배포했는데 라이브가 아니다 — 사슬을 끝까지 확인하는 법」, 「AI와 함께 GPU 지원사업 연동 현황을 실측으로 점검하기」
- 문서 정리 = 데카(deka2026)