2025년 5월 31일·7분
AI 개발로 웹·모바일·백엔드 경계가 흐려지는 이유
AI 도우미가 UI, API, 데이터 로직을 함께 생성하면서 웹·모바일·백엔드 작업이 겹칩니다. 무엇이 변하고 있으며 팀은 어떻게 적응하는지 알아보세요.
AI 도우미가 UI, API, 데이터 로직을 함께 생성하면서 웹·모바일·백엔드 작업이 겹칩니다. 무엇이 변하고 있으며 팀은 어떻게 적응하는지 알아보세요.
수년간 “웹”, “모바일”, “백엔드”는 단순한 라벨이 아니라 팀이 소프트웨어를 구축하는 방식을 규정하는 경계였습니다.
웹은 보통 브라우저에서 실행되는 모든 것을 뜻했습니다: 페이지, 컴포넌트, 상태 관리, 화면을 상호작용하게 만드는 UI 로직. 웹 팀은 빠른 반복, 반응형 레이아웃, 브라우저 간 호환성에 맞춰 최적화했습니다.
모바일은 네이티브 iOS와 Android 앱(그리고 이후의 크로스플랫폼 프레임워크)을 의미했습니다. 모바일 개발자는 앱스토어 출시, 디바이스 성능, 오프라인 동작, 푸시 알림, 플랫폼별 UI 패턴에 신경 썼습니다.
백엔드는幕后의 서비스였습니다: 데이터베이스, 비즈니스 규칙, 인증, 통합, 큐, 그리고 웹·모바일 양쪽에 데이터를 공급하는 API. 백엔드 작업은 신뢰성, 데이터 일관성, 확장성, 공통 로직에 집중했습니다.
이 분리는 조정 오버헤드를 줄여줬습니다. 각 레이어가 고유한 도구, 배포 주기, 전문 지식을 필요로 했기 때문입니다. 팀도 종종 이런 현실을 반영했죠:
또한 소유권도 분명했습니다: 로그인 화면이 깨지면 “웹” 또는 “모바일” 문제였고, 로그인 API가 실패하면 “백엔드” 문제였습니다.
경계가 사라진다는 뜻이 아닙니다. 다만 작업이 더 이상 깔끔하게 분할되지 않는다는 뜻입니다.
예를 들어 하나의 제품 변경—"온보딩 개선"—이 UI, API 형태, 데이터 추적, 실험까지 하나의 번들로 걸치는 일이 늘어납니다. 경계는 여전히 존재하지만 덜 엄격하게 느껴집니다: 더 많은 공유 코드, 더 많은 공유 도구, 같은 사람이 여러 레이어를 더 자주 수정합니다.
오랫동안 팀은 레이어별로 작업을 조직했습니다: “웹이 페이지를 만들고”, “모바일이 화면을 만들고”, “백엔드가 엔드포인트를 추가한다”, “데이터가 테이블을 만든다.” 각 레이어가 다른 도구와 깊은 컨텍스트, 많은 수동 연결을 요구할 때는 이 분리가 합리적이었습니다.
AI 보조 개발은 작업 단위를 레이어에서 기능으로 위로 밀어 올립니다.
AI 도구에 “결제 화면을 추가해”라고 요청하면 보통 하나의 UI 파일에 멈추지 않습니다. 좋은 프롬프트는 자연스럽게 의도를 포함합니다: 사용자가 무엇을 하려는지, 어떤 데이터가 필요한지, 성공/실패 시 어떻게 처리되는지, 어떻게 저장되는지.
그 결과 사람들은 다음과 같은 프롬프트로 이동합니다:
AI 출력은 종종 번들로 도착합니다: UI 컴포넌트, API 라우트, 유효성 검사 규칙, 데이터베이스 변경—때로는 마이그레이션 스크립트와 기본 테스트까지. 이는 AI가 “너무 똑똑한” 것이 아니라 기능이 실제로 작동하는 방식을 따르기 때문입니다.
이것이 AI가 레이어 지향적이기보다 기능 지향적인 이유입니다: 클릭 → 요청 → 로직 → 저장 → 응답 → 렌더링이라는 사용자 스토리를 따라 생성합니다.
작업 계획은 “레이어별 티켓”에서 “명확한 수용 기준을 가진 하나의 기능 슬라이스”로 이동합니다. 예전처럼 세 번의 핸드오프(웹 → 백엔드 → 데이터) 대신, 팀은 하나의 소유자가 경계를 넘어 기능을 주도하고, 위험이 큰 부분은 전문가가 리뷰하는 방식을 목표로 합니다.
실무 결과는 조정 지연 감소지만, 명확성에 대한 기대치가 높아진다는 것입니다. 기능이 잘 정의되지 않으면(엣지 케이스, 권한, 에러 상태) AI는 겉보기에는 완성된 코드처럼 보이지만 실제 요구사항을 빠뜨린 코드를 기꺼이 생성합니다.
AI 보조 개발은 “분리된 스택”(웹용, 모바일용, 백엔드용)에서 공유 빌딩 블록으로의 이동을 가속화합니다. 코드가 빠르게 초안화되면 병목은 일관성입니다: 모든 채널이 같은 규칙, 같은 데이터 형태, 같은 UI 패턴을 사용하나요?
팀들은 TypeScript를 표준으로 삼는 경우가 늘고 있습니다. 타입은 API 응답을 설명하고 백엔드 유효성 검증을 구동하며 프런트엔드 폼을 구동할 수 있습니다.
도구도 수렴합니다: 포맷팅, 린팅, 테스트가 통합되어 변경사항이 제품의 한 부분을 통과시키는 동안 다른 부분을 깨뜨리지 않도록 합니다.
모노레포는 공유 코드를 현실적으로 만듭니다. 앱 간 로직을 복사하는 대신 재사용 가능한 패키지를 추출합니다:
이것은 AI가 여러 곳에서 코드를 생성할 때 발생하는 일탈을 줄입니다. 단일 공유 패키지는 생성된 코드를 정렬 상태로 유지할 수 있습니다.
크로스플랫폼 프레임워크와 디자인 시스템은 UI 레이어에서 같은 아이디어를 밀어붙입니다: 컴포넌트를 한 번 정의하고 웹과 모바일에서 재사용합니다. 별도의 앱이 남아 있더라도 공유 토큰(색상, 간격, 타이포그래피)과 컴포넌트 API가 기능을 일관되게 구현하기 쉽게 합니다.
또 다른 주요 변화는 OpenAPI 같은 명세로부터 API 클라이언트를 자동생성하는 것입니다. 각 플랫폼에서 네트워크 호출을 수동으로 작성하는 대신, 타입이 있는 클라이언트를 생성해 웹, 모바일, 백엔드 계약을 동기화 상태로 유지합니다.
경계가 흐려질 때, “스택”은 기술보다는 공유 원시(타입, 스키마, 컴포넌트, 생성된 클라이언트)에 관한 것이 됩니다. 이들로 기능을 엔드-투-엔드로 적은 핸드오프와 놀라움 없이 출시할 수 있습니다.
AI 보조 개발은 빠르게 누락된 컨텍스트를 채워주기 때문에 사람을 자신의 ‘레인’ 밖으로 밀어냅니다.
프론트엔드 개발자가 “ETags와 레이트 리밋으로 캐싱을 추가해”라고 요청하면 작동 가능한 서버측 변경을 받을 수 있고, 백엔드 개발자는 “이 화면을 더 빠르게 느껴지게 해”라고 요청하면 스켈레톤 로딩, 낙관적 UI, 재시도 동작을 건드리는 제안을 받을 수 있습니다.
AI가 미들웨어나 API 게이트웨이 규칙을 몇 초에 초안화할 수 있게 되면 “백엔드 코드를 안 씁니다”라는 마찰이 줄어듭니다. 그 결과 프런트엔드 작업의 모습이 바뀝니다:
Cache-Control, ETags, 클라이언트 측 캐시 무효화 추가가 UI 성능 작업의 일부가 됩니다.백엔드 결정은 사용자 경험을 규정합니다: 응답 시간, 부분 실패, 어떤 데이터를 먼저 스트리밍할 수 있는가. AI는 백엔드 개발자가 UX를 고려한 변경(예: 부분 결과 반환, 커서 기반 페이지네이션, 요약 응답 제공)을 제안하고 구현하기 쉽게 만듭니다.
페이지네이션은 경계 흐림의 좋은 예입니다. API는 안정적인 커서와 예측 가능한 정렬을 필요로 하고, UI는 “더 이상 결과 없음”, 재시도, 빠른 뒤로/앞으로 네비게이션을 처리해야 합니다.
유효성 검사도 마찬가지입니다: 서버측 규칙이 권위적이어야 하지만 UI는 즉각적인 피드백을 위해 이를 반영해야 합니다. AI는 종종 양쪽을 함께 생성합니다—공유 스키마, 일관된 에러 코드, 폼 필드에 매핑되는 메시지.
에러 처리도 크로스-레이어가 됩니다: 429(레이트 제한)는 단순 상태 코드가 아니라 UI 상태(“30초 후 다시 시도하세요”)를 유도하고 백오프 전략을 트리거해야 할 수 있습니다.
“프런트엔드” 작업에 API 수정, 캐싱 헤더, 인증 엣지 케이스가 들어가면, 옛 경계 기준에 근거한 추정은 부정확해집니다.
팀은 기능 결과물(예: “검색이 즉각적이고 신뢰할 수 있게 느껴짐”)으로 소유권을 정의하고 체크리스트에 크로스-레이어 고려사항을 포함할 때 더 잘합니다. 다른 사람이 다른 부분을 구현하더라도 기능 소유자가 모든 조각이 함께 출시되도록 보장하는 식입니다.
Backend-for-Frontend(BFF)는 특정 클라이언트 경험에 맞춘 얇은 서버 레이어입니다—대개 웹용과 모바일용 각기 하나씩. 모든 앱이 동일한 “일반” API를 호출해 기기에서 데이터를 재구성하는 대신, BFF는 UI가 필요로 하는 형태로 이미 맞춘 엔드포인트를 노출합니다.
웹과 모바일 화면은 개념을 공유하지만 세부가 다릅니다: 페이지네이션 규칙, 캐싱, 오프라인 동작, “빠름”의 감각 등. BFF는 각 클라이언트가 정확히 필요한 것을 요청하게 해 일괄적인 타협을 강요하지 않습니다.
제품팀 관점에서는 UI 변경이 작은 BFF 업데이트로 함께 배포될 수 있어 광범위한 플랫폼 계약을 매번 조정할 필요가 없어 출시가 간소화됩니다.
AI 보조 개발로 팀은 점점 UI 요구사항에서 바로 엔드포인트를 생성합니다: “결제 요약은 총액, 배송 옵션, 결제 수단을 한 번의 호출로 필요로 한다.” 이는 화면이나 사용자 여정 중심의 API(즉 UI-형태 API)를 장려합니다.
이는 왕복을 줄이고 클라이언트 코드를 작게 유지한다면 장점입니다. 위험은 API가 현재 UI의 거울이 되어, BFF가 구조 없이 성장하면 향후 재설계 비용이 커진다는 점입니다.
BFF는 개발을 가속화하지만 다음과 같은 중복을 만들 수 있습니다:
좋은 규칙은 BFF는 데이터를 오케스트레이션하고 형태를 잡아야 하며 핵심 비즈니스 행동을 재정의해서는 안 된다는 것입니다.
다음 경우에 BFF를 추가하세요: 복잡한 화면별 조합이 많거나 뷰당 네트워크 호출이 많거나 서로 다른 클라이언트 요구가 계속 충돌할 때.
제품이 작고 UI가 아직 불안정하거나 잘 설계된 API와 가벼운 클라이언트 조합으로 요구를 충족할 수 있다면 BFF는 피하거나 최소화하세요.
BFF를 도입한다면 경계를 일찍 설정하세요: 공통 비즈니스 규칙은 코어 서비스에 두고, BFF는 UI 친화적 집계, 캐싱, 권한 인지 데이터 형태화에 집중하게 하세요.
AI 어시스턴트가 React 컴포넌트, 모바일 화면, 데이터베이스 쿼리를 몇 분 만에 생성할 수 있으면 “코드 작성”은 “코드 리뷰”로 옮겨갑니다. 처리량은 증가하지만, 변경이 UI, API, 데이터 레이어를 가로지를 때 미묘한 실수가 늘어날 위험도 커집니다.
AI는 읽기 쉬운 코드를 산출하는 데 보통 문제 없습니다. 더 높은 가치의 리뷰 질문은 다음과 같습니다:
레이어를 연결할 수 있는 리뷰어의 가치가 단순 스타일을 다듬는 사람보다 커집니다.
반복적으로 문제가 되는 지점에 집중하세요:
빠른 산출에는 더 강한 가드레일이 필요합니다. PR에 가벼운 체크리스트를 두면 리뷰어의 일관성을 유지하고, 자동화 테스트는 인간이 놓치는 것을 잡아냅니다.
좋은 “AI 속도” 보완책 예시:
실무 패턴은 도메인 전문가(제품, 컴플라이언스, 플랫폼 컨텍스트)와 AI를 다루는 빌더를 페어로 두는 것입니다. 빌더는 빠르게 생성하고 반복하며, 도메인 전문가는 불편한 질문을 던집니다: “사용자가 정지된 계정이면 어떻게 되나?” “어떤 데이터가 민감한가?” “이 지역에서 허용되는가?”
이 조합은 코드 리뷰를 병목이 아닌 크로스-스택 품질 관행으로 바꿉니다.
AI가 UI, API, 저장소를 한 번에 건드리는 기능을 쉽게 배포해 주면 보안 문제는 더 이상 ‘다른 사람의 문제’가 아닙니다. 위험은 팀이 보안을 잊는 것이 아니라, 경계 소유자가 불분명해져 작은 실수가 빠져나간다는 점입니다.
자주 보이는 문제:
.env 예시 값이 커밋되거나 토큰이 로그에 찍힘경계가 흐려지면 “데이터”의 범위도 흐려집니다. 다음을 설계 결정으로 우선 다루세요:
AI 생성 코드가 틀릴 가능성을 줄이려면 “기본 경로”를 안전하게 만드세요:
AI에 크로스-레이어 변경을 생성하도록 요청하기 전에 표준 프롬프트를 사용하세요:
Before generating code: list required authZ checks, input validation rules, sensitive data fields, logging/redaction rules, and any new dependencies. Do not place secrets in client code. Ensure APIs enforce permissions server-side.
그다음 간단한 체크리스트로 리뷰하세요: 서버에서 권한 검사, 시크릿 미노출, 입력 검증 및 인코딩, 로그/이벤트 마스킹, 새 의존성 정당화 여부 확인.
AI 보조 개발은 보드에 나타나는 작업 방식을 바꿉니다. 하나의 기능이 모바일 화면, 웹 흐름, API 엔드포인트, 분석 이벤트, 권한 규칙을 동시에 건드리고 종종 같은 PR에 포함됩니다.
이 때문에 “프런트엔드”와 “백엔드” 작업이 더 이상 깔끔하게 분리되지 않아 시간 추적이 어려워집니다.
기능이 레이어를 가로지를 때는 “몇 개의 엔드포인트”나 “몇 개의 화면” 기준의 추정이 통계적으로 틀리기 쉽습니다. 더 신뢰할 수 있는 접근법은 사용자 영향과 리스크로 추정하는 것입니다.
실무 패턴:
소유권을 컴포넌트로(웹이 소유, 백엔드가 소유) 할당하는 대신 결과물(사용자 여정이나 제품 목표)으로 정의하세요. 하나의 팀(또는 한 명의 직접 책임자)이 종단간 경험을 소유하고 성공 지표, 에러 처리, 운영 준비성을 포함해 관리합니다.
전문가는 여전히 필요하지만, 이렇게 하면 책임이 명확해집니다. 전문가는 리뷰하고 안내하지만, 기능 소유자가 모든 조각이 함께 출하되도록 보장합니다.
경계가 흐려지면 티켓은 더 날카로운 정의를 필요로 합니다. 좋은 티켓은 다음을 포함합니다:
크로스-레이어 작업은 릴리스 시 가장 자주 실패합니다. 어떤 백엔드 변경을 먼저 배포해야 하는지, API가 하위 호환성을 유지하는지, 모바일 최소 버전이 무엇인지 명확히 소통하세요.
단순한 릴리스 체크리스트가 도움이 됩니다: 기능 플래그 계획, 롤아웃 순서, 모니터링 신호, 롤백 절차—웹·모바일·백엔드 모든 팀이 공유해 생산에서 놀라지 않도록 하세요.
AI가 UI, 모바일 화면, 백엔드 엔드포인트를 연결해 주면 겉보기엔 완성된 것처럼 보이지만 접합부에서 실패할 수 있습니다.
빠른 팀은 테스트와 관측성을 하나의 시스템으로 취급합니다: 테스트는 예측 가능한 파손을 잡고, 관측성은 이상한 문제의 원인을 설명합니다.
AI는 어댑터 생성—필드 매핑, JSON 재구성, 날짜 변환, 콜백 연결—에 능합니다. 그게 바로 미묘한 결함이 존재하는 자리입니다:
이런 문제는 각 레이어가 자체 테스트를 통과해도 통합에서 조용히 어긋날 수 있어 단위 테스트로는 잡기 어렵습니다.
계약 테스트는 손을 잡는 테스트입니다: 클라이언트와 API가 요청/응답 형태와 핵심 동작에 합의하는지 검증합니다.
초점을 좁게 유지하세요:
이것은 특히 AI가 모호한 프롬프트로 리팩터하거나 새로운 엔드포인트를 생성할 때 중요합니다.
소수의 수익/신뢰-중요 흐름(가입, 결제, 비밀번호 재설정)을 웹/모바일 + 백엔드 + DB를 가로지르는 E2E 테스트로 검증하세요.
100% E2E 커버리지를 목표로 하지 말고 실패 시 피해가 큰 부분에 대해 높은 신뢰도를 목표로 하세요.
경계가 흐려지면 “어떤 팀이 소유하나”로 디버깅하기 어렵습니다. 기능 단위로 계측하세요:
몇 분 내에 “무엇이 바뀌었고, 누가 영향을 받으며, 어디서 실패하는가”를 답할 수 있다면 크로스-레이어 개발은 빠르되 느슨해지지 않습니다.
AI 도구는 여러 레이어를 한꺼번에 바꾸기 쉽게 만들어 속도를 높이지만 일관성을 해칠 위험도 있습니다. 가장 좋은 아키텍처 패턴은 이를 거부하지 않고, 인간이 시스템을 여전히 추론할 수 있는 명확한 이음새로 유도합니다.
API-퍼스트는 엔드포인트와 계약에서 시작해 클라이언트와 서버를 구현합니다. 소비자가 많고 예측 가능한 통합이 필요할 때 효과적입니다.
스키마-퍼스트는 한 단계 더 깊이 들어가 공용 스키마(OpenAPI나 GraphQL)를 정의하고, 클라이언트·스텁·문서를 생성합니다. AI 지원 팀에게는 스키마가 AI가 신뢰하고 따를 수 있는 단일 출처가 되기 때문에 종종 적절한 절충점입니다.
기능-퍼스트는 작업을 사용자 결과물(예: 결제, 프로필 편집)로 조직하고 크로스-레이어 변경을 하나의 소유 표면 뒤에 번들합니다. 이는 프롬프트 방식으로 AI가 자연스럽게 생각하는 방식과 일치합니다.
실무적으로는 기능-퍼스트 전달과 스키마-퍼스트 계약의 결합이 유용합니다.
모두가 동일한 계약을 목표로 할 때 “이 필드는 무슨 뜻인가?” 논쟁이 줄어듭니다. OpenAPI/GraphQL 스키마는 또한 다음을 쉽게 합니다:
핵심은 스키마를 버전 관리되는 제품 표면으로 취급하는 것입니다.
원한다면 가벼운 입문 자료를 내부에 두세요: /blog/api-design-basics.
팀 경계가 흐려져도 코드 경계가 흐려질 필요는 없습니다. 명확성을 유지하세요:
이렇게 하면 AI 생성 변경이 “상자” 안에 머물어 리뷰가 빨라지고 회귀가 줄어듭니다.
기능-퍼스트 작업이 얽힌 코드가 되지 않게 하려면:
목표는 엄격한 분리 아닙니다—예측 가능한 연결 지점을 만들어 AI가 따르고 사람이 신뢰할 수 있게 하는 것입니다.
AI는 팀의 속도를 높여줄 수 있지만 가드레일 없는 속도는 재작업으로 이어집니다. 목표는 모두가 "모든 것"을 하게 만드는 것이 아니라, 크로스-레이어 변경이 안전하고 리뷰 가능하며 반복 가능하도록 만드는 것입니다.
경계가 흐려도 전문가는 여전히 중요하지만, 몇 가지 공통 기술은 협업을 원활하게 합니다:
이것들은 모두가 갖춰야 할 기술로, AI가 제안한 것을 검증하기 쉽게 만듭니다.
AI는 산출물을 늘립니다; 일관성은 습관이 결정합니다.
공유 Definition of Done부터 맞추세요:
경량 템플릿을 추가하세요: PR 체크리스트, 기능 스펙 원페이지, API 변경 설명 표준. 일관된 구조가 리뷰를 빠르게 하고 오해를 줄입니다.
표준화는 기억에 의존하면 안 됩니다. 자동화에 집어넣으세요:
이미 이러한 체계가 있다면 점진적으로 엄격도를 올리세요—한 번에 엄격 규칙을 전면 적용하지 마세요.
플랫폼들이 AI 보조 워크플로를 중심으로 등장하는 이유 중 하나는 이런 “기능-퍼스트” 변경이 끝까지 일관되게 느껴지도록 하기 위함입니다. 예를 들어 Koder.ai는 단순 코드 스니펫이 아닌 채팅을 통해 완전한 기능을 생성·반복하는 워크플로를 제공하면서 기획 모드, 배포/호스팅, 소스 코드 내보내기 같은 팀의 관행을 지원합니다. 실무에서는 웹의 React, 백엔드 서비스, 데이터 변경을 한 워크플로에서 건드릴 필요가 많아지므로 이런 도구들이 편의를 제공합니다.
레이어를 넘는 한 기능(예: UI, API 필드, 데이터 저장소가 필요한 설정 토글)을 선택하고 성공 지표(사이클 타임, 결함률, 후속 수정 빈도)를 미리 정의하세요.
스프린트 동안 실험을 진행한 뒤 무엇이 깨지거나 느리게 했는지에 따라 표준, 템플릿, CI를 조정하세요. 다음 기능으로 반복합니다.
이렇게 하면 AI 도입은 과대광고가 아닌 결과로 뒷받침되고, 워크플로가 진화하는 동안 품질을 보호할 수 있습니다.
레이어는 기술적으로(브라우저, 디바이스, 서버, 데이터베이스) 여전히 존재하지만, 일상 업무는 더 이상 깔끔하게 분리되지 않습니다. AI 도구는 사용자 스토리를 따라 UI → API → 로직 → 저장소까지 끝에서 끝으로 변화를 생성하는 경향이 있어, 단일 “기능” 작업이 하나의 PR에서 여러 레이어를 가로지를 때가 많습니다.
기능 프롬프트에는 자연스럽게 의도와 결과(성공/실패 시 동작, 필요한 데이터, 저장 방식 등)가 포함됩니다. AI는 UI 컴포넌트, 엔드포인트, 유효성 검사, 마이그레이션 같은 레이어 간 접착 코드를 생성하므로, 작업 계획은 "레이어별 티켓"에서 "수용 기준을 가진 하나의 기능 슬라이스"로 바뀝니다.
다음과 같은 번들 형태가 자주 나옵니다:
이는 출발점으로 받아들이세요. 엣지 케이스, 보안, 성능, 클라이언트 간 호환성 검증이 여전히 필요합니다.
다음 원칙으로 범위를 정하고 과제를 배정하세요:
이렇게 하면 조율 지연이 줄어들지만, 기능을 초기에 명확히 정의해야 합니다.
일반적인 변화:
목표는 일관성입니다. 그래야 AI가 생성한 코드가 앱과 서비스 간에 흩어지지 않습니다.
BFF는 특정 클라이언트 경험(웹 또는 모바일)을 위해 설계된 얇은 서버 계층입니다. 화면이 집약적 조합을 필요로 하거나 왕복 네트워크 호출이 많은 경우 유용합니다. 지킬 점:
그렇지 않으면 로직 중복과 여러 진실의 원천이 생길 위험이 있습니다.
문법이나 스타일보다는 시스템 동작에 집중하세요:
경량 PR 체크리스트와 핵심 E2E 흐름이 리뷰어의 페이스를 맞추는 데 도움이 됩니다.
흐려진 경계에서 자주 발생하는 실패는 다음과 같습니다:
안전 기본값을 쉽게 만들면 AI가 생성한 코드가 틀릴 가능성이 줄어듭니다: 최소 권한, API 경계에서의 입력 검증, 로그 적출 제한, 의존성 위생 등.
우선 두 가지 테스트를 우선하세요:
그리고 기능 단위로 계측하세요:
이렇게 하면 레이어별 단위 테스트가 놓치는 접합부 버그를 잡을 수 있습니다.
작게 시작해 가드레일을 표준화하세요:
목표는 모든 사람이 모든 것을 하게 만드는 것이 아니라, 기능이 여러 레이어를 건드릴 때도 안전하고 반복 가능한 전달을 보장하는 것입니다.