사전에서 context(컨텍스트)를 찾아보면 어떤 사건이 발생했을 때의 주변 상황 정도로 설명하고 있습니다. 컴퓨터 소프트웨어에서도 컨텍스트 스위칭, 로그 컨텍스트, 애플리케이션 컨텍스트 등 컨텍스트라는 단어를 많이 사용합니다.

라라벨은 IoC를 위한 Service Container¹가 있으며, 여기에 어떤 데이터 타입이든 바인딩할 수 있고, 애플리케이션 실행 중에 아래처럼 꺼내 쓸 수 있습니다.

$container = app();
$container->bind('foo', function () {
	return 'bar';
});
$container->make('foo'); // 'bar'

그런데, 아래와 같은 문제가 있죠². 작은 애플리케이션에서는 이렇게 쓴다고 전혀 문제없지만, 애플리케이션이 커지면 결국 개발자에게 큰 부담으로 다가옵니다.

이번 포스트에서는 라라벨 애플리케이션에서 애플리케이션 실행 시점의 주변 상황을 담아 놓고 필요할 때 꺼내 쓰기 위한 데이터 컨테이너를 구현했던 썰을 풀어보려합니다. ApplicationContext라 이름 지었고 Java 언어의 ThreadLocal³과 비슷한 역할을 한다고 보면 됩니다. 주로 아래와 같은 상황에 유용하게 사용되기를 바라며 만들었어요.

• 프레임워크 영역(=main)의 데이터를 코어 영역(=app)으로 전달할 때
• 로깅 및 감사
• 프로세스간 컨텍스트 릴레이 등등 (e.g. Api -> Queue, App -> External, …)

이 슬라이드는 Modern PHP User Group 2018년 7월 정기 모임 발표 자료입니다.

중학교 때 배운 후, 잊어 버리고, 매번 필요할 때마다 찾아 보는 것이 진법(進法)이다. 요즘은 교과 과정이 없어졌다고 하지만, 자녀들이 물어볼 때를 대비해 기록해 놓는다. 또, 개발자로서 이진법을 잘 이해하지 못하고 있는 나 자신이 부끄럽기도해서 필요할 때마다 꺼내볼 수 있도록 치트시트를 만들어 두는 거다.

이 포스트를 쓰기 위한 예제를 진행하면서 스웨거가 해결하고자 했던 문제점을 좀 더 깊이 있게 생각해보는 계기가 되었습니다. 이 시리즈에서는 다음 내용을 다루려고 합니다.

1. 스웨거란 무엇이며, 왜, 언제 쓰는가?
2. PHP 기반 API 서버 프로젝트에 스웨거를 어떻게 적용해야 하는가?

네이버 국어사전에 따르면 찍새와 딱새를 이렇게 정의하고 있습니다.

• 찍새 닦을 구두를 모아서 구두닦이에게 가져다주는 일만 하는 사람을 속되게 이르는 말.
• 딱새 은어로, ‘구두닦이’를 이르는 말.

예~ 구두닦이 서비스를 말하는 겁니다. 주제와 전혀 다른 구두닦이 서비스를 언급한 이유는, 제가 속한 회사의 서비스가 이런 식으로 역할 분담이 되어 있기 때문입니다. 상점으로부터 배송 대행 요청을 접수 받는 서비스와(이하 프라임), 기사님들에게 배송 대행 업무를 나누어 주고, 배정 받은 기사님이 물건을 보내고자하는 상점으로 가서 물건을 픽업하고 목적지까지 배송하고 상품가액과 수수료를 결재 받는 서비스(이하 부릉)로 구성되어 있습니다. 아무리 구두닦이 장인들이 모여 있더라도 구두를 찍어 오지 못하면 서비스는 쪼그라들겁니다. 반면에, 영업의 신들이 구두를 아무리 잘 찍어와도 구두를 깨끗이 닦지 못하면 손님은 다시 찾아오지 않을 겁니다. 결국 둘 간에 강한 결합이 존재하며, 서로 선순환을 일으켜야 한다는 사실을 알 수 있습니다.

참고로 프라임 서비스는 라라벨 서버, 닷넷 및 Android 클라이언트로 구성되어 있습니다. 부릉 서비스는 스프링 서버, 닷넷 및 Android 클라이언트로 구성되어 있습니다. 두 서비스를 전부 관리하는 관리도구는 자바스크립트 SPA _{SINGLE PAGE APPLICATION}로 구성되어 있습니다.

이 포스트와 관련해서 중요한 사실은 프라임도 부릉에게는 일개 클라이언트라는 점입니다. 부릉은 멀티 클라이언트 플랫폼에 대응하기 위해 스웨거 API 스펙을 관리하고 있고, 프라임은 부릉이 노출하고 있는 API를 사용하기 위해서 스웨거 스펙으로 자동 생성한 PHP 클라이언트 라이브러리를 컴포저로 땡겨서 vendor에 꽂아서 사용합니다. 저는 프라임 서버 개발자입니다. 지난 일년간을 스웨거 스펙의 소비자이기만 하다가, 최근에 갑자기 ‘PHP로 짠 서버 프로젝트가 스웨거 API의 생산자가 될 수 있을까?’라는 생각이 들기 시작했습니다.

MVP_{Minimum Viable Product}로 개발한 서비스는 시장성 및 사업성이 검증되면 버리고 다시 짜야 합니다. MVP는 “더럽지만, 신속하게, 작동하는 서비스를 확보한다”는게 가치이기 때문입니다. 사업 모델이 검증되면, 투자를 받고 사람을 뽑아서 오랫동안 유지할 코드 베이스, 성장을 이끌어 낼 수 있는 코드 베이스를 확보해야 합니다. 대부분의 스타트업들이 이 타이밍을 놓치고 있고, 제가 속한 회사도 예외는 아닙니다.

본문의 예제를 보기전에 예제 코드가 쓰이는 사업 이해를 위해 간단히 설명을 드립니다.

(회사의 공식 입장이 아닌, 직원으로서 나름의 생각입니다) 우리 회사는 현재 “이륜차 네트워크를 이용한 근거리 배송 대행 서비스”를 업으로 하고 있으며, 사업 모델(= 서비스 모델 + 비즈니스 모델)은 다음과 같습니다.

서비스 모델

• 출발지 A 지점에서 도착지 B 지점으로 소형 화물을 이동시킨다.
• A ~ B간의 거리는 일반적으로 3Km 이내이며,
• 이동 수단으로 이륜차를 이용하고,
• 서비스를 위해 IT 기술을 이용한다.
• 화물 운송은 대체로 40분 이내에 끝난다.

비즈니스 모델

• 화물 운송 니즈가 있는 S 화주에게 배송 대행 수수료를 받아, 실제로 물건을 이동시키는 K 기사에게 비용을 지불하고 마진을 챙긴다.
• 배송 건수에 따라 S 화주로 부터 월 단위 시스템 사용료도 받는다.

본문에 사용한 예제는 화주 S로 부터 배송 대행 요청을 받아, K 기사 네트워크를 보유하고 배송을 수행하는 시스템에 위임하는 코드입니다. 공개를 위해 이름을 약간 바꾸긴 했지만, 실제 상용 서비스에 사용하는 코드입니다. 하나의 배송 대행 요청에 대해 웹/앱 인스턴스에서 큐 메시지로 전송하기 위해 한 번, 큐 워커 인스턴스에서 메시지를 핸들링 하기 위해 한번, 총 두 번 사용됩니다(= 비동기 처리). 현재 우리 회사의 사업 규모로 볼 때 컴퓨터(서버)가 이 코드를 하루에 10만번 정도 읽고 실행합니다.

여기서 질문!

그렇다면 개발자는 이 코드를 몇 번이나 읽을까요? 성공적인 서비스에서 유지보수가 되어야 하는 코드는 개발자와 개발자를 거치면서 만 번 정도 읽힌다고 합니다. 컴퓨터가 이해할 수 있는 코드는 작동하기만 한다면 아무렇게나 짜도 됩니다. 그런데, 사람이 읽어야 하는 코드는, 그것도 서비스 유지보수를 위해 수 천번 이상을 읽어야 하는 코드는 어떻게 짜야 할까요?

클린코드(엉클밥), 리팩토링(마틴파울러)의 책을 완벽히 이해하지도 못했고, 이해했다고 해도 모든 내용을 실천하지는 못합니다. 지금 MVP를 짜고 있나요? 그렇지 않다면, 몇 달 뒤의 자기 자신과 이 코드를 읽게 될 동료/후배 개발자들을 위해 좀 더 깔끔한 코드를 짜면 좋겠습니다. 디자인 원칙과 모범 사례를 지킨 코드는 버그와 사이드 이펙트를 현저히 줄여주고, 생산성을 월등히 끌어올려줍니다.

이 글을 읽는 분 중에 Before 코드를 쓰신 선배님이 있을 수 있습니다. 비록 유지보수가 편리한 코드로 바꾸는 타이밍을 놓치긴했지만(이건 경영진과 매니저의 잘못), MVP를 만들어 주셔서 제가 월급을 받으며 일할 수 있기에 존경과 감사의 마음을 글로나마 전달합니다. 해서 Before 코드에 대한 설명은 달지 않겠습니다.

이제 예제를 볼까요?