..

정글 - Devops란?

이동석 코치님 강의

 

IT 개발 문화의 변화

  1. 과거 개발 방식
    과거에는 제품 하나를 완성하는 데 3년 이상 걸렸고, 모든 단계가 문서로 확정되는 ‘폭포수 모델’이 일반적이었다. QA 팀은 여러 제품을 동시에 검증하느라 일정이 밀렸고, 운영팀은 안정성을 이유로 업데이트를 꺼리는 보수적인 문화를 유지했다.

  2. 서버와 인프라 관리
    당시 서버는 수동으로 증설해야 했으며, 자원 사용률이 70%를 넘으면 관리자가 직접 서버를 추가하는 규칙이 있었다. 이런 방식은 효율성이 낮고 변화에 대응하기 어려웠다.

변화의 시작 – 애자일과 DevOps의 등장

  1. 애자일(Agile) 개발의 등장
    제품 출시 주기가 3년에서 3개월로 짧아지면서, 문서 대신 코드와 커뮤니케이션 중심으로 협업하는 애자일 문화가 확산되었다. 개발 과정에서 스크럼 같은 프레임워크를 활용해 빠르게 피드백을 주고받는 것이 핵심이 되었다.

  2. 고객 중심 개발과 MVP
    고객에게 기능 목록을 보여주고 우선순위를 함께 정하는 방식으로 전환되었으며, 최소 기능만 담은 MVP(Minimum Viable Product)를 먼저 출시해 시장 반응을 보고 개선하는 전략이 자리 잡았다.

품질 혁신 – 테스트 중심 개발

  1. 테스트 주도 개발(TDD)
    문서 없이도 개발할 수 있도록 TDD(Test-Driven Development) 방법론이 도입되었다. 이는 기능 구현 전 테스트 코드를 먼저 작성하고, 테스트를 통과하도록 코드를 완성하는 방식이다.

  2. 테스트의 중요성
    테스트 코드가 없는 코드는 코드로 인정받지 않으며, 오픈소스 프로젝트는 최소 95% 이상의 테스트 커버리지를 요구한다. 이를 달성하지 못하면 레거시 코드로 간주된다.

DevOps의 개념과 자동화

  1. DevOps의 의미
    DevOps는 ‘Development(개발)’과 ‘Operations(운영)’을 결합한 개념으로, 개발자가 코드를 완성하면 CI/CD 파이프라인을 통해 자동으로 빌드·테스트·배포가 이루어진다.

  2. 운영 자동화의 확산
    운영자는 서버 하드웨어 사양을 이해하고 OS 설치 및 설정 자동화를 수행해야 하며, 클라우드 시대에는 서버 증설조차 코드로 제어할 수 있게 되었다.

  3. DevOps의 유연한 정의
    DevOps는 특정 도구나 표준이 아니라, 개발과 운영의 경계를 허무는 조직 문화와 사고방식의 변화로 이해해야 한다.

기술 선택과 철학

  1. 프로젝트 성격에 맞는 기술 선택
    변화가 적은 대규모 시스템(금융, 공공기관 등)은 Java/Spring, 변화가 잦은 스타트업형 프로젝트는 Python/Node.js가 적합하다. 스키마가 자주 바뀌면 MongoDB, 고정적이라면 RDB를 사용한다.

  2. 기술 선택의 근거
    프레임워크와 언어를 고를 때는 단순한 유행이 아니라, 프로젝트 특성과 운영 환경을 논리적으로 설명할 수 있어야 한다.

핵심 철학

  1. 완벽보다 회복 속도
    개발자는 완벽한 코드를 목표로 하기보다, 에러가 발생했을 때 얼마나 빨리 복구할 수 있는지를 중심으로 사고해야 한다.

  2. DevOps의 본질
    DevOps는 단순한 자동화 기술이 아니라, 개발 주기의 가속화와 품질 보증, 협업 문화의 혁신을 동시에 이루기 위한 새로운 시대의 개발 철학이다.