TL;DR

  • 아키텍처는 판단 가능한 시간 범위 안에서 좋은 결정을 쉽게 만드는 일이며, 적절한 선택은 조직의 규모와 제약, 기술 환경에 따라 달라짐.
  • 스타트업은 생존과 초기 성과에 집중하고, 은행·오픈 소스 프로젝트·대기업은 각각 감사 추적과 응답 시간, 하위 사용자, 장기 고객의 요구에 영향을 받음.
  • 에이전트 기반 개발 환경에서는 디자인 시스템과 역할 기반 접근 제어(RBAC)처럼 비용이 드는 구조적 선택도 높은 변경 빈도와 복잡성을 줄이는 데 보탬이 됨.
  • Twill의 재플랫폼 작업은 4개월 동안 범위 확대를 엄격히 통제하면서 디자인 시스템과 RBAC를 도입했고, 이후 손으로 작성하던 SQL을 생성형 쿼리로 옮기는 등 구조를 보완함.
  • 에이전트는 시간을 말할 수 있지만 경험하지는 않으므로, 미래의 변화와 그 영향을 고려하는 일은 인간의 책임임.

아키텍처와 판단의 시간 범위

  • 아키텍처의 근본적 역할은 합리적으로 판단할 수 있는 시간 범위 안에서 좋은 결정을 더 쉽게 만드는 일임.
  • 소규모 스타트업은 장기적인 시간 범위를 헤아리기 어려워 아키텍처 투자의 투자 수익률(ROI)이 제한적임.
  • 은행은 감사 추적 요구를, 거래 시스템은 응답 시간 요구를 아키텍처 선택에 반영함.
  • 오픈 소스 프로젝트는 하위 사용자에게 제약을 받으며, 대기업은 장기 고객의 요구에 영향을 받음. Windows와 하위 호환성이 사례임.
  • 아키텍처를 둘러싼 의견 차이는 아키텍처 자체보다 무엇이 합리적인 결정인지, 어떤 시간 범위에서 판단하는지에 관한 경우가 많음.

Google Slides와 API의 시간적 제약

  • 슬라이드 자료를 만들며 Claude Design으로 작업하고 PowerPoint로 내보낸 뒤 Google Slides로 가져오며, Claude in Chrome으로 위치가 어긋난 부분을 정리하고 Claude Code에 수정할 항목을 기록함.
  • 이 과정에서 Google Slides 모바일 앱을 작업하던 수년 전과 같은 문제, 즉 적절한 API의 부재를 다시 마주함.
  • 실시간 편집과 관련된 요인 때문에 모든 기능을 자바스크립트(JS) 계층에 두는 선택이 합리적이었을 수 있음.
  • 당시의 선택은 똑똑한 사람들이 자신들이 가진 맥락과 우선순위에 따라 신중하게 내린 결정이었겠지만, 요즘 Google Docs MCP가 기대에 못 미칠 때마다 그 선택을 떠올리게 됨.
  • 그 결정이 고려한 시간 범위에는 휴대전화와 태블릿의 확산, 해당 기기에서의 실질적인 업무 수행은 물론 MCP의 등장도 포함되지 않았음.

스타트업에서의 선택과 Twill 재플랫폼

  • 성과를 얻고 생존해야 하는 스타트업은 당장의 미래를 생각하며 장기적인 미래가 나타나기를 기대하므로, 유연성을 유지해야 함.
  • 나쁜 선택은 시간이 지나며 문제를 일으킬 수 있지만, 좋은 선택도 정당화하기에는 비용이 너무 클 수 있음.
  • Twill 재플랫폼을 4개월 만에 출시할 때 범위 확대를 엄격히 제한하고 단순성을 유지하며 불필요한 복잡성을 피함.
  • 다만 에이전트 기반 개발과 좋은 결정을 쉽게 만드는 일을 고려해, 비용이 비교적 큰 아키텍처 선택 두 가지는 투자할 가치가 있다고 판단함.

디자인 시스템과 역할 기반 접근 제어

  • 첫 번째 선택은 디자인 시스템 구축임. 테스트와 접근성 규칙을 적용하기 쉬워지고 시각적 일관성이 확보됨.
  • 두 번째 선택은 역할 기반 접근 제어(RBAC) 모델임.
  • 여러 사용자가 같은 플랫폼 데이터를 서로 다른 방식으로 보므로, 회원·후보자·채용 담당자 등이 각각 볼 수 있는 정보를 명확히 구분하는 일이 중요함. 권한을 더 쉽게 파악할 수 있을수록 그 구조의 효과가 커짐.
  • 플랫폼은 요구사항을 찾아가는 과정에서 변화가 잦은 영역이므로, 유형을 추가하거나 항목을 이동하기 쉽게 만들 필요가 있음. 실제로 이러한 변화가 발생함.
  • 새 유형을 쉽게 추가하고 테이블에 한 줄을 넣으면 hasPermission()이 참을 반환하도록 설계함.
  • 보안 고려 사항이 핵심인 영역이므로, 정돈되고 이해하기 쉬운 구조가 보안 규칙을 적용하는 데 유리함.

에이전트 기반 개발과 인간의 책임

  • 에이전트 기반 개발 이전에는 디자인 시스템과 RBAC 중 어느 쪽도 비용을 정당화하기 어려웠을 것임.
  • 에이전트 기반 개발 환경에서는 변경이 잦고 복잡해질 가능성이 높은 영역에서 이 두 선택이 기대보다 훨씬 적은 문제를 일으키는 효과를 확인함.
  • 다른 영역에서 구조적 문제가 나타나자 손으로 작성하던 SQL을 생성형 쿼리로 옮기는 등 비슷한 작업을 추가함.
  • 에이전트가 시간 범위를 압축하고 패턴을 맹목적으로 따를 수 있다는 논점도 있지만, 더 중요한 질문은 에이전트에게 무엇이 합리적인 결정인지임.
  • 인간은 과거를 되살리고 미래의 자신을 상상하는 이른바 정신적 시간 여행 능력을 지니며, 이 능력은 다른 동물 대부분에게 없거나 매우 드묾.
  • 에이전트는 시간에 관해 이야기하지만 시간을 경험하지는 않음.
  • 인간은 과거에 무슨 일이 있었는지만 아는 것이 아니라, 막을 수 있었던 일이 실제로 벌어진 순간을 감각적으로 느끼며, 다음에 일어날 일과 우리가 만든 결과를 안고 살아갈 사람들에게 관심을 둠.
  • 미래와 그 안에서 바뀔 가능성을 추론하는 능력은 인간의 몫이며, 따라서 그 책임도 인간에게 있음.