지금
헤론 오토마타라는
이커머스 업무 자동화 SaaS를 만들고 있다.
현재는
그 기반이 되는 DB를 구축하는 단계다.
처음에는 DB를 만든다고 하면
테이블과 컬럼을 정하고
데이터 관계를 잡아가는 일이라고 생각했다.
그런데 실제로 하나씩 정하다 보니
하나의 선택이 계속 다른 선택을 불러왔다.
상품 테이블에 deleted_at이라는
삭제 시점을 기록하는 컬럼 하나를 넣었다.
그러자
삭제한 상품을 다시 살릴 수 있어야 하는지,
중복 검사는 어떻게 할지,
언제 영구 삭제할지 같은 문제가 따라왔다.
컬럼 하나를 정했는데
어느 순간 DB를 넘어
기능과 운영 정책까지 같이 생각하고 있었다.
이런 고민이 이어지면서
상품 테이블은 결국 23개의 컬럼까지 늘어났다.
대략 이런 구조다.
시스템
id / tenant_id / heron_code
created_at / updated_at / deleted_at
필수 정보
product_name / is_package / origin / status
상품 정보
seller_sku / barcode / model_name / model_no
옵션
option_1 / option_2 / option_3
option_group / sort_order
기타
tax_type / brand_id / category_id / memo23개라는 숫자가 문제라는 뜻은 아니다.
각각 필요한 이유가 있었다.
더 중요한 것은
이 상품 테이블 자체가
헤론 오토마타 전체에서는 아주 작은 일부라는 점이다.
현재 생각하고 있는 전체 구조에는
회사, 상품, 가격 이력, 채널 상품, 매핑,
업로드 기록, 원본 데이터, 결과 데이터 등이 따로 있다.
상품 테이블 하나를 정리하는 데도
이 정도의 판단이 필요했다.
그 뒤의 테이블과 기능까지 생각하기 시작하면
범위는 금방 훨씬 커졌다.
나중에 보니
이런 현상이 흔히 말하는
Scope Creep, 즉 프로젝트 범위가
조금씩 커지는 현상과 비슷했다.
처음부터 큰 기능 하나를 추가한 것이 아니다.
필요해 보이는 작은 결정들이
하나씩 붙으면서
전체 범위가 계속 넓어졌다.
아직 프로젝트를 많이 해보지 않은 나에게는
지금 결정해야 하는 것과
나중에 결정해도 되는 것을 나누는 일
이 생각보다 어려웠다.
DB를 만들다가
아직 구현하지 않은 화면을 생각하고,
화면을 생각하다가
운영 방식을 생각하고,
그러다 보면
앞으로 생길 문제까지 먼저 설계하고 있었다.
AI를 같이 사용하면서
이런 생각은 더 쉽게 이어졌다.
하나를 물어보면 가능한 방법이 나오고,
그 방법을 보다 보면 다음 조건이 보이고,
다시 물어보면 또 다음 설계가 나온다.
AI가 틀린 답을 줘서 생긴 문제는 아니었다.
오히려 하나씩 보면
대부분 그럴듯했고
적용할 만한 이유도 있었다.
AI는
“이걸 만들 수 있는가?”
에는 꽤 쉽게 방법을 제시한다.
하지만
“이걸 지금 만들어야 하는가?”
는 결국 내가 선택해야 했다.
만들 수 있다는 것과
지금 만들어야 한다는 것은 달랐다.
돌이켜보면
헤론 오토마타에는 내가 생각할 수 있는
거의 모든 생각이 들어간 느낌이다.
제품 기능만 정한 것도 아니다.
정의와 범위, 작업 규칙,
시스템 구조, Phase 지도, 기술 스택까지
프로젝트를 어떻게 만들고 운영할지도 같이 정리했다.
방향과 최종 판단은 내가 하고,
AI는 선택지를 제시하고
그 생각을 문서와 구조로 정리했다.
이커머스 업무에서 겪었던 문제,
제품을 어떻게 만들지에 대한 생각,
DB와 기능을 설계하면서 새로 배우는 내용까지
하나의 프로젝트 안에서
계속 연결되고 있다.
개발 공부도
이 프로젝트와 따로 떼어두지 않았다.
AI가 코드를 만들어줘도
그대로 붙여 넣고 넘어가지는 않는다.
한 번에 동작 한두 개씩 나눠서
직접 실행해 보고,
무엇을 하는 코드인지,
왜 그렇게 동작하는지 확인한다.
마지막에는
안내 없이 다시 해보고
내 말로 설명해 본다.
설명하려고 하면
내가 정확히 이해하지 못한 부분이 드러난다.
그래서 헤론 오토마타는
제품을 만드는 프로젝트이면서
실제 개발을 공부하는 과정이기도 하다.
이번에 느낀 것은
생각을 많이 하는 것 자체보다
그 많은 생각 중에서
’무엇을 지금 선택할 것인가’
가 더 어렵다는 점이었다.
지금은
설계를 하나 더 추가하는 것보다
실제 테이블을 만드는 쪽으로 넘어가고 있다.
필요한 문제는
실제로 만들면서 다시 만나면 된다.