One Man Framework 가능성의 증명¶

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

[Interpretive Note] 이 글은 단순히 ‘1인 개발이 가능하다’는 사례를 보여주려는 것이 아니라, 시스템을 관리·운영하는 소요를 구조적으로 줄이는 판단이 어떤 결과를 낳는지를 알리기 위해 작성되었습니다.

Executive Summary¶

본 문서는 1인 개발 및 운영·관리 소요를 구조적으로 최소화한 시스템의 실제 결과를 제시한다.
12개월간 거래 44만 건, 53억 원 규모의 상용 시스템을 1인 단독으로 안정 운영한 실제 사례를 기반으로 한다.
운영 한계는 규모가 아니라 관리 포인트의 수와 복잡성에 의해 결정된다.
반복 업무는 도구화하고 권한을 이양하여, 개발자는 예외 상황만 처리하도록 구조화한다.
장애 대응보다 중요한 것은 장애가 발생하지 않도록 만드는 설계다.
최적화는 단순 비용 절감이 아니라 변경 영향 범위를 최소화하는 구조적 단순화다.
적절한 이키텍처를 선택하라. 전자상거래의 특성을 반영 개별 화면에 최적화한 명령적 API 설계한다. (Not RESTful API)
도구 선택은 유행이 아닌 비즈니스 맥락과 실제 운영 조건을 기준으로 한다.
가능 조건은 명확하다: 연간 개발자 개입 에러 30건 미만, 총 관리 소요 24일 이내로 한다.
이는 견고함을 최우선으로 둔 아키텍처적 의사결정의 누적 결과다.

증명¶

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

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

우선 어느 규모인가?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

최적화 해라¶

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

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

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

적절한 아키텍처를 선택해라.¶

전자상거래와 물류 시스템과 같은 복잡한 비즈니스 환경에서는, 단순히 업계의 유행이나 표준이라는 이유만으로 RESTful API를 채택하는 것은 심각한 비효율과 구조적 리스크를 초래할 수 있다. RESTful 아키텍처는 본질적으로 정적 문서의 배포와 공유에 최적화된 구조로, 상태 비저장성(Stateless), 캐시 가능성(Cacheability), 인터페이스 일관성(Uniform Interface) 등 몇 가지 제약 조건을 전제로 한다. 이러한 제약은 정보의 효율적 배포에는 유리하지만, 실시간으로 상태가 변화하고 복잡한 트랜잭션이 빈번하게 발생하는 업무 시스템에는 적합하지 않다.

따라서 전자상거래, 물류, 교육/학습관리 등과 같이 상태 변화와 트랜잭션, 복잡한 규칙이 핵심인 시스템에서는, 각 화면(또는 업무 시나리오)에 최적화된 명령적(Command-based) API 설계가 훨씬 더 효과적이다. 명령적 API란, 단순히 CRUD 엔드포인트를 나열하는 것이 아니라, 실제 사용자의 행위와 비즈니스 플로우에 맞춘 명확한 명령(예: 주문 승인, 결제 처리, 재고 예약 등)을 API 단위로 제공하는 방식이다. 이를 통해 한 번의 API 호출로 여러 상태 전이와 트랜잭션을 원자적으로 처리할 수 있으며, 서버가 비즈니스 로직과 데이터 일관성, 보안의 책임을 명확히 지게 된다. 결과적으로 클라이언트는 복잡한 상태 관리나 트랜잭션 보상 로직에서 해방되고, 시스템 전체의 신뢰성과 유지보수성이 크게 향상된다.

특히, 명령적 API 설계는 다음과 같은 장점을 제공한다. 첫째, 실제 업무 플로우에 맞춘 API 설계로 인해, 클라이언트와 서버 간의 의사소통이 명확해지고, 요구사항 변경에도 유연하게 대응할 수 있다. 둘째, 트랜잭션의 원자성과 데이터 일관성을 서버에서 보장할 수 있으므로, 중간 상태 노출이나 보안 취약점이 현저히 줄어든다. 셋째, 네트워크 호출 횟수를 최소화하여 성능을 높이고, 장애 포인트를 줄일 수 있다. 넷째, 복잡한 도메인 모델과 엔터티 간의 관계를 서버에서 효과적으로 관리할 수 있어, 클라이언트의 구현 복잡성을 크게 낮출 수 있다. 마지막으로, 명령적 API는 실제 운영 환경에서 발생하는 다양한 예외 상황에 대한 대응이 용이하며, 장애 발생 시 원인 분석과 복구가 훨씬 단순해진다.

적절한 도구를 사용해라¶

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

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

흔히 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에 집중할 것.

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