TL;DR

  • 에이전트 코딩으로 UI와 기능 변경은 빠르게 되돌릴 수 있지만, 데이터 손실은 배포로 복구할 수 없어 데이터 계층의 결정에는 더 많은 숙고가 필요함.
  • 레이아웃·기능·번역은 테스트와 배포를 거쳐 빠르게 반복 수정할 수 있으며, 잘못된 판단을 바로잡는 비용이 낮음.
  • 소프트 삭제, 마이그레이션의 down() 메서드, 백업은 코드 변경을 되돌릴 뿐 실제 데이터 손실을 복구하지 못하며, 이벤트 소싱도 기록하지 않은 이벤트는 복원할 수 없음.
  • 저장할 데이터와 형식, 마이그레이션, 백업, 복구, 개인정보 보존 기간은 기존 데이터에 미치는 영향을 따져야 하는 일방통행문임.
  • 사용자가 제공한 데이터는 앱의 핵심 자산으로, 잃어버리면 다시 만든 앱은 로그인 화면만 있는 빈 껍데기임.

나머지 모든 요소에는 실행 취소가 있음

  • 에이전트 코딩으로 기능은 며칠 만에, 디자인은 몇 시간 만에 구현할 수 있으며, 레이아웃 변경·템플릿 수정·흐름 재구성도 1년 전에는 상상하기 어려웠던 속도로 진행됨.
  • 대부분의 작업을 휴대전화로 원격 코딩 환경에 접속해 진행하며, 변경 사항을 되돌릴 수 있으면 반복 작업의 비용이 낮음.
  • 실제 사용에서 레이아웃이 적절하지 않으면 다음 버전을 배포하고, 버그나 잘못된 번역은 수정 후 다시 배포하며, 혼란을 줄이지만 사용성을 떨어뜨리는 재설계도 다시 배포해 고칠 수 있음.
  • 진행 방향이 마음에 들지 않는 기능은 취소할 수 있으며, 브랜치는 그대로 두어도 문제가 되지 않음.
  • 모든 변경은 테스트 스위트를 거치며 병합 전에 차이점도 확인함. 달라진 점은 잘못된 판단의 비용으로, 실제 사용자가 화면을 혼란스러워하면 몇 분 만에 수정할 수 있음.
  • 따라서 빠르게 작업하고, 반복하고, 방향을 바꾸고, 중간에 결정을 바꾸며, 배포와 재배포를 거듭하고, 끝내지 않은 변경도 되돌림. 새 버전을 만드는 비용이 낮아 세 가지 버전을 시도하는 일이 일반적인 작업 방식이 됨.

데이터에는 실행 취소가 없음

  • 데이터 계층을 다룰 때는 작업을 멈춤. 휴대전화로 처리할 수 없으며, 방해받지 않고 생각할 수 있는 상태로 책상 앞 노트북에 앉아야 함. 이 계층의 실수는 다음 배포로 되돌릴 수 없기 때문임.
  • 소프트 삭제, 적절한 down() 메서드를 둔 마이그레이션, 전날의 백업 같은 코딩 패턴은 충격을 줄이지만, 데이터 손실 자체가 아니라 코드 변경을 되돌림.
  • 마이그레이션이 열을 비우면 down()으로 열은 다시 만들 수 있지만 내용은 빈 상태임.
  • 이벤트 소싱(event sourcing)은 현재 상태 대신 모든 변경을 이벤트(OrderPlaced, AddressChanged 등)로 저장하고, 그 이벤트로 테이블을 구성하는 방식임. 잘못된 마이그레이션으로 테이블이 망가져도 테이블을 버리고 이벤트를 새 테이블에 다시 적용할 수 있음.
  • Spatie의 이벤트 소싱 패키지에는 이를 위한 event-sourcing:replay 명령이 있으며, 데이터 계층의 실질적인 실행 취소에 가장 가까운 방식임.
  • 다만 일방통행문은 이벤트로 옮겨갈 뿐 사라지지 않음. 추가 전용 로그에 잘못 설계된 이벤트가 들어가면 영원히 남고, 기록하지 않은 이벤트는 재생할 수 없음. 사용자가 계정 삭제를 요청할 때 사용자의 모든 행동을 담은 추가 전용 로그는 마지막으로 원하는 것임.
  • 데이터는 데이터임. 보유하지 않은 데이터는 재현할 수 없음.
  • Snapkin에서는 아침 식사 접시 위의 흰 덩어리가 요거트가 아니라 스키르(skyr)라고 한 번 알려주면 이를 기억해 이후에도 사용함. 질문 화면은 오후 만에 다시 만들 수 있지만 답변은 재구성할 수 없음. 스키르를 먹은 사람만 그 답을 알고 있으며, 앱에는 한 번만 전달했기 때문임.

일방통행문

  • Jeff Bezos는 2015년 Amazon 주주 서한에서 결정을 두 종류로 나눔.

어떤 결정은 중대한 결과를 낳고 되돌릴 수 없거나 거의 되돌릴 수 없는 일방통행문임. 이런 결정은 체계적이고 신중하며 천천히, 충분한 숙고와 협의를 거쳐 내려야 함. 문을 통과한 뒤 보이는 것이 마음에 들지 않아도 이전 상태로 돌아갈 수 없음. […] 하지만 대부분의 결정은 그렇지 않음. 바꿀 수 있고 되돌릴 수 있는 양방향문임.

  • 에이전트 코딩은 구축하는 것 대부분을 양방향문으로 바꿈. 레이아웃·기능·번역은 시도한 뒤 마음에 들지 않으면 되돌릴 수 있음.
  • Bezos는 양방향문을 일방통행문처럼 신중하게 다뤄 회사가 느려지는 실수를 경고함. 에이전트 코딩 환경에서는 그 반대의 실수가 우려됨. 주변의 모든 작업이 빠르게 진행되기 때문에 일방통행문도 양방향문 속도로 통과할 수 있음.
  • 데이터 계층에는 일방통행문이 존재함.
  • 마이그레이션
  • 저장할 데이터와 저장 형식
  • 데이터 구조
  • 백업
  • 복구
  • 모든 데이터 마이그레이션과 데이터를 저장할지, 저장한다면 어떻게 저장할지 결정해야 하는 순간마다 작업을 멈춤. 이제 시간과 사고의 대부분은 UI, UX, 기능, 다음 작업 목록이 아니라 이런 결정에 들어감.
  • UI·UX·기능은 유동적으로 유지할 수 있으며, 사용자의 의견이나 요구에 따라 바꿀 수 있음. 데이터는 신성한 자산임.
  • 데이터 결정이 영구적이라는 뜻은 아님. 열 형식을 바꾸거나 테이블을 분리하거나 필드를 다른 곳으로 옮길 수 있음. 그러나 모든 변경은 이미 존재하는 행에 영향을 주므로 데이터가 사라지지 않는지, 모든 변경이 의도된 것인지 확인하는 데 더 많은 노력과 숙고가 필요함.
  • 레이아웃 변경은 새 배포로 끝나지만 데이터 변경에는 계획이 필요함. 기존의 모든 행에 어떤 일이 생기는지, 변경이 제대로 적용됐는지 어떻게 확인하는지, 문제가 생기면 어떻게 되돌리는지를 정해야 함.
  • 저장하기로 결정한 필드는 보호하고 백업한 뒤 결국 다시 삭제해야 하는 대상이 됨. 저장하지 않기로 한 필드는 영원히 사라지며, 지난 화요일에 무엇을 했는지 사람들에게 다시 물을 수 없음.

개인정보 보호와 보존 기간도 서두르지 않음

  • 개인정보 보호와 데이터 보존에는 보유 기간, 접근 권한, 계정 삭제 시 처리 방식, 백업까지 삭제 범위에 포함되는지, 삭제하기로 약속한 데이터가 남아 있는 백업을 어떻게 볼지 등의 결정이 따름.
  • 어느 질문도 빠른 답이 없으며, 에이전트가 30초 만에 마이그레이션을 작성한다고 쉬워지지 않음. 느린 부분은 마이그레이션 작성이 아니라 기존 데이터에 미칠 영향을 숙고하는 일임.

데이터가 곧 애플리케이션임

  • 앱에서 UI, 웹사이트, 모바일 앱, 서버, 인프라를 모두 제거해도 이를 다시 만들 수 있으며, 현재 도구를 사용하면 그 어느 때보다 빠르게 구축할 수 있음.
  • 사용자가 제공한 데이터는 그렇게 다시 만들 수 없음. 데이터를 잃으면 재구축한 것은 로그인 화면만 있는 빈 껍데기가 됨.
  • 따라서 레이아웃은 휴대전화로 기꺼이 반복 수정하지만, 마이그레이션은 책상 앞에 앉을 때까지 미룸.