컨테이너·쿠버네티스·Pub/Sub 개념: 챗봇을 클라우드에 올리며 인프라 용어를 처음 배웠다

사내 문서를 채팅에서 자연어로 물어보는 챗봇을 만들어 클라우드에 올리는 작업이었다.

개발이 주업이 아닌 입장에서 인프라를 처음 제대로 만졌다. 컨테이너, 쿠버네티스, 클라우드 인증, 메시지 큐 같은 것들.

용어 자체가 벽이었다

부끄럽지만 이런 상태였다.

• git과 GitHub이 같은 건 줄 알았다
• 봇이 A 클라우드에서 도는 줄 알았다 (사실은 B에서 돌고, A는 채팅 연결용이었다)
• "이미지를 굽는다"가 무슨 말인지 몰랐다
• 서비스 계정 키가 내 개인 계정 키인 줄 알았다

결정적으로 막힌 것

봇을 만들어 배포까지 했는데 정작 내 계정으로는 봇을 못 썼다.

내 계정이 우리 조직 도메인이 아니었다(외부 계정). 그래서 채팅 클라이언트가 "멘션이 잘못된 것 같습니다"라며 전송 자체를 막았다.

서버 설정도 코드도 어디를 고쳐도 안 됐다. 봇 로그가 텅 비어 있었는데, 알고 보니 요청이 애초에 서버까지 오지도 않은 거였다.

용어가 하나씩 정리된 방식

git과 GitHub — git은 기술(도구)이고, GitHub은 그 저장소를 인터넷에 올려두는 집(호스팅)이다. 이메일이라는 기술과 Gmail이라는 서비스의 관계와 같다. 속은 같은 git이다.

컨테이너 — 코드 + 실행환경(언어·라이브러리·설정)을 한 상자에 밀봉한 것이다. "내 컴퓨터선 되는데 서버선 안 돼"를 없앤다.

• 이미지 = 그 밀봉된 상자
• 굽는다(build) = 그 상자를 만드는 것

쿠버네티스 — 컨테이너를 여러 개, 여러 서버에 굴려주는 관리자다. (우리는 나중에 더 단순한 단일 서버로 옮겼다.)

메시지 큐(Pub/Sub) — 우편함이다. 보내는 쪽이 상자에 넣고, 받는 쪽이 꺼낸다. 둘이 직접 안 만나서, 받는 서버에 "외부에서 들어오는 문"이 없어도 된다. 그만큼 공격받을 곳이 줄어든다.

환경변수 — 비밀값(키)은 코드에 안 넣고 환경변수로 읽게 한다. 그래야 키가 바뀌어도 코드를 안 고친다. 값은 클라우드 금고가 넣어준다.

제일 큰 깨달음 — "지도"가 필요했다

비개발자가 인프라를 배울 때 진짜 벽은 **"각 조각이 뭔지"가 아니라 "조각들이 어디서 도는지"**였다.

봇이 사는 곳       →  A 클라우드
채팅 연결          →  B 클라우드 (빌려 쓰는 우체국)
답변 만드는 곳     →  AI API

셋을 분리해서 그리는 순간 대부분의 혼란이 풀렸다. 그전까지는 전부 한 덩어리로 보여서, 문제가 생겨도 어디를 봐야 할지 몰랐다.

플랫폼 제약은 코드로 못 뚫는다

채팅 플랫폼이 "외부 조직 사용자의 앱 상호작용"을 정책으로 막아두면, 서버 설정도 허용목록도 코드도 아무 소용이 없다.

이걸 인정하는 데 시간이 걸렸다. 계속 "설정 어딘가에 방법이 있겠지" 하고 찾았으니까.

그런데 "안 된다"를 단정하는 것도 이르다

문서에 "외부 사용자는 멘션을 못 한다"고 적혀 있었다. 그래서 안 된다고 결론 냈다.

그런데 다른 메커니즘이 같은 제약을 받는지는 별개였다. 멘션은 막혀도, "봇이 방의 일반 메시지를 구독해서 읽는" 다른 경로는 문서에 명시가 없었다.

확실한 결론을 내려면 작게 만들어서 실제로 해보는 수밖에 없다.

남길 것

• 인프라를 배울 때 필요한 건 용어 사전이 아니라 지도다. 어느 조각이 어디서 도는지를 먼저 그린다.
• 로그가 텅 비었으면 요청이 도달하지 않은 거다. "실패 로그가 없다"와 "성공했다"는 다르다.
• 플랫폼 정책은 코드로 못 뚫는다. 인정하고 다른 길을 찾는 게 빠르다.
• 문서에 "안 된다"고 적힌 것도, 다른 경로까지 막혔다는 뜻은 아니다. 명시가 없으면 작게 만들어 확인한다.

더 봐야 할 것

• 메시지 구독 방식에서 외부 사용자가 쓴 메시지도 봇에 전달되는지. 문서에 없어서 직접 해봐야 한다