한 회사가 에이전시에 대시보드 구축을 요청합니다.

요청서에는 20개의 화면, 여러 개의 차트, AI 어시스턴트(AI assistant), 그리고 선호하는 기술 스택(technology stack)이 포함되어 있습니다. 이는 단순한 디자인 및 개발 프로젝트처럼 보입니다.

그 후 탐색(discovery)이 시작됩니다.

고객 데이터가 웹사이트, CRM, ERP, 스프레드시트 사이에서 수동으로 복사됩니다. 직원들은 불일치하는 기록을 수정합니다. 관리자들은 조치를 취하기에는 너무 늦은 시점에 보고서를 받습니다. 고객들은 주문 상태를 확인하거나 문서를 직접 다운로드할 수 없어 고객 지원팀에 연락합니다.

요청된 대시보드는 프로세스를 더 현대적으로 보이게 만들 뿐입니다. 프로세스 자체를 해결하지는 못합니다.

유용한 제품은 데이터, 사람, 규칙, 그리고 의사결정을 연결하는 운영 시스템(operational system)입니다.

이 사례는 2026년 3분기로 진입하며 나타나는 핵심적인 시장 변화를 포착합니다:

표준적인 코드(Standard code)를 생산하는 비용은 점점 저렴해지고 있습니다. 무엇을 구축해야 하는지 이해하고, 이를 프로덕션(production) 환경에서 신뢰할 수 있게 만드는 것이 더욱 가치 있어지고 있습니다.

AI는 레이아웃, 컴포넌트(components), 테스트, 그리고 애플리케이션의 상당 부분을 생성할 수 있습니다. 클라우드 플랫폼(Cloud platforms)은 이미 인증, 결제, 스토리지, 분석, 메시징 및 인프라를 제공하고 있습니다.

맞춤형 소프트웨어(Custom software)가 사라진 것은 아닙니다. 수요가 비즈니스의 더 깊은 곳으로 이동했습니다: 고객 포털, 내부 도구, B2B 커머스, 통합(integrations), 워크플로우 자동화(workflow automation), AI 지원 운영, 그리고 레거시 현대화(legacy modernization).

구매자에게 이는 소프트웨어를 구매하는 방식을 변화시킵니다. 개발자에게 이는 어떤 기술이 지속적인 우위를 창출하는지를 변화시킵니다.

데이터 참고: 이 전망은 2026년 7월에 이용 가능한 정보를 바탕으로 합니다. 최신 완전한 미국의 분기별 이커머스(e-commerce) 수치는 2026년 1분기를 다루고 있으며, 2분기 발표는 8월 18일로 예정되어 있습니다.

하나의 용어, 두 개의 매우 다른 시장

"웹 개발(Web development)"은 이제 점점 더 서로 달라지는 두 가지 범주의 작업을 설명합니다.

첫 번째 범주는 마케팅 사이트(marketing sites), 랜딩 페이지(landing pages), 콘텐츠 플랫폼(content platforms), 표준형 스토어(standard stores), 그리고 초기 프로토타입(early prototypes)을 포함합니다. 이러한 프로젝트들은 여전히 중요하지만, 제작 방식이 점점 더 표준화되고 있습니다. 템플릿(Templates), 로우코드(low-code) 제품, AI 빌더(AI builders), 그리고 성숙한 SaaS 도구들이 인도 시간(delivery time)과 기술적 차별성을 줄이고 있습니다.

두 번째 범주는 브라우저에서 실행되지만 비즈니스 운영에 내장되는 소프트웨어를 포함합니다:

• 고객 및 파트너 포털(customer and partner portals);
• 내부 워크플로우 시스템(internal workflow systems);
• B2B 주문 플랫폼(B2B ordering platforms);
• SaaS 제품(SaaS products);
• 문서 처리 애플리케이션(document-processing applications);
• CRM 및 ERP 통합(CRM and ERP integrations);
• 레거시 시스템(legacy systems)을 위한 현대적 인터페이스.

이러한 시스템의 비용은 페이지 수에 의해 결정되지 않습니다. 이는 역할(roles), 권한(permissions), 데이터 소유권(data ownership), 통합(integrations), 마이그레이션(migration), 보안(security), 그리고 장애 발생 시의 결과(consequences of failure)에 따라 달라집니다.

API를 사용할 수 없게 되면 어떤 일이 발생할까요? 어떤 플랫폼에 정확한 고객 기록이 포함되어 있습니까? 누가 주문을 승인할 수 있습니까? 어떤 작업에 감사 추적(audit trail)이 필요합니까? 한 시간의 다운타임(downtime)은 얼마만큼의 비용을 초래할까요?

비즈니스 핵심 플랫폼(business-critical platform)은 단순히 "대규모 웹사이트"로 계획될 수 없습니다. 이는 또한 프로세스 분석(process analysis), 아키텍처(architecture), 테스트(testing), 관측성(observability), 문서화(documentation), 인프라(infrastructure), 그리고 출시 후 지원(post-launch support)을 필요로 합니다.

세련된 인터페이스는 망가진 프로세스를 숨길 수는 있습니다.

하지만 그것을 복구할 수는 없습니다.

미국: 구매자는 가치의 증명을 기대한다

미국은 여전히 가장 매력적인 소프트웨어 시장 중 하나이지만, 가장 경쟁이 치열한 시장 중 하나이기도 합니다.

미국 노동통계국(US Bureau of Labor Statistics)은 2024년에서 2034년 사이에 소프트웨어 개발자(software developers), 품질 보증 분석가(quality assurance analysts), 그리고 테스터(testers)의 고용이 15% 성장할 것으로 전망합니다. 웹 개발자(Web developers)와 디지털 디자이너(digital designers)는 7% 성장할 것으로 예상되는 반면, 컴퓨터 프로그래머(computer programmers)는 6% 감소할 것으로 예상됩니다.

이 수치들은 에이전시의 매출을 측정하는 것은 아니지만, 구조적인 변화를 보여줍니다. 시장은 고립된 프로그래밍 (programming) 작업에는 낮은 가치를 부여하는 반면, 요구사항 이해, 시스템 설계, 플랫폼 통합, 데이터 보호, 그리고 출시 후 소프트웨어 운영과 같은 완전한 엔지니어링 책임에는 더 높은 가치를 부여하고 있습니다.

이와 동일한 패턴이 이커머스 (e-commerce)에서도 관찰됩니다. 계절 조정된 미국의 소매 이커머스 (retail e-commerce) 매출은 2026년 1분기에 전년 대비 9.8% 증가한 3,267억 달러에 달했으며, 이는 전체 소매 매출의 16.9%를 차지했습니다.

하지만 기회는 단순히 더 많은 상점을 구축하는 것에 그치지 않습니다. 가치 있는 작업의 상당 부분은 매장 전면(storefront) 뒤편에 위치합니다:

• 계정별 가격 책정 및 B2B 주문;
• 구독 및 반복 구매;
• ERP, 창고 및 재고 동기화;
• 풀필먼트 (fulfillment) 및 반품 자동화;
• 고객 셀프 서비스;
• 결제 및 성능 최적화.

커머스 웹사이트는 드물게 고립된 판매 채널로 존재합니다. 그것은 결제, 물류, 회계, 재고 및 고객 서비스와 연결된 인터페이스입니다.

미국의 구매자들은 종종 가치 실현 시간 (time-to-value)을 통해 프로젝트를 평가합니다. 그들은 첫 번째 사용 가능한 릴리스 (release)가 언제 나타날지, 그것이 어떤 프로세스를 개선할지, 비용이나 매출에 어떤 영향을 미칠지, 그리고 운영 환경 (production)에서 누가 시스템을 소유하게 될지를 알고 싶어 합니다.

다음 두 제안을 비교해 보십시오:

“우리는 TypeScript 프론트엔드 (frontend)를 사용하여 현대적인 고객 포털을 구축할 것입니다.”

그리고:

“우리는 고객에게 송장, 문서, 배송 업데이트 및 주문 내역에 대한 직접적인 접근 권한을 제공하여, 고객 지원 팀이 처리하는 일상적인 요청을 줄여줄 것입니다.”

첫 번째는 구현 (implementation)을 설명합니다.

두 번째는 비즈니스 결과 (business result)를 설명합니다.

프레임워크 (framework)는 전략이 아니며, 기술 목록은 비즈니스 케이스 (business case)가 아닙니다.

유럽: 하나의 지역, 다양한 소프트웨어 시장

유럽은 다른 유형의 복잡성을 보여줍니다.

유럽 연합 (European Union)은 공유된 경제 및 규제 공간이지만, 그 안의 기업들은 국가, 산업, 규모 및 디지털 성숙도에 따라 크게 다릅니다. 영국 (United Kingdom)은 별도의 상업 및 규제 환경을 더합니다.

Eurostat의 보고에 따르면 2025년에 EU 기업의 53%가 클라우드 서비스 (cloud services)를 구매했습니다. AI를 사용한 비율은 약 20%로, 2024년의 13%에서 증가했습니다. 도입 수준은 여전히 불균형했습니다. 대기업의 55%가 AI를 사용한 반면, 중소기업 (SMEs)은 19%에 그쳤습니다.

이러한 격차는 두 가지 평행한 기회를 창출합니다.

디지털 성숙도가 높은 조직은 더 강력한 통합 (integrations), 데이터 플랫폼 (data platforms), AI 거버넌스 (AI governance), 자동화 (automation), 그리고 레거시 현대화 (legacy modernization)를 필요로 합니다. 반면 다른 기업들은 여전히 스프레드시트 (spreadsheets), 반복적인 데이터 입력, 공유 편지함, 그리고 파편화된 보고 (fragmented reporting)를 대체해야 합니다.

두 경우 모두, 모든 것을 새로 구축하는 것이 최선의 답인 경우는 드뭅니다.

어떤 기업은 이미 CRM, 회계 플랫폼 (accounting platform), 커머스 시스템 (commerce system), 문서 서비스, 그리고 산업 특화 ERP를 사용하고 있을 수 있습니다. 이때 부족한 제품은 종종 이들을 연결하는 계층인 경우가 많습니다: 즉, 포털 (portal), 워크플로 애플리케이션 (workflow application), 통합 서비스 (integration service), API, 또는 공유된 운영 뷰 (shared operational view)입니다.

이것이 하이브리드 아키텍처 (hybrid architecture)가 기본값이 되고 있는 이유입니다:

표준 기능은 구매합니다. 차별화된 워크플로는 구축합니다.

유럽 시장으로의 확장 또한 제품 결정 단계를 앞당깁니다. 시스템은 각 시장마다 서로 다른 언어, 결제 수단, 인보이스 (invoices), 세금 규칙, 접근성 동작 (accessibility behavior), 그리고 법적 콘텐츠를 필요로 할 수 있습니다.

현지화 (Localization)가 항상 번역만을 의미하는 것은 아닙니다. 때로는 워크플로와 아키텍처를 변경해야 할 수도 있습니다.

AI 거버넌스에 있어 2026년 3분기가 중요한 이유

2026년 8월 2일은 유럽 소프트웨어 팀들에게 이번 분기 중 가장 중요한 날짜 중 하나입니다.

이 날짜부터 EU AI Act (EU 인공지능법)가 광범위하게 적용되며, 일부 고위험 시스템 (high-risk systems)에 대해서는 예외 사항과 추후 적용 일정이 적용됩니다. 특정 AI 상호작용 및 생성된 콘텐츠에 대한 관련 투명성 의무 (transparency obligations) 또한 적용되기 시작합니다.

모든 내부 어시스턴트나 지원 챗봇 (support chatbot)이 고위험 시스템이 되는 것은 아닙니다. 하지만 "주요 모델 제공업체의 API를 호출한다"는 것만으로는 더 이상 적절한 거버넌스 전략이 될 수 없습니다.

팀들은 다음 사항을 이해해야 합니다:

• AI가 어떤 작업을 수행하는지;
• 어떤 개인정보나 기밀 데이터에 접근할 수 있는지;
• 정보가 어디에서 처리되고 보관되는지;
• AI가 개입되었음을 사용자에게 어떻게 알리는지;
• 누가 결과를 검토하거나 무효화할 수 있는지;
• 신뢰도(confidence)가 낮을 때 어떤 일이 발생하는지;
• 중요한 작업이 어떻게 로그(log)에 기록되는지.

이러한 질문들은 사용자 경험 (UX), 아키텍처 (architecture), 권한 (permissions), 관측 가능성 (observability), 모델 선택 (model selection), 그리고 벤더 관리 (vendor management)에 영향을 미칩니다.

접근성 (Accessibility) 또한 유사한 경로를 따르고 있습니다. 유럽 접근성 법안 (European Accessibility Act)은 2025년 6월 28일부터 이커머스 (e-commerce), 소비자 금융 (consumer banking), 전자 통신 (electronic communications), 티켓팅 (ticketing)을 포함한 특정 제품 및 서비스에 적용되었습니다.

따라서 접근성은 출시 며칠 전에 수행하는 감사 (audit)의 대상이 아니라, 컴포넌트 라이브러리 (component libraries), 디자인 시스템 (design systems), 수락 기준 (acceptance criteria), 그리고 테스트 (testing) 단계에 포함되어야 합니다.

개발자들에게 규제는 엔지니어링 제약 사항 (engineering constraint)이 되어가고 있습니다.

구매자들에게 컴플라이언스 (compliance, 준수)는 제품 품질의 일부가 되어가고 있습니다.

기업들이 자금을 지원하는 분야

미국과 유럽 전역에서 투자는 측정 가능한 프로세스를 변화시키는 소프트웨어에 집중되고 있습니다.

포털 및 워크플로우 자동화 (Portals and workflow automation)

포털은 일상적인 상호작용을 전화, 이메일, 수동 지원으로부터 분리할 때 가치를 창출합니다.

고객은 주문을 추적하고, 송장에 접근하며, 문서를 교환하고, 결제를 수행하며, 서비스 내역을 독립적으로 검토할 수 있습니다. 성공의 기준은 "12개의 화면을 전달하는 것"이 아닙니다. 이는 지원 요청의 감소, 주문 주기의 단축, 또는 오류의 감소를 의미할 수 있습니다.

내부 도구 (Internal tools) 또한 유사한 가치를 제공합니다. 많은 기업이 여전히 스프레드시트 (spreadsheets), 편지함 (inboxes), 메시징 플랫폼 (messaging platforms), 그리고 반복적인 데이터 내보내기 (exports)를 통해 핵심 프로세스를 운영하고 있습니다.

취약한 자동화 프로젝트는 기존의 양식을 디지털화하는 데 그칩니다.

더 강력한 프로젝트는 다음과 같이 질문합니다:

• 어떤 단계가 사라질 수 있는가?
• 어떤 결정이 예측 가능한 규칙을 따르는가?
• 필요한 데이터가 이미 어디에 존재하는가?
• 어떤 예외 상황에 사람이 필요한가?
• 지연과 오류가 어디에서 발생하는가?

잘못된 프로세스를 자동화하는 것은 낭비를 더 빠르게 이동시킬 뿐입니다.

워크플로우를 재설계하는 것은 그 낭비를 제거할 수 있습니다.

통합(Integrations) 및 레거시 현대화(legacy modernization)

API가 존재한다고 해서 안전한 통합(integration)이 보장되는 것은 아닙니다.

데이터가 중복되거나, 식별자(identifiers)가 일관되지 않거나, 웹훅(webhooks)을 사용할 수 없거나, 제한 사항(limits)에 대한 문서화가 제대로 되어 있지 않을 수 있습니다. 또한 레거시 애플리케이션(Legacy applications)에는 수년간 문서화되지 않은 비즈니스 규칙(business rules)이 포함되어 있을 수 있습니다.

이러한 시스템을 단 한 번의 "빅뱅(big bang)" 릴리스로 교체하는 것은 우아해 보일 수 있지만, 운영 측면에서는 무모한 일입니다.

더 안전한 전략은 점진적인 방식입니다. 기존 규칙을 문서화하고, 권위 있는 데이터 소스(authoritative data sources)를 식별하며, 선택된 기능들을 API를 통해 노출하고, 현대적인 인터페이스를 도입하며, 모듈을 점진적으로 교체하고, 통제된 단계에 따라 사용자를 마이그레이션(migrate)하는 것입니다.

구매자의 핵심 질문은 다음과 같습니다:

"우리 플랫폼을 새로 작성해 줄 수 있습니까?"

이 아니라 다음과 같습니다:

"우리 비즈니스를 중단시키지 않고 어떻게 현대화할 것입니까?"

B2B 커머스(B2B commerce) 및 AI 운영(AI operations)

표준적인 소비자용 상점은 기존 플랫폼에서 종종 출시될 수 있습니다. 커머스에 협상된 가격, 기업 계정, 신용 한도, 승인 체인(approval chains), 유통업체 역할, ERP 제어 재고 또는 특화된 풀필먼트(fulfillment)가 포함되는 경우 맞춤형 개발(Custom development)이 가치를 발휘합니다.

B2B 커머스에서 카탈로그(catalog)는 종종 쉬운 부분에 속합니다. 진짜 제품은 그 뒤에 숨겨진 상업적 로직(commercial logic)입니다.

"AI 챗봇 개발" 또한 의미를 갖기에는 너무 일반적인 용어가 되어가고 있습니다. 유용한 AI는 송장에서 데이터를 추출하거나, 요청을 분류하거나, 문서를 검색하거나, 응답 초안을 작성하거나, 신청서를 검증하거나, 케이스 파일을 요약하거나, 승인된 정보를 CRM으로 전송할 수 있습니다.

가장 신뢰할 수 있는 패턴은 통제된 자동화(controlled automation)입니다:

AI가 일반적인 케이스를 처리하고, 사람이 중요한 결정을 승인하며, 특이한 케이스는 에스컬레이션(escalated)됩니다.

팀은 출력값이 어떻게 검증될지, 완료된 각 작업의 비용이 얼마인지, 그리고 모델이 실패했을 때 어떤 일이 발생하는지를 이해해야 합니다.

2026년 3분기를 형성하는 네 가지 개발 트렌드

1. AI 에이전트(AI agents)의 인도(delivery) 단계 진입

GitHub는 2026년 6월에 Agentic Workflows(에이전트 워크플로우)를 퍼블릭 프리뷰(public preview)로 전환하며, 이슈 분류(issue triage), CI 실패 분석, 문서 업데이트와 같은 추론 기반의 리포지토리(repository) 작업을 지원하기 시작했습니다.

중요한 변화는 단순히 AI가 더 많은 코드를 생성할 수 있다는 점이 아닙니다. 리포지토리는 인간과 에이전트(agent) 모두에게 이해 가능하고 안전해야 합니다.

이는 명시적인 아키텍처 경계(architectural boundaries), 타입 계약(typed contracts), 자동화된 테스트(automated tests), 재현 가능한 환경(reproducible environments), 구조화된 로그(structured logs), 제한된 권한(restricted permissions), 그리고 필수적인 리뷰(mandatory review)의 가치를 높입니다.

혼란스러운 리포지토리에서 작업하는 유능한 에이전트는 혼란을 더 빠르게 만들어낼 뿐입니다.

2. 강력한 제약 조건(Strong constraints)의 중요성 증대

더 많은 구현(implementation)이 자동으로 생성됨에 따라 타입 시스템(Type systems), 정적 분석(static analysis), 테스트, 그리고 명확하게 정의된 API의 가치가 더욱 높아집니다.

구매자가 던져야 할 올바른 질문은 다음과 같습니다:

“어떤 언어를 사용하나요?”

가 아니라,

“한 모듈의 변경이 다른 모듈을 조용히 망가뜨리는 것을 무엇이 방지하나요?”

여기에 대한 답변에는 단순히 기술 명칭뿐만 아니라 엔지니어링 관행(engineering practices)이 포함되어야 합니다.

3. AI의 유닛 이코노믹스(unit economics) 시대

GitHub는 2026년 6월에 Copilot을 사용량 기반 과금(usage-based billing) 방식으로 전환했으며, 사용량은 AI 크레딧(AI Credits)과 토큰 소비량(token consumption)을 통해 계산됩니다.

이는 더 넓은 현실을 반영합니다: 다단계 AI 작업은 가변적인 인프라 비용(variable infrastructure cost)입니다.

프로덕션 기능(production feature)을 구현하기 위해서는 모델 호출(model calls), 임베딩(embeddings), 검색(search), 저장(storage), 재시도(retries), 모니터링(monitoring), 중재(moderation), 그리고 인간의 리뷰(human review)에 대한 비용 지출이 필요할 수 있습니다.