AI가 DevOps 엔지니어를 대체할까? 2026년 기준 현실적인 전망과 커리어 전략

AI가 DevOps 엔지니어를 대체할까?
솔직히 말하면… 그럴 가능성은 거의 없습니다.
대신 “한 명이 관리하는 규모”가 미친 듯이 커질 뿐이에요.

아래 내용은 당신이 공유한 스크립트와 그걸 바탕으로 정리된 글의 핵심을
전부 한국어로 재구성한 겁니다.
번역이 아니라, 처음부터 한국어로 쓴 블로그 글처럼 다시 쓴다고 생각하면 됩니다.
(DevOps, Kubernetes, Terraform, CI/CD 같은 SW 관련 용어는 요청대로 전부 English 그대로 씁니다.)

 

“AI가 DevOps를 다 해준다”는 말, 어디까지 진짜일까?

 

---

1. “AI가 DevOps를 다 해준다”는 말, 어디까지 진짜일까?

요즘 여기저기서 이런 얘기 들리죠.

“AI가 Terraform도 쓰고, Kubernetes cluster도 만들고, CI/CD pipeline도 알아서 짜준다.”

심지어 어떤 데모에서는 agent가 자동으로 infrastructure를 만들고,
문제 생기면 스스로 고치는 것처럼 보여주기도 합니다.

그런데 Brett Fisher(10년 넘게 Docker랑 DevOps를 가르친 사람)가
KubeCon 같은 컨퍼런스에서 2년 동안 실제 엔지니어들한테 물어본 질문은 딱 하나였습니다.

“AI를 DevOps에 진짜 쓰고 있어요? Prod infrastructure에요, 장난 말고요.”

대부분의 대답은 이거였어요.

“ChatGPT로 코드나 YAML은 좀 쓰게 하지만,
AI가 직접 infrastructure를 만지게 하진 않아요.”

즉, 시연 영상·마케팅·슬라이드에서의 AI와
실제 팀들이 Production에서 쓰는 AI 사이에는
꽤 큰 간극이 존재합니다.

그 간극의 중심에 있는 숫자가 하나 있어요.

 

 

---

2. 70% 정확도: DevOps에선 사실상 0%와 다를 바 없다

Brett이 언급한 것 중에 Sweep Bench라는 게 있습니다.
이건 AI 모델들이 실제 GitHub issue를 얼마나 잘 해결하는지를 평가하는 벤치마크예요.

• 가짜 예제가 아니라
• 진짜 오픈소스 프로젝트에서 가져온 버그/feature 요청들입니다.

여기서 최신, 비싼 frontier model들 (예: Claude Sonnet, GPT-4급 모델들)이
얼마나 성능을 내냐면… 대략 70% 성공률 정도입니다.

70%라니, 듣기에 괜찮아 보이죠?

근데 DevOps 기준으로 보면, 이건 이런 의미입니다.

• Terraform 코드가 70%만 맞다 → infra가 아예 안 떠요.
• Kubernetes YAML이 70%만 맞다 → pod가 안 뜨거나 crash
• CI/CD pipeline이 70%만 맞다 → 빌드/배포가 실패
• Security policy가 70% 맞다 → 취약점이 그대로 열려 있을 수 있음

DevOps 세계에서는 “거의 됐다”가 “전혀 안 됐다”랑 별 차이가 없습니다.
동작하느냐, 안 하느냐가 전부거든요.

블로그 글이면 70% 완성된 초안을 받아서
나머지 30%를 수정하면 그럭저럭 publish할 수 있습니다.

하지만:

• “70% 완성된 Kubernetes cluster”
• “70% 완성된 CI/CD pipeline”
• “70% 안전한 Security 설정”

이런 건 존재 가치가 없어요.

그래서 “AI가 70%까지 해준다”는 말은, DevOps에선 “아직은 못 믿는다”에 가깝습니다.
무조건 사람이:

• 결과물을 읽어보고
• 수정하고
• 디버그하고
• 책임져야 합니다.

 

 

---

3. Software Engineer vs DevOps Engineer: 같은 모델, 다른 난이도

Brett이 강조하는 포인트가 하나 더 있어요.
AI가 가장 잘 동작하는 영역은 아직까지는 “애플리케이션 코드” 쪽 입니다.

 

3.1 Software 개발자는 이미 AI 전용 툴이 깔려 있다

애플리케이션 개발자는:

• GitHub Copilot
• Cursor
• ChatGPT / Claude IDE extension
• VS Code / JetBrains용 AI plugin

이런 걸로,

• 함수 뼈대
• test code
• refactoring
• 설명까지 죄다 자동으로 받아볼 수 있습니다.

IDE를 열면 AI가 바로 옆에 있는 구조예요.

 

3.2 DevOps 엔지니어의 현실은 완전 다르다

DevOps 엔지니어의 일은 한 군데에 모여 있지 않습니다.

• AWS / GCP / Azure console
• Terraform repo
• Kubernetes cluster
• GitHub Actions / GitLab CI / Jenkins
• Prometheus, Grafana, Datadog, New Relic
• Security tool, IAM, network policy…

하나의 IDE 안에 다 들어가는 구조가 아니죠.

그래서 DevOps에서의 질문은

“AI가 DevOps를 도와줄 수 있냐?”

보다는,

“어디서부터 쓰기 시작해야 안전하고,
어느 부분에 가장 먼저 적용하는 게 좋을까?”

이에 가깝습니다.

Brett의 답은 의외로 단순해요.

“작고 구체적인 부분부터 시작해라.
한 번에 전체를 자동화하려 하지 말고.”

Kubernetes 도입할 때도:

• 처음부터 전 서비스 마이그레이션 하지 않고
• 하나의 service부터 옮겨 본 뒤
• 점점 확장했죠.

AI도 똑같이 접근해야 합니다.

 

 

---

4. 지금 당장 DevOps에서 쓸 만한 AI 활용 사례

이제 현실적으로 오늘부터 도전해 볼 수 있는 영역들을 정리해 보겠습니다.

 

4.1 케이스 1 – CI/CD: AI 실험장으로 딱 좋은 영역

CI/CD pipeline은 AI 적용을 시작하기 좋은 구간입니다.

이유를 정리해 보면:

1. 실패해도 blast radius가 작다
   • pipeline이 망가지면 build/배포가 안 될 뿐이지
   • 바로 prod를 깨먹지는 않습니다.
2. 패턴이 반복적이다
   • build → test → lint → package → push → deploy
   • AI가 반복 패턴을 기반으로 하는 작업을 정말 잘합니다.
3. feedback loop가 빠르다
   • commit → pipeline 실행 → 몇 분 안에 성공/실패 확인
   • 금방금방 수정하면서 학습하기 좋죠.

그래서 다음 같은 일을 AI에게 시키기 좋습니다.

• 새로운 repo에 맞는 GitHub Actions / GitLab CI pipeline YAML 초안 생성
• 기존 pipeline 리팩토링 (cache 추가, job 병렬화 등)
• 팀 표준에 맞게 pipeline snippet 자동 생성

단, 무조건 사람이 review 합니다.
AI가 pipeline을 “완성”하는 게 아니라,
사람이 리뷰하기 편한 초안을 만들어 준다고 생각해야 합니다.

 

 

---

4.2 케이스 2 – Observability + Alert Triage: 읽기 전용 AI

Brett이 가장 현실적이라고 보는 use case가 바로 이겁니다.

시나리오는 대략 이렇습니다.

1. Monitoring system에서 alert 발생
   • 예: Prometheus + Alertmanager, Datadog, CloudWatch, New Relic 등
2. PagerDuty 같은 alerting tool이 AI에게도 알림 전달
   AI는 그걸 트리거로 삼아서:
   • 관련 service의 log 조회
   • CPU, memory, latency 같은 metrics 조회
   • 최근 deployment 이력 확인
   • 비슷한 과거 incident 찾아보기
3. 그리고 Slack 같은 채널에 이렇게 정리해서 올립니다.

“지금 alert 기준으로 보면,
– 최근 deploy 이후 error rate spike
– 특정 pod OOMKilled
– DB connection pool 고갈
셋 중 하나일 가능성이 높아 보입니다.
관련 log와 metric 요약은 아래에 정리했습니다.”

여기서 핵심은:

• AI는 read-only 모드라는 것
• infra를 직접 건드리지 않습니다.
• 틀려도 “조금 시간 낭비” 정도에서 끝납니다.

하지만 맞으면?

새벽 3시에 일어나서 log 뒤지고 metric 챙겨 보는
그 30~60분이 그냥 사라집니다.

이 패턴이 DevOps에서 AI를 쓸 때 가장 이상적입니다.

Low risk + High value + Read-only + Suggestion only

 

 

---

5. MCP: AI에게 “살아 있는 시스템”을 보여주는 방법

스크립트에서 자주 나오는 키워드가 하나 있죠.
바로 MCP (Model Context Protocol) 입니다.

MCP를 엄청 단순하게 말하면 이거예요.

“AI가 GitHub, AWS, Kubernetes, metric system 같은 곳에
정식 API로 접근할 수 있게 해주는 공통 프로토콜”

지금 우리는 보통 이렇게 AI를 씁니다.

• Terraform 코드 복붙해서 ChatGPT 창에 붙여넣기
• Kubernetes YAML 복사해서 “이거 좀 고쳐줘”
• error log를 복사해서 “왜 죽는지 알려줘”

즉, 사람이 context를 제공하는 구조죠.

MCP가 있으면 AI가 직접:

• GitHub repo에서 특정 파일 내용 읽기
• AWS 계정에서 resource 상태 조회
• Kubernetes cluster 상태 확인
• monitoring metrics 조회
• team documentation, runbook 읽기

이런 걸 할 수 있습니다.

이렇게 되면, AI는
“prompt 한두 줄”에 의존하는 게 아니라
실제 시스템 상태를 보고 판단할 수 있게 됩니다.

물론 여기에도 전제가 하나 있습니다.

시스템이 정리돼 있고,
naming convention, security rule, 표준이
문서로 정리돼 있어야 한다는 것.

그렇지 않으면 AI는 그냥:

• “대충 이런 식으로 쓰겠지?”
• “이 정도 권한이면 되겠지?”

하고 자기 멋대로 상상합니다.

그래서 오히려 이런 말까지 나옵니다.

“AI 시대에는 오히려 QA, tester, document 작성자들이 더 중요해질 수도 있다.”

AI에게 신뢰할 수 있는 context를 주려면:

• 명확한 요구사항
• 잘 작성된 문서
• 일관된 구조 및 예시

가 필수니까요.

결론적으로:

지금 문서 정리하고 runbook 정리하는 일은
미래의 AI를 위한 투자이기도 합니다.
바로 그 문서를 AI가 먹고 자라니까요.

 

 

---

6. 70% → 90%: “시간을 들여 튜닝한 AI”의 모습

처음에 AI를 한 workflow에 집어넣으면:

• 대략 70% 정도 맞습니다. (Sweep Bench 기준 느낌상)

여기서 할 수 있는 게:

1. task scope를 더 좁히고
2. requirement를 더 구체적으로 적고
3. 문서를 더 체계화해서 AI에게 통째로 먹이고
4. MCP 같은 걸로 실제 context를 더 많이 연결하고
5. prompt를 계속 튜닝하는 것

이 과정을 몇 주, 길면 몇 달 반복하면
“특정한 좁은 문제”에 대해서는 AI가

“10번 중 9번 정도는 한 번에 제대로 해주는 수준”

까지 올라갈 수 있습니다.

예를 들어:

• “이 repo의 GitHub issue 중 DevOps 태그가 붙은 것들은
  – 이 Terraform module 구조를 따르고
  – 이 naming convention을 지키고
  – 이 IAM role만 쓰고
  – 이 policy check를 통과하도록
  PR을 만들어라.”

이런 식으로 꽉 막힌 룰 속에서는
AI가 꽤 쓸 만한 효율을 보여줄 수 있습니다.

하지만 이건:

• 매우 좁은 문제 영역
• 엄청 많이 제공한 context
• 잘 정리된 문서와 예시

위에서만 가능한 이야기입니다.
“한 방에 모든 DevOps 자동화”와는 거리가 멀어요.

그래서:

• 미리 Infrastructure as Code를 잘 구조화해 놓고
• CI/CD도 표준화 해 두고
• runbook, architecture diagram, standard를 정리해 둔 팀일수록

AI를 활용하기가 훨씬 유리합니다.

 

 

---

7. KubeCon에서 들은 현실: “다들 실제론 아직 안 쓰고 있다”

Brett이 제일 인상 깊었던 경험은 이거예요.

2년 동안 KubeCon expo hall을 돌아다니면서,
만나는 사람마다 “AI DevOps 쓰냐?”고 물어봄.

그런데 나오는 얘기는:

• “우리 회사에서 AI inference 직접 돌리진 않아요.”
• “AI로 infrastructure를 자동으로 수정하게 하진 않아요.”
• “ChatGPT로 코드나 YAML은 쓰지만, 자동 배포까지 맡기진 않아요.”

반면에,

• 발표 세션
• 마케팅 슬라이드
• 블로그 글

에서는 모두:

“AI로 DevOps 자동화,
agentic DevOps,
fully autonomous pipeline…”

이런 말을 합니다.

짧게 말하면:

“말”로는 엄청 쓰는 것 같지만,
“실전”에서는 아직 거의 안 쓰고 있다.

그리고 Brett 말로는
2024~2025 들어서야 비로소

• “그럼 우리 진짜 어디부터 AI 써볼까?”
• “Prod에 안전하게 넣으려면 어떻게 해야 하지?”

라는 얘기가 본격적으로 나오고 있다고 합니다.

즉,

지금 당장 AI DevOps 안 하고 있다고 해서
절대 뒤처진 게 아닙니다.

오히려 대부분의 팀은
이제 막 “진지하게 고려해 볼까?” 수준이에요.

 

 

---

8. 인프라 역사로 보는 DevOps 잡(Job)의 미래

Brett은 30년 넘게 인프라·운영 분야에 있었기 때문에,
AI 이전에 지나온 여러 번의 큰 변화를 직접 겪었습니다.

그 흐름은 대략 이렇습니다.

1. 1990년대 – mainframe → PC
2. 2000년대 초 – physical hardware → virtualization
3. 약 2010년 전후 – on-prem → cloud
4. 그 이후 – cloud → container / Kubernetes
5. 지금 – container → “AI-augmented operations”

이전에도 항상 이런 걱정이 있었습니다.

• “이제 자동화되면 사람 덜 필요하겠네?”
• “virtualization되면 서버 관리 인원 줄겠지?”

하지만 실제로 일어난 일은 완전히 달랐습니다.

Brett이 말하는 “rough chart”는 이렇습니다.

• 90년대: 한 명의 sysadmin이 관리하던 서버 수 → 10대 수준
• virtualization 도입 이후 → 100대
• cloud 시대 → 1,000대
• container/Kubernetes → “서버 수”가 아니라
  workload 기준으로 수만 개까지 관리 가능

즉, 인당 관리 규모가 계속 확대됐습니다.

그렇다고 기업이

“좋다, 그럼 사람 줄이자.”

라고 했느냐? 거의 반대였습니다.

• 더 많은 서비스
• 더 많은 region
• 더 많은 DR site
• 더 많은 실험 환경
• 더 높은 가용성 목표

을 요구하게 됐죠.

티켓 큐가 0이 된 적은 없습니다.
“하고 싶은 것”이 늘어난 만큼
해야 할 일도 계속 늘어났습니다.

AI도 똑같은 패턴을 따를 가능성이 큽니다.

• 한 DevOps 엔지니어가 50,000 containers,
  수십만 serverless 함수까지 관리할 수 있게 되더라도

그때 회사가 할 말은 아마 이거일 겁니다.

“좋아, 그럼
– 더 많은 product를 만들고
– 더 많은 region에 진출하고
– 더 빠른 배포랑 더 높은 신뢰성을 구현하자.”

그래서 요약하면:

AI는 DevOps 엔지니어를 없애는 게 아니라,
DevOps 엔지니어 한 명의 영향력을 확 키워준다.

일 자체가 사라지지 않고,
스코프가 넓어지는 쪽으로 변하는 겁니다.

 

 

---

9. “Syntax는 AI가 알면 되지 않나요?”에 대한 진짜 대답

정말 많이 나오는 질문이 있습니다.

“앞으로는 사람은 architecture나 design 위주로만 하고,
syntax나 구현은 AI가 다 하는 거 아니에요?”

Brett의 대답은 꽤 명확합니다.

“그렇게 되려면 아직 멀었다.
당분간은 syntax도 알고 있어야 한다.”

그 이유는 간단합니다.

• Kubernetes API endpoint가 잘못 노출됐다.
• Terraform으로 위험한 security group이 생성됐다.
• CI/CD가 이상하게 prod에 rollout을 해버렸다.

이때 회사는 누구를 탓할까요?

• “AI를 해고하자.”라고 할 수는 없습니다.
• 책임은 결국 commit/merge/deploy를 승인한 사람에게 옵니다.

postmortem에서 5 Whys를 시작하면:

• “왜 이 설정이 prod에 적용됐지?”
• “왜 이 PR이 review 없이 merge됐지?”
• “왜 이 risk를 인지하지 못했지?”

이게 전부 사람의 책임과 판단 영역입니다.

즉, 사람이:

• Kubernetes가 어떻게 동작하는지 알고 있어야 하고
• Terraform 코드가 좋은지 나쁜지 구분할 줄 알아야 하고
• CI/CD pipeline에서 risk가 어디 있는지 감지할 수 있어야 합니다.

AI가:

• 코드를 “써줄 수는” 있지만
• 그 코드에 대한 책임은 사람에게 있기 때문에

syntax·구현을 완전히 모른 채
“설계만 살짝 아는 사람”으로는 버티기 어렵습니다.

그래서 앞으로의 스킬 변화는

“직접 손으로 모든 걸 쓰는 사람 →
AI가 쓴 걸 판단·수정·감독하는 사람”

쪽에 가깝습니다.

하지만 판단하려면 기본 개념과 syntax를 반드시 알아야 합니다.

 

 

---

10. 지금 DevOps 채용 공고가 말해주는 것

스크립트에서는 실제 DevOps/Cloud/Platform 채용 공고를
여러 나라에서 모아서 분석했다는 내용도 나옵니다.

거기서 반복적으로 등장하는 요구사항은:

• Kubernetes
• Terraform
• Docker
• CI/CD tool (GitHub Actions, GitLab CI, Jenkins 등)
• Cloud platform (AWS/GCP/Azure)
• Observability tool

반면 거의 보이지 않는 건:

• “ChatGPT DevOps 사용 필수”
• “AI agent for infrastructure 필수”

AI 관련 내용은 있다 해도
대부분 “플러스 요인” 정도로 언급될 뿐입니다.

정리하면:

지금은 여전히 DevOps 기본기가 핵심입니다.
AI는 그 위에 쌓는 부스터에 가깝습니다.

그래서 학습 순서는 이게 자연스럽습니다.

1. DevOps 기본 스택 (Linux, cloud, container, Kubernetes, Terraform, CI/CD, observability 등)을 solid하게 쌓고
2. 그 위에 AI tool 사용법, prompt 전략, workflow 자동화를 얹기

 

 

---

11. DevOps에서 AI 도입, 현실적인 로드맵

자, 그럼 실제로 어디서부터 시작하면 좋을지 단계별로 정리해 보겠습니다.

 

Step 1 – 이미 회사에서 쓰는 AI부터 활용

팀에서 이미:

• ChatGPT/Claude/Gemini
• GitHub Copilot, Cursor

같은 걸 쓰고 있다면, 새 툴 찾기 전에
먼저 그 도구들로 DevOps 작업을 얼마나 도와받을 수 있는지 탐색해 보는 게 좋습니다.

새로운 도구 5개를 한꺼번에 도입하면
배우는 데만 시간이 다 날아갑니다.

 

Step 2 – 작은 영역 하나만 골라서 실험

처음부터 “우리 DevOps 전부 AI로 자동화!” 이런 건 망하는 지름길입니다.

대신 예를 들면:

• CI/CD pipeline 생성/개선
• 특정 Kubernetes manifest/Helm chart 초안 생성
• Terraform module boilerplate 생성
• runbook 초안 작성

처럼 작고, rollback이 쉬운 영역 하나만 골라보는 게 좋습니다.

그리고 무조건:

“AI가 1차 draft → 사람이 review & 수정”

구조로 가야 합니다.

 

Step 3 – 팀 표준과 요구사항을 문서로 만들고, AI에 먹이기

AI에게 “잘 해봐”라고 하면
대부분 나름대로 최선을 다하지만,
그 최선이 팀 기준에서 엉망일 가능성이 큽니다.

그래서 먼저 정리해야 하는 것들:

• naming convention
• IAM role / policy 규칙
• 허용되는 region, account
• tagging standard
• security rule (예: public access 금지 조건 등)
• “좋은 예시”가 담긴 코드 snippet

이걸 문서로 정리해서
prompt에 붙이거나,
MCP 등으로 AI가 직접 읽을 수 있게 해주면
품질이 눈에 띄게 올라갑니다.

 

Step 4 – Human in the loop 유지

AI를 “상급 엔지니어”로 보면 안 됩니다.
대략 이렇게 생각하면 딱 맞습니다.

“엄청 똑똑한 인턴인데,
가끔은 진짜 자신감 있게 틀린다.”

그래서:

• review 없이 direct merge 금지
• prod 배포 전 반드시 사람 눈으로 확인
• 중요 security 설정은 2인 이상 검토

이런 식의 기본적인 가드레일은 꼭 필요합니다.

 

Step 5 – 한 workflow에 집중해서 튜닝

“여기저기 조금씩 쓰는” 것보다
특정 workflow 하나에 집중해서

• prompt template을 만들고
• 필요한 문서를 정리하고
• 예시를 모으고
• 실패/성공 케이스를 분석하면

그 workflow에 한해서는
정말 유용한 도우미 수준의 AI가 됩니다.

예:

• “DevOps 관련 GitHub issue → AI가 PR 생성 → 사람이 review”
• “alert 발생 → AI가 log/metric 분석 summary 작성 → 사람이 최종 원인 판별”

 

Step 6 – Build vs Buy 고민

조금 익숙해지고 나면, 선택지가 생깁니다.

1. Build
   • open source + script + MCP를 조합해서
     우리 팀만의 DevOps AI workflow를 직접 만든다.
   • 장점: 커스터마이징 자유, 내부 구조 다 이해 가능
   • 단점: 시간·유지보수 비용 큼
2. Buy
   • DevOps 특화 AI 플랫폼을 구매한다.
   • 장점: 빠르게 시도 가능, UI/UX 정리돼 있을 가능성 컸
   • 단점: 비용 + vendor lock-in + 우리 상황에 딱 안 맞을 수 있음

어느 쪽이든, 핵심 문제는 똑같습니다.

“이 AI가 우리 infra와 standard를
어디까지, 얼마나 제대로 이해하고 있느냐?”

그래서 문서와 구조가 잘 돼 있는 팀일수록
어느 옵션을 선택하든 결과가 좋습니다.

 

 

---

12. 앞으로의 DevOps: “AI와 함께 일하는 사람”의 모습

Brett이 상상하는 가까운 미래 workflow는 이런 그림입니다.

• 본인은 GitHub repo에 issue만 올립니다.
• 나머지:
  • security scan
  • Terraform / Kubernetes / CI/CD 수정
  • CVE detection + remediation 제안
  • best practice 위반 체크
  등은 AI가 pipeline에서 단계별로 처리합니다.

자기는:

• issue를 열고
• AI가 만든 PR을 review해 주고
• approve / 수정 / reject만 하면 됩니다.

드라마 Silicon Valley에 나오는
DevOps 캐릭터 Gilfoyle처럼,

겉으로는 “AI가 내 역할을 대신하는 것처럼” 보이지만,
실제로는 그 AI를 설계·관리·감독하는 사람이 되는 거죠.

다만, Brett이 실제로 들은 사례에 따르면:

• AI로 DevOps PR review를 자동화하려고 시도한 팀도 있었지만
• 구현과 튜닝 과정이 너무 복잡해서,
  당장은 “모두가 쉽게 따라 할 수 있는 수준은 아니다.”

즉, 방향은 어느 정도 보입니다.
하지만 아직은 실험과 시행착오 단계에 가깝습니다.

 

 

---

13. 우리가 진짜로 물어야 할 질문

많은 사람이 묻습니다.

“AI가 DevOps 엔지니어를 대체할까요?”

하지만 Brett의 관점에서 진짜 질문은 이겁니다.

“AI 덕분에 DevOps 엔지니어 한 명이
1,000개가 아니라 50,000개의 container를 다룰 수 있게 되면,
조직은 그 능력을 어떻게 쓸까?”

역사를 보면 답은 뻔합니다.

• 더 많은 product
• 더 많은 feature
• 더 많은 region
• 더 높은 안정성과 복구 전략

일감은 줄어들지 않고, 오히려 늘어납니다.

그래서 앞으로를 준비하는 가장 현실적인 방법은:

1. 기본기를 포기하지 않기
   • Kubernetes, Terraform, CI/CD, cloud, networking, security
   • 이 모든 건 여전히 필수입니다.
2. AI를 “대체재”가 아니라 “증폭기”로 보기
   • “내가 할 일을 대신하는 존재”가 아니라
   • “내가 더 큰 문제를 다루게 도와주는 도구”
3. 문서화와 구조화에 투자하기
   • 지금 쓰는 runbook, architecture doc, standard가
     나중에 AI의 “교과서”가 됩니다.
4. 작게 시작해서, 빠르게 배워 나가기
   • CI/CD, observability 같은 저위험 영역부터
   • 직접 손을 대 보는 게 가장 빠른 학습입니다.
5. 과장된 홍보는 항상 의심하기
   • “완전 자동화”를 말하는 사람에게는
     꼭 “Prod에서 실제로 쓰는 고객 사례가 있냐”고 물어보세요.
6. 지금부터 차분하게 실험해 보기
   • 공포감 때문이 아니라,
   • 도구를 남들보다 먼저 손에 익히기 위해서.

 

 

---

마무리: 지금 할 수 있는 한 가지

여기까지 읽었다면,
머릿속에 그림은 대충 그려졌을 겁니다.

“AI는 당장 나를 대체하진 않는다.
대신, 잘 쓰는 사람이 훨씬 큰 영향을 미치게 한다.”

지금 이번 주 안에 해볼 수 있는
아주 구체적인 액션을 하나 꼽자면:

현재 프로젝트 중 하나를 골라서,
CI/CD pipeline 또는 Terraform/Kubernetes config 한 구간에
AI를 “초안 작성 도구”로 써 보고,
내가 그걸 어떻게 review하고 고치는지 관찰해 보는 것.

이 한 번의 실험에서:

• AI가 뭘 잘하고
• 어디서 자주 틀리고
• 내가 어떤 기준으로 “이건 안 돼”라고 판단하는지

를 굉장히 많이 얻게 될 겁니다.

원한다면,
당신이 지금 쓰고 있는 stack(Kubernetes인지, Terraform인지, GitHub Actions인지 등)을 알려주면

• AI 도입하기 좋은 첫 번째 workflow를 같이 골라보고
• 그때 쓸 prompt 템플릿이랑
• 위험 줄이는 guardrail 아이디어도
  한국어로 딱 맞게 같이 짜볼 수 있어요.