One Man Framework 가능성의 증명¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
초안: 2025년 11월 / 개정: 2025년 12월

2025년 12월 현재, 이미 1년 이상 운영중이다. 증명 끝!

논리학적으로 가능성의 증명은 실제 사례 1건만 찾으면 된다. 그런고로 증명은 아주 간단하다. 그러나 이 글을 읽는 사람들이 정말 궁금해할 것은 어떤 조건에서 어느 규모를 운영할 수 있는가?일 것이다.

우선 어느 규모인가?

사전에 분명히 알려둘 것은 이것은 1인 개발자가 어느 정도 규모의 IT 시스템을 라이브 운영할 수 있는가에 대한 내용이지, 절대로 사업을 성장시키는 것에 대한 이야기는 아니다. 시스템은 이미 오랜기간 운영 중이었으며, 많은 고객을 갖추고 있었다.

나는 3년 전부터 개입하여 거의 실패한 차세대 시스템의 재구축, 완성, AWS로의 이전, 운영을 해결하였을 뿐이다. 고객 유치는 개발자의 업무가 아니다.

현재 이 시스템은 2024년 11월부터 2025년 11월까지 12개월간 합계 거래량 44만 건, 금액 53억 원을 처리했다.

Abstract¶

규모는 12개월 합계 거래량 44만 건, 금액 53억 원
연간 로그 데이터 생산 500GB
AWS 인프라 사용
AWS Aurora를 이용한 단일 디비
로드 밸런서 + 웹 서버 + 디비의 평범한 구조
Vue 2.x, Java 17 SpringBoot 3.0 JPA, 일부 고성능 처리 필요시 Node.js 사용
개발자 개입이 필요한 연간 에러 30건 미만
비즈니스상 예외적인 사례에 대한 보정 도구 제작
ISMS 2년 연속 심사 통과
매우 간단한 보안 모델
로드밸런서와 이중화된 서버 구성
Robustness 설계
최적화된 설계/개발로 웹서버 사양 다운사이징 (16GB -> 4GB)
최적화된 설계/개발로 데이터베이스 데이터 다운사이징 (80GB -> 15GB)
전방위적인 연산 최적화
버스트시 JAVA 최대 CPU 사용률 30% 미만
버스트시 JAVA 최대 RAM 사용률 75% 미만
오류 자동 감지 설정
알람 설정
간단한 CLI 도구를 자체 제작 - 반복업무 자동화
자동화된 CLI 배포 도구

핵심은 규모가 아니라, 관리 소요이다.¶

시스템의 크기보다 더 중요한 것은 관리에 드는 시간과 노력을 최소화하는 것이다. 규모가 커져도 관리 포인트가 적다면, 1인 운영이 충분히 가능하다. 견고하고, 신뢰성 있게 개발하며, 반복적 작업은 최대한 도구화 & 자동화하고, 적절히 권한을 이양하고, 개발자는 특별한 예외 상황만 신경 쓸 수 있도록 운영해야 한다.

도구를 만들고 권한을 이양해라¶

운영에 필요한 반복 업무, 데이터 보정, 모니터링 등은 직접 처리하지 말고, 누구나 사용할 수 있는 도구로 만들어라. 그리고 그 도구를 신뢰할 수 있는 동료나 운영 담당자에게 이양하면 개발자는 본연의 개발과 개선에 집중할 수 있다.

신뢰할 수 있는 운영자가 사용한다면, 도구는 다소 거칠거나 위험성이 있어도 괜찮으며, 이는 많은 예외 사항 처리나 안전 장치를 적게 가져가도 된다는 것을 의미한다. 도구는 그만큼 단순해지지만, 운영자에게 운영의 자유가 늘어나며, 보다 많은 예외 상황을 대처할 수 있다.

고장 자체를 불가능하게 만들어라¶

문제가 발생하지 않도록 설계 단계에서부터 결함을 최대한 제거해야 한다. 이런 주장은 흔히 장애가 발생할 수 있는 지점을 미리 파악하고, 자동 복구나 우회, 알람 등으로 사전에 대응하는 것으로 오해한다. 그러나, 그런 언급은 현실적 방안이 아니다.

솔직히, 대부분의 경우 자동 복구나 우회는 망상에 가깝다. 이런 방법은 기본적으로 개발비/운영비 2배를 의미하며, 복잡성에 기인한 신뢰성 문제가 함께 따라온다.

이 시스템은 쇼핑몰로 무료 배송 혜택을 받는 사람들이 있다. 내가 이 시스템을 완전히 재설계하기전, 무료 배송 혜택 여부는 기간내 주문 수량에 따라 계산되는 방식이었다. 당연히 예외 상황이 속출하고, 받아야하는데 못 받거나, 안 받아야하는데 받는일이 빈번했으며, 그것은 모두 개발자의 부담으로 돌아올 수 밖에 없다.

그래서 그러한 일의 발생이 원천적으로 불가능하도록 매커니즘을 변경하였다. 판촉 기간과 판촉 대상을 명확히 DB에 기록하고, 사용자에게는 노출되지 않는 배송 쿠폰 장부를 정확하게 DB에 기록해서, 기간 & 주문 수량을 통한 간접 계산으로 인한 오차 발생 가능성을 원천 차단하였다. 이를 통해 연간 약 30일의 관리 소요를 줄였다.

최적화 해라¶

가끔 최적화를 불필요한 연산, 과도한 리소스 사용, 중복 데이터 등을 지속적으로 삭제하는 것으로 이해하기도 한다. 그러나 최적화는 그렇게 단순한 '삭감'의 관점이 아니다.

물론 불필요한 사용량은 물론 줄인다. 그러나 필요성이 있다면, 중복도 적극 활용해야 한다.

당연하지만 주문 정보에는 '주문 상태' 컬럼이 있다. 주문 상태는 많은 것을 설명할 수 있으므로, isPaid, canDrop, isDrop, needShipping, sentShipping 등과 분명히 중복된다. 그럼에도 나는 모두 Boolean 변수를 선언하여 기록하고 관리한다. 주문 상태가 변경되는 소수의 처리 포인트를 별도의 코드 파일에 모아 엄격하게 관리함으로써, 시스템 전체의 조건부 동작이 모두 일률적으로 제어가 가능하다. 만약 주문 상태를 코드를 조회 조건으로 활용하여 그 코드에 따라 동작한다면, 약간의 변경만으로 많은 작업이 발생하게 된다. 주요 상태 변경 함수를 특별 관리함으로써, 시스템 전체에서 신호의 파급이 단순·명확해지고, 사이드 이펙트(Side Effect)의 발생 가능성을 원천 차단한다. DB 인덱스의 성능상 이점은 보너스다.

적절한 도구를 사용해라¶

모든 것을 직접 만들 필요는 없다. 이미 검증된 오픈소스, 클라우드 서비스, 자동화 도구 등을 적극적으로 활용하면 개발과 운영의 부담을 크게 줄일 수 있다. 아마존의 데이터베이스, 로그 관리, 알람, 웹서버 감시 도구들은 좋은 기능을 가지고 있다. 연동 가능한 외부 도구까지 사용하면, 비상시 전화 연락도 받을 수 있다.

그러나, 모든 것을 외부 도구로 쓰지도 마라.

흔히 JAVA를 하면, CI/CD를 해야 하고, 으레 젠킨스를 써야 할 것으로 생각한다. 그런 생각은 무비판적인 사고일 뿐더러, 도구를 썼으니 내 책임은 없다는 식의 방만함일 뿐이다. 아이러니하게, CI/CD - 지속적 통합(Continuous Integration), 지속적 배포(Continuous Delivery)를 위한 도구는 설치하면서, 통합 전략과 배포 전략을 검토하는 곳은 손에 꼽을 정도로 드물다.

도구는 그저 도구다. 어떤 도구를 설치할지 고민하기 전에, 어떤 문제가 있는지 식별하고 처리 방법의 결정을 먼저 해라. 1년에 50억 원을 결제하는 시스템이지만, 이 시스템의 배포는 주간 배포가 아니며, 나이트 빌드를 올려도 실행하고 검증해줄 상시 QA팀도 없다. 주요 패치의 배포 간격은 거의 3개월에 달한다. 이런 상황에서는 단순 작업인 배포 시 휴먼 에러를 막는 간단한 자동화된 CLI 도구면 충분하다. 나는 이것을 node.js로 간단히 작성하였다. SSH를 열고, 파일을 올리고, API요청을 하고, bash 스크립트를 수행한다. 단지 그뿐이지만, 훌륭하게 작동하며, 별도의 서버도 필요없고, 기능이나 설정을 관리할 필요성도 없다.

내가 이 프로젝트에 개입하기 이전에는 빌드 후에 로드밸런서에서 머신을 하나씩 내리고, 업로드하고, 추가 적용을 수작업으로 진행하였다. 이 간단한 Node 프로그램의 개발/사용의 연간 관리 소요는 1일에 수렴한다. 만약 젠킨스라면 연간 20일, 수작업으로 로드밸런서 조작 및 파일 업로드 등을 진행한다면 연간 10일 정도는 필요하다.

Robustness - 견고함¶

시스템이 견고하다는 것은 단순히 장애가 적다는 의미를 넘어서, 예측 불가능한 상황에서도 전체 서비스가 무너지지 않는 구조를 의미한다고 생각하는 사람이 많다. 그러나 현실에서 개발자와 설계자가 구현할 수 있는 견고함은 이와는 다르다. 예를 들어, 이 세상에 섭씨 400도에서 동작하는 컴퓨터는 없다. 그러니 어떤 예측 불가능한 상황에서도 무너지지 않는 시스템 같은것은 신기루일 뿐이다.

실제 견고함에는 크게 세 가지가 필요하다. 1. 예정된 비즈니스 흐름이 정상 동작한다. 2. 예정되지 않은 행위를 하더라도, 시스템이 중단되지 않는다. 3. 예정되지 않은 행위를 할 때, 오류의 원인(정상 흐름 중단의 원인)이 명확하게 표시된다.

5년 이상의 경험을 가진 개발자라면, 이러한 기준은 항시 개발에서 체감하고 있다. 문법 오류의 지점을 정확히 찾아내는 컴파일러/런타임은 믿고 쓸 수 있다. 반면, 전혀 엉뚱한 위치를 오류로 지정하는 도구는 많은 시간 낭비를 가져온다.

인간은 신뢰할 수 있는 도구를 쓸 때 효과적으로 작업할 수 있다. 시스템이 견고하지 않다면, 오류의 원인을 밝히는 데만 연간 수십 일을 소모해야 한다. 그러나 충분히 견고하다면, 사용자의 99.9%는 아무런 문제를 느끼지 못할 것이고, 0.1%가 겪는 문제는 비교적 단시간 내에 처리할 수 있다.

결론: 어떤 경우에 가능한가?¶

실현하기 위한 조건

단 한 문장으로 조건을 정리하자면 아래와 같다.

"개발자 개입이 필요한 연간 에러 30건 미만, 건당 평균 소요시간 1일 내외. 총 연간 관리소요 24일 이내"

하지만, 위 조건은 결과론적이며, 이를 성립하려면 기획/설계/구현/운영에서 많은 것을 준비해야 한다.

비즈니스를 정확히 파악할 것. 개발팀에 국한된 것이 아니라, 모든 부서가 자신들의 일을 명확히 알고 혼선이 없을 것. 따라서, 불필요한 개발/운영이 없을 것.
비즈니스에 맞는 아키텍처를 채택하고, 유지비(돈+시간+노력+복잡성)를 줄이도록 개발할 것.
기획/설계/구현/운영에 있어 '견고성'을 우선 가치로 할 것
이용가치에 비해 복잡한 도구를 배제할 것. 최대한의 가성비를 얻어낼 수 있는 도구를 채택할 것.
유능한 운영팀이 있을 것. 즉, 다소 위험성이 있는 도구를 주어도, 적절히 잘 사용할 수 있을 것.
잠재적 최대 가치에 휘둘리지 말 것. 당장의 RoI에 집중할 것.

SeeAlso¶

소프트웨어 아키텍처는 의사결정이지, 모방이 아니다 - 아키텍처 결정하기
소프트웨어 아키텍처는 확장보다 불변에 의해 결정된다 - 아키텍처 결정하기
제발 catch 좀 줄여라 - 견고성(Robustness)을 위한 실용적 방법...
불신의 코딩 vs 신뢰의 코딩 - 견고성(Robustness)을 얻는 방법에 대한 오해

Author¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
https://js-seth-h.github.io/website/Biography/

Over 20 years in software development, focusing on design reasoning and system structure - as foundations for long-term productivity and structural clarity.

Researched semantic web and meta-browser architecture in graduate studies,
with an emphasis on structural separation between data and presentation.

Ph.D. in Software, Korea University
M.S. in Computer Science Education, Korea University
B.S. in Computer Science Education, Korea University