기존 시스템(Brownfield) 기반의 헬스케어 제품. 관계를 유지하지 못했던 두 곳의 이전 벤더들. 그리고 고객사의 리더십 팀이 AI-Native 개발이 실제로 무엇을 의미하는지에 대한 생각을 바꾸게 할 만큼 빠르게 출시된 첫 번째 모듈.

2주 전, 우리는 실제 임상적 영향력을 가진 병원용 플랫폼을 구축하는 헬스케어 제품 기업과 협업을 시작했습니다. 이것은 완전히 새로운 프로젝트(Greenfield) 이야기가 아닙니다. 우리 이전에도 한 곳 이상의 벤더가 이 고객사를 놓쳤는데, 이는 제품이 잘못되어서가 아니라 지속적으로 가치를 증명하거나 약속한 바를 이행하지 못했기 때문입니다.

그것이 우리가 마주한 상황이었습니다. 기존 코드베이스(Brownfield codebase), 이전에 데인 적이 있는 고객, 그리고 핵심 소프트웨어와 함께 여러 하드웨어 통합을 포함할 만큼 복잡한 제품. 이것이 처음 2주 동안 일어난 일이며, 왜 고객사의 CEO가 포옹을 요청하며 끝났는지에 대한 이유입니다.

목차

1. 첫날 우리가 설정한 기대치
2. 70~80%를 뒷받침하는 장치
3. 2주 만에 출시된 첫 번째 모듈
4. 회의
5. 이 이야기가 실제로 증명하는 것
6. 이것이 왜 '바이브 코딩(Vibe Coding)'이 아니었는가
7. 자주 묻는 질문(FAQs)

첫날 우리가 설정한 기대치

코드 한 줄을 쓰기 전에, 우리는 헬스케어 소프트웨어 분야에서 눈썹을 치켜뜨게 만들 법한 이야기를 고객에게 했습니다. 바로 AI, 구체적으로 Claude 모델을 사용하여 코드베이스의 약 70~80%를 생성하겠다는 것이었습니다.

여러 하드웨어 통합과 환자 안전 및 규정 준수에 관한 엄격한 요구사항이 포함된 이토록 복잡한 제품에 대해, 이미 벤더들의 과잉 약속을 지켜봐 온 고객에게 이는 대담한 주장입니다. 이것은 나머지 20~30%인 아키텍처(Architecture), 의사결정 워크플로우(Decision workflows), 설계 규율(Design discipline)이 완벽할 때만 가능합니다.

기술 스택(The stack):

웹 프론트엔드, 병원 현장용 데스크톱 애플리케이션, 그리고 클라우드 인프라(Cloud infrastructure) 전반에 걸쳐 실행되는 저 기술 스택은, 이를 하나로 묶어주는 프로세스가 없다면 AI가 생성한 코드가 조용히 잘못될 수 있는 바로 그러한 접점(Surface area)입니다.

70~80%를 뒷받침하는 제어 장치 (The Harness)

새로운 프로젝트의 램프업(Ramp-up) 단계 중이었음에도 불구하고 우리가 그러한 약속을 자신 있게 할 수 있었던 이유는, 우리가 즉흥적으로 행동하지 않았기 때문입니다. 우리에게는 계획(Planning), 코딩(Coding), 리뷰(Review) 전반에 걸쳐 팀이 AI 모델을 사용하는 방식을 규정하는 내부 ADLC, 즉 AI 개발 라이프사이클(Lifecycle) 프로세스와 제어 장치(Harness)가 있습니다. 이는 AI 모델에 반복적으로 프롬프트를 입력하며 요행을 바라는 것과, AI 생성을 반복 가능하고 구조화된 프로세스를 통해 실행하는 것의 차이입니다.

그 프로세스 위에는 프레임워크에서 얻을 수 없는 경험이 자리 잡고 있습니다. 2만 시간의 실무 코딩 경험 덕분에, 우리의 리드 엔지니어는 AI가 생성한 결과물을 검토할 때 AI 모델이 내놓은 첫 번째 버전을 그대로 수용하는 대신, 결정 워크플로(Decision workflows)를 SOLID 원칙과 확립된 디자인 패턴(Design patterns)을 중심으로 재구조화해야 하는 지점을 즉각적으로 파악할 수 있었습니다.

AI는 코드를 생성할 수 있습니다. 하지만 그 코드 중 어떤 버전을 실제로 배포해야 하는지 아는 데에는 실제 엔지니어링적 판단(Engineering judgment)이 필요합니다.
AI 보조(AI-assisted) 개발과 AI 네이티브(AI-native) 개발 사이의 간극

2주 만에 출시된 첫 번째 모듈

프로젝트 시작 후 2주 이내, 기술적으로는 여전히 램프업 단계였음에도 불구하고 우리는 첫 번째 모듈을 인도했습니다. 그것은 프로토타입(Prototype)이나 데모(Demo) 형태로 전달된 것이 아니라, 실제 빌드(Build) 형태로 인도되었습니다.

코드와 함께, 우리는 일반적인 인수인계 문서(Handoff doc)를 훨씬 뛰어넘는 문서를 전달했습니다. 우리는 문서를 9개의 섹션으로 나누었으며, 각 섹션은 단순히 엔지니어링 팀이 습관적으로 기록하는 내용이 아니라, 병원 소프트웨어 구매자가 실제로 질문하는 사항들을 다루었습니다.

1. 경영 요약 및 아키텍처 (Executive Summary & Architecture)
2. 명명 규칙 (Naming Conventions)
3. 설계 철학 (Design Philosophy) (협상 불가능한 원칙)
4. 환자 안전 최우선 (Patient Safety First)
5. 설계에 의한 보안 (Security by Design)
6. 아키텍처로서의 컴플라이언스 (Compliance as Architecture)
7. 회복 탄력성 아키텍처 (Resilience Architecture)
8. 부채 없는 유지보수성 (Maintainability Without Debt)
9. 기록된 결정, 규제 준수 및 구현 로드맵 (Recorded Decisions, Regulatory Compliance & Implementation Roadmap)

저 목록에 무엇이 있는지 주목하십시오. 환자 안전과 보안은 부록에 덧붙여진 사후 고려 사항이 아닙니다. 그것들은 아키텍처와 나란히, 협상 불가능한 설계 철학으로 명시되어 있습니다. 이는 의도적인 선택이며, AI가 당신이 이를 빠르게 작성하도록 도울 수는 있지만, 대신 결정해 줄 수는 없는 종류의 선택입니다.

회의 (The Meeting)

우리는 고객사의 경영진에게 모듈과 문서를 안내했습니다. 반응은 고객이 만족했을 때 보이는 정중한 고개 끄덕임이 아니었습니다. 그것은 오히려 불신에 가까운 것이었습니다.

회의가 끝날 무렵, CEO가 일어섰습니다. 악수를 하려던 대신 그는 이렇게 물었습니다. "Raj, 한번 안아봐도 될까요?" 이는 우리가 받은 최고의 찬사 중 하나였습니다. 정확히 말하자면, 그것이 세련된 기업용 언어가 아니었기 때문입니다. 그것은 수개월이 걸릴 것으로 예상되었던 작업이 2주로 압축된 것을 본 것에 대한 진실된 반응이었습니다.

회의 전, COO는 우리를 따로 불러 가장 눈에 띄었던 점은 속도가 아니었다고 말했습니다. 그것은 우리 팀이 소프트웨어 엔지니어링의 베스트 프랙티스 (Best Practices)를 핵심적으로 고민하며, 단순히 기능 (Features)이 아닌 시스템 (Systems)을 구축한다는 점이었습니다. 기술적 방향을 밀접하게 지도해 온 CTO는 팀의 주도성, 커뮤니케이션, 대응력, 그리고 우리가 얼마나 일관되게 높은 기준을 스스로에게 적용하는지에 대해 깊은 인상을 받았다고 말했습니다.

이 이야기가 실제로 증명하는 것

이 내용을 단순히 "AI가 빠르게 만들었다"라고 읽기는 쉽습니다. 그것은 사실이지만 불완전하며, AI에 관한 대화에서 가장 지나치게 단순화되는 부분입니다.

AI는 어떤 디자인 패턴 (design patterns)을 강제할지, 어떤 의사결정 워크플로우 (decision workflows)에 인간의 검토가 필요한지, 또는 규제가 엄격한 병원 플랫폼의 어떤 섹션을 첫 번째 AI 출력물에 맡겨두어서는 안 되는지를 결정하는 판단력을 대체하지 않았습니다. AI가 한 일은 코드의 7080%를 수동으로 작성해야 했던 기계적인 저항을 제거함으로써, 숙련된 엔지니어들이 병원 소프트웨어가 5년 후에도 안전하고, 규정을 준수하며, 유지보수 가능한지를 실제로 결정짓는 나머지 2030%의 작업에 거의 모든 시간을 쏟을 수 있도록 한 것입니다.

그것이 바로 AI-native development (AI 네이티브 개발)의 진정한 정의입니다. 엔지니어링을 줄이는 것이 아닙니다. AI가 과거 시니어 엔지니어의 시간을 몇 달씩 잡아먹었던 무게를 짊어짐으로써, 더 중요한 부분에 엔지니어링을 더 많이 적용하는 것입니다.

이것이 '바이브 코딩 (Vibe Coding)'이 아닌 이유

이 이야기가 무엇이 아닌지를 명확히 짚고 넘어갈 가치가 있습니다. 왜냐하면 현재 이 두 가지가 끊임없이 혼동되고 있기 때문입니다. 자연어로 AI 모델에 프롬프팅 (prompting)을 하고 모델이 내놓는 결과물을 그대로 배포하는 '바이브 코딩 (Vibe coding)'은 프로토타입, 내부 도구, 그리고 아이디어를 빠르게 검증하는 데에는 진정으로 유용합니다. 하지만 이는 이번 프로젝트에서 일어난 활동과는 동일한 작업이 아니며, 그 차이는 철학적인 것이 아니라 구조적인 것입니다.

보안 연구원들 (Security researchers)과 엔지니어링 팀들은 지난 1년 동안 동일한 패턴을 반복해서 기록해 왔습니다. 통제된 검토 프로세스 (governed review process) 없이 배포되는 AI 생성 코드는 악용 가능한 취약점 (vulnerabilities), 코드베이스 전반의 일관성 없는 패턴, 누락된 에러 핸들링 (error handling), 그리고 감사 추적 (audit trail)의 부재를 초래하는 경향이 있다는 것입니다. 이는 주말 동안 만드는 프로토타입에는 수용 가능한 트레이드오프 (trade-off)일 수 있습니다. 하지만 환자 데이터를 다루고, 병원 하드웨어와 통합되며, 5년 후에도 규제 기관의 조사(regulatory scrutiny)를 견뎌내야 하는 소프트웨어에는 결코 수용될 수 없는 일입니다.

우리가 이 고객에게 언급했던 7080%라는 수치는 바이브 코딩 (vibe coding)과 AI-native 개발이 표면적으로 공유하는 부분입니다. 두 방식 모두 AI가 코드의 대부분을 생성하게 해줍니다. 하지만 그 수치 아래에 숨겨진 모든 요소에서 두 방식은 갈라집니다. 즉, AI가 어떻게 프롬프트(prompt)되고 검토되는지를 제어하는 하네스 (harness), 모델이 그날그날 기본값으로 설정한 패턴이 아닌 SOLID 원칙을 기반으로 구축된 의사결정 워크플로우 (decision workflows), 모든 설계 선택을 환자 안전 및 규정 준수 (compliance)와 연결하는 문서화 추적 (documentation trail), 그리고 AI 모델이 틀리거나 위험할 정도로 모호하게 남겨두는 2030%를 잡아낼 수 있는 충분한 실무 경험을 갖춘 엔지니어들이 필요합니다.

바이브 코딩 (vibe coding)은 작동하는 데모를 얼마나 빨리 만들 수 있는지에 최적화되어 있습니다. 반면, 제대로 수행된 AI-native 개발은 데모가 끝난 후에도 시스템이 여전히 안전하고, 감사 가능하며 (auditable), 유지보수 가능한지(maintainable)에 최적화되어 있습니다. 병원 플랫폼에게 있어, 두 번째 질문이야말로 유일하게 중요한 질문입니다.

자주 묻는 질문 (Frequently Asked Questions)

헬스케어 분야에서 AI-native 소프트웨어 개발이란 무엇을 의미하나요?
Claude와 같은 AI 모델이 프로덕션 코드 (production code)의 대부분, 통상적으로 70~80%를 생성하는 동시에, 엔지니어는 아키텍처 (architecture), 의사결정 워크플로우 (decision workflows), 보안 및 규정 준수 (compliance)에 집중하는 것을 의미합니다. 이는 작은 코드 조각에 대해 가끔씩 AI의 도움을 받는 것과는 다릅니다.

병원급 소프트웨어를 구축하는 데 보통 얼마나 걸리나요?
하드웨어 통합 및 규정 준수 요구사항이 필요한 병원용 모듈의 전통적인 개발 방식은 종종 5~6개월이 소요됩니다. AI-native 프로세스와 확립된 엔지니어링 하네스 (engineering harness)를 사용하면, 유사한 범위의 작업도 몇 주 만에 출시할 수 있습니다.

규제 산업에서 AI가 정말로 프로덕션 코드의 70~80%를 작성할 수 있나요?
네, 강력한 엔지니어링 규율 (engineering discipline)이 결합된다면 가능합니다. AI가 생성한 코드는 그 코드를 둘러싼 인간 주도의 의사결정 워크플로우 (decision workflows), 디자인 패턴 (design patterns), 그리고 규정 준수 아키텍처 (compliance architecture)의 수준만큼만 품질을 보장받을 수 있습니다.

병원 기기 및 하드웨어 통합에는 어떤 기술 스택이 효과적인가요?
일반적인 패턴은 React 프론트엔드, 온프레미스 (on-premises) 병원용 Electron 데스크톱 애플리케이션, 데이터 처리 및 AI 오케스트레이션 (orchestration)을 위한 Python 백엔드, 그리고 AWS 인프라를 결합하며, 하드웨어 및 기기 통합을 위한 전용 레이어 (layer)를 포함합니다.

ADLC, 즉 AI 개발 생명주기 (AI development lifecycle)란 무엇인가요?
이는 계획, 코딩, 리뷰 전반에 걸쳐 AI 모델이 사용되는 방식을 제어하는 구조화된 프로세스이자 프레임워크입니다. 이를 통해 AI-네이티브 (AI-native) 개발이 임시방편 (ad hoc)이 아닌 반복 가능한 프로세스가 되도록 하며, 이는 규제가 엄격하고 환자를 직접 대면하는 소프트웨어에서 가장 중요한 요소입니다.

바이브 코딩 (vibe coding)과 AI-네이티브 개발의 차이점은 무엇인가요?
바이브 코딩 (vibe coding)은 AI 모델에 프롬프트를 입력하고 그 결과물을 거의 그대로 배포하는 것을 의미합니다. 이는 프로토타입 (prototype) 제작에는 유용하지만, 보안 검토 (security review)와 감사 추적 (audit trails)을 생략하는 경우가 많습니다. 반면 AI-네이티브 개발 역시 코드의 대부분을 생성하는 데 AI를 사용하지만, 이를 관리된 프로세스, 아키텍처 리뷰 (architecture review), 그리고 규정 준수 매핑 (compliance mapping) 내에 포함시킵니다. 이것이 바로 실제 프로덕션 등급 (production-grade)의 규제 대상 소프트웨어에 진정으로 필요한 방식입니다.