서버 요청 처리·프레임워크·공통 모듈·단위 테스트

서버 프로그램은 요청을 해석하고 업무 규칙을 수행한 뒤 응답한다. 프레임워크와 라이브러리의 호출 주도권, API의 계약, 공통 모듈의 책임, 기본적인 취약성 식별과 테스트의 차이를 구분한다.

그림으로 확인하기

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

서버 요청 처리 흐름과 계층별 책임

서버 프로그램의 구체적인 구조는 기술과 프레임워크에 따라 달라지지만, 대표적인 요청 흐름은 다음과 같이 정리할 수 있다.

클라이언트 요청 → 웹 서버·WAS → 공통 전처리 → 라우팅 → 컨트롤러 → 서비스 → DAO·리포지터리 → 결과 변환 → 응답

• 웹 서버(Web Server)는 HTTP 요청을 받고 정적 자원을 제공하거나 동적 처리가 필요한 요청을 애플리케이션 실행 환경으로 전달할 수 있다.
• 웹 애플리케이션 서버(WAS)는 서버 측 애플리케이션을 실행하고 동적 요청을 처리한다.
• 실제 제품에서는 두 역할이 한 제품이나 프로세스 안에 함께 구현될 수 있으므로, 제품명보다 역할을 기준으로 구분한다.

형식 검증과 업무 규칙 검증도 구분해야 한다. 필수값 누락, 숫자 형식 오류처럼 요청 자체를 해석하기 위한 검증은 주로 입력 경계에서 수행한다. 주문 가능한 수량, 계정 권한, 중복 신청 금지처럼 업무 의미에 관한 검증은 서비스나 도메인 규칙에서 수행하는 것이 적절하다.

유스케이스 단위의 트랜잭션 경계는 보통 서비스 계층에 두지만, 이는 모든 시스템에 강제되는 고정 규칙은 아니다. 중요한 점은 여러 저장 작업이 하나의 업무 단위로 성공하거나 실패해야 하는 범위를 명확히 정하는 것이다.

계층과 물리적 서버는 다르다

컨트롤러·서비스·데이터 접근 계층은 책임을 나눈 논리적 구조이다. 세 계층이 하나의 프로세스에서 실행될 수도 있고, 여러 서버나 서비스에 분산될 수도 있다. 따라서 “계층형 구조를 적용하면 각 계층을 반드시 별도 서버에 배치해야 한다”는 설명은 틀리다.

예를 들어 상품 조회 요청을 처리할 때 컨트롤러가 요청 파라미터를 해석하고, 서비스가 조회 조건과 권한을 판단하며, 리포지터리가 DB 조회를 수행한다. 컨트롤러가 업무 규칙과 SQL까지 모두 담당하면 전송 형식 변경과 데이터 저장 방식 변경이 한 모듈에 함께 영향을 주어 유지보수가 어려워진다.

프레임워크·제어의 역전·의존성 주입

프레임워크와 라이브러리

프레임워크는 반복되는 기반 구조를 제공한다. 대표적인 특성은 다음과 같다.

• 모듈화: 기능을 역할별 구성 요소로 나누어 사용할 수 있다.
• 재사용성: 요청 처리, 데이터 변환, 예외 처리와 같은 공통 기반을 반복 구현하지 않아도 된다.
• 확장성: 정해진 인터페이스나 확장 지점에 사용자 코드를 연결할 수 있다.
• 제어의 역전: 애플리케이션이 전체 흐름을 직접 조립하기보다 프레임워크가 객체 생명주기와 호출 순서를 관리한다.

프레임워크가 전체 흐름을 제어한다고 해서 업무 규칙까지 자동으로 설계해 주는 것은 아니다. 개발자는 프레임워크의 확장 규칙에 맞춰 업무 코드를 작성해야 한다.

IoC와 DI의 포함 관계

제어의 역전(Inversion of Control)은 객체 생성, 호출 순서, 생명주기와 같은 제어권을 외부로 넘기는 넓은 원리이다. 의존성 주입(Dependency Injection)은 객체가 사용할 협력자를 직접 생성하거나 검색하지 않고 생성자, 메서드, 설정 속성 등을 통해 외부에서 받게 하는 구체적인 방식이다.

의존성 주입(DI) ⊂ 제어의 역전(IoC)

예를 들어 서비스 객체가 특정 DB 리포지터리를 내부에서 직접 생성하면 두 구현이 강하게 묶인다. 서비스가 리포지터리 인터페이스를 생성자로 전달받도록 만들면 운영에서는 실제 DB 구현을, 단위 테스트에서는 테스트 대역을 연결할 수 있다.

다만 DI를 사용했다는 사실만으로 결합도가 자동으로 낮아지는 것은 아니다. 구체 구현의 세부 기능에 계속 의존하거나 지나치게 많은 협력자를 주입받으면 구조가 복잡해질 수 있다.

API와 인터페이스 계약

API(Application Programming Interface)는 다른 프로그램이나 모듈이 기능을 사용할 수 있도록 제공하는 인터페이스이다. 함수 이름·매개변수·반환형으로 구성될 수도 있고, 웹에서는 요청 주소·HTTP 메서드·입력 및 응답 형식으로 정의될 수도 있다. API는 웹 API만을 뜻하지 않는다.

예를 들어 getPrice(productId)가 상품 번호를 받아 가격을 반환한다면, 호출자는 사용 방법을 알아야 하지만 내부 DB 조회 구현까지 알 필요는 없다. 인터페이스는 사용 규칙이고 구현은 그 기능을 실제로 수행하는 코드이다.

API 명세에는 기능, 입력의 자료형·필수 여부·범위, 정상 출력, 실패 시 응답을 명확히 적는다. 문서상 정수만 받는 API가 실제로 임의 문자열도 허용한다면 입력 계약과 구현이 일치하지 않는 것이다.

보안 취약성 식별의 기본

인증은 누구인지 확인하는 것이고 인가는 어떤 행위를 허용할지 결정하는 것이다. 클라이언트 화면에서 버튼을 숨기는 것만으로 서버의 권한 검사를 대체할 수 없다. 사용자의 입력이 자료형에 맞더라도 업무상 허용된 범위를 벗어날 수 있으므로 형식 검증과 업무 규칙 검증을 함께 고려한다.

공통 모듈과 테스트의 기본 연결

공통 모듈은 여러 기능에서 사용하는 공통 처리의 단위이다. 중복되는 코드라는 이유만으로 서로 다른 책임을 하나로 합치지 않는다. 높은 응집도는 내부 요소가 하나의 목적에 밀접하게 관련됨을 뜻하며, 낮은 결합도는 다른 모듈의 내부 구현에 불필요하게 의존하지 않음을 뜻한다.

단위 테스트는 함수·메서드·모듈 등 작은 단위를 확인하고, 통합 테스트는 구성 요소 사이의 실제 연결과 데이터 전달을 확인한다. 테스트는 입력과 기대 결과를 정한 뒤 실제 결과와 비교해야 한다. “오류 없이 실행되었다”와 “요구한 결과가 나왔다”는 같은 판단이 아니다.

상품 수량 검증 함수에 대해 정상 수량, 허용 최소·최대 경계, 범위 밖 수량을 확인할 수 있다. 테스트할 대상과 외부 DB 같은 의존 대상을 분리하면 작은 단위의 실패 원인을 더 명확히 확인할 수 있다.

인터페이스 계약으로 책임 구분하기

API는 웹 요청에만 한정되지 않는다. 라이브러리 함수, 객체의 공개 메서드, 운영체제의 시스템 호출도 사용자가 어떤 입력을 전달하고 어떤 결과를 받는지 정한 인터페이스가 될 수 있다.

계약에는 입력 자료형·필수 여부·허용 범위·단위, 성공 결과, 실패 시 오류 표현을 포함한다. 선택 입력에는 생략 시의 의미가 필요하다. 예를 들어 같은 정수 60이라도 초와 밀리초는 다른 값이므로 이름만 맞추어 전달해서는 안 된다. 자료형이 맞더라도 업무 규칙을 만족하지 않을 수 있다.

모듈의 내부 표현을 외부 호출 계약과 분리하면, 외부 계약을 유지하는 내부 변경이 호출자로 전파되는 범위를 줄일 수 있다. 이것이 변경 후 검증을 생략해도 된다는 뜻은 아니다.

컨트롤러는 요청을 받아 적절한 서비스에 전달하고 결과를 응답 형식으로 바꾼다. 서비스는 업무 규칙을 수행하고, DAO·리포지터리는 저장·조회 기술의 세부를 감싼다. 경로나 HTTP 메서드에 따라 처리기를 고르는 라우팅과, 업무 데이터를 검사하는 처리는 별개이다. 공통 전처리를 한곳에 모아도 각 업무의 권한 검사를 생략할 근거는 되지 않는다.

인증은 요청 주체를 확인하는 과정이고 인가는 그 주체가 해당 자원·작업을 사용할 권한이 있는지 확인하는 과정이다. 클라이언트 화면의 검사나 버튼 숨김만으로 서버의 검증·인가를 대신하지 않는다. DI로 객체를 외부에서 주입해도 구체 구현을 강하게 요구하는 인터페이스까지 저절로 좋은 설계로 바뀌는 것은 아니다.