banksalad·문제"문서보다 작동하는 소프트웨어"라는 애자일 원칙 때문에 테크스펙 작성이 부정되거나, 늘 최신화해야 하는 부담스러운 문서로 오해되는 일이 잦다.
접근테크스펙을 일방향 정적 문서가 아니라 협업과 창의가 필요한 작업 전에 조기 피드백을 받는 양방향 토론방으로 재정의한다. 영화의 시나리오·콘티처럼 지적 생산활동의 일부로 본다.
결과테크스펙은 배포 시점에 수명을 다하므로 최신화가 필요 없다. 오히려 개인 간 상호작용과 즉각적 피드백이라는 애자일 본래 취지를 강화하는 도구가 된다.
토스 SLASH·문제조직이 성숙할수록 팀 내부보다 팀 사이의 회색지대 문제(책임 불명확, 다중 조직이 얽혔으나 소유자 없음)가 병목이 된다. AI 시대에 그 복잡도는 더 커진다.
접근토스는 기존의 일정 관리 중심 TPM(Technical Program Manager)을 "정의되지 않은 중요 문제를 구조화하고 해결"하는 역할로 재정의했다. 문제 발굴 → 구조화 → 실행 가능한 상태로 전환까지가 핵심.
결과문제 구조화 능력 + 전략을 실행으로 변환하는 힘 + 완결성을 갖춘 TPM이 고성과 조직의 필수 역할이 된다.
무신사 테크·
NHN Cloud Meetup·문제개발 진행을 보고할 때 "진행 중" 같은 모호한 상태 표현은 가시성을 떨어뜨린다. 어떤 작업이 끝났는지 외부에서 알기 어렵다.
접근NHN Cloud 의 "Artifact Driven Development" — 과정보다 결과물(PR, 디자인 문서, spec) 을 일급 시민으로 다룬다. 모든 작업이 명확한 산출물로 정의되도록 워크플로 재설계.
결과진행 상황 가시성과 완료 기준 명확성이 동시에 개선. 협업 비용이 줄어들고 비동기 협업이 자연스러워졌다.