소프트웨어 구축 스택·클라우드·개발보안 정책

핵심 요약

소프트웨어 구축에서는 운영체제·미들웨어·프레임워크·애플리케이션의 역할을 나누고, 필요한 실행 환경과 서비스 제공 방식을 선택한다. 클라우드는 단순한 원격 서버 임대가 아니라 필요한 자원을 유연하게 제공·관리하는 방식이다. 외부 서비스를 이용해도 이용자의 계정·데이터·접근권한 책임이 사라지지는 않는다.

1. 소프트웨어 구성 요소

같은 제품이 여러 역할을 함께 제공할 수 있다. 제품명만 보고 역할을 단정하기보다 문제에서 어떤 기능을 설명하는지 확인한다.

웹 서버와 WAS

웹 서버는 HTTP 요청을 받아 정적 파일 제공, 다른 서버로 요청 전달 등의 일을 수행한다. WAS(Web Application Server)는 업무 로직을 실행하여 동적인 서비스를 제공한다. 둘을 구분하는 기본 단서는 정적 자원의 전달과 업무 애플리케이션 실행이다.

리버스 프록시는 서버 앞에서 요청을 받아 뒤의 서버로 전달하고, 로드 밸런서는 요청을 여러 서버로 나누어 부하를 분산한다. 역할이 겹칠 수 있으나 이름이 같은 뜻은 아니다. DBMS는 데이터 저장·검색·무결성·동시성 등 데이터 관리 기능을 제공한다.

2. 대표 미들웨어

RPC는 지역 함수 호출처럼 사용할 수 있어도 네트워크 지연·통신 실패가 존재한다. MOM은 생산자와 소비자의 처리 시점을 분리할 수 있지만 메시지 순서·중복·실패 처리를 저절로 모두 해결하는 것은 아니다.

EAI는 기업 내부 애플리케이션의 연계를 지원하는 접근이고, ESB는 공통 버스 구조로 메시지 전달·변환·라우팅 등을 지원한다. 특정한 데이터베이스 테이블이나 네트워크 장비의 이름과 혼동하지 않는다.

3. 개발·배포의 기본 흐름

소스 작성 → 빌드 → 시험 → 배포 → 운영을 구분한다. 빌드는 소스와 관련 자원을 실행·배포 가능한 산출물로 만드는 과정이고, 배포는 그 결과를 대상 환경에 설치·반영하는 과정이다.

CI(지속적 통합)는 변경을 자주 통합하고 자동 빌드·시험으로 문제를 조기에 발견하는 실천이다. 지속적 제공(Continuous Delivery)은 언제든 배포할 수 있는 상태를 유지하는 것이며 운영 배포에 승인 절차가 남을 수 있다. 지속적 배포(Continuous Deployment)는 정해진 검증을 통과한 변경을 운영까지 자동 반영하는 방식이다.

DevOps는 개발과 운영의 협업·자동화·피드백을 강화하는 접근이다. 보안을 함께 통합하는 DevSecOps도 특정 도구 하나나 ‘보안 담당자 없이 운영하는 방식’의 이름이 아니다.

개발 프레임워크는 목적과 언어를 함께 구분한다. 예를 들어 Scrapy는 Python 기반의 웹 크롤링·데이터 추출 프레임워크다. Spring 같은 응용 개발 프레임워크와 사용 목적을 구별하되 설치 명령이나 세부 API까지 혼동하여 외울 필요는 없다.

4. 클라우드의 다섯 특성

확장성은 증가한 부하를 감당하도록 용량을 늘릴 수 있는 성질이고, 탄력성은 변하는 수요에 맞춰 자원을 늘리거나 줄이는 성질이다. 측정 서비스는 모든 클라우드가 반드시 같은 과금 체계를 사용한다는 뜻은 아니다.

가상화는 자원을 논리적으로 나누고 추상화하는 기술이며 클라우드의 기반이 될 수 있다. 그러나 가상머신 한 대가 존재한다는 사실만으로 클라우드 서비스가 완성되는 것은 아니다.

5. 서비스 모델

예를 들어 가상 서버를 받아 운영체제와 프로그램을 설치하면 IaaS, 코드 배포에 집중할 수 있는 실행 플랫폼을 받으면 PaaS, 완성된 온라인 업무 프로그램을 사용하면 SaaS에 가깝다.

서비스가 상위로 갈수록 제공자가 관리하는 범위가 커지지만, SaaS이므로 잘못 공개한 문서나 탈취된 사용자 계정은 이용자 책임과 무관하다는 해석은 틀리다. 세부 책임은 서비스 계약과 구성에 따라 확인해야 한다.

좌우로 이동해 그림을 확인하세요.그림 크게 보기

6. 배치 모델과 관련 기술

서비스 모델은 무엇을 제공하는가, 배치 모델은 누가 사용하며 어떻게 배치하는가의 분류다. 퍼블릭 IaaS, 프라이빗 PaaS처럼 함께 표현할 수 있다. 퍼블릭 클라우드에서 ‘퍼블릭’은 모든 고객 데이터가 공개된다는 뜻이 아니다.

서버리스는 개발자가 서버 인프라 관리 부담을 덜고 기능·서비스 사용에 집중하는 방식이다. 실제 서버가 존재하지 않는다는 뜻은 아니다. 엣지 컴퓨팅은 데이터 발생 지점 가까이에서 처리하여 지연과 네트워크 부담을 줄이려는 접근이다. 중앙 클라우드와 병행할 수 있다.

7. 개발보안 정책

개발보안 정책은 보호할 정보와 책임, 허용·금지 행위, 개발 과정에서 지킬 보안 원칙을 정한다. 표준은 구체적인 공통 기준, 절차는 실행 순서, 지침은 적용을 돕는 안내로 구분할 수 있다.

주요 내용은 보안 요구사항의 반영, 최소 권한, 안전한 코딩, 의존 구성요소의 취약점 확인, 시험과 검토, 운영 환경의 안전한 설정, 문제 발생 시 보고·조치다. 소스와 설정에 비밀번호·비밀키를 하드코딩하거나 공용 저장소에 공개하지 않도록 한다.

외부 라이브러리나 클라우드 서비스를 도입해도 출처·지원 상태·보안 설정을 확인해야 한다. 자동화가 있다는 사실은 검토 책임이 없어졌다는 의미가 아니다.

미들웨어의 처리 보장과 클라우드의 성질

RPC 호출에서 시간 초과가 발생했다면 요청이 서버에 도착하지 않았을 수도 있고, 처리가 끝났지만 응답이 유실되었을 수도 있다. '시간 초과=업무 미실행'으로 단정해 중복 청구 등을 발생시키지 않도록 요청 식별·상태 조회·멱등성 등을 설계한다. MOM에서 적어도 한 번 전달(At-least-once)은 중복 전달 가능성을 포함하므로 소비자는 같은 메시지 재처리의 영향을 통제해야 한다. 정확히 한 번의 업무 효과와 네트워크 메시지 전달 횟수는 같은 개념이 아니다.

ESB는 서로 다른 서비스의 메시지 라우팅·변환·연계를 공통 기반에서 지원한다. TP Monitor는 트랜잭션 처리, ORB는 분산 객체의 요청 중개에 초점이 있다. Reverse Proxy는 클라이언트가 원본 서버 대신 접속하는 서버 측 중계이며, 클라이언트 측의 대외 접근을 중계하는 Forward Proxy와 역할 방향이 다르다.

커뮤니티 클라우드는 공통 목적이나 보안·정책 요구를 가진 특정 공동체가 사용한다. 하이브리드 클라우드는 구분되는 둘 이상의 클라우드 인프라가 연결된 구성이며, 서버 한 대에 가상 머신을 여러 개 만든다는 뜻이 아니다. 제공 모델 IaaS·PaaS·SaaS와 배포 모델 Public·Private·Community·Hybrid는 서로 다른 분류 축이다.

서버리스도 물리 서버가 없어지는 것이 아니다. 제공자가 실행 기반 운영의 많은 부분을 담당하지만, 사용자가 작성한 코드·데이터·권한·설정의 책임이 자동 소멸하지 않는다. 서비스 모델을 판단할 때는 제품명보다 누가 어떤 계층을 운영·관리하는지 확인한다.