[DEVOPS-001][입문] 개발과 운영을 잇는 DevOps 이해하기
페이지 정보
본문
[이번 수업]
기능을 만드는 일과 실제 서비스를 안정적으로 운영하는 일은 하나의 생명주기입니다. 이번에는 DevOps가 개발자와 운영자의 협업, 반복 작업의 자동화, 빠른 피드백을 통해 변경을 안전하게 전달하는 방식임을 배우고 자동 테스트를 첫 품질 관문으로 만들어 봅니다.
[선수지식]
PY-001의 Python 실행법과 TOOL-001의 개발환경 개념을 알면 됩니다. 별도 서버나 외부 서비스는 필요하지 않습니다.
[학습목표]
1. DevOps가 도구 하나나 직무 이름만을 뜻하지 않는 이유를 설명할 수 있습니다.
2. 코드에서 운영 피드백까지 이어지는 흐름을 설명할 수 있습니다.
3. 모든 변경에서 반복 실행할 자동 테스트를 만들 수 있습니다.
[핵심개념]
DevOps는 Development(개발)와 Operations(운영)를 연결하는 문화와 작업 방식입니다. 팀이 요구사항, 코드, 테스트, 배포, 운영 결과까지 함께 책임지고 부서 사이의 긴 대기와 전달 오류를 줄이는 것이 핵심입니다. 개발자는 운영 중 발생할 문제를 고려하고, 운영자는 배포 가능한 구조와 빠른 피드백을 개발 단계부터 함께 설계합니다.
좋은 흐름은 작은 변경을 버전 관리에 기록하고, 빌드·테스트·보안 검사·패키징을 같은 절차로 반복하며, 검증된 결과물을 배포한 뒤 로그·메트릭·사용자 피드백을 다음 변경에 반영합니다. 자동화는 사람의 판단을 없애는 것이 아니라 반복 가능한 검사를 빠르고 일관되게 수행해 사람이 중요한 판단에 집중하도록 돕습니다.
CI(지속적 통합)는 여러 변경을 자주 합치고 자동으로 검증하는 방식입니다. CD는 검증된 결과물을 배포 가능한 상태로 유지하는 지속적 전달, 또는 운영 환경까지 자동 반영하는 지속적 배포를 가리킬 수 있으므로 팀에서 뜻을 명확히 해야 합니다. NIST는 CI/CD 파이프라인을 소스 코드가 빌드·테스트·패키징·배포·운영 단계를 지나며 자동화 도구와 피드백으로 지원되는 작업 흐름으로 설명합니다.
운영 피드백에는 오류 로그, 응답 시간, 자원 사용량, 장애와 사용자 문의가 포함됩니다. 실패를 숨기지 않고 재현 가능한 정보와 함께 개발로 되돌려야 같은 문제가 반복되지 않습니다. 배포 전에는 성공 조건과 롤백 방법도 정합니다.
[따라하기]
같은 폴더에 price.py와 test_price.py를 만듭니다. 먼저 price.py입니다.
def total(price, quantity):
if price < 0 or quantity < 0:
raise ValueError("negative value")
return price * quantity
다음은 test_price.py입니다.
import unittest
from price import total
class TotalTest(unittest.TestCase):
def test_total(self):
self.assertEqual(total(3000, 2), 6000)
def test_negative_value(self):
with self.assertRaises(ValueError):
total(-1, 2)
Windows는 ‘py -m unittest -v’, macOS·Linux는 ‘python3 -m unittest -v’를 실행합니다. test_negative_value와 test_total 옆에 ok가 표시되고 마지막에 ‘Ran 2 tests’와 ‘OK’가 나오면 성공입니다. 이 명령을 모든 코드 변경에 실행하도록 자동화하면 작은 CI 품질 관문의 출발점이 됩니다.
[흔한 실수]
자동화 도구를 설치하면 DevOps가 완성된다고 생각하지 마세요. 개발과 운영 사이에 새 DevOps 팀을 벽처럼 두는 것도 전달 단계를 하나 더 만들 수 있습니다. 불안정한 수동 절차를 그대로 자동화하기 전에 단순화하고 실패 시 중단 조건을 정합니다. 배포 성공만 보지 말고 서비스 상태와 롤백 가능성까지 확인해야 합니다.
[보안 주의]
보안 검사는 마지막 배포 직전에 한 번만 하지 말고 설계와 변경 흐름에 포함합니다. 파이프라인에 비밀번호나 접근 키를 코드로 넣지 말고 전용 비밀 저장소와 최소 권한을 사용하세요. 외부 기여 코드를 높은 권한으로 실행하지 않으며 의존성·입력·산출물의 출처와 변경 이력을 확인합니다.
[직접 해볼 과제]
test_total의 기대값 6000을 잠시 5000으로 바꾸어 테스트가 실패하고 명령이 실패 상태를 반환하는지 확인하세요. 다시 복구한 뒤 수량 0의 결과가 0인지 확인하는 test_zero_quantity를 추가하고 세 테스트를 모두 통과시킵니다.
[확인문제]
1. DevOps를 단순한 자동화 도구 목록으로 보면 안 되는 이유는 무엇인가요?
2. CI에서 자동 테스트가 주는 피드백은 무엇인가요?
3. 배포 뒤 운영 정보를 다시 개발에 전달해야 하는 이유는 무엇인가요?
[다음 학습]
다음 게시 과정은 SEC-001 ‘기밀성·무결성·가용성과 위협 모델’입니다. DEVOPS 트랙의 다음 단계는 DEVOPS-002 ‘Docker 이미지와 컨테이너’입니다.
[공식 참고 자료]
CNCF 공식 용어집 — DevOps
https://glossary.cncf.io/devops/
NIST SP 800-204C — DevSecOps와 CI/CD 파이프라인
https://csrc.nist.gov/pubs/sp/800/204/c/final
NIST SP 800-218 — 안전한 소프트웨어 개발 프레임워크
https://csrc.nist.gov/pubs/sp/800/218/final
Python 공식 문서 — unittest
https://docs.python.org/3/library/unittest.html
기능을 만드는 일과 실제 서비스를 안정적으로 운영하는 일은 하나의 생명주기입니다. 이번에는 DevOps가 개발자와 운영자의 협업, 반복 작업의 자동화, 빠른 피드백을 통해 변경을 안전하게 전달하는 방식임을 배우고 자동 테스트를 첫 품질 관문으로 만들어 봅니다.
[선수지식]
PY-001의 Python 실행법과 TOOL-001의 개발환경 개념을 알면 됩니다. 별도 서버나 외부 서비스는 필요하지 않습니다.
[학습목표]
1. DevOps가 도구 하나나 직무 이름만을 뜻하지 않는 이유를 설명할 수 있습니다.
2. 코드에서 운영 피드백까지 이어지는 흐름을 설명할 수 있습니다.
3. 모든 변경에서 반복 실행할 자동 테스트를 만들 수 있습니다.
[핵심개념]
DevOps는 Development(개발)와 Operations(운영)를 연결하는 문화와 작업 방식입니다. 팀이 요구사항, 코드, 테스트, 배포, 운영 결과까지 함께 책임지고 부서 사이의 긴 대기와 전달 오류를 줄이는 것이 핵심입니다. 개발자는 운영 중 발생할 문제를 고려하고, 운영자는 배포 가능한 구조와 빠른 피드백을 개발 단계부터 함께 설계합니다.
좋은 흐름은 작은 변경을 버전 관리에 기록하고, 빌드·테스트·보안 검사·패키징을 같은 절차로 반복하며, 검증된 결과물을 배포한 뒤 로그·메트릭·사용자 피드백을 다음 변경에 반영합니다. 자동화는 사람의 판단을 없애는 것이 아니라 반복 가능한 검사를 빠르고 일관되게 수행해 사람이 중요한 판단에 집중하도록 돕습니다.
CI(지속적 통합)는 여러 변경을 자주 합치고 자동으로 검증하는 방식입니다. CD는 검증된 결과물을 배포 가능한 상태로 유지하는 지속적 전달, 또는 운영 환경까지 자동 반영하는 지속적 배포를 가리킬 수 있으므로 팀에서 뜻을 명확히 해야 합니다. NIST는 CI/CD 파이프라인을 소스 코드가 빌드·테스트·패키징·배포·운영 단계를 지나며 자동화 도구와 피드백으로 지원되는 작업 흐름으로 설명합니다.
운영 피드백에는 오류 로그, 응답 시간, 자원 사용량, 장애와 사용자 문의가 포함됩니다. 실패를 숨기지 않고 재현 가능한 정보와 함께 개발로 되돌려야 같은 문제가 반복되지 않습니다. 배포 전에는 성공 조건과 롤백 방법도 정합니다.
[따라하기]
같은 폴더에 price.py와 test_price.py를 만듭니다. 먼저 price.py입니다.
def total(price, quantity):
if price < 0 or quantity < 0:
raise ValueError("negative value")
return price * quantity
다음은 test_price.py입니다.
import unittest
from price import total
class TotalTest(unittest.TestCase):
def test_total(self):
self.assertEqual(total(3000, 2), 6000)
def test_negative_value(self):
with self.assertRaises(ValueError):
total(-1, 2)
Windows는 ‘py -m unittest -v’, macOS·Linux는 ‘python3 -m unittest -v’를 실행합니다. test_negative_value와 test_total 옆에 ok가 표시되고 마지막에 ‘Ran 2 tests’와 ‘OK’가 나오면 성공입니다. 이 명령을 모든 코드 변경에 실행하도록 자동화하면 작은 CI 품질 관문의 출발점이 됩니다.
[흔한 실수]
자동화 도구를 설치하면 DevOps가 완성된다고 생각하지 마세요. 개발과 운영 사이에 새 DevOps 팀을 벽처럼 두는 것도 전달 단계를 하나 더 만들 수 있습니다. 불안정한 수동 절차를 그대로 자동화하기 전에 단순화하고 실패 시 중단 조건을 정합니다. 배포 성공만 보지 말고 서비스 상태와 롤백 가능성까지 확인해야 합니다.
[보안 주의]
보안 검사는 마지막 배포 직전에 한 번만 하지 말고 설계와 변경 흐름에 포함합니다. 파이프라인에 비밀번호나 접근 키를 코드로 넣지 말고 전용 비밀 저장소와 최소 권한을 사용하세요. 외부 기여 코드를 높은 권한으로 실행하지 않으며 의존성·입력·산출물의 출처와 변경 이력을 확인합니다.
[직접 해볼 과제]
test_total의 기대값 6000을 잠시 5000으로 바꾸어 테스트가 실패하고 명령이 실패 상태를 반환하는지 확인하세요. 다시 복구한 뒤 수량 0의 결과가 0인지 확인하는 test_zero_quantity를 추가하고 세 테스트를 모두 통과시킵니다.
[확인문제]
1. DevOps를 단순한 자동화 도구 목록으로 보면 안 되는 이유는 무엇인가요?
2. CI에서 자동 테스트가 주는 피드백은 무엇인가요?
3. 배포 뒤 운영 정보를 다시 개발에 전달해야 하는 이유는 무엇인가요?
[다음 학습]
다음 게시 과정은 SEC-001 ‘기밀성·무결성·가용성과 위협 모델’입니다. DEVOPS 트랙의 다음 단계는 DEVOPS-002 ‘Docker 이미지와 컨테이너’입니다.
[공식 참고 자료]
CNCF 공식 용어집 — DevOps
https://glossary.cncf.io/devops/
NIST SP 800-204C — DevSecOps와 CI/CD 파이프라인
https://csrc.nist.gov/pubs/sp/800/204/c/final
NIST SP 800-218 — 안전한 소프트웨어 개발 프레임워크
https://csrc.nist.gov/pubs/sp/800/218/final
Python 공식 문서 — unittest
https://docs.python.org/3/library/unittest.html
- 이전글[SEC-001][입문] 기밀성·무결성·가용성과 위협 모델 이해하기 26.08.29
- 다음글[CLOUD-001][입문] IaaS·PaaS·SaaS와 공동 책임 이해하기 26.08.29
댓글목록
등록된 댓글이 없습니다.