[ Approach · LAFI ]

무엇을 만들지 정하고, 오래 운영할 수 있게 만듭니다.

안정적인 프로덕트는 탄탄한 운영 설계에서 출발합니다. 스택을 고르기 전 비즈니스 제약과 요구조건을 명확히 하고, 프로젝트 완료 후에도 팀이 독립적으로 운영할 수 있는 구조를 구축합니다.

[ Operating Method ]

발견부터 인계까지, 네 단계.

단계마다 무엇을 먼저 확인하고 무엇을 남기는지 정해 둡니다. 남는 것은 팀이 매일 쓰는 문서와 도구입니다.

01Discovery
조건부터 분리합니다
트래픽, 지연 시간, 데이터 신선도, 팀 소유권을 먼저 나눕니다. 스택은 이 조건을 정리한 뒤에 고릅니다.
What stays도메인 지도리스크 인벤토리의사결정 로그
02Core
작고 단단한 핵심부터 만듭니다
오래 쓸 기본 구조를 먼저 만들고, 자주 바뀌는 화면은 그 위에 따로 둡니다. 변하지 않는 부분에 가장 많은 시간을 씁니다.
What stays도메인 모듈인터페이스변경 기준
03Release
검증 가능하게 배포합니다
관측, 롤백 기준, 운영 지표를 릴리즈 경로에 넣습니다. 배포는 됐지만 작동하는지 모르는 상태를 시스템에서 막습니다.
What stays관찰성롤백 기준운영 지표
04Sustain
운영의 완전한 자립을 지원합니다
체계적인 문서와 런북으로 내부 팀이 외부 의존 없이 운영할 수 있도록 인계합니다. 인계는 첫 주부터 개발과 함께 진행합니다.
What stays런북인계페어 세션

[ Working Agreement ]

사용하는 기술 스택은 달라져도, 모든 프로젝트에서 반드시 지키는 네 가지 원칙을 공유합니다.

같은 저장소에서 일합니다
클라이언트 팀과 같은 저장소에서 매주 돌아가는 단위로 맞춰 갑니다. 진행 상황이 항상 코드로 보입니다.
결정은 기록으로 남깁니다
왜 이렇게 설계했는지 아키텍처 의사결정 로그(ADR)로 남깁니다. 인계 이후에도 맥락이 사라지지 않습니다.
배포 이후까지 함께 봅니다
관측과 롤백 기준이 들어가야 진짜 배포입니다. 그 기준을 팀과 함께 정하고, 운영 지표로 확인합니다.
외부 의존 없이 자립할 수 있게 설계합니다
한 업체에 계속 의존해야 하는 구조는 사업의 리스크입니다. 명확한 아키텍처 문서와 런북을 통해 내부 팀이 온전히 소유하고 발전시킬 수 있도록 합니다.

[ Get in touch ]

먼저 어떤 문제인지부터 듣습니다. 데모와 견적, 일정은 그다음에 정리합니다. 첫 대화는 보통 30–45분이고, 필요하면 NDA부터 작성하고 시작합니다.