국내 금융·공공 SI 판에서 UI 생산성을 말할 때 등장하는 단어는 20년째 둘이다. 넥사크로와 웹스퀘어. 그리고 2025년부터 완전히 다른 방향에서 같은 단어가 나온다. 바이브코딩으로 React를 뽑는다.

“어느 쪽이 더 생산적인가”를 물으면 대개 벤더 자료를 서로 던지는 싸움이 된다. 이 글은 그 싸움을 하지 않는다. 대신 두 가지를 한다. 첫째, 양쪽 생산성 주장의 출처 등급을 분리한다. 둘째, 두 생산성이 애초에 같은 축 위에 있지 않다는 것을 보인다.

먼저 결론부터.

넥사크로·웹스퀘어는 자유도를 줄여서 생산성을 만든다. 바이브코딩은 자유도를 늘려서 만든다. 전자는 분산이 작은 조직의 생산성이고, 후자는 분산이 큰 개인의 생산성이다. 그리고 전자의 이득은 생애주기 전체에, 후자의 이득은 초안 구간에 집중된다.

1. 먼저 인정하고 갈 것: 양쪽 다 검증된 숫자가 없다

이 주제를 다루는 글 대부분이 “넥사크로 도입으로 생산성 30% 향상”, “AI로 개발 속도 10배” 같은 숫자를 나란히 놓는다. 그 숫자들의 출처를 실제로 따라가 보면 이렇다.

넥사크로 쪽

투비소프트 공식 제품소개 자료(1차·벤더)에는 정량 수치가 없다. “개선된 개발 환경을 제공하여 개발 생산성이 향상됩니다”, “높은 개발 생산성 / 코드 개발 절감 / 높은 재사용성 / 표준화된 품질” 같은 정성적 표현뿐이다.1 “생산성 N% 향상” 형태의 공식 수치는 이번 조사에서 찾지 못했다.

웹스퀘어 쪽

인스웨이브 공식 뉴스레터(1차·벤더)에도 “오픈 소스를 재활용하여 개발 생산성을 제고” 수준의 정성적 표현만 있다.2 흔히 인용되는 30%라는 수치는 공식 제품 문서가 아니라 한국소프트웨어산업협회 SW유통시스템에 벤더가 제출한 자사 구축사례에서 나온다 — “WebSquare5 도입으로 개발 생산성이 기존 대비 약 30% 향상되었으며 (…) 사용자 업무 효율이 50% 이상 개선”.3

이건 벤더가 조달 채널에 제출한 자기 사례다. 측정 방법도, 비교 대상(무엇 대비 30%인가)도, 재현 절차도 공개되어 있지 않다. 인용은 할 수 있지만 “벤더 주장, 제3자 재현 불가” 라벨을 떼면 안 된다.

바이브코딩 쪽

여기가 더 심하다. “10배” 부류의 숫자는 대부분 출처가 없거나 벤더 마케팅이다. 그리고 원저자 본인이 이미 범위를 못 박아 뒀다. 바이브코딩이라는 단어를 만든 Andrej Karpathy의 2025년 2월 2일 원문은 이렇게 끝난다.

“I ‘Accept All’ always, I don’t read the diffs anymore. (…) The code grows beyond my usual comprehension, I’d have to really read through it for a while. (…) It’s not too bad for throwaway weekend projects, but still quite amusing.”4

용어를 만든 사람이 스스로 “버릴 주말 프로젝트에는 나쁘지 않다”고 적었다. 금융 원장 화면을 이걸로 뽑자는 주장의 근거로 이 트윗을 쓰는 건 원문을 거꾸로 읽는 것이다.

그래서 양쪽 벤더 숫자는 이 글에서 근거로 쓰지 않는다. 대신 아래 중립 연구를 축으로 삼는다.

2. 중립 증거 — AI 코딩 생산성은 실측하면 다르게 나온다

METR 무작위대조시험 (2025)

지금까지 나온 AI 코딩 생산성 연구 중 방법론이 가장 엄격한 것은 METR의 RCT다. 숙련 오픈소스 개발자 16명에게 자기 저장소의 실제 이슈 246개(평균 2.0시간짜리)를 주고, 이슈 단위로 AI 사용 허용/금지를 무작위 배정했다. 대상 저장소는 평균 약 23,000 스타, 개발자들은 해당 저장소에 평균 5년 경력. 도구는 Cursor Pro + Claude 3.5/3.7 Sonnet, 기간은 2025년 2~6월.5

결과는 이렇다.

시점 예측/결과
개발자 사전 예측 24% 단축
경제학 전문가 예측 39% 단축
ML 전문가 예측 38% 단축
개발자 사후 체감 20% 단축
실측 19% 지연

핵심은 마지막 두 줄이다. 작업을 끝낸 본인들이 20% 빨라졌다고 믿었는데, 실제로는 19% 느렸다. 체감과 실측이 반대 방향으로 39%포인트 벌어졌다.

이게 왜 중요한가. 현장에서 “AI 쓰니까 훨씬 빠르다”는 진술은 거의 전부 자기보고다. METR는 그 자기보고가 체계적으로 틀릴 수 있다는 것을 통제된 조건에서 보였다.

한 가지 단서는 정직하게 붙여야 한다. 이 연구의 표본은 자기 저장소를 5년간 다룬 숙련 개발자다. 그린필드 프로젝트, 낯선 코드베이스, 주니어 개발자에게 같은 결과가 나온다는 보장은 없다. METR 자신도 논문에서 이 결과를 일반화하지 말라고 명시한다.

DORA 2024 → 2025

Google Cloud DORA 보고서는 훨씬 큰 표본(2025년 약 5,000명)의 관측 연구다. 인과가 아니라 상관이라는 한계가 있지만, 2년 연속 데이터의 방향 변화가 의미 있다.

DORA 2024: AI 채택률이 25% 증가할 때마다 배포 처리량 −1.5%, 안정성 −7.2%. 동시에 코드 품질 인식 +3.4%, 리뷰 속도 +3.1%, 문서화 +7.5%, 개인 생산성 +2.1%. DORA가 제시한 가설은 “AI가 코드를 많이 뽑아 변경 단위(batch size)가 커졌고, 이는 소규모 배치라는 원칙을 위반한다”는 것이다.6

DORA 2025: 처리량은 플러스로 반전됐다. 그러나 안정성은 여전히 마이너스다. 보고서의 결론 문장은 “AI는 증폭기(amplifier)”다 — 잘 굴러가는 조직은 더 잘 굴러가게, 망가진 조직은 더 망가지게 만든다. 느슨하게 결합된 아키텍처와 빠른 피드백 루프를 가진 팀은 이득을 보고, 강하게 결합되고 프로세스가 느린 팀은 거의 못 얻는다.7

숫자 하나만 더. 개발자의 90%가 AI를 쓰고 80% 이상이 생산성이 올랐다고 믿지만, 30%는 AI 결과물을 거의 신뢰하지 않는다(2024년 39%에서 하락).7 Stack Overflow 2025 개발자 설문에서는 46%가 AI 정확도를 불신하고, “높게 신뢰”는 3%에 그쳤다.8

정리하면 중립 증거의 그림은 이렇다. AI는 코드를 뽑는 속도를 올리지만, 인도(delivery)의 안정성은 아직 깎는다. 그리고 사람은 자기가 얼마나 빨라졌는지를 과대평가한다.

3. 넥사크로·웹스퀘어는 무엇으로 생산성을 만드는가

이제 비교 대상의 작동 원리를 보자. 두 제품의 구조는 공식 문서로 확인된다.

넥사크로플랫폼(투비소프트, 1차·공식 문서)9

  • 개발도구: 넥사크로 스튜디오 — WYSIWYG IDE에서 화면 디자인·개발·디버깅·배포를 일원화
  • 프레임워크: Unified.js (자체 JS 프레임워크)
  • 실행환경: NRE/WRE — 자체 개발 렌더 엔진·스크립트 엔진
  • 화면 정의: XML 기반(.xfdl 등)으로 컴포넌트 속성·바인딩·이벤트를 선언, 비즈니스 로직은 별도 스크립트로 분리
  • 배포: 웹·모바일·데스크톱을 하나의 소스로(OSMU)

WebSquare5(인스웨이브, 1차·공식 문서)10

  • 구조: Engine(JAR, 웹서버에 설치되어 XML을 HTML로 서빙) + Studio(Eclipse 기반 WYSIWYG IDE)
  • 표방: No ActiveX, No Runtime, Only Standard (HTML5 웹표준)
  • 데이터 모델: DataCollection — DataMap(단일), DataList(목록), LinkedDataList(필터·정렬 뷰) 3종. 컴포넌트는 ref="data:[DataCollection ID].[Key/Column id]" 형태로 선언적 바인딩

두 제품이 생산성을 만드는 방식은 하나로 요약된다. 선택지를 없앤다.

  • 컴포넌트 세트가 고정된다 → “그리드 뭐 쓸까”를 논의하지 않는다
  • 화면이 XML 선언이다 → 레이아웃 구현 방식이 사람마다 갈리지 않는다
  • 데이터 바인딩 규약이 하나다 → 상태 관리 라이브러리 선택 논쟁이 없다
  • 런타임/배포 타깃이 하나다 → 브라우저 호환성 매트릭스가 제품 문제로 흡수된다

즉 개인의 최고 속도를 올리는 게 아니라, 팀 전체의 최저 속도를 끌어올리고 분산을 줄인다. 200명이 3년간 800개 화면을 찍어내야 하고 그중 상당수가 이 프레임워크를 처음 만지는 인력일 때, 이 성질은 “빠름”보다 훨씬 값이 나간다.

그리고 이건 인수인계·유지보수 구간에서 복리로 돌아온다. 5년 뒤 다른 SI 업체가 들어와도 화면 XML의 문법은 같다. React 프로젝트에서 “이건 2021년에 Redux로 짜다가 2023년에 절반만 Zustand로 옮긴 코드”를 만나는 것과 대비된다.

4. 바이브코딩은 무엇으로 생산성을 만드는가

정반대다. 제약을 없애서 만든다.

LLM에게 “결제 내역 테이블에 정렬·필터·페이지네이션 붙여줘”라고 하면 컴포넌트 라이브러리를 고르고, 상태 관리를 정하고, 타입을 세우고, 스타일을 붙인 결과물이 한 번에 나온다. IDE 팔레트에서 끌어다 놓는 것보다 훨씬 넓은 공간을 훨씬 빠르게 탐색한다.

문제는 그 넓은 공간이 곧 분산이라는 점이다. 같은 요구를 두 번 시키면 두 번 다른 구조가 나온다. 사람이 다르면 더 벌어진다. 자유도를 늘려서 얻은 속도는 정의상 표준화의 반대편에 있다.

그리고 이득이 발생하는 구간이 다르다. 개발 리드타임을 이렇게 쪼개보자.

\[T_{\text{total}} = T_{\text{draft}} + T_{\text{review}} + T_{\text{rework}} + T_{\text{maintain}}\]

바이브코딩이 확실하게 줄이는 것은 $T_{\text{draft}}$ 하나다. 나머지 셋은 줄지 않거나, 늘어난다. 읽지 않은 코드를 리뷰해야 하고, 이해하지 못한 코드를 고쳐야 하고, 작성자가 없는 코드를 유지보수해야 한다. DORA 2024가 관측한 “AI 채택 ↑ → 안정성 −7.2%”는 정확히 이 이전(displacement)의 관측치로 읽힌다.

여기에 암달의 법칙을 그대로 적용할 수 있다. 초안이 전체 리드타임에서 차지하는 비율을 $f$라 하면, 초안을 무한히 빠르게 만들어도 전체 속도 향상의 상한은

\[S_{\max} = \frac{1}{1-f}\]

$f=0.3$이면 $S_{\max} \approx 1.43$이다. 초안 작성 시간을 0으로 만들어도 전체는 1.43배밖에 못 빨라진다. “10배”가 나오려면 $f \geq 0.9$여야 하는데, 그건 리뷰도 통합도 유지보수도 없는 프로젝트, 즉 Karpathy가 말한 버릴 주말 프로젝트다. 원저자의 단서가 수식과 정확히 맞아떨어진다.

METR가 실측한 것은 바로 이 $T_{\text{total}}$이고, 그 값이 1보다 작지 않았다(19% 지연).

5. 결정적 비대칭 — 학습 코퍼스 밀도

여기서부터가 이 비교의 진짜 핵심이고, 대개 언급되지 않는 부분이다.

LLM의 코드 생성 품질은 그 스택의 공개 학습 코퍼스 밀도에 비례한다. 그래서 “넥사크로 vs 바이브코딩 React”는 사실상 바이브코딩이 가장 잘 되는 스택과 가장 안 되는 스택을 비교하는 것이다.

숫자로 확인해 보자. 아래는 2026-08-12 직접 측정한 값이다.

항목 React Nexacro WebSquare
Stack Overflow 질문 수 475,990 (reactjs 태그)11 전용 태그 없음 전용 태그 없음
대표 저장소 스타 247,110 (facebook/react)12 10 (nexacro-spring/nexacro-core)13 2 (inswave/inswave.github.io)14
벤더 공식 조직 공개 저장소 — 7개 (2015년 개설, 사실상 정지) 4개
벤더 공식 조직 스타 총합 — 약 20 2

스타 기준으로 약 12,000배, 커뮤니티 질문 기준으로는 분모가 0이라 비율조차 계산되지 않는다. 두 프레임워크의 한국어 질의응답은 벤더 자체 커뮤니티에 갇혀 있고, 그건 공개 크롤 코퍼스에 거의 들어가지 않는다.

범용 LLM에게 .xfdl 화면을 짜라고 하면 문법을 지어낸다. 컴포넌트 이름을 환각하고, 존재하지 않는 속성을 쓴다. 바이브코딩의 전제인 “안 읽고 Accept All”이 여기서는 성립하지 않는다. 틀린 것을 걸러내려면 결국 문법을 아는 사람이 전부 읽어야 하고, 그러면 $T_{\text{draft}}$ 절감마저 사라진다.

그리고 이 격차는 좁혀지는 게 아니라 벌어진다. React 코드는 매일 공개 저장소에 쌓이고 다음 모델의 학습 데이터가 된다. 독자 마크업 코드는 폐쇄망 고객사 서버에 쌓이고 아무 데도 가지 않는다.

두 벤더가 자체 코파일럿을 만든 것이 그 증거다

양사 모두 자체 AI를 내놨다.

  • 투비소프트 ‘넥사 AI’ (2025년 12월 발표, 벤더 발표): 자연어 코드 생성 Copilot, AI Inspect(표준 자동점검), AI Comment, AI Xporter, AI Analyzer. “자연어 명령만으로 넥사크로 환경에 최적화된 코드와 속성을 즉시 생성”.15 이전 세대 ‘NexaAssist’는 OpenAI 임베딩 모델 기반의 검색·추천이었지 생성이 아니었다.1
  • 인스웨이브 ‘WebSquare AI’ (2024년 출시, 벤더 발표): LLM 기반 코파일럿, 설계서→화면 자동생성, 코드 자동완성, Q&A, 테스트케이스 생성. 자체 SW개발 특화 LLM ‘딥스퀘어’ 보유를 주장.1617

이 사실을 뒤집어 읽는 게 중요하다. 범용 LLM이 자사 마크업을 다룰 수 있었다면 자체 코파일럿을 별도로 만들 이유가 없다. 벤더가 RAG나 파인튜닝으로 별도 시스템을 세워야 했다는 것 자체가 공개 코퍼스 부재의 자백이다.

동시에 이건 경로 하나가 열렸다는 뜻이기도 하다. 다만 이 코파일럿들의 성능을 검증한 제3자 자료는 찾지 못했다. 파운데이션 모델을 처음부터 학습시켰다는 근거도 확인되지 않는다(넥사 AI의 “OpenAI 임베딩 기반” 문구로 보아 범용 모델 + 자사 문서 RAG 구성으로 추정되나, 이는 추정이다). 현재로서는 벤더 주장이고 그 이상 말할 수 없다.

6. 그런데 금융·공공이 이걸 고르는 이유는 생산성이 아니다

여기서 흔한 오해 하나를 정리하자. 금융·공공이 넥사크로/웹스퀘어를 쓰는 1순위 이유는 “생산성이 좋아서”가 아니다.

정부 정책부터 확인하면, 행정안전부 「전자정부 웹사이트 품질관리 지침」(고시 제2020-38호)은 웹표준·호환성·접근성·개방성·접속성·편의성·신뢰성을 품질관리 원칙으로 명시한다.18 「공공사이트 플러그인 제거 가이드라인」(2018)은 플래시·실버라이트·자바애플릿·ActiveX 등 비표준 기술 제거를 점검 항목으로 못 박았다.19 금융위원회도 2015년 NPAPI 지원 중단 대응에서 “웹 표준(HTML5) 준수를 적극 유도”를 방침으로 밝혔다.20

중요한 것은 — 이 어떤 정책도 특정 상용 UI 프레임워크를 지정하지 않는다. 넥사크로도 웹스퀘어도 정책 문서에 등장하지 않는다.

그럼에도 사실상 표준처럼 굳은 이유는 정책이 요구하는 항목들이 제품 인증으로 환산되기 때문이다. 인스웨이브는 GS(굿소프트웨어) 1등급, SA(소프트웨어 접근성) 인증, 전자정부표준프레임워크 4.2 호환성 인증 보유를 조달 우위 요소로 내세운다(벤더 주장).21 조달 평가표에서 인증은 점수다. 인증 취득 비용을 감당할 수 있는 벤더만 남고, 그게 진입장벽이 된다.

실제 채택 규모도 확인된다(제3자 보도): 넥사크로 N은 조달청 디지털서비스몰 기준 점유율 1위(60.2%)로 보도되었고, 금융감독원이 2022년부터 약 200여 단위 업무 UI를 전환 중이다.22 인스웨이브는 2025년 3분기 기준 국무조정실·방위사업청·경찰청·소방청 등 20여 공공기관과 공급계약을 체결했다(전년 동기 13건 대비 증가).23

정리하면 이 프레임워크들이 파는 것은 개발 속도가 아니라 다음 다섯이다.

  1. 대량 그리드 성능 — 수만 행 렌더링·엑셀 유사 편집이 제품 기능으로 보장됨
  2. 접근성 인증 — SA 인증이 조달 요건에 직결
  3. 감사 추적성 — 화면 정의가 선언적 XML이라 산출물 대조·감리가 성립
  4. 벤더 SLA와 책임 소재 — 장애 시 계약상 책임질 상대가 존재
  5. 표준화된 인력 시장 — “넥사크로 경력 3년” 인력을 조달할 수 있음

바이브코딩은 이 다섯 중 무엇도 공급하지 못한다. 특히 3번과 4번은 기술이 아니라 계약의 문제다.

7. 그렇다고 락인 비용이 공짜인 것도 아니다 — 투비소프트 사례

자유도를 벤더에게 넘긴 값은 벤더가 흔들릴 때 청구된다. 지금 실제로 벌어지고 있는 일이다.

투비소프트(코스닥 079970)는 2024·2025 회계연도 재무제표에 대해 2년 연속 감사의견 거절(감사범위 제한)을 받았고, 한국거래소 코스닥시장본부는 2026년 6월 4일 상장폐지를 결정했다(정리매매 6/8~6/16, 상장폐지일 6/17 예정).24 회사가 상장폐지결정 효력정지 가처분을 신청하면서 거래소는 6월 5일 정리매매와 상장폐지 일정을 정정하고 6월 8일부터 매매거래를 정지했다 — 정지 만료 시점은 “법원의 결정 확인 시까지”다.2526 이 글을 쓰는 2026년 8월 12일 기준 법원의 최종 판단을 확인할 수 있는 공개 자료는 찾지 못했다.

재무 추이도 같은 방향이다(DART 사업보고서 기준, 연결 매출, 억원): 2021년 378 → 2022년 432 → 2023년 430 → 2024년 281 → 2025년 268. 2021~2024년 영업적자가 이어졌고, 2025년 영업이익 2.1억 원으로 흑자 전환했으나 매출 감소는 계속됐다. 경영난에 따른 임금 체불과 인력 이탈(약 3개월간 직원 50명 감소)도 보도되었다.27

대비되게 인스웨이브(코스닥 450520, 2023년 9월 상장)는 매출 2020년 211 → 2022년 436 → 2023년 326 → 2024년 304 → 2025년 388억 원으로, 조정 구간을 거쳐 재성장 중이다(DART 사업보고서 기준).

여기서 끌어낼 교훈은 “투비소프트를 쓰지 마라”가 아니다. 한 회사의 독자 런타임에 화면 자산 전체를 얹는다는 것은 그 회사의 재무 상태를 시스템 리스크로 편입하는 것이라는 점이다. React를 쓸 때는 이 항목이 아예 존재하지 않는다. 오픈소스의 진짜 값은 성능이 아니라 여기에 있다.

역설적이지만 이건 바이브코딩 진영의 가장 강한 논거이기도 하다. 생산성이 아니라 자산의 이동 가능성 쪽에서 나온다.

8. 그래서 어디에 무엇을 쓰나

두 축이 다르므로 대체 관계가 아니라 배치 문제로 봐야 한다.

상황 적합 이유
폐쇄망 금융 원장, 수백 화면, 다년 SI, 인력 회전 큼 넥사크로/웹스퀘어 분산 축소·감리·SLA·인력 조달
대내 백오피스, 대량 그리드, 접근성 인증 필수 넥사크로/웹스퀘어 그리드 성능·SA 인증
대외 서비스, 디자인 차별화, 프론트 인력 상시 보유 React 생태계·채용·자산 이동 가능성
PoC·프로토타입·내부 도구·검증용 화면 바이브코딩 React $f$가 크고 유지보수 부담이 작음
마이그레이션 타당성 검토 바이브코딩 React 버릴 코드를 싸게 만드는 게 목적

그리고 실무에서 실제로 유효한 조합 하나. 레거시 화면 명세를 읽고 이관 계획을 세우는 작업에는 LLM이 잘 듣는다. XML 화면 정의는 선언적이라 구조 파싱과 목록화에 강하고, 이건 코드 생성이 아니라 독해다. 생성은 못 해도 읽는 건 한다.

바이브코딩을 조직에 들일 때의 실무 규칙도 위 증거에서 그대로 따라 나온다.

  1. $f$가 큰 곳에만 쓴다 — 리뷰·통합·유지보수 부담이 작은 구간
  2. 변경 단위를 강제로 작게 유지한다 — DORA 2024가 지목한 실패 경로가 batch size다
  3. 체감을 지표로 대체한다 — METR가 보인 대로 자기보고는 39%포인트까지 틀린다. 변경 리드타임과 변경 실패율을 실제로 측정한다
  4. 안정성 지표를 같이 본다 — DORA 2025에서도 안정성은 아직 마이너스다

9. 이 글이 말하지 못하는 것

정직하게 한계를 적는다.

  • 넥사크로/웹스퀘어와 React의 생산성을 같은 조건에서 비교한 중립 벤치마크는 존재하지 않는다. 이 글도 그런 비교를 하지 않았다. 양쪽의 생산성 수치는 전부 벤더 주장이며, 그 사실을 지적하는 것까지가 이 글의 범위다.
  • METR 결과는 숙련 개발자 16명, 성숙한 오픈소스 저장소라는 특정 조건의 실측이다. 그린필드나 주니어 대상 일반화는 근거가 없다.
  • DORA는 관측 연구라 인과가 아니다. “AI 때문에 안정성이 떨어졌다”가 아니라 “AI 채택률과 안정성이 음의 상관”이다.
  • 넥사 AI·WebSquare AI의 실제 코드 생성 품질을 검증한 제3자 자료를 찾지 못했다. 이 코파일럿들이 코퍼스 희소성 문제를 실제로 얼마나 해결했는지는 현재 알 수 없다.
  • 코퍼스 밀도 수치는 2026-08-12 시점의 측정값이며 변동한다.

마무리

“넥사크로가 빠른가 바이브코딩이 빠른가”는 잘못 세운 질문이다. 둘은 서로 다른 것을 최적화한다.

넥사크로·웹스퀘어는 누가 만들어도 같은 결과가 나오게 해서 조직 단위 처리량을 만든다. 대가로 자유도와 벤더 독립성을 내놓는다 — 그 값은 투비소프트 사례에서 지금 청구되고 있다.

바이브코딩은 한 사람이 짧은 시간에 많이 만들게 해서 개인 단위 처리량을 만든다. 대가로 표준화와 예측 가능성을 내놓고, 비용을 리뷰·유지보수 구간으로 미룬다. 그리고 그 이득은 $1/(1-f)$라는 천장을 넘지 못한다.

마지막으로 하나만 더. 이 비교에서 바이브코딩 쪽이 구조적으로 불리한 지점이 있다는 것이 이 글에서 새로 확인된 사실이다. 넥사크로와 웹스퀘어의 공개 코드 코퍼스는 각각 스타 20개와 2개다. LLM의 힘이 데이터에서 나오는 한, 이 두 스택은 바이브코딩이 가장 안 통하는 영역으로 남는다. 그리고 그 격차는 매일 벌어진다.

그래서 실제 결론은 이렇다. 바이브코딩이 넥사크로·웹스퀘어를 대체할 가능성보다, React 진영과 SI 진영 사이의 기술 격차가 더 벌어질 가능성이 높다.

References

  1. 투비소프트, 「넥사크로 N 제품소개서」(PDF, 1차·벤더 자료). https://www.tobesoft.com/download/product/nexacro/Nexacro_N.pdf ↩ ↩2

  2. 인스웨이브시스템즈 뉴스레터 2014년 7월호 (1차·벤더 자료). http://www.inswave.com/inswave/newsletterIns/201407/solution.html ↩

  3. 한국소프트웨어산업협회 SW유통시스템, WebSquare5 구축사례 (벤더 제출 자료, 제3자 검증 불가). https://data.kosw.or.kr/egovdata/cop/bbs/selectBoardArticle.do?bbsId=BBSMSTR_000000000181&nttId=4233 ↩

  4. Andrej Karpathy, X(구 Twitter), 2025-02-02 (1차·원저자). 아카이브: https://archive.is/yNSTA · 인용: Simon Willison, “Not all AI-assisted programming is vibe coding”, 2025-03-19, https://simonwillison.net/2025/Mar/19/vibe-coding/ ↩

  5. METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, 2025-07-10 (1차·연구). https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ · arXiv:2507.09089, https://arxiv.org/abs/2507.09089 ↩

  6. Google Cloud DORA, “2024 Accelerate State of DevOps Report” (1차·연구). https://dora.dev/research/2024/dora-report/ ↩

  7. Google Cloud DORA, “2025 State of AI-assisted Software Development Report” (1차·연구). https://dora.dev/dora-report-2025/ ↩ ↩2

  8. Stack Overflow, “2025 Developer Survey” (1차·설문). https://survey.stackoverflow.co/2025/ ↩

  9. 투비소프트 공식 제품 페이지 및 넥사크로 17 공식 문서 (1차·공식). https://www.tobesoft.com/product/nexacro · https://docs.tobesoft.com/product_information_nexacro_17_ko/6b366e2b289d3393 ↩

  10. 인스웨이브 WebSquare5 공식 사용자 가이드, Ch.01 및 Ch.21 DataCollection (1차·공식). https://docs.inswave.com/support/guide/sp4_english_html/chapter_01.xhtml · https://docs1.inswave.com/sp5_user_guide/dde1408893e6e120 ↩

  11. Stack Overflow reactjs 태그 질문 수, 2026-08-12 측정. https://stackoverflow.com/questions/tagged/reactjs ↩

  12. GitHub facebook/react 스타 수, 2026-08-12 측정. https://github.com/facebook/react ↩

  13. GitHub nexacro-spring (투비소프트 공식 조직) 저장소 목록, 2026-08-12 측정. https://github.com/nexacro-spring ↩

  14. GitHub inswave (인스웨이브 공식 조직) 저장소 목록, 2026-08-12 측정. https://github.com/orgs/inswave/repositories ↩

  15. “투비소프트, AI 개발 플랫폼 ‘넥사 AI’ 공개”, ZDNet Korea, 2025-12-04 (제3자 보도, 내용은 벤더 발표). https://zdnet.co.kr/view/?no=20251204142005 · 공식 페이지 https://nexacro.co.kr/nexaai/nexaai ↩

  16. “인스웨이브시스템즈, AWS 서밋서 웹스퀘어 AI 소개”, ZDNet Korea, 2024-05-20 (제3자 보도, 내용은 벤더 발표). https://zdnet.co.kr/view/?no=20240520155305 ↩

  17. 인스웨이브 이노베이션 데이 2025 관련 보도, ZDNet Korea, 2025-03-20 (제3자 보도, 내용은 벤더 발표). https://zdnet.co.kr/view/?no=20250320135355 ↩

  18. 행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2020-38호, 2020-07-30 전부개정) (1차·공식). 국가법령정보센터: https://law.go.kr/LSW/admRulLsInfoP.do?admRulSeq=2100000191651 ↩

  19. 행정안전부, 「공공사이트 플러그인 제거 가이드라인」, 2018-11-06 (1차·공식). https://hrstpolicy.re.kr/kistep/download/WebsiteQualityControlGuidelines.pdf · 관련 보도: 연합뉴스 2018-11-06, https://www.yna.co.kr/view/AKR20181106038600004 ↩

  20. 금융위원회, 「[보도참고] 구글 NPAPI 지원중단에 따른 금융소비자 유의사항」, 2015 (1차·공식). “관계부처 및 유관기관과 공조하여 웹 표준(HTML5) 준수 및 새로운 방식의 인증·보안기술의 도입을 적극 유도” 문구 확인. https://www.fsc.go.kr/po010101/71712 ↩

  21. “인스웨이브, 공공기관 20여 곳과 웹스퀘어5 공급계약”, ZDNet Korea, 2025-11-12 (제3자 보도, 인증 보유 및 순위 관련 내용은 벤더 주장). https://zdnet.co.kr/view/?no=20251112171851 · 전자신문 https://www.etnews.com/20251112000404 ↩

  22. “넥사크로 N, 조달청 디지털서비스몰 점유율 1위”, 헤럴드경제, 2024-03-05 (제3자 보도, 원자료는 조달청 데이터). https://biz.heraldcorp.com/article/3339752 ↩

  23. 이투데이, 2025-11-12 (제3자 보도). https://www.etoday.co.kr/news/view/2524699 ↩

  24. 한국거래소 코스닥시장본부 공시, 「주권매매거래정지해제 — 상장폐지에 따른 정리매매 개시」, 2026-06-04 (1차·거래소 공시). 상장폐지사유: 감사의견 거절(감사범위 제한), 근거규정: 코스닥시장상장규정 제18조. 보도: 디지털투데이, https://www.digitaltoday.co.kr/news/articleView.html?idxno=635489 ↩

  25. 한국거래소 공시, 「정리매매 보류 관련 시장안내」 및 「주권매매거래정지」, 2026-06-05 (1차·거래소 공시). 보도: 이데일리, https://www.edaily.co.kr/News/Read?newsId=04444406645478768 ↩

  26. “투비소프트, 상폐 효력정지 가처분 신청…8일부터 거래정지”, 더파워, 2026-06-05 (제3자 보도). https://www.thepowernews.co.kr/view.php?ud=202606051506035455de3f0aa1be_7 ↩

  27. 투비소프트 DART 사업보고서 (1차·공시). https://kind.krx.co.kr/external/2025/03/24/001179/20250324003935/11011.htm · 경영난 관련 보도: 뉴스웨이 2026-07-14, https://www.newsway.co.kr/news/view?ud=2026071416234796838 ↩