기본 콘텐츠로 건너뛰기

폐쇄망 STT/TTS 인프라를 혼자 자동화하기까지 — 6년 차 엔지니어 이야기

들어가며

저는 폐쇄망에서 STT/TTS 인프라 설치와 운영을 맡고 있는 엔지니어입니다. 인프라 일을 시작한 지는 6년 정도 됐고, 그동안 자동화 스크립트를 꾸준히 만들어왔습니다. 이 글은 자동화 기술 가이드가 아니라, 혼자 폐쇄망 환경에서 자동화를 만들어온 과정과 그 사이에 깨달은 것들을 솔직하게 정리한 글입니다. 자동화 시작하려는 분, 혼자 인프라 운영하는 분, AI 도구를 어떻게 활용할지 고민하는 분들께 작은 참고가 됐으면 합니다.

왜 자동화를 시작했나

이유는 단순했습니다. 사람이 없었어요. 폐쇄망에 STT/TTS 인프라를 설치하러 나가는 작업이 많은데, 같이 일하던 사람들이 하나둘 회사를 떠나면서 설치 가능한 인력이 점점 줄어들었습니다. 결국 설치를 할 수 있는 사람이 저를 포함해 몇 명 안 남았고, 그마저도 동시에 여러 현장이 있을 때는 도저히 손으로 못 했습니다.

자동화가 거창한 이유로 시작된 게 아니라, 그냥 안 하면 일이 안 굴러갔어요. 저녁에 컨테이너 하나씩 손으로 올리다가 새벽에 끝나는 게 매주 반복되니까, 결국 "이걸 어떻게든 자동으로 돌게 만들어야겠다"는 생각만 들었습니다.

처음엔 정말 단순했다

지금 생각하면 웃기는데, 제 첫 번째 자동화 스크립트는 "1+n" 계산이었습니다. 진짜 그게 시작이었어요. 쉘 스크립트로 변수 두 개 더하는 것. 그게 됐다는 것만으로 신기해서 그 다음엔 2를 만들고, 그 다음엔 같은 파일을 100개 복사하는 스크립트로 갔습니다. 별것 아닌데 이런 작은 스크립트들이 쌓이면서 점점 자신감이 생겼습니다.

이 초석 작업들이 나중에 진짜 자동화로 연결됐습니다. 파일 복사가 됐으니까 컨테이너 설정 파일을 여러 환경에 뿌리는 것도 가능해졌고, 변수를 다룰 줄 알게 되니까 환경별로 다른 설정을 자동으로 적용할 수 있게 됐습니다. 거창한 자동화는 단순한 것들이 쌓여서 만들어지는 거였어요.

진짜 자동화 — STT/TTS Docker 컨테이너 실행

제가 가장 많이 쓰는 자동화는 STT/TTS Docker 컨테이너 자동 실행입니다. 폐쇄망 환경에 컨테이너를 한 번에 다 올려야 하는데, 손으로 하나씩 docker run 명령어 치는 건 현실적으로 불가능합니다.

구조는 단순합니다. path.sh라는 변수 정의 파일을 따로 만들어서 컨테이너 이름, 포트, 볼륨 경로, 환경 변수 같은 걸 모두 변수로 잡아놓습니다. 그리고 docker-compose.yml에서 이 변수들을 참조하도록 작성해두면, 환경마다 path.sh만 바꿔서 같은 docker-compose.yml로 전체 컨테이너를 한 번에 올릴 수 있습니다.

처음 만들었을 때는 프로토타입 수준이었는데, 매번 설치하면서 부족한 부분을 발견하고 보완했습니다. 실행 속도가 너무 느린 건 명령어를 정리하고, 에러 처리가 안 되던 건 검증 단계를 추가하고, 같은 환경 변수를 두 번 적는 게 귀찮으니까 한 번만 적도록 구조를 바꾸고. 6년 동안 이런 식으로 조금씩 다듬어왔습니다.

컨테이너 재시작 API도 만들었다

자동화는 아니고 코드를 짠 거지만, 전체 컨테이너를 API 호출 한 번으로 재시작하는 스크립트도 만들었습니다. 운영 중에 STT/TTS 서비스 전체를 다시 올려야 하는 경우가 생각보다 자주 있는데, 그때마다 손으로 컨테이너를 하나씩 재시작하면 시간이 너무 오래 걸립니다.

그래서 리부팅 코드를 만들어서 외부에서 API로 호출하면 전체 컨테이너가 정해진 순서대로 재시작되도록 했습니다. 의존성 있는 컨테이너는 순서대로 올라가고, 중간에 실패하면 멈추도록 만들었습니다. 이런 작은 도구 하나가 운영 중에 진짜 큰 도움이 됩니다.

Claude가 등장하고 나서 — 좋기도 하고 한편으론 난감

최근에 Claude를 자동화 작업에 쓰기 시작했습니다. 솔직히 좋은 점이 많습니다. 쉘 스크립트 문법 헷갈릴 때 바로 확인되고, 에러 처리 같은 거 짤 때도 한 번에 깔끔하게 나옵니다. 예전에는 인터넷 검색하고 책 뒤지면서 한참 걸렸던 작업들이 빠르게 끝나는 경우가 많아졌습니다.

그런데 한편으로 난감한 부분도 있었습니다. 전체적인 코드 흐름을 Claude가 다 판별하지는 못하는 상황이 있어요. 특히 폐쇄망 환경의 특수성, 회사 인프라의 구체적인 구조, 기존 스크립트와의 연동 같은 건 Claude가 알 수 없으니까 결국 제가 다 알려줘야 합니다. 그리고 Claude가 좋아 보이는 답을 줘도, 그게 실제 환경에서 작동하는지는 제가 확인해야 하는데, 환경에 대한 이해가 없으면 검증 자체가 어렵습니다.

실수도 많이 했다 — 솔직한 실패담

자동화하면서 실수 정말 많이 했습니다. 가장 크게 사고친 건 컨테이너를 다 죽인 적입니다. 재시작 스크립트를 테스트하다가 조건문을 잘못 짜서 모든 컨테이너가 중지된 채로 다시 안 올라온 일이 있었어요. 다행히 운영 서버는 아니었지만 그 후로 항상 테스트 환경에서 충분히 돌려본 다음에 운영에 적용합니다.

변수값 잘못 넣어서 실행이 안 됐던 적도 많습니다. path.sh에 변수 하나 빠뜨려서 컨테이너가 안 올라가는 건 양반이고, 변수 이름을 비슷한 거랑 헷갈려서 엉뚱한 경로에 마운트된 적도 있었습니다.

최근에는 다른 사람과 소통이 잘못돼서 누가 뭘 했는지 모르는 상황이 왔던 적도 있습니다. 자동화 스크립트는 한 명만 쓰는 게 아니라 여러 사람이 쓰니까, 누가 어떤 환경에 무슨 변경을 적용했는지 기록하는 게 정말 중요합니다. 코드만 있고 기록이 없으면 나중에 디버깅이 거의 불가능해집니다.

자동화하면서 깨달은 진짜 중요한 것

자동화 6년 하면서 가장 중요하게 깨달은 건 하나입니다. 내가 알아볼 수 있어야 한다는 것. 자동화 스크립트의 플로우를 정확히 모르고 만들면 항상 꼬입니다. 내가 정확히 알고 있으면 문제가 생겨도 어디서 막혔는지 빠르게 찾는데, 모르면 처음부터 디버깅이 시작됩니다.

이게 Claude 같은 AI 도구 쓸 때 더 중요해집니다. AI가 좋은 답을 줘도 내가 그 답을 검증하고 이해할 수 있어야 합니다. 모르고 그냥 AI가 생성해주는 대로 쓰면, 나중에 문제가 생겼을 때 뭐라고 질문해야 할지조차 모르는 상황이 옵니다. 저도 그런 적이 있었고, 결국 처음부터 다시 코드를 읽으면서 이해해야 했습니다.

그래서 저는 AI가 만든 코드라도 한 줄씩 읽어보고, 이해 안 되면 "이 부분이 왜 이렇게 동작하는지 설명해줘"라고 물어봅니다. 시간 좀 더 걸려도 결국 그게 더 빠릅니다.

자주 묻는 질문

코딩 잘 못해도 자동화 시작할 수 있나요?

저도 처음엔 1+n 계산하는 쉘 스크립트로 시작했습니다. 진짜 그게 시작이었어요. 거창하게 시작할 필요 없습니다. 본인 업무에서 매번 반복되는 작은 작업 하나부터 자동화하면 됩니다. 그게 쌓이면 나중에 큰 자동화로 이어집니다.

Claude 같은 AI 도구가 있으면 자동화가 쉬워지나요?

코드 짜는 시간은 확실히 줄어듭니다. 그런데 코드를 이해하고 검증하는 시간은 줄어들지 않습니다. 오히려 AI가 빠르게 코드를 내놓으니까 그걸 검증하는 부담이 더 커집니다. AI 도구는 작업 속도를 올려주는 보조 수단이지, 본인 이해를 대신해주지는 않습니다.

폐쇄망 환경에서 AI 도구 쓰는 게 어렵지 않나요?

제 경우는 외부 작업 가능한 환경에서 코드를 받아서 폐쇄망으로 가져오는 방식으로 일합니다. 직접 폐쇄망에서 AI에 접속하긴 어렵지만, 코드 작성과 검토에는 충분히 활용할 수 있습니다. 환경 정보를 자세히 알려주는 게 핵심입니다.

자동화하다가 실수하면 어떻게 하나요?

저는 컨테이너를 다 죽인 적도 있고, 변수 실수로 엉뚱한 곳에 마운트한 적도 많습니다. 실수를 피하는 방법은 두 가지입니다. 첫째, 항상 테스트 환경에서 먼저 돌려봅니다. 둘째, 변경 기록을 남깁니다. 누가 언제 무엇을 바꿨는지 기록 안 하면 나중에 디버깅이 거의 불가능해집니다.

40대에 시작해도 늦지 않을까요?

제 나이 40인데 인프라 자동화 시작한 지 6년밖에 안 됐습니다. 기억력도 좋지 않아서 매번 책이나 인터넷을 뒤져서 작업합니다. 그래도 끈질기게 하다 보니 자동화 스크립트를 만들어서 배포하고, 남들이 모르는 패턴까지 머릿속에 쌓여 있습니다. 시작하는 데 늦은 나이는 없는 것 같습니다.

마치며

자동화는 어렵지 않습니다. 단지 끈질기게 해야 합니다. 6년 동안 1+n 쉘 스크립트에서 시작해서 STT/TTS 인프라 전체를 자동으로 올리는 시스템까지 만들었습니다. 그 과정에서 실수도 많이 했고, 컨테이너를 죽인 적도 있고, 변수 실수로 시간 날린 적도 많습니다. 그래도 포기하지 않으니까 결국 만들어졌습니다.

혹시 자동화 시작하시려는 분이 있다면, 거창하게 시작하지 마세요. 본인 업무에서 매번 손으로 하던 작은 작업 하나부터 자동화해보세요. 그게 쌓이면 어느 순간 큰 자동화가 만들어집니다. 그리고 AI 도구는 분명 도움이 되지만, 본인이 이해하지 못하는 코드는 결국 본인을 곤란하게 만듭니다. 천천히 가더라도 본인이 알아볼 수 있는 자동화를 만드시는 게 좋습니다.

📌 참고 자료

본 글은 운영자의 실제 사용 경험을 기반으로 작성됐습니다. 도구의 정책, 가격, 기능은 각 서비스 정책에 따라 변경될 수 있으므로 최신 정보는 공식 사이트에서 확인하시기 바랍니다.

본 글은 어떠한 협찬·광고 관계 없이 작성됐습니다. 운영자의 개인 경험이며, 모든 사용자에게 동일하게 적용되지 않을 수 있습니다.

최종 검토일: 2026년 05월 18일

댓글

이 블로그의 인기 게시물

RHEL 9.3에서 Docker rootless 변환 작업, Claude Code로 3시간 만에 해결한 후기

들어가며 STT/TTS 인프라를 설치하는 일을 하다 보면 평소 같은 설치는 별 문제가 없습니다. 문서대로 따라가면 되니까요. 진짜 문제는 보안 정책이 까다로운 고객사 환경에서 시작됩니다. 최근에 RHEL 9.3 환경에서 Docker를 rootless로 변환하라는 고객사 요청을 받았는데, 이 작업에 거의 3시간을 매달렸습니다. Gemini도 써보고 Claude도 써봤는데 결국 해결한 건 Claude Code였습니다. 이 글에서는 그 과정과, 인프라 엔지니어 입장에서 RHEL 환경에서 AI 도구를 어떻게 활용하는 게 효율적이었는지 솔직하게 정리해봤습니다. 문제 상황 — Docker rootless 변환 Docker에는 rootful과 rootless 두 가지 실행 방식이 있습니다. 일반적으로는 root 권한으로 실행하는 rootful이 편한데, 보안에 민감한 고객사는 root 권한으로 컨테이너가 도는 걸 좋아하지 않습니다. 권한 분리가 명확하지 않다는 이유로요. 이번 프로젝트 고객사도 같은 요청을 했고, 기존에 rootful로 설치돼 있던 STT 인프라를 rootless로 변환해야 했습니다. 처음 접근은 단순했습니다. rootless로 다시 설치하면 되겠다 싶었는데, 막상 작업해보니 전체 구성이 rootless로 통일되면서 새로운 문제가 생겼습니다. root 권한으로 가져와야 하는 환경 리소스를 일반 사용자 권한으로는 가져올 수 없는 부분이 있었기 때문입니다. 부분적으로는 rootless로 동작해야 하지만, 특정 리소스는 root 권한이 필요한 상황이었습니다. Gemini와 Claude로 먼저 시도했던 이유 처음에는 Gemini를 썼고, 그 다음에 Claude도 써봤습니다. 두 도구 모두 답변은 잘 해줬는데 문제는 따로 있었습니다. 답변을 받아도 직접적으로 환경에서 확인해볼 수가 없으니, 적용했다가 안 되면 다시 질문하고, 다시 안 되면 또 질문하는 패턴이 반복됐습니다. 대화형 AI 도구의 답변은 일반적으로 잘 정리돼 있긴 한데, 제 환경...

AI로 블로그 글 100편 자동 발행했더니 일어난 일

들어가며 2개월. 100편. AdSense 거절 1회. 이게 제가 첫 블로그를 운영하고 받은 성적표입니다. 거절 메일을 받고 한참을 멍하니 화면을 봤습니다. 글이 백 편이나 있는데, 도대체 뭐가 부족하단 말인가 싶었거든요. 지금 돌아보면, 부족한 게 없는 게 아니라 전부 부족했습니다. 그리고 그걸 깨닫는 데 두 달이 걸렸어요. 같은 길을 가려는 분들이 같은 시간을 낭비하지 않으셨으면 해서, 솔직한 회고록을 남깁니다. 1. 왜 시작했나 — 자동화에 대한 환상 저는 IT 인프라 엔지니어입니다. 평소 업무에서 자동화를 자주 다루다 보니, "AI로 글까지 자동화하면 부수입이 되겠다"는 생각이 자연스러웠습니다. 검색해보니 유튜브에는 그런 광고가 넘쳤어요. "하루 30분 투자로 월 100만원" , "AI로 자동 발행하고 잠자는 동안 수익" 같은 것들요. 처음엔 자동화보다 직접 써보자는 마음이었습니다. 그런데 알아볼수록 자동화 콘텐츠가 너무 많이 나왔고, 결국 "다들 하니까 나도"라는 마음으로 시작했습니다. 솔직히 말하면, 가족 사정도 있었습니다. 두 딸의 아버지로서 본업 외에 부수입이 절실했고, 자동 블로그는 가장 적은 돈으로 시작할 수 있는 부수입처럼 보였거든요. 2. 시스템 구축 — Antigravity와 Leo Agent 처음 만든 시스템은 유튜브에서 본 antigravity 기반 자동 발행 도구를 제 상황에 맞게 변형한 것이었습니다. 발행 도구 이름은 제가 보던 유튜브에서 만들었고 이름은 "Leo Agent" 였습니다. 처음엔 하루 1편으로 시작했어요. 그런데 너무 적어 보여서 하루 2편, 그러다 3편으로 늘렸습니다. 4시간 간격으로 발행하면 좋다는 글을 보고, "그럼 아침·점심·저녁이 사람들이 가장 많이 보는 시간이지 않나?" 싶어서 그 패턴으로 갔습니다. 주제는 처음엔 정하지 못해서 제 일상 이야기를 쓰다가,...

Claude vs Gemini vs ChatGPT — 인프라 엔지니어가 다 써본 솔직한 비교

들어가며 AI 도구를 쓰다 보면 결국 다 한 번씩은 써보게 됩니다. 저도 인프라 엔지니어로 일하면서 ChatGPT, Claude, Gemini를 모두 써봤습니다. 이 글은 세 도구를 일정 기간 이상 직접 사용해본 사람의 솔직한 후기입니다. 어떤 도구가 무조건 좋다는 결론은 없습니다. 작업 종류와 상황에 따라 다르고, 비용 부담도 무시할 수 없으니까요. 비슷한 고민을 하시는 분들께 작은 참고가 됐으면 합니다. 처음은 ChatGPT였다 당연한 시작이었습니다. ChatGPT가 가장 먼저 나왔고, 그래서 처음 써본 도구도 ChatGPT였습니다. 처음 썼을 때는 정말 신기했습니다. 질문하면 답이 나오고, 코드도 짜주고, 모르는 개념도 설명해주니까요. 그래서 유료 결제도 했습니다. 그런데 쓰다 보니 점점 불만이 생겼습니다. 답변이 느려지는 느낌도 있었고, 같은 작업을 시켜도 결과가 일정하지 않았습니다. 프롬프트를 아무리 잘 작성해도 어느 순간 한계가 명확하게 보였습니다. 특히 코드 작업이 길어지면 앞에서 한 약속을 잊거나, 엉뚱한 방향으로 가는 일이 많았습니다. 결국 점점 안 쓰게 됐습니다. 지금은 거의 사용하지 않고, 구독은 일단 해지 예정으로 두고 있습니다. 다만 ChatGPT가 무조건 나쁘다는 건 아닙니다. 일상 정보 검색이나 그림 분석 같은 일반 사용에는 여전히 정보가 풍부해서 강점이 있다고 봅니다. 단지 제 작업—인프라와 코드 중심—에는 맞지 않았을 뿐입니다. Claude — 코드 작업에서 진가 Claude는 처음에 존재 자체를 몰랐습니다. 주변에서 쓰는 사람도 없었고요. 그러다가 코딩 작업에 강점이 있다는 이야기를 듣고 써보기 시작했습니다. 처음 써보고 가장 인상적이었던 건 코드 품질이었습니다. 같은 요청을 했을 때 코드가 깔끔하고 정렬이 잘 되어 있었습니다. 주석도 충실해서 긴 코드라도 나중에 다시 봤을 때 이해하기 쉬웠습니다. ChatGPT나 Gemini에서 받은 코드는 주석이 약해서 시간이 지나면 "이게 왜 이렇게 됐...