중소·중견기업 시스템 구축, 왜 실패하는가

한눈에 보기

• 문제: 중소·중견기업은 업무 시스템을 만들 방법이 마땅치 않다. 전산팀은 과부하, 외주는 비용 장벽, 프리랜서는 유지보수 공백이다.
• 더 큰 문제: 어렵게 만들어도 오래가지 못한다. 만든 사람이 떠나면 아무도 고치지 못하고, 결국 방치되다 폐기된다.
• 최근의 오해: 생성형 AI로 직접 만들면 된다는 기대가 있으나, 화면은 나와도 실제 업무 시스템에 필요한 데이터·권한·알림·연동까지는 닿지 못한다.
• 대안: canai.team은 기획자가 실제 작동하는 화면 위에서 기획하고, 자연어로 고치고, 검증된 모듈과 자동 테스트로 유지하는 방식을 제공한다.
• 요청: 소규모 업무 1건을 대상으로 한 시범 구축 검토. → 10. 다음 단계

1. 추진 배경과 문제 정의

중소·중견기업이 업무 효율화를 위해 시스템 구축을 시도할 때 직면하는 구조적 한계와 실패 요인은 다음과 같다.

① 기존 시스템 개발 방식의 3대 한계

• 내부 전산팀 의뢰: 전산팀은 ERP·보안·장애 대응처럼 더 급한 일을 먼저 한다. 그 결과 현업의 신규 기획안은 후순위로 밀리고 소통 과정에서 무산되는 경우가 많다. 전산팀의 역량 문제가 아니라 우선순위의 문제다.
• 외부 전문 업체 위탁: 초기 개발 비용 부담이 커 추진 단계에서 좌절된다.
• 프리랜서 고용: 단기 비용은 낮으나 개발 후 연락 두절, 인수인계 부재 등으로 유지보수 리스크가 높다.

② IT 인력의 구조적 불안정성

• 전문업체(법인)와 계약을 맺더라도 실제 개발은 '사람'이 담당한다. IT 업계의 평균 퇴사율은 약 20% 수준이다.
• 시스템을 만든 핵심 개발자가 장기간 잔류할 확률이 낮고, 인력이 교체되면 기존 코드를 파악하지 못해 시스템이 낙후되거나 결국 폐기된다.

③ 경영진의 시스템 투자 인식 장벽

• "지금도 인력(엑셀 등 수작업)으로 돌아가는데 왜 굳이 비용을 들여 시스템을 만드느냐"는 인식이 존재한다.

2. 'AI 직접 개발'과 '단순 AI 대행'의 한계

최근 생성형 AI를 활용한 코딩이 대안으로 부각되었으나, 실무 적용에는 명확한 기술 장벽이 존재한다.

① 개인 수준의 AI 코딩(바이브 코딩)의 실패 요인

• 작동 불능 및 무한 루프: 웹페이지의 레이아웃(퍼블리싱)은 나오지만 실제 기능이 연동되지 않고, 오류를 고치는 과정에서 코드가 꼬이는 '바이브 코딩(Vibe Coding)'의 악순환이 발생한다.
• 실제 비즈니스의 복잡성: 단순 예제와 달리 실무는 데이터베이스(DB) 설계, 로그인·권한 설정, 알림·메일 발송 등 인프라 연동이 필수적이어서 비개발자가 혼자 감당하기 어렵다.

② 단순 AI 시스템 개발 업체의 한계

• 기획서를 전달하고 요건 정의를 거쳐 납품받더라도, 실제 작동 화면을 사용해보는 단계에서 최초 기획과의 괴리가 대거 발견된다.
• 구축 이후 비즈니스 환경 변화나 경영진 지시에 맞춰 시스템을 수정해야 할 때, 담당 개발자 퇴사 등으로 고치지 못하고 버려지는 악순환이 반복된다.

3. 그렇다면 canai.team은 무엇이 다른가

"화면을 보고 자연어로 고친다"는 점만 보면 앞서 지적한 바이브 코딩과 같아 보인다. 차이는 말로 고친다는 점이 아니라, 고친 것이 무너지지 않게 받쳐주는 기반에 있다.

4. 해결 방식

canai.team은 기획자가 시스템 구성부터 지속적인 유지보수까지 직접 주도할 수 있는 환경을 제공한다.

① 실제 작동 화면 기반의 '살아있는 기획'

• 종이 기획서로 소통하는 대신, 실제 구동되는 화면을 먼저 확인하며 기획을 구체화하고 논리적 모순을 보완한다.
• 기획자가 화면에서 수정할 영역을 선택하고 "여기에 날짜 선택 도구를 추가해줘"와 같이 자연어로 요청하면 반영된다. 복잡한 개발 도구나 터미널 조작이 필요 없다.

② 신속하고 정밀한 테스트 환경

• 기획자가 작성하기 어려워하는 테스트 시나리오를 화면 구성을 기반으로 자동 생성한다.
• 확정된 시나리오는 Playwright 등 검증된 자동화 도구로 반복 실행되어, 수정할 때마다 기존 기능이 망가지지 않았는지 확인한다.

③ 안전한 자산 관리와 소스코드 투명성

• 모든 소스코드는 깃허브(GitHub) 저장소로 관리되어 변경 이력이 남고 기술적 종속을 예방한다. 소스 반출 조건은 8. 자주 나오는 질문 참조.

5. 핵심 기술력과 비용 효율성

① 준비된 공통 표준 모듈

매번 처음부터 새로 짜지 않고, 검증된 모듈을 조립해 구축 기간과 오류를 줄인다.

• 인증/권한: 회원가입 및 역할 기반 권한 관리(Role-based Auth)
• 보안/백업: 침입 방지 모듈 및 자동 데이터 백업 인프라
• 커뮤니케이션: 메일 및 카카오 알림톡 자동 발송 모듈
• 유틸리티: 대용량 엑셀 업로드/다운로드 변환 모듈
• 모바일·현장 입력: 사진 촬영과 위치·시각 기록을 포함한 현장 입력 모듈

② 시스템의 지속적 최신화 (외딴섬 현상 방지)

• 개발된 채 방치되어 기술적으로 낙후되는 일반 시스템과 달리, 표준 모듈을 주기적으로 최신 기술에 맞춰 갱신한다. 이미 구축된 시스템도 기술 기반이 함께 따라간다.

6. 도입 형태와 비용

경영진의 의사결정 방식을 고려해 두 가지 도입 형태를 제안한다.

• 월 구독 모델: 초기 비용 부담 없이 시작해 효율을 먼저 검증한다. 구독료는 아직 결정 전이다.
• 영구 구매(소유) 모델: 시스템 소유권을 기업의 무형자산으로 확보해 비용 승인 절차를 단순화한다. 구매가는 아직 결정 전이다.

7. 도입 사례

실제 운영 중인 시스템을 바탕으로 작성 준비 중이다.

8. 자주 나오는 질문

도입 검토 자리에서 반드시 제기되는 질문들이다.

Q. canai.team 서비스가 중단되면 우리 시스템은 어떻게 되나?

• 모든 소스코드는 깃허브(GitHub) 저장소에 보관되며 소유권은 고객사에 있다. 서비스가 중단되더라도 고객사는 소스와 데이터를 그대로 보유하므로, 다른 인력이나 업체가 이어받아 운영·수정할 수 있다.

Q. 소스코드와 데이터의 소유권은 누구에게 있나?

• 고객사에 있다. 소스는 깃허브 저장소로 관리되어 변경 이력까지 고객사가 확인하고 언제든 내려받을 수 있다.

Q. 기존 회계·인사·그룹웨어와 연동되나?

• 연동 API 모듈을 통해 ERP, 그룹웨어, SSO(통합 로그인), 구글 워크스페이스, 마이크로소프트 팀즈 등 사내에서 사용하는 시스템과 연결한다.

Q. 전산팀과는 어떻게 협업하나?

• 전산팀을 대체하지 않는다. 보안·연동·데이터 기준을 정하는 주체는 전산팀이며, 그 기준 안에서 전산팀이 우선순위를 두기 어려운 현업의 작은 업무 시스템을 맡는다. 소스와 변경 이력은 전산팀이 언제든 확인할 수 있다.

Q. 비개발자가 정말 수정할 수 있나?

• 개발 도구 대신 웹 화면에서 수정할 영역을 선택하고 채팅으로 요청하는 방식이다. 수정 후에는 자동 테스트가 기존 기능의 이상 여부를 확인한다.

Q. 보안 점검·감사 요구에 대응할 수 있나?

• 권한 관리, 감사 로그, 백업·복구가 공통 모듈에 포함되며, 보안 감사에 필요한 문서를 제공한다.

9. 기대 효과

• 구축 기간과 비용 절감: 외주 소통 단계와 재개발 비용을 줄여 현업에 빠르게 적용한다.
• 유지보수 공백 해소: 담당 개발자 교체와 무관하게, 기획자가 자연어 요청으로 시스템을 계속 고칠 수 있다.
• 현업 맞춤 최적화: 실제 사용하는 실무자 손에서 계속 다듬어지는 시스템을 구축한다.

10. 다음 단계

1. 시범 대상 업무 1건 선정 — 사용 인원이 적고 효과가 눈에 보이는 업무를 권장한다.
2. 해당 업무의 화면 초안 시연 — 문서가 아니라 작동 화면으로 확인한다.
3. 시범 구축 범위와 비용 확정 — 6장의 미정 항목이 이 단계에서 결정된다.