원샷 SaaS 대체품은 그만, 매일 쓰는 내부 도구 만들기

메타데이터

• 원문 제목: [한영자막] 엉성한 원샷 SaaS 대체품은 이제 그만 만드세요
• URL: https://www.youtube.com/watch?v=3jtlfKL-N4A
• 채널: Tech Bridge
• 원본 게시일: 2026-10-18
• 정리일: 2026-10-19
• 영상 길이: 약 13분 21초
• 주제: 에이전트 기반 내부 도구 개발, 제품 완성도, 사용자 경험, 검증

---

📌 핵심 질문 / 핵심 논점

==에이전트가 만든 소프트웨어가 실제로 작동하는 데서 멈추지 않고, 매일 꺼내 쓰고 싶은 제품이 되려면 무엇을 더해야 하는가?== 좋은 코드베이스와 반복 가능한 패턴을 마련하고, 에이전트가 기본적으로 놓치는 제품 경험을 구체적으로 요구하며, 팀의 기준을 스킬로 고정하고, 실제 인프라에서 기능을 끝까지 검증해야 한다.

• Railway의 사내 마케팅 도구는 웹 콘텐츠·이메일·소셜 게시·미디어·외부 제작자 CRM·작업·런칭 계획을 하나로 모았다.
• 자동 저장, 실시간 협업, 낙관적 업데이트, 실행 취소, 보관, URL 상태, 무한 스크롤은 작동하는 기능과 매일 쓰기 좋은 제품 사이를 메운다.
• 기존 화면을 참고 사례로 지정하고 제품 의견을 에이전트 스킬로 축적하면 새 기능의 일관성을 높일 수 있다.
• 빌드와 테스트의 통과만으로는 사용자 경험을 보증하지 못하며, 실행 중인 인프라에서 실제 경로를 직접 사용해야 한다.

내부 도구를 SaaS로 대체하는 비용 장점만 바라보면 CRUD 화면을 한 번 생성하는 데 그치기 쉽다. 도구를 매일 쓰는 사람에게는 저장 안정성, 반응 속도, 취소와 복구, 탐색 편의, 화면 간 일관성이 제품의 일부다. 에이전트는 이런 세부를 알아서 완성하지 않으므로, 만들고 싶은 경험을 명시하고 끝까지 확인하는 작업이 필요하다.

1. 원샷 구현과 매일 쓰는 제품 사이의 간격

1.1. SaaS 대체를 넘어 Railway 내부 운영 도구로 확장

1. 작동하는 소프트웨어와 쓰고 싶은 소프트웨어는 다르다

   1. 원샷(one-shot)으로 기능이 동작하더라도 실제로 사용하고 싶은 수준의 제품과는 큰 간격이 남는다.
   2. 좋은 제품은 기능이 있다는 사실에 그치지 않고 다듬어져 있으며, 사용감이 좋고 쓰는 즐거움을 준다.

2. 여러 업무 흐름을 하나의 도구로 묶었다

   1. Railway 웹사이트 콘텐츠와 변경 로그(changelog), 블로그를 관리하고 이메일 발송과 여러 소셜 플랫폼 동시 게시를 지원한다.
   2. 웹사이트 미디어 관리, 외부 제작자와의 협업을 위한 미니 CRM, 작업 추적, 여러 일정의 조율과 런칭 계획, 캘린더를 한곳에 모았다.
   3. 댓글과 실시간 편집도 더해 콘텐츠 작업을 함께 진행할 수 있게 했다.

1.2. 배포 환경과 관점의 유효 기간

1. 에이전트로 구축하고 Railway에서 운영했다

   1. 에이전트가 내부 도구를 만들었고, 애플리케이션은 Railway에서 자동 배포되도록 구성했다.
   2. 앱뿐 아니라 버킷, 데이터베이스, 서버까지 Railway 인프라에 올려 개발과 운영 환경을 한 흐름으로 다뤘다.

2. 빠르게 변하는 기술 환경을 전제로 삼았다

   1. 녹화 시점은 2026년 가을, 10월이며 에이전트와 모델의 역량은 몇 달 만에도 달라질 수 있다고 선을 그었다.
   2. Edinburgh 야외 벤치에서 진행하는 색다른 발표라는 가벼운 도입 뒤에, 경험에서 얻은 원칙도 시대에 따라 바뀔 수 있다는 점을 덧붙였다.

2. 기술 스택보다 일관된 코드베이스가 중요하다

2.1. 에이전트가 기존 패턴을 재사용하게 만들기

1. 언어와 프레임워크의 중요성은 상대적이다

   1. 에이전트가 여러 언어와 프레임워크를 다룰 수 있다는 점에서 기술 스택만으로 결과가 결정되지는 않는다.
   2. 그러나 실제로 계속 사용할 도구를 만들 때는 코드베이스의 구조와 추상화 품질이 에이전트 결과의 일관성에 큰 영향을 준다.

2. 기존 추상화와 패턴이 재발명을 막는다

   1. 구조가 탄탄하면 새 기능을 추가할 때마다 에이전트가 같은 문제를 새 방식으로 풀거나 새로운 규칙을 도입할 필요가 없다.
   2. 기존 사례를 따라 구현하므로 새 화면과 기능이 이미 있는 부분과 비슷한 품질과 동작을 유지하기 쉽다.

2.2. 필요할 때는 검증된 제품을 선택한다

1. 웹 개발에는 익숙한 일관된 스택을 사용한다

   1. 특정 언어가 만능이라는 주장보다, 코드베이스를 제대로 구조화하고 반복 가능한 선택을 유지하는 것이 우선이다.
   2. 웹 작업에서는 자신의 검증된 기본 스택을 일관되게 활용하는 편이 에이전트가 따를 패턴을 쌓는 데 유리하다.

2. 콘텐츠 관리에는 Payload를 고려한다

   1. 콘텐츠 중심 제품에는 Payload를 추천할 만큼 사용 경험과 추상화가 만족스러웠다.
   2. 여러 CMS를 비교하는 긴 탐색을 거쳤으며, 직접 만들 능력이 있더라도 CMS를 처음부터 구현하는 선택은 피했다.

3. 매일 쓰는 제품을 만드는 상호작용 패턴

3.1. 자동 저장과 동시 편집으로 작업을 보호한다

1. 자동 저장은 문서 편집기의 기본 기대치다

   1. 매번 저장 버튼을 누르게 하지 말고 입력 중에도 백그라운드에서 진행 상황을 자동 저장하도록 요청한다.
   2. 저장은 비차단(non-blocking)으로 처리해 사용자가 입력을 계속할 수 있게 하고, 미저장 변경이 있을 때는 브라우저 탭을 닫지 못하게 하는 보호 장치도 둘 수 있다.

2. 실시간 협업으로 여러 사용자의 편집을 지원한다

   1. 동시 편집을 추가하면 여러 사람이 같은 문서나 작업물에 협력할 수 있다.
   2. 에이전트는 이 기능을 구현할 수 있지만 먼저 동작 방식을 검토하고 명시적으로 요청해야 한다. 구현 후 실시간 기능을 얻는 데 7억 토큰이 들었다는 과장 섞인 농담으로 비용과 반복 과정을 표현했다.

3.2. 낙관적 업데이트와 실행 취소로 반응성을 높인다

1. 낙관적 업데이트는 기다리는 느낌을 줄인다

   1. 작업을 시작할 때마다 로딩 스피너를 보여 주기보다 성공한 것처럼 화면을 먼저 갱신하고, 실제 변경은 백그라운드에서 서버와 동기화한다.
   2. 동기화가 실패하면 화면 상태를 롤백하고 사용자에게 실패를 알린다. 모든 작업에 무조건 적용하지 말고 적절한 경우를 골라 사용한다.
   3. 즉각적인 피드백은 화면을 더 빠르고 민첩하게 느끼게 만든다. 에이전트에게 적용 대상과 계획을 함께 정해 달라고 요청할 수 있다.

2. 되돌릴 수 있는 삭제는 실수를 복구한다

   1. 기본 삭제 흐름은 버튼을 누르고 확인 대화상자에서 확정한 뒤 데이터를 지우는 방식이지만, 사용자가 마음을 바꿀 기회를 주지 않는다.
   2. 삭제 직후 화면에서 항목을 숨기고 잠시 취소 기회를 제공한 다음, 시간이 지나면 실제 삭제를 수행한다.
   3. 사용자가 실행 취소를 누르면 항목을 되돌린다. 이 방식은 UI를 먼저 바꾸고 실제 작업을 지연하는 낙관적 처리의 한 형태다.

3.3. 보관, URL 상태, 무한 스크롤로 탐색을 다듬는다

1. 삭제와 별도로 보관 기능을 둔다

   1. 검색이나 화면에서 항목을 감추고 싶을 때마다 영구 삭제를 강요하면 사용자가 불필요하게 데이터를 잃을 수 있다.
   2. 보관(archive)과 보관 해제(unarchive)를 제공하면 항목을 작업 화면이나 검색 결과에서 감추면서 나중에 다시 복구할 수 있다.

2. 필터와 정렬 조건을 URL에 보존한다

   1. 레코드 목록의 필터와 정렬 조건처럼 중요한 상태를 URL에 담으면 현재 화면의 맥락을 주소로 표현할 수 있다.
   2. 동료에게 링크를 보내면 같은 필터·정렬 상태를 그대로 전달해 무엇을 보라는지 쉽게 공유할 수 있다.

3. 반복적인 페이지 이동 대신 무한 스크롤을 제공한다

   1. 목록이 길다고 계속 더 보기나 다음 페이지를 클릭하게 하지 말고 스크롤에 따라 데이터를 이어서 불러오게 한다.
   2. 끝에 도달했음을 자연스럽게 보여 주면 사소해 보이는 차이가 매일 반복되는 사용 경험에서 크게 작용한다.

4. 에이전트에 제품 기준을 전달하는 방법

4.1. 기존 화면을 구체적인 참고 사례로 지정한다

1. 좋은 화면을 한 번 정의하고 재사용한다

   1. 새 기능을 만들 때 기존 페이지를 UI뿐 아니라 데이터 조회 방식, 화면 흐름, 전체 구조의 참고 대상으로 지정한다.
   2. 같은 개념을 다루는 목록이라면 생성·조회·수정·삭제(CRUD) 동작과 화면을 서로 비슷하게 유지해 앱의 품질 기준을 재사용한다.

2. 참고 지시는 결과를 개선하지만 보장은 아니다

   1. 기존 화면을 사용하라고 시켜도 에이전트가 지시를 따르지 않는 경우가 있으며 모델이 때때로 엉뚱하게 행동한다고 느낄 수 있다.
   2. 그럼에도 참고 페이지를 지정했을 때 성공률과 화면 간 일관성이 더 높았으므로, 지시와 실제 결과 확인을 함께 수행한다.

4.2. 팀의 의견을 에이전트 스킬로 축적한다

1. 제품에 대한 의견을 재사용 가능한 규칙으로 만든다

   1. 화면, 상호작용, 오류 메시지에 대한 팀의 판단을 에이전트 스킬(agent skills)에 적으면 이후 기능 개발에서 반복해 적용할 수 있다.
   2. 요청마다 같은 기준을 다시 설명하는 대신, 스킬을 구현 지침으로 제공해 에이전트가 일관된 방향을 따르도록 한다.

2. 서로 다른 세 종류의 스킬을 활용한다

   1. 첫 번째 디자인 엔지니어링 스킬은 UI와 타이포그래피, 레이아웃, 오류 메시지를 개선하는 데 쓰였다.
   2. 두 번째 디자인 엔지니어링 스킬은 애니메이션과 그 밖의 세부적인 시각 반응을 다듬는 데 쓰였다.
   3. Railway 에이전트 스킬은 버킷·데이터베이스·앱·서버 등 Railway 자원을 이해하고 배포하도록 도왔다.

5. 기능 완료의 기준은 실제 엔드투엔드 검증이다

5.1. 빌드와 테스트 통과만으로는 충분하지 않다

1. 에이전트의 완료 보고와 실제 경험은 다를 수 있다

   1. 기능 구현 뒤 빌드와 테스트가 통과했다고 보고해도 사용 흐름에서 깨지는 경험이 남을 수 있다.
   2. 코드 검사 결과만으로 실제 사용자가 겪는 문제까지 확인했다고 간주하지 않는다.

2. 실패를 드러내고 수정하는 반복 루프를 만든다

   1. 기능을 실제로 실행하면 에이전트가 구현하고, 직접 사용하고, 실패를 발견하고, 수정하는 과정을 반복할 수 있다.
   2. 검증 루프를 갖추면 기능 완성도가 크게 달라진다. 컴퓨터 사용(computer use) 역량이 좋아진 뒤 이러한 반복이 특히 효과적이었다.

5.2. 실행 중인 인프라에서 실제 경로를 끝까지 사용한다

1. 에이전트에게 검증을 명시적으로 요구한다

   1. 새 기능을 추가한 뒤 실제 사용 흐름을 끝까지 확인하라고 요청한다.
   2. 단위 테스트나 빌드 결과에 머물지 말고 실행 중인 인프라를 이용해 기능을 엔드투엔드(end-to-end)로 시험하도록 한다.

2. 명시적 요청이 빠진 단계를 보완한다

   1. 에이전트는 실제 서비스 환경에서 시험할 능력이 있지만, 그 능력을 활용하도록 검증 범위와 기대 동작을 알려야 한다.
   2. 좋은 코드 구조, 분명한 제품 경험 요구사항, 재사용 가능한 스킬, 실제 검증을 결합하면 빠르게 만들면서도 안정적이고 일관된 내부 도구를 얻을 수 있다.

주요 발언 모음

“작동하는 소프트웨어와 내가 실제로 사용할 소프트웨어 사이에는 큰 간격이 있다.”

“탄탄한 추상화가 있는 코드베이스에서는 에이전트가 매번 바퀴를 다시 발명하지 않고 기존 패턴을 따른다.”

“기능이 동작한다고 끝내지 말고, 실제 인프라에서 엔드투엔드로 직접 사용해 검증해야 한다.”

“다듬어지고 쓰는 즐거움을 주는 내부 도구를 만들면 회사의 SaaS 계층이 될 수 있다.”

핵심 데이터 & 수치

• 원본 게시일: 2026-10-18에 게시된 영상이다.
• 길이: 801초, 약 13분 21초 분량이다.
• 녹화 시점: 2026년 가을, 10월이라고 밝혔다.
• 실시간 편집 구현: 기능 구현 후 실시간 동작을 확보하는 데 7억 토큰이 들었다는 표현은 과장된 농담으로 제시됐다.
• 내부 시스템 범위: 웹 콘텐츠, 변경 로그, 블로그, 이메일, 소셜 게시, 미디어, 미니 CRM, 작업·런칭 계획, 캘린더, 댓글, 실시간 편집을 포함한다.
• 운영 기반: 앱과 데이터베이스, 버킷, 서버를 포함한 내부 도구 전반을 Railway에서 운영하고 자동 배포했다.

결론 및 시사점

1. 내부 SaaS 대체품을 만들 때 기능 목록을 복제하는 데 그치지 말고 매일 반복되는 실제 업무 흐름과 사용감을 설계한다.
2. 에이전트가 새 패턴을 즉흥적으로 만들지 않도록 코드베이스의 추상화와 기존 화면의 사례를 정돈한다.
3. 자동 저장·복구, 동시 편집, 즉각적 피드백, 취소, 보관, 공유 가능한 URL, 자연스러운 목록 탐색을 구체적으로 요청한다.
4. 반복해서 적용할 제품 기준은 에이전트 스킬로 만들어 다음 기능에도 유지한다.
5. 완료 조건에 실제 인프라 기반의 엔드투엔드 사용 검증을 포함하고, 실패를 수정할 때까지 반복한다.

20줄 핵심 요약

• 에이전트가 만든 기능이 동작한다는 사실만으로 매일 쓰고 싶은 제품이 완성되지는 않는다.
• Railway 내부 도구는 웹 콘텐츠, 변경 로그, 블로그, 이메일, 소셜 게시를 한곳에서 관리한다.
• 외부 제작자 CRM과 미디어 관리 기능이 콘텐츠 운영 흐름에 함께 포함됐다.
• 작업 추적과 런칭 계획, 캘린더, 댓글, 실시간 편집이 팀 협업을 지원한다.
• 앱과 관련 인프라를 Railway에 두고 변경 내용을 자동 배포했다.
• 기술 스택의 유행보다 구조가 정돈된 코드베이스와 재사용 가능한 추상화가 중요하다.
• 기존 패턴을 제공하면 에이전트가 기능마다 새로운 규칙을 만들 필요가 줄어든다.
• 콘텐츠 중심 웹 제품에는 직접 CMS를 만들기보다 Payload 같은 검증된 선택지를 활용할 수 있다.
• 문서 편집기에는 저장 버튼을 반복해서 누르지 않아도 되는 자동 저장이 기본 기대치다.
• 미저장 상태에서 탭을 닫지 못하게 하면 작업 손실을 한 겹 더 막을 수 있다.
• 실시간 협업은 여러 사용자의 동시 편집을 지원하지만 명시적으로 요구해야 한다.
• 낙관적 업데이트는 성공 상태를 먼저 보여 주고 서버 동기화 실패 시 화면을 롤백한다.
• 모든 상황에 낙관적 업데이트를 적용하지 말고 적합한 작업을 선택해야 한다.
• 삭제 직후 잠시 실행 취소를 제공하면 사용자의 실수를 복구할 수 있다.
• 보관과 보관 해제를 지원하면 항목을 숨기면서도 영구 삭제를 피할 수 있다.
• 필터와 정렬 상태를 URL에 저장하면 동료와 동일한 화면 맥락을 공유할 수 있다.
• 무한 스크롤은 반복적인 다음 페이지 클릭 없이 목록을 자연스럽게 탐색하게 한다.
• 기존 페이지를 참고 사례로 지정하면 새 기능의 UI와 데이터 흐름이 더 일관돼진다.
• 제품 판단을 디자인·애니메이션·인프라 에이전트 스킬로 축적하면 기준을 반복해서 적용할 수 있다.
• 실제 인프라에서 엔드투엔드로 사용하고 실패를 고칠 때 비로소 기능 완료를 확인할 수 있다.