AI 시대는 Kubernetes의 가장 큰 실수를 다시 반복하고 있다 — 그리고 엔지니어가 지금 선택해야 할 것들
어딘가 묘한 기시감이 느껴진다.
한때 Infrastructure나 DevOps 근처에 있었던 사람이라면 기억할 것이다. Kubernetes 초창기, 그 뜨거운 분위기. 뭐든지 클러스터 안으로 넣던 시절 말이다. Metrics도, Database도, Storage orchestration도, Monitoring도 전부 Kubernetes로 해결하려 했다. 하나의 플랫폼으로 모든 걸 통제하겠다는 이상.
그리고 지금, 똑같은 장면이 다시 펼쳐지고 있다. 다만 이번 키워드는 Kubernetes가 아니라 AI다.
솔직히 말해, 이 지점에서 한 번쯤은 멈춰 서야 한다.
“AI가 내 일을 가져갈까?”라는 불안
먼저 이 감정부터 인정하자. 이건 과장이 아니다.
주변을 보면, 실제로 엔지니어가 줄어들고 AI 도구가 코드를 작성하는 장면이 현실이 됐다. Slack 대화방, 퇴근 후 맥주 자리, 혼자 노트북을 닫는 순간—어디서나 같은 질문이 떠오른다.
‘이 기술, 나를 필요 없게 만드는 거 아닐까?’
반응은 보통 두 가지다.
- “AI가 와도 나는 괜찮아”라는 막연한 낙관
- “이제 뭘 배워도 소용없다”는 체념
하지만 둘 다 본질을 비켜간다.
답은 미래가 아니라, 과거에 있다.
Kubernetes는 원래 단순했다 — 우리가 복잡하게 만들었을 뿐
불편한 사실 하나.
Kubernetes 자체는 그렇게 복잡한 시스템이 아니었다.
핵심만 보면 이렇다.
- 선언적 API
- 상태를 저장하는 etcd
- 원하는 상태와 실제 상태를 맞추는 Controller
끝이다.
문제는 사람들이었다. Oracle, Java, React, Legacy networking 같은 서로 다른 세계를 하나로 묶으려다 보니, 수많은 접착제가 필요해졌다. 접착제가 늘어나면 계층이 생기고, 계층은 곧 불안정성으로 이어진다.
가장 치명적인 실수는 기술이 아니라 태도였다.
“이게 정말 클러스터 안에 있어야 할까?”라는 질문을 하지 않게 된 것.
외부에서 잘 돌아가던 Metrics 시스템을 굳이 안으로 끌어왔고, 운영 경계가 분명하던 Database도 Pod 안에 넣었다. 그러다 보니 클라우드 안에서 또 다른 클라우드를 만드는 아이러니가 생겼다.
지금 AI에서도 같은 흐름이 보인다.
AI는 새로운 “일단 넣어보자”가 되고 있다
요즘 AI는 거의 모든 곳에 등장한다.
Customer support, 내부 Workflow, 의사결정, 브레인스토밍, 채용 필터링까지—AI, AI, AI.
어떤 경우엔 효과가 있다. 어떤 경우엔 그냥 그렇다. 그리고 어떤 경우엔, 조용히 시스템을 더 나쁘게 만든다.
문제는 AI가 아니다. 생각 없이 적용하는 태도다.
무언가에 AI를 붙이기 전에, 엔지니어라면 최소한 이 세 가지는 물어야 한다.
- 우리가 진짜 풀고 싶은 문제는 뭔가?
- 이게 가장 단순한 해결책인가?
- 이 복잡성을 추가하면서 무엇을 포기하게 되는가?
현실에서는 대부분 곧바로 “어떻게 붙일까?”부터 시작한다.
그 순간부터 커리어의 방향이 흔들리기 시작한다.
‘How’는 싸다. ‘Why’는 희귀하다
AI는 ‘How’를 정말 잘한다.
코드 작성, API 연결, 최적화, 여러 버전 생성—눈 깜짝할 사이다.
만약 엔지니어로서의 가치가 거기서 끝난다면, 경쟁 상대는 사람이 아니라 AI다.
AI가 아직 잘 못하는 건 그 이전 단계다.
- 이 시스템이 왜 존재하는지
- 왜 이 선택이 다른 대안보다 나은지
- 왜 이번엔 굳이 AI를 쓰지 않는 게 맞는지
AI를 쓰지 말자는 이야기가 아니다. Architectural literacy의 문제다.
살아남는 엔지니어는 이렇게 말할 수 있는 사람이다.
“이 도구는 강력하지만, 지금 이 문제엔 맞지 않습니다.”
거꾸로 배우기: What → Why → How
많은 사람들이 기술을 거꾸로 배운다.
How부터 시작한다.
- 어떻게 Deploy 하는지
- 어떻게 Prompt를 쓰는지
- 어떻게 최적화하는지
당장은 뭔가 하는 느낌이 든다. 하지만 금방 무너진다.
더 오래 가는 방식은 이렇다.
- What — 이건 정확히 뭔가?
- Why — 왜 이런 게 필요해졌나?
- How — 그래서 어떻게 구현됐나?
맥락과 배경을 이해하면, 구현은 훨씬 쉬워진다. 그리고 무엇보다 자동화되기 어렵다.
AI는 절차를 외울 수는 있어도, 맥락에서 오는 판단은 대신할 수 없다.
AI가 아직 가져가지 못한 영역들
2025년 이후를 생각한다면, 에너지를 쏟을 곳은 분명하다.
- System design과 Architecture 판단
- Business constraint를 이해하는 능력
- 비기술 직군과의 소통
- 만들지 않는 선택을 할 수 있는 용기
- 도구를 무분별하게 쓰지 않는 절제력
이건 유행어가 아니다. 실제로 사고가 터지는 지점들이다.
아이러니하게도, AI 덕분에 이런 역량은 더 비싸진다. 실행이 쉬워질수록, 결정은 더 어려워지기 때문이다.
Open source와 DeepSeek가 보여준 것
오랫동안 ‘AI는 거대 기업만 할 수 있다’는 말이 당연처럼 받아들여졌다. 그런데 Open source 모델들이 그 전제를 흔들었다.
이 장면은 Cloud와 Kubernetes 초기와도 닮았다.
- 도구는 점점 민주화되고
- 힘은 분산되며
- 경쟁력은 소유가 아니라 이해에서 나온다
이제 중요한 건 최고의 AI를 갖고 있느냐가 아니다.
어떤 문제를 풀고 있느냐다.
느린 게 오히려 프로다
요즘 시대에 가장 역설적인 사실 하나.
빨리 도입할수록 시니어인 건 아니다.
모든 트렌드를 쫓는 건 불안의 신호일 수 있다. 숙련된 엔지니어일수록 멈추고, 질문하고, 필요 없는 건 버린다.
미래는 AI 헤드라인을 쫓는 사람의 것이 아니다.
- 끝없는 호기심을 가진 사람
- 자존심을 내려놓을 줄 아는 사람
- 속도보다 판단을 중시하는 사람
AI는 앞으로 인간이 평생 쓸 코드보다 더 많은 코드를 쓰게 될 것이다.
하지만 여전히 왜 이 시스템이 존재해야 하는지는 알려주지 못한다.
그건 우리의 몫이다.
기억해둘 문장 하나
How만 할 줄 알면 AI와 경쟁하게 된다.
What과 Why를 설명할 수 있으면 AI는 증폭기가 된다.
Kubernetes에서도, AI에서도, 그리고 그 이전의 모든 기술 변화에서도 반복된 교훈이다.
FAQ (2025 기준)
Q. AI 때문에 엔지니어 일자리가 사라질까?
A. 사라지기보단 변한다. 구현보다 판단의 비중이 커진다.
Q. AI tool 학습은 여전히 중요한가?
A. 중요하다. 다만 목적이 아니라 수단이어야 한다.
Q. 장기적으로 안전한 역량은?
A. Architecture, 소통, trade-off 분석, 비즈니스 이해.
Q. AI를 모든 곳에 쓰는 전략은 위험한가?
A. 그렇다. 복잡성은 항상 비용을 동반한다.
Q. Kubernetes의 실수를 반복하지 않으려면?
A. 무엇을 넣을지가 아니라, 무엇을 빼야 하는지부터 고민하라.
Q. Open source는 AI에서도 의미가 있을까?
A. 여전히 크다. 집중된 힘을 분산시키는 역할을 한다.
Q. 주니어는 AI부터 배워야 할까?
A. 기본기가 먼저다. AI는 빨리 변하지만 기본은 남는다.
Q. 지금 가장 흔한 커리어 실수는?
A. 속도를 방향으로 착각하는 것.
Q. AI는 나를 더 좋은 엔지니어로 만들어줄까?
A. 생각을 대신하지 않는다면, 그렇다.
Q. 가장 중요한 태도는?
A. 자존심 없는 호기심. 이건 언제나 유효하다.
'SW > 인공지능' 카테고리의 다른 글
| LLM부터 RAG, AI Agent까지 한 번에 정리한 최신 AI 핵심 개념 9가지 (2025 기준) (0) | 2026.02.28 |
|---|---|
| 메타가 인수한 Manus AI란? 자율 AI 에이전트가 무엇인지 한 번에 정리 (0) | 2026.02.26 |
| LTX-2란 무엇인가? 12GB GPU로 로컬에서 오디오·비디오 생성하는 오픈소스 AI 정리 (0) | 2026.02.21 |
| AI로 작성한 코드, 정말 안전할까? AI 생성 코드의 문제점과 실무 대응 전략 (0) | 2026.02.13 |
| MeDo vs Lovable 비교 후기: AI App Builder로 실제 서비스까지 만들어본 솔직한 결과 (0) | 2026.02.10 |