01 · 왜 지금 설계인가
코딩을 잘하는 사람은 많습니다.
설계를 잘하는 사람은 많지 않습니다.
AI 코딩 도구가 나오면서 코드 쓰는 속도는 더 이상 문제가 아닙니다. 문제는 그 앞뒤에 있습니다. 무엇을 어떤 구조로 만들지 정하는 일, 만든 게 설계대로 도는지 확인하는 일. 바이브 코딩으로 만든 시스템이 무너지는 지점이 늘 여기였습니다.
프롬프트로 기능을 하나씩 붙이다 보면 2~3주 뒤에 아무도 손을 못 대는 코드가 남습니다. 테이블 설계, 모듈 경계, 상태 전이를 먼저 적어 두지 않으면 AI가 쓴 코드는 유지가 안 됩니다.
돌아가는 것과 맞게 돌아가는 것은 다른 얘기입니다. AI는 자기가 쓴 코드가 통과하는 테스트를 씁니다. 경계값, 장애 복구, 권한 흐름은 시험 항목을 사람이 정하고 결과도 사람이 봐야 합니다.
고객이 주는 건 기능 목록이지 시스템이 아닙니다. 그걸 엔티티, 흐름, 운영 절차로 바꾸는 게 설계이고, 여기서 경험 차이가 납니다.
02 · 일하는 순서
30년 동안 시스템 설계하던 방식은 그대로 두고 구현 주체만 바꿨습니다. 구조와 데이터 모델을 설계서로 확정하면, 역할을 나눈 에이전트가 그 설계서를 보고 코드를 씁니다. 검증 게이트는 제가 지킵니다.
요구를 엔티티·상태·흐름으로 변환합니다.
마스터 에이전트가 설계서를 기준으로 작업을 분배합니다.
동작 여부가 아니라 설계 의도대로 동작하는지 확인합니다.
코드만 넘기지 않습니다.
에이전트를 어떻게 나눌지도 설계 일입니다. 역할 분담, 사람이 확인하는 지점, 자동 시험에 맡길 범위는 프로젝트마다 다시 정합니다. 같은 구성을 어디에나 쓰지 않습니다.
03 · 설계 사례
고객사명은 뺐습니다. 어떤 구조 문제가 있었고 어떻게 풀었는지 위주로 적었습니다.
04 · 제공 범위
설계서, 코드, 시험 결과 레포트를 한 세트로 넘깁니다. 넘긴 뒤의 유지보수 범위는 견적 단계에서 따로 정합니다.
요구 정리서, 설계서, 시험 레포트 순서로 각 단계를 문서로 확인받고 다음으로 넘어갑니다. 회의는 꼭 필요할 때만 합니다.
1차는 MVP로 좁게 잡고, 나머지는 업그레이드 항목으로 뺍니다. 처음부터 전부 넣은 견적은 내지 않습니다.
개발 책임과 운영 책임, 보안 적용 수준, 유지보수 범위를 견적서에 명시합니다. 나중에 해석이 갈리는 걸 막기 위해서입니다.
사업소득(3.3%) 처리 또는 사업자 세금계산서 발행 중 선택하실 수 있습니다. 국내·해외 모두 진행합니다.