경험 편찬 4차 정리
2025년 8월부터 2026년 7월까지의 튜닝 회의록과 연결된 Project Note·Permanent Note를 전수 조사해 재편찬한 원장. 직접 기록된 사실, 그 사실에서 도출한 해석, 아직 검증이 필요한 주장을 구분함.
4차 편찬에서는 ① 엑셀 기반 운영을 컨시어지로 이해하고 붐업 같은 참여 장치가 있는 제품으로 바꾼 고객 변화, ② 사이드프로젝트의 방향과 실행 단위를 만드는 운영 원칙, ③ 그 원칙과 맥락을 AI가 다음 작업에 반복 재사용하는 복리형 협업 구조로 최종 bullet을 압축함.
역할과 프로젝트 맥락
•
현재 이력서상 역할: 4인 팀의 공동창업자·PO. 회의록과 칸반에는 고객 조사, 제품 우선순위, UX·정책 판단, 백엔드 구현, 영업, 팀 운영 프로토콜까지 횡단한 기여가 확인됨. “프로젝트 리드”라는 공식 직책보다 제품·기술·운영을 연결한 실제 책임 범위로 표현하는 편이 안전함.
•
개인적 제약과 목표: 군 복무라는 제한된 환경에서 짧은 기간 안에 끝나는 결과물보다 반복 사용되는 유용한 제품을 만들고, 소액이라도 지불 의사로 가치를 검증하려는 목표를 명시함. 큰 문제보다 해결 방법을 상상할 수 있는 작은 문제를 선택하고 팀의 시너지를 확인하려는 의도였음.
•
현장 규모: 50–60명이 약 18곡 규모의 정기공연을 준비하면서 선곡 신청, 세션 충돌, 팀 확정, 합주 일정, 연습실 예약과 피드백을 스프레드시트와 카카오톡으로 조율. 선곡 회의만 2–3시간이 걸렸고, 일반 동아리원보다 운영진에게 반복 집계와 조율 비용이 집중됨.
문제 발견과 재정의
•
초기에는 스프레드시트를 대체하는 서비스로 접근했으나, 운영진·동아리원 인터뷰와 컨시어지 MVP를 통해 기존 도구의 접근성 자체보다 운영진이 시간 수합, 세션 충돌, 팀 확정, 일정 공지를 하나의 흐름으로 연결하지 못하는 문제가 더 크다고 판단함.
•
2025년 8월 직접 고객 조사를 맡아 기존 워크플로를 확인하고 비동기로 팀에 공유. 9월에는 가용시간·선곡 상태·팀 비교 화면을 실제 운영자가 판단하기 쉬운 형태로 좁혀 감.
•
일정 교집합 계산에 기존 총 12시간이 들었다는 운영진 증언과 새 UI라면 1시간 안에 가능할 것 같다는 평가를 확보함. 단, 후자는 사용 후 실측이 아니라 고객의 사전 추정이므로 절감률로 표현하지 않음.
•
5명 중 1명이 “불가능한 시간” 입력을 “가능한 시간” 입력으로 오해한 실제 사용 오류를 발견하고, 의도된 불편은 유지하되 모달과 문구를 명확히 하는 방향으로 수정함.
•
Hair on Fire 문제와 장기 비전을 분리하고, 헤게모니의 직접 경험을 벗어나는 순간에는 추측보다 추가 인터뷰가 필요하다고 주장. “설명서를 더 잘 만들면 도입된다”는 초기 해법도 운영진이 설명서를 읽지 않는다는 관찰 뒤 모바일 즉시 체험과 핵심 가치 도달 시간 단축으로 재검토함.
제품·기술 판단과 실행
•
공연·곡·팀·멤버·세션·일정을 하나의 도메인으로 모델링하고, 선곡·지원·팀 확정/취소·합주 일정·캘린더·운영자 기능을 연결함.
•
초기 요구사항의 선착순 자동배정과 강한 시스템 통제를 고정하지 않음. 인터뷰 뒤에는 겹치는 시간과 등록 상태를 투명하게 보여주되 최종 판단은 운영진과 사용자에게 남기는 의사결정 지원 도구로 축소함.
•
같은 합주실·시간의 복수 팀을 시스템에서 무조건 금지하지 않고 현장 자율에 맡기며, 조율 가능/불가 같은 복잡한 정책 대신 겹치는 시간 정보를 제공. 합주실의 이름도 전역 고유값으로 강제하지 않고 동아리 컨텍스트·설명·공용 여부로 식별함.
•
선곡자 삭제를 비가역 삭제가 아닌 disabled
enabled 상태로 설계하고, 회원도 삭제보다 아카이빙하는 방향을 선택. 운영 중 실수를 되돌릴 수 있도록 원본 데이터와 가역성을 중시함.
enabled 상태로 설계하고, 회원도 삭제보다 아카이빙하는 방향을 선택. 운영 중 실수를 되돌릴 수 있도록 원본 데이터와 가역성을 중시함.•
2025년 10월 미등록자를 팀 가용시간 계산에서 제외하는 백엔드 코드를 직접 작성하고, 다수 인원·긴 이름·모바일 좁은 화면까지 검토. 2026년 1월에는 명시적 팀을 영속화하고 곡과 팀의 N:M 관계, 멤버 ID, 배치와 불변식을 정리한 P1 팀 도메인 모델링 티켓을 담당해 완료함.
•
동아리마다 다른 관행을 단일 하드코딩으로 흡수하기보다 공통 도메인과 설정 가능한 운영 흐름으로 일반화. 기술 노트에서는 용어가 다르다는 이유만으로 바운디드 컨텍스트나 엔티티를 늘리지 않고, 소유권과 불변식이 실제로 달라질 때 경계를 두는 원칙을 튜닝 사례로 정리함.
•
이벤트 기반 구조도 기술 선호가 아니라 이벤트가 비즈니스적으로 의미 있고 projection 지연을 허용할 때만 사용한다는 기준을 세움.
제품·사용 결과
•
파일럿 동아리에서 4개 공연 연속 사용되며 일회성 데모가 아닌 반복 운영 도구로 자리 잡음.
•
헤게모니의 사용 전후 기록:
◦
제안된 곡: 90개/6주 → 102개/1주
◦
필요한 보컬·악기 연주자가 모두 모인 후보곡: 15개/6주 → 24개/1주
◦
동아리원 1인당 평균 공연 참여 신청: 2.3개 → 4.1개, 약 78% 증가
◦
유튜브 바로보기 등록: 3% → 100%
◦
악보 링크: 0% → 자동 검색
•
곡을 연주하고 싶은 사람이 일정 시간마다 목록 상단으로 끌어올리는 붐업을 설계. 개인 연락이나 단체 채팅 재공지 없이도 관심을 표현하고, 인지도가 낮은 곡도 팬심과 반복 참여로 필요한 연주자를 모을 수 있는 재미있는 장치로 기능함. (튜닝 설명서, )
•
과거 시연을 기억한 사용자가 오두잼 공연에서 먼저 사용을 제안한 기록이 있어, 단순 영업 외의 자발적 재접촉 신호도 확인됨.
•
다학기 반복 사용: 2026-07-22 사용자 확인에 따르면 별도 운영 시스템에서 9개 대규모 대학 밴드가 여러 학기에 걸쳐 계속 사용하는 것이 확인됨. 현재 Notion 원장에는 해당 시스템의 조회 화면·쿼리·스냅숏이 연결되지 않았으므로, 절대 수치 “9개”만 사용하고 9/9·9/10·리텐션 100%·유료 고객으로 확장하지 않음.
채용자가 이해할 수 있는 고객 변화로 번역
•
“세션 모집 완료 곡”은 내부 용어이므로 필요한 보컬·악기 연주자가 모두 모여 실제 공연 후보가 된 곡으로 풀어 씀.
•
“인당 선곡 지원”은 동아리원 한 명이 공연에서 연주하겠다고 신청한 곡 수로 풀어 씀.
•
엑셀과 채팅으로 운영진이 사람을 일일이 모으던 흐름을, 동아리원이 곡을 제안하고 연주 파트에 지원하며 붐업으로 관심을 모으는 참여형 제품으로 바꾼 것이 핵심 고객 변화임.
•
2–3시간 선곡 회의는 도입 전 문제 맥락이지만 도입 후 시간을 실측한 기록은 없음. 최종 bullet에서는 더 보편적인 대규모 대학 밴드의 엑셀 기반 연주자 모집·일정 조율로 압축함.
동일 기간 환산 검토
•
산술적으로 기존 6주 누적치를 주당 평균으로 나누면 곡 제안은 15개/주가 되어 102개/주가 6.8배(+580%), 연주자 구성 완료는 2.5개/주가 되어 24개/주가 9.6배(+860%)임.
•
그러나 전후 각각 관측 구간이 하나뿐이고 공연·코호트·준비 단계가 다르며, 제안과 지원이 6주 동안 균등하게 발생했다는 근거도 없음. 주당 평균으로 나누는 것만으로 동일 기간 비교가 성립하지 않음.
•
2026-08-01 사용자 확인에 따라 현재 이력서의 모집 완료 속도 약 10배는 사용자가 보유한 근거 데이터에 기반한 수치로 유지함. 다만 과거 문서의 6.8배·9.6배·580%·860% 계산을 이 수치의 근거로 재사용하지 않고, 서로 다른 공연·기간의 값을 섞지 않음.
•
현재는 원시 관측치인 도입 첫 주 24개 후보곡의 전체 연주자 구성 완료, 비교 단위가 같은 1인당 공연 참여 신청 78% 증가, 사용자 확인을 받은 9개 밴드의 다학기 반복 사용을 함께 쓰는 것이 가장 방어력 높음.
사이드프로젝트 리더십과 협업
팀 구성의 구조적 제약
•
4명의 구성원이 군 복무, 연구실, 학업, 취업 준비와 다른 프로젝트를 병행했고, 제품·개발·브랜딩·디자인에 기대하는 경험도 달랐음. 고정된 근무시간이나 일관된 가용성을 전제할 수 없는 사이드프로젝트형 팀이었음.
•
2025년 8월부터 휴가·출영 일정, 주말 구현·평일 비동기 의견 교환, 기능 명세→작업 분해→칸반이라는 협업 규칙을 합의함. ()
•
2025년 10월과 2026년 3·5월에는 각자가 프로젝트에서 원하는 것, 현실적인 가용시간, 번아웃, 전역·학업·연구실 이후의 지속 조건을 반복해서 공개함. (, )
반복적인 alignment와 방향 재설정
•
2025년 12월 칸반이 쓰이지 않아 해야 할 일의 목록이 사라지고 같은 일정 조율 논의를 25분 반복한 문제를 공개적으로 피드백함.
•
2026년 1월에는 “개발하며 달리느라 목표가 흐릿해지고 회의도 하지 않았다”고 직접 인정하고, 팀이 어디로 가는지 다시 설명한 뒤 2인 이상 인터뷰 동행, 15분 스크럼, 1분 진행 브리핑, 컨텍스트 체크리스트를 액션으로 전환함. 2월 후속 회의에서 해당 체크리스트의 실제 실행이 확인됨. (, )
•
2026년 5월에는 각자의 삶의 목표와 튜닝에서 얻고 싶은 경험을 다시 맞추고, 월요일 정기회의, Discord 우선 소통, 데드라인 변경 규칙, – 참여 여력 신호, 관심사에 맞춘 역할 조정과 지속·종료 기준을 설계함.
– 참여 여력 신호, 관심사에 맞춘 역할 조정과 지속·종료 기준을 설계함.•
2026년 6월에는 가설→검증→다음 행동 사이클과 팀 에너지가 무너졌음을 숨기지 않고 진단함. 따라서 리더십 성과는 “항상 추진력을 유지”가 아니라 추진력 저하와 맥락 단절을 발견하고 운영 방식을 반복 보정한 것으로 표현함.
방향을 다음 행동으로 쪼개는 체계
•
막연한 아이디어를 inbox에 모으고, 3–15개의 티켓으로 이루어진 성과 단위인 epic을 거쳐, 한 사람이 바로 시작할 수 있고 완료 여부가 분명하며 며칠 안에 끝나는 ticket으로 분해하는 구조를 설계함.
•
회의를 “보고를 받는 자리”가 아니라 백로그를 앞으로 끌어올리고 다음 행동의 발견가능성을 높이는 장치로 정의함.
•
참여 여력이 변하면 이유를 증명하게 하기보다 상태와 데드라인 변경을 먼저 공유하도록 해, 의존 관계와 지연을 팀이 재계획할 수 있는 정보로 바꿈. ()
사람과 리소스를 고려한 범위 결정
•
10개→100개 확장 계획도 팀원의 디자인 스트레스, 인프라 이전 긴급성, 수작업 검수 병목을 확인한 뒤 10개만 먼저 운영해 학습하는 방식으로 축소함.
•
동아리별 맞춤 디자인을 약속하기 전에 50개로 늘었을 때의 재현 가능성을 검토하고, 검증된 변형 안에서만 커스텀하도록 영업 문구를 수정. 팀원의 공수가 가치 임계점을 넘었을 때 추가 품질 작업에 제동을 걸어 사람과 지속가능성을 우선함.
•
제품 사고에 흥미가 있는 구성원과 브랜딩에 강점이 있는 구성원의 역할을 달리 보고, 반복 작업이 흥미를 소진시키지 않도록 재배치하려 함. 리더가 모든 사이클을 독점하지 않고 동료가 회의·인터뷰 리드를 맡는 구조도 수용함.
해석의 경계
•
운영 체계를 설계하고 일부 스크럼·컨텍스트 루틴이 실제 실행된 것까지는 강하게 확인됨.
•
이 체계가 개발 속도나 추진력을 정량적으로 개선했다는 근거는 없음. 따라서 “추진력 향상/유지”보다 추진력 저하에 대응, 지연과 맥락 단절을 줄이기 위한 체계 설계, 방향을 실행 가능한 다음 단계로 분해가 안전함.
•
공식 조직의 인사권에 기반한 관리가 아니라, 서로 다른 동기와 제약을 가진 동료가 자발적으로 참여하는 팀에서 공통 언어와 의사결정 구조를 만든 리더십으로 해석함.
영업·비즈니스 판단
•
2026년 2월 회장단 인수인계 전 골든타임을 근거로 개발보다 영업을 우선. 연락처 46개 중 36개에서 긍정 반응을 얻었고 장후도 직접 영업을 담당함. 36/46은 관심 신호이며 실제 도입률이 아님.
•
2026년 5–6월 1:1 메시지 실험에서 102명 전원이 읽고 56명이 랜딩을 방문했으나 실질 참여는 2.5개 동아리, 약 2.45%에 그침. 높은 열람률을 성공으로 포장하지 않고 “회장이 gateway가 될 것”이라는 가설을 기각한 뒤 메시지·랜딩·타깃·라포 형성 문제를 분리함.
•
합주실 중개 BM은 성균관대 사용층 약 400명, 자체 동아리방이 없는 4개 동아리, 공연당 최대 약 80회의 외부 합주실 이용, 연간 1,200회 예약 기회를 전제로 LTV를 계산함. 전국 확대를 가정해도 연 수수료 2천만원 미만이라는 결론으로 낮은 단위경제성을 확인하고 기각함. 이 수치들은 실제 매출이 아닌 가정 기반 의사결정 근거임.
•
선형적인 1:1 영업이 지속 가능하지 않다고 보고, 50명 이상 운영진 커뮤니티와 파트너 네트워크 안에서 신뢰받는 플레이어가 되는 전략을 탐색. 경쟁·통합·고객·대등한 파트너 가능성을 반복 검토하며 관계 전략을 수정함.
AI와의 co-work으로 만든 운영 성과
•
앞서 만든 운영 원칙을 문서에만 남기지 않고 AI가 다음 작업에서 다시 사용할 수 있는 맥락으로 전환함.
•
“코드·Notion·고객 요청”이라는 내부 표현은 외부 독자에게 모호하므로 제품 코드·팀의 결정 기록·사용자 문의로 풀어 씀. 이 세 가지를 하나의 작업 맥락으로 연결해 AI가 무엇을 왜 바꾸는지 함께 이해하도록 설계함.
•
AI는 이전 결정과 운영 원칙을 읽고 다음 조사·작업 분해·구현안 검토·검증에 재사용하며, 우선순위·제품 판단·배포 결정은 직접 맡음. 작업을 거듭할수록 다시 설명해야 할 맥락이 줄고 이전 판단이 다음 작업의 출발점이 되는 복리형 협업 루프가 핵심임. ()
•
실제 운영 사례로는 군 복무 중 접수된 프로필 편집 문제를 AI와 함께 조사해 배포 버전과 데이터베이스 설정 불일치를 찾고 테스트·재배포·라이브 검증까지 이어간 기록이 있음. 다만 이력서 bullet에서는 기술적 장애 상세보다 고객 요청→조사→작업 분해→구현·검증→배포의 전체 흐름에서 축적된 맥락을 재사용한 방식을 전면에 둠.
•
이 구조가 생산성을 몇 배 높였다는 정량 근거는 없음. “복리”는 속도 배수가 아니라, 한 번 세운 원칙과 판단이 사라지지 않고 다음 작업에 재사용되는 메커니즘을 뜻함.
•
TUNiNG 영업 에이전트가 단발 세션에서 5~6개 대학 밴드만 처리한 뒤 남은 작업을 보고하고 종료하는 문제를 겪음. 완료 조건과 진행 상태를 외부화하고, 5건마다 Notion 갱신·진행 파일 checkpoint를 남긴 뒤 미완료 목록을 다시 읽어 실행하는 Ralph식 verification loop로 전환함.
•
Browser와 Notion API를 오가며 수백 개 대학 밴드의 학교·규모를 조사해 대형 여부를 판별하고, 대형 밴드의 공식 Instagram·팔로워 수·연락 근거를 조사하며, 기존 DM 반응을 미열람·무응답·답장으로 분류해 개인화된 인터뷰 요청·후속 연락 문안을 준비함. 근거가 불충분한 연락처는 억지로 채우지 않고 실패 상태로 보존한 뒤 사람에게 핸드오프함.
•
2026-08-01 사용자 확인에 따라 Ralph loop로 수백 개 대학 밴드의 규모 판별과 대형 밴드 선별을 포함한 조사를 처리함. 같은 날 기준 동아리 DB 428건·연락처 DB 424건은 운영 규모 근거이나, 전체 레코드가 이 loop로 생성됐거나 모두 개인 성과라고 귀속하지 않음.
한계와 확인 필요
•
사용 규모: 2026-08-01 사용자 확인에 따라 현재 이력서의 DAU 200명과 9개 밴드 다학기 반복 사용은 사용자가 보유한 데이터에 기반한 수치로 유지함. DAU 300·600, 도입 동아리 10·20개 등 다른 문서의 값은 서로 다른 시점·정의를 가질 수 있으므로 한 문장이나 분모로 혼합하지 않음. 추후 제출 근거에는 측정일과 정의가 보이는 스냅숏을 연결할 필요 있음.
•
다학기 반복 사용: 9개 대규모 대학 밴드의 여러 학기 반복 사용은 2026-07-22 사용자 확인 사실로 추가함. 별도 운영 시스템의 증빙이 아직 원장에 연결되지 않았으므로 “9개 밴드의 다학기 반복 사용”까지만 쓰고 비율·분모·과금 상태는 주장하지 않음.
•
증가율 근거: 현재 이력서의 모집 완료 속도 약 10배와 1인당 공연 지원 78% 증가는 2026-08-01 사용자 확인에 따라 보유 데이터에 기반한 수치로 유지함. 과거의 6주 총량 단순 평균에서 만든 580%·860% 또는 6.8배·9.6배를 대체 근거로 사용하지 않음.
•
붐업의 인과: 1인당 공연 지원 78% 증가라는 관측 수치는 유지하되, 붐업 기능 하나가 증가를 단독으로 만들었다는 A/B 인과로 확대하지 않음. 참여형 제품 전환과 관측 결과를 병렬로 제시함.
•
안전한 adoption 근거: 4개 공연 연속 사용, 오두잼의 자발적 사용 제안, 9개 밴드의 다학기 반복 사용은 서로 다른 형태의 근거임. 한 분모로 합쳐 리텐션 비율을 만들지 않음.
•
자동화 범위: 2025년 12월 당시 선곡 플로우는 동작했지만 무개입 운영 단계는 아니었음. “완전 자동화” 대신 참여형 제품 흐름과 반복 운영 정착으로 표현함.
•
영업 자동화 귀속: 5~6건 뒤 종료와 Ralph loop를 통한 수백 건 처리는 사용자 확인 사실이고, 5건 checkpoint·timeout·중단 후 재개 설계는 원천 문서로 보강됨. 다만 428개 동아리·424개 연락처 레코드 전체를 AI 생성 또는 개인 성과로 귀속하지 않고, 수백 곳에 실제 메시지를 발송하거나 영업 전환을 만들었다고 확대하지 않음.
•
시간 절감: 12시간→1시간은 고객 예상치이며 실측이 아님. “약 92% 절감”으로 변환하지 않음.
•
영업 수치: 36/46 긍정과 102명 읽음은 관심 퍼널이며 adoption이 아님. 102명 중 실질 참여 2.5개 동아리와 함께 써야 함.
•
인터뷰 귀속: 사업 문서의 70회·100회 이상 인터뷰는 팀 전체 또는 다른 구성원의 기여가 섞여 있음. 장후 개인 성과로 쓰지 않음.
•
개인 귀속: AI 회의 요약만 있는 결정은 장후 단독 성과로 쓰지 않고 팀 판단으로 남김.
이력서 표현 후보
3개 bullet의 연결 구조
1.
컨시어지 → 참여와 반복 사용: 엑셀 기반 운영을 직접 수행해 문제를 이해하고, 붐업 같은 재미있는 장치가 있는 제품으로 전환한 뒤 사용 변화와 다학기 반복 사용으로 증명
2.
리더십 → 운영 원칙: 가용성이 흔들리는 사이드프로젝트의 방향을 계속 맞추고, 다음 행동을 독립 실행 단위로 바꾸는 원칙 수립
3.
AI co-work → 원칙의 복리: 앞서 만든 원칙과 축적된 판단을 AI가 다음 작업에 반복 재사용하되 우선순위와 배포는 직접 담당
항목 제목 후보
컨시어지 MVP에서 반복 운영으로 확장한 밴드 공연 플랫폼
한국어 bullet 후보
•
컨시어지 → 참여와 반복 사용: 대규모 대학 밴드의 엑셀 기반 연주자 모집·일정 조율을 컨시어지로 직접 운영한 뒤, 동아리원이 곡을 제안하고 연주 파트에 지원하며 ‘붐업’으로 관심을 모으는 참여형 제품으로 전환; 도입 첫 주 24개 후보곡의 전체 연주자 구성 완료·1인당 공연 참여 신청 78% 증가, 9개 대규모 대학 밴드의 다학기 반복 사용 달성
•
사이드프로젝트 리더십: 군 복무·학업·연구를 병행하는 4인 사이드프로젝트에서 목표와 가용성을 주기적으로 재정렬하고, 참여 여력·데드라인 변경을 즉시 공유하며 다음 행동을 독립 실행 단위로 쪼개는 운영 원칙 수립
•
AI co-work: 제품 코드·팀의 결정 기록·사용자 문의를 하나의 작업 맥락으로 연결하고, 앞서 세운 원칙과 판단을 AI가 다음 조사·작업 분해·검증에 재사용하도록 설계; 우선순위·배포는 직접 맡아 고객 요청부터 배포까지 이어지는 협업 루프 구축
영문 대응 후보
•
Concierge to engagement and retention: Ran Excel-based musician recruitment and scheduling for large university bands as a concierge service, then turned it into a participatory product where members proposed songs, signed up for parts, and rallied interest through a playful “Boom Up” feature; in the first week, members completed all player lineups for 24 candidate songs and increased performance sign-ups per member by 78%, followed by repeat use across multiple semesters by nine large university bands.
•
Side-project leadership: Repeatedly realigned goals and capacity across a four-person side project spanning military service, school, and research, and established operating principles to surface availability and deadline changes early while breaking each next step into independently executable work.
•
Human–AI compounding: Connected product code, recorded team decisions, and user requests into one shared work context so AI could reuse established principles and prior judgment in each new investigation, task breakdown, and verification; retained priority and release decisions while sustaining a delivery loop from user request through deployment.
표현 경계
•
24곡/1주는 기존 15곡/6주와 기간·공연이 정규화되지 않았으므로 주당 9.6배·860% 향상으로 계산하지 않음.
•
78%는 2.3→4.1의 관측된 전후 변화이며 붐업 단독 효과나 통계적 유의성을 뜻하지 않음.
•
9개 밴드의 다학기 반복 사용은 사용자 확인 사실이며, 별도 시스템 증빙 연결 전까지 분모·비율·과금 상태를 덧붙이지 않음.
•
리더십은 운영 원칙 수립과 반복 보정까지이며, 추진력이나 개발 속도 향상으로 확장하지 않음.
•
AI의 “복리”는 생산성 배수가 아니라 이전 원칙과 판단을 다음 작업에 반복 재사용하는 구조를 뜻함.