기본 콘텐츠로 건너뛰기

면책조항

면책조항

1. 정보의 정확성

AI Dig Deep에 게재된 모든 콘텐츠는 작성 시점의 정보를 기반으로 하며, AI 도구·서비스의 빈번한 업데이트로 인해 실제와 차이가 있을 수 있습니다. 글마다 표시된 "최종 검토일"을 참고하시고, 중요한 결정은 반드시 해당 서비스의 공식 자료를 확인하시기 바랍니다.

2. 개인 의견

본 사이트의 리뷰, 추천, 평가는 운영자의 개인적인 사용 경험과 의견에 기반합니다. 개별 사용자의 환경, 목적, 숙련도에 따라 결과가 다를 수 있습니다.

3. 외부 링크

본 사이트에 포함된 외부 링크의 콘텐츠나 서비스에 대해 본 사이트는 어떠한 책임도 지지 않습니다. 외부 사이트 이용 시 해당 사이트의 정책을 확인하시기 바랍니다.

4. 광고 및 제휴

본 사이트는 Google AdSense를 비롯한 광고와 제휴 마케팅을 통해 수익을 얻을 수 있습니다. 단, 이러한 수익이 콘텐츠의 객관성을 훼손하지 않도록 노력하며, 제휴 관계가 있는 경우 해당 글에 명시합니다.

5. 손해 배상

본 사이트의 정보 이용으로 인해 발생한 직간접적 손해에 대해 운영자는 법적 책임을 지지 않습니다. 사용자의 판단과 책임 하에 정보를 활용해주시기 바랍니다.

6. 저작권

본 사이트의 모든 콘텐츠는 별도 표시가 없는 한 운영자에게 저작권이 있습니다. 무단 복제·전재를 금지하며, 인용 시 출처와 링크를 명시해주시기 바랍니다.

시행일: 2026년 4월 30일

댓글

댓글 쓰기

댓글로 의견 부탁드립니다. 욕설·광고는 삭제됩니다.

이 블로그의 인기 게시물

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 도구의 답변은 일반적으로 잘 정리돼 있긴 한데, 제 환경...
댓글 쓰기
자세한 내용 보기

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

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

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

들어가며 저는 폐쇄망에서 STT/TTS 인프라 설치와 운영을 맡고 있는 엔지니어입니다. 인프라 일을 시작한 지는 6년 정도 됐고, 그동안 자동화 스크립트를 꾸준히 만들어왔습니다. 이 글은 자동화 기술 가이드가 아니라, 혼자 폐쇄망 환경에서 자동화를 만들어온 과정과 그 사이에 깨달은 것들을 솔직하게 정리한 글입니다. 자동화 시작하려는 분, 혼자 인프라 운영하는 분, AI 도구를 어떻게 활용할지 고민하는 분들께 작은 참고가 됐으면 합니다. 왜 자동화를 시작했나 이유는 단순했습니다. 사람이 없었어요. 폐쇄망에 STT/TTS 인프라를 설치하러 나가는 작업이 많은데, 같이 일하던 사람들이 하나둘 회사를 떠나면서 설치 가능한 인력이 점점 줄어들었습니다. 결국 설치를 할 수 있는 사람이 저를 포함해 몇 명 안 남았고, 그마저도 동시에 여러 현장이 있을 때는 도저히 손으로 못 했습니다. 자동화가 거창한 이유로 시작된 게 아니라, 그냥 안 하면 일이 안 굴러갔어요. 저녁에 컨테이너 하나씩 손으로 올리다가 새벽에 끝나는 게 매주 반복되니까, 결국 "이걸 어떻게든 자동으로 돌게 만들어야겠다"는 생각만 들었습니다. 처음엔 정말 단순했다 지금 생각하면 웃기는데, 제 첫 번째 자동화 스크립트는 "1+n" 계산이었습니다. 진짜 그게 시작이었어요. 쉘 스크립트로 변수 두 개 더하는 것. 그게 됐다는 것만으로 신기해서 그 다음엔 2를 만들고, 그 다음엔 같은 파일을 100개 복사하는 스크립트로 갔습니다. 별것 아닌데 이런 작은 스크립트들이 쌓이면서 점점 자신감이 생겼습니다. 이 초석 작업들이 나중에 진짜 자동화로 연결됐습니다. 파일 복사가 됐으니까 컨테이너 설정 파일을 여러 환경에 뿌리는 것도 가능해졌고, 변수를 다룰 줄 알게 되니까 환경별로 다른 설정을 자동으로 적용할 수 있게 됐습니다. 거창한 자동화는 단순한 것들이 쌓여서 만들어지는 거였어요. 진짜 자동화 — STT/TTS Docker 컨테이너 실행 제가 가장 많이 쓰...
댓글 쓰기
자세한 내용 보기