함대구성법

제1조 (제정 배경)

2026-09-12 linux2 재설치·HBA 고장·SSD 역할 재배치 등으로 약 5시간의 순수 삽질(대표 표현)이 발생했다. 이 경험을 계기로, 앞으로는 "기기를 새로 놓거나 재설치할 때, 매번 수작업으로 반복하는 것" 자체를 없애는 방향으로 함대 구성 방식을 법제화한다. 목표는 명확하다 — 선을 꽂고 전원을 켜는 순간 이미 다 되어 있는 상태(대표: "후속 노가다 전혀 없이 plug in 하고 스위치 온 하자마자 다 되어 있게").

제2조 (역할별 표준 소프트웨어 구성)

기기의 역할형(03_함대동기화법.law.md 제5조)에 따라 아래 표준 구성을 따른다. 신규 역할형이 추가될 때마다 이 표를 갱신한다.

2026-09-12 실측: linux2에 위 연산형 구성 전체를 실제로 설치·검증 완료(Claude Desktop 1.52386.3, ChatGPT 26.908.40834, VS Code 1.137.0, Chrome 153.0.8010.36, Telegram 7.2.8). 설치 출처는 전부 공식 저장소(downloads.claude.ai, persistent.oaistatic.com, packages.microsoft.com, dl.google.com, Telegram 공식 snap) — 비공식 래퍼(nativefier 등) 불필요함이 확인됨.

제3조 (lin2 등 소형 기기로의 확대)

대표 지시(2026-09-12): "lin2에도 linux2와 같은 원격 화면 시스템이 설치되면 좋지 않은지" — 맞다. 소형 수집형 기기도 연산형과 동일한 원격 데스크톱·앱 구성을 갖추는 방향으로 확대한다. lin2는 이미 상당 부분 구축되어 있어(제2조 실측 근거 자체가 lin2 확인에서 나옴), linux2가 오히려 lin2를 따라간 사례다 — 먼저 구축된 기기의 구성을 다른 기기의 기준으로 역이용하는 것이 원칙(신규 기기는 매번 새로 설계하지 말고, 이미 검증된 기기의 저장소·설정을 그대로 복제).

제4조 (설치 자동화 — SSH 키·소프트웨어 사전 내장)

① SSH 키 사전 내장: Ubuntu Server(Subiquity) 설치 시 autoinstall 설정(cloud-init 기반)으로 GitHub 사용자명만 지정하면 ssh_import_id 기능을 통해 설치 완료와 동시에 SSH 키가 이미 등록된 상태로 부팅되게 할 수 있다. 13_하드웨어운용법.law.md 제13조(GitHub .keys 배포)의 자연스러운 확장 — 수동으로 curl ... >> authorized_keys를 칠 필요조차 없어진다.

② 소프트웨어 자동 설치: 위 autoinstall 설정의 late-commands 단계에 제2조의 역할별 표준 구성 설치 스크립트를 넣으면, 설치가 끝나고 재부팅되는 시점에 이미 Chrome·Telegram·Claude Desktop·ChatGPT·VS Code·원격 데스크톱까지 전부 설치된 상태로 나온다.

③ 목표 워크플로: 새 드라이브 준비 → autoinstall 설정 파일을 얹은 설치 USB로 부팅 → 설치 완료·재부팅 → 그 자리에서 바로 SSH 키 접속, 원격 데스크톱 접속, 필요한 앱 전부 사용 가능. 수동 개입 지점을 0에 가깝게 줄이는 것이 목표.

④ 이 표준 autoinstall 템플릿은 _infra/autoinstall_template.yaml(가칭)로 별도 관리하며, 역할형별 변형(제2조 표)을 이 템플릿의 옵션으로 반영한다. 실제 템플릿 작성은 별도 작업으로 진행(이 조항은 방향성 확정, 구현은 후속).

제5조 (Solfit 상품화 아이디어와의 구분)

체크박스로 원하는 도구를 선택하면 그 구성대로 골든이미지가 만들어지는 방식은 Solfit의 상품 아이디어이지 이 함대구성법의 내부 표준과는 별개다 — 내부 함대는 역할형별로 이미 정해진 표준 구성을 따르고, Solfit 고객용 커스터마이징 옵션은 _wiki/_makefund/_Solfit/business_ideas.md 쪽에 별도 기록한다. 혼동하지 않도록 이 조항으로 명시해 구분한다.

제6조 (네트워크 토폴로지와 SSH 키의 관계)

기본 배선 원칙: 공유기(라우터) 아래에 스위치를 하나 두고, 함대의 각 기기를 전부 그 스위치에 물려서 서로 통신하게 한다(2026-09-12 논의— 기기 수가 3대를 넘어가면 직결 배선은 비현실적이고 스위치가 사실상 필수라는 결론 참고).

SSH 키가 필요한 이유: 이렇게 묶인 함대 안에서 기기끼리(또는 대표가 맥북에서) 비밀번호 없이 편리하게 접속하려면 SSH 키 인증이 표준이다.

SSH 키의 실전 문제와 해법: 다만 SSH 공개키 문자열 자체가 매우 길어서, 새 기기를 처음 셋업할 때(특히 물리 콘솔·KVM처럼 클립보드 공유가 안 되는 환경) 손으로 타이핑하는 건 "거의 지옥"(대표 표현)이다. 이 문제의 해법이 바로 GitHub에 SSH 키를 미리 등록해두고, curl https://github.com/<사용자명>.keys >> ~/.ssh/authorized_keys 한 줄만 치는 것 — 13_하드웨어운용법.law.md 제13조에 이미 표준으로 확정되어 있다. 이 조항은 그 표준이 "왜 필요한가"의 배경(네트워크 토폴로지 문맥)을 보강하는 역할이다.

실전 활용: 이렇게 SSH 키로 비밀번호 없이 접속 가능해진 이후에는, ssh [email protected]처럼 IP 하나만으로 각 기기의 터미널을 그 자리에서 바로 불러와 거점 본부(작업 콘솔)로 삼아 업무를 수행할 수 있다 — 매번 물리 콘솔에 가거나 비밀번호를 입력할 필요 없이, 맥북 한 대에서 함대 전체를 원격으로 지휘하는 구조가 완성된다.

제7조 (OS 최신본 상시 수집·자동 갱신)

함대 내부 수집기 하나를 지정해, Linux(Ubuntu Server/Desktop 등)· Windows·macOS(맥미니/맥북 관련 설치 매체)의 공식 최신 설치 이미지를 상시 보관하고, 새 버전이 나오면 자동으로 갱신하는 체계를 구축한다. 목적: 재설치가 필요할 때마다 "지금 최신 버전이 뭐지"부터 확인하는 낭비를 없애고, 설치 매체가 항상 최신 상태로 준비되어 있게 함. 실제 구현(수집기 지정, 다운로드·검증·교체 스크립트)은 별도 작업으로 진행(이 조항은 방향성 확정).

제8조 (IP 부여·고정·네이밍·하드웨어 등록 — 기존 확립 규칙 통합 참조)

새 기기를 함대에 편입할 때 매번 규칙을 새로 만들지 않도록, 이미 확립된 아래 규칙들을 한곳에 모아 참조한다. 이 조항은 새 규칙을 만드는 게 아니라, 여러 문서에 흩어진 기존 규칙을 함대구성법 관점에서 다시 연결한 것이다.

① 고정 IP 부여 방법: 서브넷 172.30.1.0/24 안에서 기기별로 번호대를 정해 고정 배정한다(DHCP 임대가 아니라 각 기기의 netplan/ 네트워크 설정에 직접 고정). 현재 배정 현황(예): .50=lin1, .52=lin2, .100=m1(맥미니), .150=linux1, .151=linux2 IPMI, .152=linux2 OS, .170=win1, .254=공유기 게이트웨이. 신규 기기는 미사용 번호대 확인 후 배정하고 _infra/storage_map.tsv· _gw/_machines/*.md에 즉시 기록한다.

② 기계 네이밍 방법: 함대 약어는 13_하드웨어운용법.law.md 제7조②(OS·규모 기준 축약, 예: l1=linux1, l2=linux2, w1=win1, d1=del1, m1=맥미니) — 대형 서버는 linux*, 소형 수집기는 lin*으로 구분(project_lin_fleet_expansion 메모리 참고).

③ 하드웨어(디스크 등) 네이밍 방법: {제조사약어}{용량}{일련번호} (예: hy1t1=hynix 1TB 1번, to16t3=Toshiba 16TB 3번, se16t1=Seagate 16TB 1번) — _infra/DISK_LEDGER.md·_knowhow/_cowork/HARDWARE_NAMING.md 가 단일 출처. 슬롯명(마운트 위치 손잡이)은 {기계}{종류}{번호} (예: l1h1=linux1의 HDD 1번, l2boot=linux2의 SSD/정거장 2번) 방식으로 디스크 고유명과 별도로 관리한다(하나의 물리 디스크가 기계를 옮기면 슬롯명은 바뀌어도 고유명은 유지됨 — 오늘 to16t3가 l1h12→l2h11→ l2h1로 슬롯명은 여러 번 바뀌었지만 고유명 to16t3는 끝까지 유지된 것이 실례).

④ 하드웨어 등록 절차: 신규 편입 시 반드시 _infra/DISK_LEDGER.md에 모델·시리얼·용량·SMART 상태·편입일을 기록하고, 해당 기계의 _gw/_machines/*.md 저장장치 표에도 슬롯명으로 반영한다. 두 문서 중 하나만 갱신하고 끝내지 않는다(오늘 세션 중 l2h2가 미등록 상태로 방치되어 있다가 뒤늦게 발견된 사례가 이 절차 누락의 예).

제9조 (잉여 하드웨어 사전예약 마켓플레이스 봇 — 아이디어 등록)

아이디어 단계, 미구현. 대표 제안(2026-09-12): 함대 재배치 과정에서 어떤 하드웨어가 "언제쯤 여유분으로 빠질 예정"인지 미리 등록해두면, 자동화 봇이 이 정보를 수집해 마켓플레이스(당근마켓 등)에 사전 공지하고 예약자 명단(대기자 리스트)을 미리 받아두는 시스템.

• 동기: 14_하드웨어경제성법.law.md 제8조(유휴자원 재배치 우선 원칙)와 연결 — 재배치하고 남는 진짜 잉여분(예: del1의 기존 1TB가 m1으로 이전되면서 del1 쪽엔 남는 게 없지만, 반대로 향후 CPU 교체 등으로 빠지는 구형 부품들은 진짜 잉여가 됨)을 그냥 방치하지 않고 판매 파이프라인에 미리 태운다.
• 핵심 가치: 물건이 실제로 빠지는 시점보다 먼저 수요를 확보해두면, 막상 빠졌을 때 바로 거래 성사 — 판매 리드타임을 0에 가깝게 줄인다.
• 필요 요소(구현 전 단계, 방향만): ① "예정 잉여 등록" 대장(품목·예상 시점·상태) — 16_예정사항관리법.law.md와 겹치는 부분은 연동, ② 마켓플레이스 게시 자동화, ③ 예약자 명단 수집·연락 체계.
• 상태: 구현 안 됨 — 아이디어만 기록. 실제 착수 여부·우선순위는 대표 판단 필요.

9-1. 업글 연쇄형 예약 메커니즘 (2026-09-12 구체화)

전용 프로그램을 설치하면, 사용자는 두 가지만 입력하면 된다 — "이 부품을 언제까지 쓸 것 같다"와 "언제부터 안 쓰게 됐다"의 체크뿐. 나머지는 자동이다.

트리거 구조 — 사용자가 업그레이드를 결정하고 새 부품을 예약/구매 확정하는 순간, 그걸 감지해서 자신의 기존(구) 부품이 자동으로 마켓플레이스 예약 명단에 등록된다. 즉 "새 걸 산다"는 행위 자체가 "헌 걸 판다"는 신호로 곧바로 전환되는 구조 — 사용자가 따로 중고 거래 글을 올릴 필요가 없다.

타임라인(3일 + 7일 원칙): 1. 부품 구매 확정 기간 3일 — 신품 주문 후 취소·환불이 가능한 유예 기간(이번 세션 중 실제로 겪은 "쿠팡 자동구매확정 유예 2일 초과로 환불 불가" 사고를 반영해, 이 시스템은 좀 더 넉넉하게 3일로 잡음). 2. 총 테스트 여유기간 7일 — 신품이 도착한 뒤, 실제로 인식·작동을 검증할 시간(오늘 겪은 HBA 고장·드라이브 미인식 같은 사고가 바로 이 "도착했다고 끝이 아니다"의 실측 근거). 3. 강제 발송 마감 — 업글 부품 도착 완료 후 7일이 지나면, 기존(구) 부품은 반드시 예약자에게 발송되어야 한다. 무기한 보유 불가 — 이 마감이 있어야 예약자 입장에서도 신뢰할 수 있는 거래가 된다.

거래 구조 정정(2026-09-12) — 개인간 직거래 아님, 회사가 매수·매도 양쪽을 담당: 예약자가 이미 정해져 있다고 해서 판매자↔예약자를 직접 연결(P2P 직거래)시키지 않는다. 대신 회사가 판매자의 구부품을 먼저 매입하고, 회사가 예약자에게 재판매·배송하는 구조로 간다 — 일종의 안전결제(에스크로) 시스템이다. 판매자와 구매자가 서로 신뢰할 필요 없이 각자 회사만 상대하면 되므로, 사기·미배송·품질 분쟁 같은 P2P 직거래의 전형적 위험이 구조적으로 사라진다. 9-2의 "언더" 하부조직(벌크 수매·시장조성)과 사실상 같은 축에서 움직이는 기능 — 개인 업글발 매물도 결국 회사가 매입해서 회사가 되파는 동일한 파이프라인을 탄다.

고객 경험(2026-09-12 정리): 구매자는 판매자가 누구인지 알 필요가 전혀 없다. 구매자에게 보이는 건 회사뿐이고, 받는 건 "자신에게 가장 적합하면서 이미 실사용으로 검증까지 끝난 중고 부품"이다 — 구매자가 할 일은 그걸 받아서 그냥 자기 기기에 끼우는 것뿐. 출처 추적, 품질 걱정, 판매자와의 협상 같은 중고거래 특유의 피로감을 전부 회사가 대신 흡수하는 구조.

설계 의의: 판매자는 "쓸 만큼 다 써보고 문제 없다는 걸 확인한 뒤"에만 넘기므로 하자 있는 물건이 넘어갈 위험이 줄고, 구매자는 "언젠가 될지 안 될지 모르는 중고매물"이 아니라 확정된 날짜에 받는다는 예측 가능성을 얻는다. 오늘 세션에서 실측된 두 사고 (구매확정 유예 초과로 환불 불가, 신품 인식 불량 발견까지 시간이 걸림)가 이 3일/7일 숫자의 실제 근거가 됐다는 점을 기록해둔다.

9-2. 자회사의 대량 조달·유통("언더 업무") 병행

9-1의 P2P(개인 간 업글 연쇄) 예약 구조만으로는 마켓플레이스 공급량이 "개별 사용자가 언제 업글하느냐"에 좌우되어 불안정하다. 이를 보완하기 위해, 자회사가 대량으로 IT 하드웨어를 조달·유통하는 백엔드 공급 업무("언더 업무")를 병행한다 — 즉 마켓플레이스는 P2P 개인 매물과 자회사의 대량 조달 물량 두 층(레이어)으로 공급이 채워지는 구조다.

• 역할 구분: P2P 레이어는 "신뢰 가능한 이력이 있는 실사용 중고 부품"(사용자가 직접 3일/7일 검증을 거친 것) 공급, 자회사 레이어는 "물량 확보·가격 안정화"를 위한 벌크 조달(오늘 세션에서 논의한 중고 서버 부품 시장의 가격 역전 현상 — 신품은 SAS가 비싸고 중고는 오히려 싸지는 것과 같은 시장 구조를 활용한 대량 매입·재판매) 담당.
• "언더"라는 표현의 의미: 마켓플레이스 사용자에게는 보이지 않는 후방 공급망 업무라는 뉘앙스로 이해 — 사용자 경험은 "예약하면 온다"로 단순하게 유지하고, 그 뒤에서 자회사가 물량을 안정적으로 받쳐주는 구조.
• 상태: 구현 안 됨 — 방향성만 기록. 자회사 설립·조달 채널·법적 구조 등 구체화는 별도 검토 필요.

구조 정정(2026-09-12): 마켓플레이스 자체는 우리가 직접 운영한다. 그 위에 별도의 "언더" 하부조직을 둬서, 이 조직이 부품을 벌크로 수매한 뒤 소량씩 나눠 판매하는 역할을 전담한다 — 이건 단순 재고 장사가 아니라, 마켓플레이스 자체의 거래 활성화(유동성 공급)를 위한 시장조성자(market maker) 역할이다. 매물이 뜸할 때 이 하부조직이 직접 사고팔며 거래량과 매물 다양성을 유지시켜, 사용자 입장에서 "이 마켓플레이스엔 항상 물건이 있다"는 신뢰를 만드는 게 목적.

9-3. 비전 — IT 제품은 그 자체로 거대한 글로벌 생태계다

이 제9조 전체(P2P 업글 연쇄, 안전결제, 언더 조직의 벌크 조달·시장조성)를 관통하는 대전제(2026-09-12 대표 발언): "IT 제품은 그 자체가 거대한 글로벌 생태계다." 즉 이 마켓플레이스는 한 함대(우리 서버들)만을 위한 소규모 도구가 아니라, 전 세계에서 상시로 발생하는 IT 하드웨어의 업그레이드·폐기·재판매 흐름 자체를 포착하는 범용 플랫폼을 지향한다는 의미로 기록해둔다. 오늘 다룬 linux2·lin1·del1 등의 개별 사례는 이 큰 그림의 축소판(파일럿) 성격으로 이해한다.

차별점(2026-09-12 대표 발언) — "당근 같은 무식한 일을 굳이 하지 않아도 됨": 당근마켓류의 전형적 P2P 중고거래는 판매자가 직접 글을 쓰고, 사진을 찍고, 가격을 흥정하고, 만나서 거래하는 수작업 반복 구조다. 이 시스템은 그 수작업 자체를 없앤다 — 사용자는 "언제까지 쓸지"만 입력해두면, 업글 결정 순간 자동으로 매물 등록→회사 매입→ 검증→재판매까지 전부 자동 파이프라인을 탄다. 즉 당근마켓과 경쟁하는 게 아니라, 당근마켓이 요구하는 수작업 자체를 구조적으로 제거한 다른 층위의 서비스라는 게 핵심 차별화 지점이다.

9-4. 고객 접점 — AI 대화형 인터페이스

고객이 별도 앱 화면에서 양식을 채우는 게 아니라, AI와 대화만 하면 끝나는 구조로 간다(2026-09-12 구체화). 흐름:

1. 고객이 AI와 대화 시작
2. AI가 미리 등록된 "곧 빠질 예정" 매물 리스트를 파악하고 있는 상태에서, 고객에게 "언제쯤 업글하고 싶으신가요?"를 먼저 물어봄 (양식 입력이 아니라 AI가 먼저 질문을 던지는 능동적 방식)
3. 고객이 대답하면, AI가 그 대답을 그대로 실행(예약 등록·매칭· 결제 트리거 등 9-1~9-3의 전체 파이프라인 가동)

즉 고객 경험의 전면은 AI 비서와의 짧은 대화 하나로 압축되고, 그 뒤의 복잡한 매입·검증·재판매 로직(9-1~9-3)은 전부 AI 뒤에 숨어서 자동으로 돌아간다.

9-5. 일반화 — IT 제품에 한정되지 않음

이 제9조의 메커니즘(업글 트리거형 P2P 예약, 3일/7일 타임라인, 회사의 안전결제·시장조성, AI 대화형 인터페이스)은 IT 하드웨어에만 국한된 게 아니다(2026-09-12 대표 지적). 헬스·운동 기구처럼 사람들이 주기적으로 업그레이드(더 좋은 기구로 교체)하면서 쓰던 걸 처분해야 하는 모든 내구재 카테고리에 동일하게 적용 가능하다 — 판정 기준은 "사용자가 예측 가능한 시점에 업그레이드하고, 그 결과 쓰던 물건이 예측 가능하게 남는 카테고리인가"이지, IT 여부가 아니다. 향후 카테고리 확장 시 이 조항을 템플릿으로 재사용한다.

구체 예시(대표 제시, 2026-09-12) — 덤벨/바벨 무게 승급: 처음엔 6kg 2개로 시작하지만, 근력이 늘면 8kg이 필요해지고, 더 늘면 10kg이 필요해진다. 이 시점엔 6kg은 더 이상 필요 없어진다 — IT 부품의 CPU/ SSD 업글과 정확히 같은 패턴(구세대 부품이 필요 없어지는 시점이 예측 가능하고, 성능이 남아있는 채로 방치됨)이다. 이 조의 9-1~9-4 메커니즘을 그대로 적용하면, "8kg으로 넘어가는 순간 6kg이 자동으로 매물화"되는 구조를 동일하게 구현할 수 있다.

트리거의 객관화(2026-09-12 보강): 이 승급은 사용자의 막연한 "업글하고 싶다"는 느낌이 아니라, 자신의 근력 테스트 결과에 따라 객관적으로 판정된다 — 테스트 결과 6kg이 더 이상 자극이 안 되면 그 시점에 6kg이 자연히 유휴분으로 전환된다. 또한 승급이 항상 "하나 버리고 하나 산다"의 1:1 교체는 아니다 — 8kg·10kg을 동시에 보유한 상태에서, 다음 단계인 12kg을 미리 예약해둬야 하는 상황도 발생한다 (여러 무게를 병행 보유하며 점진적으로 위로 늘려가는 실제 운동 패턴 반영). 즉 시스템은 "1개 교체"뿐 아니라 "다수 보유 + 상위 1개 신규 예약" 패턴도 지원해야 한다.

구체 예시 2(2026-09-12) — 자동차 트레이드인: 부품 단위보다 완성차 자체가 이 모델에 더 잘 맞는다 — 설치 개념이 없고(그냥 타면 됨), 중고차 성능점검·사고이력조회 같은 검증 인프라가 이미 법제화되어 있으며, 교체 주기(3~7년)도 통계적으로 예측 가능하다. 결정적으로, 자동차 딜러 업계가 이미 수십 년째 "신차 판매 시 헌차를 딜러가 직접 매입(트레이드인)한 뒤 되파는" 정확히 같은 에스크로 구조를 실전에서 돌리고 있다 — 9-1의 "회사가 매수·매도 양쪽 담당" 구조가 세계적 규모로 이미 검증된 살아있는 증거다.

장기 리드타임형 타이밍(2026-09-12 보강): IT 부품처럼 "도착 후 3일+7일" 방식만 있는 게 아니다 — 신차처럼 주문 시점에 이미 인도 예정일이 몇 달 전부터 확정되어 있는 경우(예: "내년 3월에 신차 받기로 되어 있음"), 그 확정된 미래 인도일을 기준으로 구차 인계 시점을 몇 달 전부터 미리 스케줄링할 수 있다. 즉 이 시스템은 두 가지 타이밍 방식을 다 지원해야 한다: - 반응형(도착 후 기산): IT 부품처럼 리드타임이 짧고 인도 예정일이 불확실한 경우 — 9-1의 3일/7일 방식. - 예정형(주문 시점부터 역산): 자동차처럼 리드타임이 길고 인도 예정일이 미리 확정되는 경우 — 인도 예정월의 특정 주(예: "3월 1주차")까지 구차를 넘기도록 사전 스케줄링.

실행 사례 자료

이 법의 원칙이 실제로 적용된 사례:

아직 사례 없음: 제4조(autoinstall 기반 설치 자동화)·제7조(OS 최신본 상시 수집·자동 갱신)·제9조(잉여 하드웨어 사전예약 마켓플레이스 봇)는 이 법 자체가 "방향성 확정, 구현은 별도 작업"이라고 명시한 대로 아직 실제 구현·실행 사례가 없다.