이 글은 편의상 반말로 작성되었습니다.
보통 1월에 회고를 많이 하는데, 작년 말에 여러 이벤트가 겹쳐서 타이밍이 맞지 않았다. 지금은 어느 정도 정리가 되었고, 꽤 중요한 변화도 있었기 때문에 조금 더 늦은 2026년 3월까지의 경험을 2-3편의 글에 걸쳐 돌아보려 한다.
첫 번째 글은 전 직장에서의 회고와 이직을 결심하게 된 기술적인 이유에 대해 적어 보려고 한다.
DevOps Engineer at Allganize
올거나이즈는 B2B AI 솔루션 회사였다. 그리고 나는 1년 반 정도 DevOps 엔지니어로 일했다. 개인적으로는 백엔드 엔지니어에서 DevOps 엔지니어로 전향하여 처음으로 일한 회사였기 때문에 새로운 도전이었다. 하지만 DevOps + 클라우드 환경에 대한 흥미를 가지고 과감하게 직군을 바꾸는 결정을 하였다.
큰 작업을 돌아보자면 Docker Compose 기반이던 인프라를 Kubernetes로 전환했고, Argo CD 기반 CI/CD 파이프라인과 모니터링 구축 등 많은 일을 했다. 결과적으로 보면 경험과 기술적 성장은 꽤 이루었다고 생각한다. K8s 전환 초기 단계부터 참여하여 꽤 많은 의견을 반영할 수 있었고, Cloud를 메인으로 하면서 On-premise 환경도 다룰 기회가 있었고, 확실히 인프라 관점에서 생각하면서 전체적인 시야가 넓어졌다.
하지만 그 과정은 그렇게 순탄하지는 않았다.
반쪽짜리 K8s
회사에는 레거시 코드가 매우 많았고, 기술도 오래된 것, 도구도 마이너한 것들이 많았다. 이건 충분히 그럴 수 있는 일이다. 면접에서 어느 정도 설명을 듣고 들어가기도 했고, 이를 표준으로 바꾸는 경험 자체가 가치가 있을 것이라 생각했다. 그래서 입사할 때 최대한 개인의 선호를 배제하고, 가능한 업계 표준으로 인프라를 구성해야겠다고 다짐을 했다.
하지만 이 과정에서 가장 큰 문제는 이 상태에서 안주한 채로 K8s만 무리하게 도입하려 했다는 것이었다.
인프라 팀은 K8s 환경을 검증하고 여러 시행착오를 거쳤다. 이 과정에서 백엔드나 프론트엔드, 즉 코드 구조가 K8s에 맞게 바뀌어야 하는 부분들이 있었다. 하지만 이 부분을 개선하기 위한 제안은 번번이 무시당하거나, 다른 할 일이 있다는 이유로 거절되거나 잊혀졌다. 백엔드와 프론트엔드의 협력을 기대할 수 없었고, 안티패턴인 것을 알면서도 억지로 K8s를 끼워맞출 수밖에 없었다.
새로운 기술도 마찬가지였다. “기존 프로세스가 있다”는 이유만으로 새로운 기술 도입이 거절당했다. GitHub Actions와 Jenkins는 설명할 필요도 없는 업계 표준 스택이었다. 하지만 다른 것을 쓰고 있고 그것이 우리의 규칙이라는 이유로 도입이 거절되었다. 다른 논리적인 이유는 없었다.
다행히도 팀 리드에 계신 분은 방향성이 잘 맞았고, 트렌드 파악도 빠르신 분이었다. 그리고 시간이 지날수록 나를 많이 신뢰해 주셔서 많은 권한을 부여해 주셨다. 그래서 팀 내에서 지식 공유와 논의는 활발하게 이루어졌고, 새로운 기술 도입도 어느 정도 할 수 있었다. 하지만 팀이 회사를 바꾸는 것은 한계가 있었고 회사의 K8s는 “반쪽짜리 K8s”였다.
AI를 쓰지 않는 AI 회사
돌아보면, 2025년에 Claude Code가 돌풍을 일으키기 전에 Cursor가 있었다. Codeium과 Copilot이 먼저 있었지만, 개인적으로 AI 개발이 본격적으로 가능해진 시점은 Cursor부터였다고 생각한다.
Cursor의 사용감은 정말 좋았고 24년 말에 바로 유료 결제를 하여 사용하기 시작했다. Cursor와 Claude Code는 나에게 있어서는 혁명이었다. 기존에 여러 이유로 하지 못했던 것들을 할 수 있게 되었고, 여러 분야에서의 경험이 확실히 AI 기반 개발에는 좋은 양분이 되었다.
팀 내에 AI를 적극적으로 쓰는 분도 한 분 계셔서 그분과 이야기하는 것이 정말 즐거웠고 도움이 되었다. 갈수록 가속도가 붙었다. 업무와 개인 작업 구분하지 않고 AI를 엄청나게 괴롭혔고, 현재는 디자인을 포함하여 모든 개발을 AI를 통해 일정 수준 할 수 있게 되었다. 나만의 Harness도 만들고, 개발자로서의 가치관을 잡는 데도 큰 영향을 주었다.
25년 초 회사에서도 Cursor를 지원해 주기 시작했다. 이때 AI 기반으로 회사가 빠르게 도약할 수 있을 거라고 내심 기대했다. 하지만 리드급 엔지니어들은 Cursor가 VSCode 기반이라 익숙한 IDE를 버려야 한다는 이유로 Cursor에 부정적이었다. 여전히 Pycharm을 쓰면서 손으로 코딩을 하고 있었다. 전통적인 IDE 의존성에서 벗어나지 못하고 있었다. 재밌는 건, Claude Code를 적극적으로 사용하기 시작한 이유도 성능이 아니었다. CLI 형태라서 Pycharm과 함께 사용할 수 있었기 때문이었다. (물론 CLI로 Claude Code를 만든 Anthropic의 판단은 정말 좋았다고 생각한다)
또 25년 상반기에는 이미 간단한 앱을 AI 프롬프트만으로 만들 수 있다는 것이 증명되고 있었고, Lovable과 v0 같은 Agentic Website Builder도 나오기 시작했다. 그런데도 회사에서는 움직임이 별로 없었다. 그리고 어느 날, 누군가 Lovable로 앱을 만드는 것을 보고 엔지니어들은 신기하다, 충격적이라는 반응을 보였다. 나에게는 그것이 더 충격이었다.
25년 상반기까지 올거나이즈는 AI를 쓰지 않는 AI 회사였다. 그리고 이것의 원인은 현실에 안주하려는 조직, 그리고 변화를 거부하는 문화였다.
변하지 않는 프로세스
K8s도, AI도 결국 같은 벽에 부딪혔다. 새로운 기술을 도입해도 아무것도 변하지 않는 근본적인 이유는, 조직 자체가 일하는 방식을 개선하려는 의지가 없었기 때문이다.
보통 일반적인 회사에서 DevOps는 개발 프로세스의 중심에 있는 조직이다. 실제로 여러 프로세스를 도입하려 시도했고, 일시적으로 도입을 했던 것도 있다.
팀 리소스가 부족하여 On-prem 고객을 지원해야 할 때가 있었는데, 그 프로젝트에서는 고객의 요구사항을 무조건 들어주어야 한다는 이유로 작은 CS 하나가 들어와도 ASAP으로 처리하고 매일 배포를 하고 있었다. 이것이 너무 비효율적이었기 때문에 주간 배포 프로세스를 도입했다. 사람들은 공감해 주었고 내가 있는 동안 주간 배포는 잘 돌아갔다. 전사 워크샵에서도 Learning Point로 언급되었다. 하지만 내가 다시 On-prem 사이트를 벗어나 SaaS 환경을 맡게 된 후 그 프로세스는 조용히 사라졌다.
이후에도 기술과 방법론을 공유하고, 새로운 프로세스에 대한 가이드와 문서도 열심히 만들었다. 레거시 코드와 기술로 인한 사고가 우려되는 경우에는 팀 리드를 통해 공유하고 대안을 제시하기도 했다. 하지만 아무도 관심이 없었다. 개선안에는 “괜찮을 것 같은데요?”라는 반응이 조금 나왔지만 그뿐이었다. 당장 일어나지 않는 일에 대한 경고와 해결책에는 아무도 귀 기울이지 않았다. 이런 사항은 묻히고 무시당하거나, 몇 개월 뒤에 사고가 터지거나 C레벨이 나서야 비로소 변화가 생기는 패턴이 반복되었다.
결국 경력 후반부에는 어차피 나의 의견을 들어주는 사람은 팀뿐이었기 때문에 팀 내에서만 지식을 공유하고, 팀 내부에서 해결할 수 있는 일만 해결하는 방향으로 선회하게 되었다.
조직의 프로세스가 정립되어 있지 않고, 개선할 의지도 없으면 기술은 아무 의미가 없다. 이런 환경에서는 속도가 나올 수가 없었다.
정리
순수하게 개인적으로 생각하면, 기술적으로 성장한 것은 분명하다. K8s 전환, CI/CD 구축, 다양한 환경 운영 등 이력서에 쓸 수 있는 경험을 많이 쌓았다. AI 경험도 충분히 쌓았다.
하지만 프로세스가 없는 조직에서 개인이 아무리 노력해도 한계가 있다는 것을 절감했다. 기술 부채는 계속 쌓이고, 도입한 프로세스는 사라지고, 새로운 기술은 거부당한다. 그리고 그 과정에서 나도 수비적이고 폐쇄적으로 변해 간다는 것을 느꼈다. 이것이 이직을 결심한 첫 번째 이유였다.
다음 글에서는 기술 외적인 부분에 대해 이야기하려 한다.