Albus Dumbledore

1. 바이브 코딩의 배경

현재 소프트웨어 개발 환경은 급속도로 변화하고 있습니다. 개발자들은 단순히 코드를 작성하는 것을 넘어서, 창의적이고 직관적인 방식으로 문제를 해결해야 하는 상황에 직면하고 있습니다. 이러한 맥락에서 ‘바이브 코딩’이라는 새로운 개념이 등장하게 되었습니다.

전통적인 개발 방식은 엄격한 계획과 구조화된 접근법을 강조했습니다. 하지만 빠르게 변화하는 기술 트렌드와 사용자 요구사항은 개발자들에게 더 유연하고 적응력 있는 접근 방식을 요구하게 되었습니다. 바이브 코딩은 이러한 필요성에서 탄생한 개발 개발방식입니다.

최근 몇 년간 개발자 커뮤니티에서는 생산성과 창의성의 균형을 찾는 것이 중요한 화두로 떠올랐습니다. 많은 개발자들이 번아웃을 경험하고, 코딩에 대한 열정을 잃어가는 상황에서, 바이브 코딩은 개발 과정 자체를 즐기면서도 효율적으로 만드는 방법으로 주목받기 시작했습니다.

본 프로젝트에서는 이러한 새로운 방법의 성숙도를 체험하고 실제 적용 가능성을 가늠하기위해 기존 밀리언 달러 소프트웨어의 능력 확장을 위한 바이브 코딩 방법을 시도 해보았습니다.

 2. 본 프로젝트 개발 부분(Dreamer) 소개

목적 : 향후 기업 자율 운영을 가능케 하기 위한 기반이 되는 기업의 비즈니스 모델의 디지털 판인 디지털 트윈의 온톨로지 정보를 활용하여 비즈니스 실행을 최신 인공지능기술을 기반으로 자율적으로 할 수 있는 운영 시스템 개발

목표 : 기업 자율 운영 – 레벨 3 ( 1^st Iteration) , 고 능력 에이전트에 의한 비즈니스 실행으로 업무운영 담당자의 개입 최소화

• 비즈니스 혁신 자율 실행
• 비즈니스 솔루션 자율 개발
• 비즈니스 모델 자율 향상
• 비즈니스 프로세스 자율 실행
• 엔드-투-엔드 요구사항 관리 자동화 및 IT 개발/운영 자동화

다음 그림에서 왼쪽 부분은 기존에 있던 소프트웨어로서 대형 해외 기업에서 사용하고 있는 비즈니스 혁신 및 모델링 플랫폼으로서 온톨로지 기반 디지털 트윈을 구축하는 것을 목표로 하고 있습니다. 그 시스템의 온톨로지 기반 디지털 트윈 시스템에는 기업의 사업과 업무 처리에 대한 모든 내용이 디지털로 정의 되어 있으면 기업의 비즈니스 관련 모든 요소 간의 관계와 의미가 명료하게 정의 되어 있습니다. 상세한 내용은 http://www.bmgovernance.com 에서 확인 가능합니다.

오른쪽 부분이 대담하게도 바이브 코딩으로 시도한 부분입니다. 즉, 비즈니스 실행 팩토리는 기업의 비즈니스 프로세스를 에이전트 로봇들에게 실행 하도록 하는 것으로서 IT 시스템과 연결하고 LLM에게 컨텍스트를 제공해 줄 수 있는 MCP(Model Context Protocol), 기업의 각 부문의 역량(Competency)을 벡터화해서 기업 고유의 지식을 제공하는 전문가 RAG System, 그리고 다양한 LLM을 LLM별 장점을 살려서 에이전트들이 활용 할 수 있도록 하는 LLM 통합모델, Agent-to-Agent 협력을 지휘하는 지휘부, 그리고 이 모든 것을 아울러서 실제 비즈니스 가치를 제조하는 프로세스 엔진으로 구성 되었습니다.

[그림-1] 전체 플랫폼 구성과 바이브 코딩 적용 부분(황색 영역)

클라이언트는 VS Code Extension 을 이용한 어플리케이션입니다. 클라이언트를 VS Code Extension 으로 한 이유는 IT 개발도 워크플로우에 따라 개발하는 과정 임으로 생성된 어플케이션을 VS Code IDE 환경에서 GitHub 등과 연계를 원활하게 하기 위함 입니다.

[그림-2] 비즈니스 능력 활동 모니터링

실제 이렇게 작성된 프로그램들은 충분히 시스템 규모로 방대한 것이었습니다. 어찌 생각해보면 처음 시도로서는 무모하다고 생각 될 수 있습니다. 자료조사하고 연구하는데(요구사항 명료화)하는데 1개월, 개발하는데 1개월, 총 2개월이 걸렸습니다. 물론 중간에 수십 번 포기 할뻔한 어려움과 시행착오, 그리고 실망, 다시 희망을 발견하는 과정이 반복 되었습니다.

[그림-3] 통합 에이전트 모델과 비즈니스 온톨로지

본 시스템에서 정의하고 구현한 핵심요소 중 하나는 고 역량 에이전트 입니다. 에이전트는 전문가적 역할을 실체화 한 것으로 기본적으로 필요한 역량(Competency)을 가지고 있습니다. 여기서 역량은 업무 처리를 위한 지식과 처리 절차를 숙지하고, 강력한 계획 및 추론능력을 가지고 있고, 임무 실행에 필요한 상세한 처리와 필요 도구들을 능숙하게 다룰 수 있어야 합니다. 또한 필요에 따라서 기존 시스템 또는 외부시스템과 컨텍스트를 공유하고 다른 에이전트들과 실시간 협업이 가능해야 합니다. 이러한 고 역량의 에이전트는 업무의 각 전문가의 역할을 실체화(온톨로지에 정의된 역할의 상세 프로파일과 페르소나가 이식되어 생성) 하게 됩니다.

이러한 비즈니스 실행 팩토리는 사업혁신 및 비즈니스 모델이 디지털화된 기업의 디지털 트윈의 온톨로지를 활용하여 직접 실행하는 시스템이 되게 되며, 이러한 능력을 바탕으로 완전한 가상세계에서의 기업 운영할 수 있는 운영 시스템이 됩니다. 즉, 기업의 운영시스템이라고 생각 하면 됩니다. 운영 시스템 클라이언트는 이를 모니터링하고 결과를 확인 하는 사용자 인터페이스라고 생각 하면 될 것입니다. 실제 실행되는 모습은 유투브에서 볼 수 있습니다.(Business Capability Factory-Dreamer)

[그림-4] 에이전트 지식기반

또한 본 프로젝트 아키텍처에서 핵심 중 하나는 에이전트 지식기반 입니다. 앞에서 설명한 바와 같이 고 역량(Higher Competency) 에이전트를 생성하기 위해서는 다양한 컨텍스트와 계획 및 추론 능력이 필요 합니다. 이를 위해 전문가용 지식언어모델을 자동적으로 구축하는 것 입니다. 이러한 지식 언어모델 구축에 필요한 모든 정보는 비즈니스 혁신과 모델을 가지고 있는 디지털 트윈에서 지식 파이프라인에 따라 전문가용 지식언어모델로 축적되게 됩니다. 금융기관의 경우에는 약 100 여개의 역량(Competency) 부문별로 정의되게 됩니다. 물론 선택에 따라 60~70여개의 능력(Capability) 부문으로 정의 할 수도 있습니다. 또 하나의 축은 기업의 비즈니스 혁신 및 모델 온톨로지를 기반으로 한 지식 그래프 입니다. 비즈니스 온톨로지는 내생적(Endogenous)으로 생성되는 것과 외생적(Exogenous)으로 확장 되는 것으로 구문,의미,관계가 정의되고 시간의 흐름에 따라 변화 까지를 포함하고 있습니다. 비즈니스적으로 보자면 가치 정의, 가치 제조, 가치 전달, 가치 획득에 대한 모든 것이 그래프 모델로 정의 되어 있는 것 입니다. 진정한 기업의 업무 지식이 중복 없이 일관성 있게 디지털화 되어 있으며, 전략에서부터 IT 프로그램 코드까지 연계되어 있습니다.

이러한 환경에서 업무 처리는 실체화되어 대기중인 에이전트에게 동적으로 할당되고, 각각의 일들은 업무 조치와 툴들에 의해 수행되며, 필요에 따라 현 시스템의 정보( 모델 컨텍스트 서버를 통해) 나 맥락적 결정 또는 정보( LLM 서버를 통해) 가 취합되어 처리 됩니다.

본 프로젝트(바이브 코딩)에서는 다음과 같은 기술 기반이 사용되었습니다.

1)서버 환경

1. 운영체계 : Mac OS,Apple M2-Max,12 Core, 64GB
2. 프로그램언어 : Python
3. Agent-to-Agent Communication: G-RPC
4. 통신 프로토콜 : Web Socket
5. 데이터 베이스 : Vector DB(Chroma), Graph DB(MemGraph), Ontology DB(MongoDB)
6. 기반 아키텍처 패턴 : Event Driven Architecture
7. 에이전트 용 LLM : OpenAI-4o, Anthropic-Claude and Opus, Google-Gemini, Ollama-Mistral
8. 개발 툴 : Copilot 이나 Cursor 를 사용 하지 않고 Prompt 만을 사용하여 개발 함(의도는 IT 개발을 자동화 하기위해서는 API 만 사용해야 하기 때문에 그 문제점, 제약사항, 그리고 해결방안 찾기 위해서 였음.)
9. 개발용 LLM Prompt 서비스 사용 비중 : Anthropic-Claude(약80%), Opus(약15%), Google-Gemini(약5%). Opus를 사용한 이유는 Claude 와는 품질의 차이는 미미하나 하루 사용 빈도수(특정 시간 구간에 입력 할 수 있는 최대 프롬프트 횟수)를 좀 더 높게 잡아주는데 가격 대비 효과 미미함. Google-Gemini를 사용한 이유도 비슷함. Claude 토큰 한도(한 프롬프트에서 사용할 수 있는 입,출력 포함 최대 토큰 수) 때문이나 약간의 차이 만 있음. 일반적인 개발이라면 Claude 모델이면 충분할 것으로 생각됨

2) 클라이언트 환경

1. 운영 체계 : VS Code 가 실행되는 Mac Os, ,Windows, Unix등 운영체계
2. 프로그램 언어 : HTML/CSS, Java Script, Type Script
3. 실행 환경 : VS Code IDE extension(추후 Electron 또는 Eclipse Theia 도 적용 가능)

본 프로젝트를 진행한 개발자의 비즈니스 온톨로지 와 기술 기반 지식정도

1. 본 프로젝트 서버 기술기반에 대한 경험 : 거의 없음 ( Python 소개서 한번 읽음)
2. 본 프로젝트 클라이언트 기술기반에 대한 경험 : 경험 없고, 기술 지식 없음
3. 비즈니스 온톨로지 시스템 지식 : 고급
4. 아키텍처 사고 수준 : 고급
5. 메타 인지 수준 : 고급
6. 문제 해결 수준 : 고급

그럼, 이제 구체적으로 바이브 코딩이 무엇인지 알아 보겠습니다.

3. 바이브 코딩이란 무엇인가

1) Claude 가 설명하는 바이브 코딩

바이브 코딩은 개발자가 자신의 직관과 감각을 신뢰하며, 코딩 과정에서의 ‘흐름(flow)’을 중시하는 개발 접근법입니다. 이는 단순히 기술적 역량만을 강조하는 것이 아니라, 개발자의 정서적 상태와 창의적 에너지를 코딩 과정에 적극적으로 활용하는 것을 의미합니다.

핵심은 개발자가 자신만의 리듬과 스타일을 찾아 코딩하는 것입니다. 마치 음악가가 즉흥 연주를 하듯이, 개발자도 코드를 작성하면서 자연스러운 흐름을 따라가며 창의적인 해결책을 찾아 나가는 것이 바이브 코딩의 본질입니다. 이는 기존의 체계적이고 분석적인 접근법과는 다른, 보다 유기적이고 직관적인 개발 방식입니다.

바이브 코딩은 또한 개발 환경과 도구의 개인화를 중요시합니다. 각 개발자가 가장 편안하고 생산적으로 느끼는 환경을 구축하고, 그 안에서 자신만의 코딩 스타일을 발전시켜 나가는 것을 권장합니다. 이는 단순한 코드 작성을 넘어서, 개발이라는 행위 자체를 하나의 예술적 표현으로 보는 관점입니다.

2) Gemini가 설명하는 바이브 코딩

‘바이브 코딩(바이브 코딩)’이란 개발자 커뮤니티에서 사용되는 신조어로, 문자 그대로 ‘분위기’나 ‘느낌’을 뜻하는 ‘바이브(vibe)’와 ‘코딩(coding)’을 결합한 말입니다. 이는 엄격하고 상세한 사전 계획이나 정립된 이론에 따라 코드를 작성하기보다는, 개발자의 ‘감’ 즉, 직관과 경험에 크게 의존하여 프로그래밍하는 스타일을 의미합니다. 마치 재즈 연주자가 악보 없이 즉흥 연주를 하듯, 문제의 전체적인 흐름을 느끼며 해결책이 떠오르는 대로 자연스럽게 코드를 풀어나가는 방식을 가리킵니다.

이 용어는 사용하는 사람의 경력과 상황에 따라 긍정적 혹은 부정적인 의미를 모두 내포하는 양면성을 지닙니다. 예를 들어, 소위 ‘고인물’로 불리는 숙련된 시니어 개발자의 바이브 코딩은 수많은 경험을 통해 축적된 깊은 통찰력의 발현으로 여겨집니다. 이들의 직감은 빠르고 효율적인 문제 해결 능력으로 비춰져 감탄의 대상이 되기도 합니다. 반면, 경험이 부족한 주니어 개발자가 계획 없이 코드를 작성하는 경우, 이는 체계가 부족하여 유지보수가 어려운 ‘스파게티 코드’나 기술 부채를 유발하는 원인으로 지적 받으며 부정적인 뉘앙스로 사용됩니다.

바이브 코딩은 특히 결과물의 속도가 중요시되는 환경에서 자주 목격됩니다. 대표적으로 빠른 프로토타입 제작이 필요한 스타트업, 한국 특유의 ‘빨리빨리’ 문화 속에서 신속하게 기능을 구현해야 할 때, 또는 협업의 부담이 적은 개인 프로젝트에서 흔히 나타납니다. 또한, 프론트엔드 개발자가 정해진 수치 없이 UI를 미세하게 조정하며 ‘느낌적인 느낌’으로 디자인을 완성하거나, 숙련된 개발자가 복잡한 버그의 원인을 직감적으로 파악하여 해결할 때 바이브 코딩의 진가가 드러나기도 합니다.

결국 바이브 코딩의 성패를 가르는 핵심은 개발자의 경험입니다. 주니어 개발자의 ‘바이브’가 근거 없는 추측에 가까울 수 있는 반면, 시니어 개발자의 ‘바이브’는 수천, 수만 시간 동안 다양한 문제를 해결하며 뇌리에 각인된 패턴 인식의 결과물입니다. 따라서 겉보기에는 비슷하게 즉흥적으로 코드를 작성하는 것처럼 보여도, 그 결과물의 안정성, 확장성, 그리고 품질은 개발자의 내공에 따라 현격한 차이를 보이게 됩니다.

요컨대, ‘바이브 코딩’은 소프트웨어 개발이 단순히 딱딱한 논리와 공학적 절차만으로 이루어지는 것이 아니라, 때로는 창의성과 예술적 감각이 요구되는 복합적인 활동임을 보여주는 유머러스 하면서도 현실적인 용어입니다. 이는 체계적인 개발 방법론의 중요성과 함께, 오랜 경험에서 우러나오는 개발자의 직관적 통찰력 또한 가치 있는 능력임을 인정하는 현대 개발자 문화의 한 단면을 잘 보여주고 있습니다.

3) 본 프로젝트 개발자가 설명하는 바이브 코딩 (경험적)

본 프로젝트 개발자가 설명하고자 하는 바이브 코딩은 전통적인 개발방식, 즉 폭포수 적인 방법론을 따르든 또는 에자일 방법을 따르든 분석, 설계, 코딩, 테스트 라고 하는 정해진 방법론 기반의 산출물(Artefact)을 기반으로 개발자의 경험과 기술 기반에 대한 지식 수준에 따라 개발하는 것(소위, How 중심)이 아니라, 개발하고자 하는 대상의 필요성(Why)과 그 필요성에 초점을 맞춘 소프트웨어가 갖추어야 할 능력(What) 에 집중하고, 그 것을 달성하는 방법(How)은 AI, 즉 LLM 을 활용하여 대화식으로 개발해 나가는 방법이라고 정의 합니다.

본 프로젝트에서의 강력한 필요성은 미래예측 기법을 통한 기업의 경쟁력 확보 방안 이였습니다. 그 내용은 가까운 미래는 기대하든 또는 기대 하지 않든지 간에 AI 와 로봇을 이용하여 기업 경쟁력 확보가 중요하다는 것입니다. 따라서 기업이 비즈니스를 영위하는 방법인 비즈니스 프로세스(업무 활동)를 강력한 AI 와 실행 로봇(에이전트)를 활용하여 프로세스 능력을 제고하고, 그 결과로 기업 경쟁력이 확보할 수 있는 시스템을 개발하겠다는 것입니다. 또한 메타 인지적인 관점에서 이러한 접근방법이 증명된다면 기업의 비즈니스 모델 혁신도 자율적으로 에이전트에 의해 가능 할 것이라는 것입니다. 이러한 필요성(Why)에 따라 시스템의 필요 능력(What)을 정의 하고 개발하였습니다.

그렇기 때문에 앞에서 설명 했던 바와 같이 본 프로젝트를 진행 했던 개발자는 개발 및 운영 환경의 기반 기술에 대한 지식이 없거나 많이 부족 했음에도 불구 하고 목표를 달성 할 수 있었습니다. 물론 이 과정이 쉬었다고 말 할 수 는 없습니다. 처음 시도 였기에 어려웠고, 또한 LLM의 환각현상( Hallucination) 때문에 수없이 반복하는 어려움을 겪기도 했습니다. 그 시행 착오 과정에 많은 것을 경험 할 수 있었고, 앞으로 소프트웨어 산업에서 무엇에 중점을 두어야 할 것인지, 교육은 어떠해야 하는지 등을 배울 수 있었습니다.

4. 바이브 코딩의 특징

1) AI와 대화형으로 개발

바이브 코딩은 AI와 대화형을 개발하는 방식 입니다. 요구사항을 프롬프트 지시문으로 작성하고 이를 LLM 서비스를 통해 전달하고 원하는 결과를 얻는 방식을 말합니다. 그렇기 때문에 프롬프트(컨텍스트+지시문) 작성이 매우 중요 합니다. 만약 프롬프트 내용이 부실하거나 일관성이 없으면 생성된 저작물의 품질도 낮아 지게 됩니다. 즉, 양질의 입력이 있으면 양질의 결과물을 얻을 수 있습니다. 일관성이 결여된 프롬프트는 큰 문제를 야기 합니다. 즉, 처음에는 조그마한 차이 이지만 개발이 진행되고, 깊이가 깊어 지면 큰 차이를 불러 오게 되고, 최악의 경우는 전체 코드를 버리고, 처음 부터 다시 시작해야 하는 경우가 발생 합니다.

2) 공식적으로 미리 정해진 Artefact 없음

바이브 코딩의 기본 입력에 아직까지 정해진 표준 또는 Artefact가 없습니다. 물론 모델을 제공하면 훨씬 품질이 높은 저작물을 얻을 수 있습니다. 즉, UML과 같은 모델링에 익숙한 개발자라면 이를 적극적으로 활용해야 합니다. 만약 프롬프트 만으로 개발을 하고자 한다면, 프롬프트를 구조적으로 작성하는 방법을 미리 익히는 것이 좋습니다. 추후 여건이 허락 된다면 이부분만을 정리해 볼 생각입니다.

3) 반복적, 점진적 개발

아무리 완전한 AI라고 할지라도 어플리케이션을 한번에 개발 할 수 없습니다. 반복적이고, 점진적으로 개발하는 것이 기본이 되게 됩니다. 그렇기 때문에 반복적이고 점진적으로 개발하는 방법에 익숙한 개발자는 보다 쉽게 개발 할 수 있게 됩니다. 물론, 반복적 점진적 방법이 장점만 있는 것은 아니지만, 아키텍처 사고와 리팩토링에 대한 개념이 확실한 개발자라면 좀더 쉽게 개발 할 수 있습니다.

4) 프로토타이핑을 기본으로 시작

앞에서 설명한바와 같이 바이브 코딩의 개념은 대화형으로 개발하는 것이며, 프로토타이핑과 같이 목업(Mock-up)을 만들고(그렇게 하고 싶지 않아도 그렇게 되 버림) 이를 상세화 하는 방식으로 주로 이루어 지게 됩니다. 다른 말로 표현하자면, 처음에는 가볍게 시작하고(Mock-up), 목업의 완전성에 감탄하게 되고 마치 어플리케이션이 다 개발된 거 같아 조금만 더 하면 되겠지 하는 방식으로 이루어지게 됩니다. 물론 이 과정에서 통제를 잘하게 되면 어플리케이션을 빠른 시간에 얻을 수 있습니다.

5) Why, What 이 중요하고 How는 AI에게

AI는 Why(목표) 와 What(필요내용) 이 분명하다면 완전한 코드(Clean Code)를 즉시 생성 할 수 있습니다. 기술 기반에 대한 고급지식이 없다고 하더라도 개발 할 수 있습니다. 본 프로젝트에서는 개발자가 기술 기반에 대한 지식이 거의 없었지마는 개발할 수 있었습니다. 이제부터는 How 를 과감하게 AI 에게 생성하도록 하고, Why와 what에 집중 해야 합니다. 그런데 여기서 말하는 How에 대해 이해를 분명히 해야 합니다. 보 프로젝트에서 경험 했던 바로는 How에는 두가지 종류가 있습니다. 첫번째는 기존에 누군가가 이미 했던 또는 알려진How 입니다. 다른 하나는 아직 알려지지 않은 새로운 방식 입니다. 첫번째 경우의 것은 과감하게 AI가 하도록 합니다. 그러나 두번쨰 것은 여전히 개발자의 몫입니다.

 5. 개발자가 바이브 코딩을 활용하는 방법

개발자가 바이브 코딩을 실무에 적용하기 위해서는 먼저 해야 할 일(즉, 개발해야 할 대상)에 대한 이해가 매우 중요 합니다. 바이브 코딩은 LLM, 즉 AI 와 함께 프로젝트를 진행하는 것입니다. LLM은 How에 대해서는 정말로 빠른 시간내에 결과물을 보여 줍니다. 즉, 단순 코딩은 개발자가 AI 와 경쟁 할 수 없습니다. 개발자가 해야 할 일은 메타인지 입니다. 눈앞의 마주한 문제에 함몰되지 않고, 보다 근본적인 문제를 이해하고자 할 때 AI를 훌륭한 도구로서 사용 할 수 있습니다.

근본적인 문제란 무엇일까요? 이는 디자인 사고 워크샾에서, 또는 식스시그마 워크샆에서 했던바와 같은 왜(Why)라는 질문을 통해 근본적인 필요성과 전달해야 할 가치를 이해하는 것입니다. 그 다음은 그 가치를 전달하기 위한 능력을 시스템 사고 또는 아키텍처적인 사고를 통해 구조적으로 이해하고 ,MECE (mutually Exclusive, Completely Exhausted) 기법으로 완전성을 검증하고 이를 단계별로 반복 적용하는 것입니다.

여기서 단계별로 반복 적용 한다는 것은 상위 수준에서 하위 수준으로 반복적으로 적용 하는 것을 뜻합니다. What 과 How 의 관계는 수준의 차이 입니다. 즉, 어떤 수준(레벨)에서 하위수준은 항상 How를 나타냅니다. 전체 적으로 완성된 구조 측면에서 보면 What-How는 마치 부모와 자식처럼 세대에 걸쳐 반복적으로 나타나는 것과 같습니다.

일단 이것을 이해한다면 바이브 코딩의 핵심을 이해 했다고 저는 과감히 이야기 할 수 있습니다.

나머지는 프롬프트 작성입니다. 이해한 프로젝트 목표를 LLM에게 학습시키고(최대 10개문장이면 충분하고 대부분 4~5 문장이면 작동됨), What을 지시 문(Prompt) 으로 전달하면 How는 만족 스럽게 생성 됩니다. 여기서 이해 할 중요한 것은 HOW 는 Why와 What에 따라 얼마든지 다르게 생성 된다는 것입니다.

또한 오늘 현재(2025.6.3) 까지의 LLM 기술(Anthropic Claude Opus4, Google Gemini Pro등) 은 본 프로젝트 규모의 컨텍스트를 LLM 이 충분하게 관리 하지는 못한다는 것입니다. 따라서 개발자가 앞에서 설명한 내용을 적어도 머리 속 또는 별도의 노트에 계속 기록 유지 해야 한다는 것입니다. 추후 설명하겠지만, 아직은 이러한 규모의 컨텍스트를 일관성 있게 유지 하지 못하는 이유는 LLM 그 자체의 문제라고 하기 보다는 상업적으로 서비스를 제공하기 위해 설정된 여러가지 제약 사항 때문인 것으로 추측 됩니다.

 6. 바이브 코딩 경험담

사실은 처음부터 이렇게 큰 시스템을 구축할 생각을 가졌던 것은 아니 였습니다. 처음에는 비즈니스 혁신과 비즈니스 모델링 플랫폼에 비즈니스 솔루션 개발을 위한 Solution Factory를 계획 하였습니다. 이러한 기능은 Java 코딩으로 할 수 있었고, 개발자를 위한 지식을 취합하여 자료를 전달 하는 방식입니다. 즉, 고객의 생애 가치를 예측하는 주제라면 LLM과 온톨로지를 활용하여 필요 자료를 확보하고 데이터 마이닝 또는 기계학습 솔루션을 개발해서 제공하는 방식입니다. 이 정도는 Chain-Of-Though 또는 Tree-Of-Though 정도로 가능 했습니다. 이러한 경험을 통하여 비즈니스 프로세스 전과정을 최신 AI 기술들, 예를 들면, LLM, MCP, AGENT, RAG등을 활용하여 비즈니스 프로세스 능력을 혁신하고 자동화 할 수 있을 거라는 아이디어가 도출 되었습니다. 이러한 배경에는 능력 캡슐(획기적인 방식의 기업 능력 확보 방안,특허등록)이라는 아이디어를 적용 해보고자 하는 욕심도 작용 했습니다. 자세한 내용은 본 자료의 말미에 있는 싸이트를 방문하거나 또는 개념적인 내용은 Gartner 2022 신기술 동향 중 하나인 Packaged Business Capability를 참고 하시기 바랍니다.

이러한 생각에 따라 다소 무리했던 프로젝트를 착수 하게 되었습니다.

첫 출발은 좋았습니다. 몇 문장의 배경 설명과 목표, 가치, 필요 능력 등을 설명하는 프롬프트로 감탄 할 만한 코드가 생성 되었습니다. 앞에서 설명하였듯이, 본 프로젝트에서 본 프로젝트에 기술기반에 대한 경험과 지식이 없는 개발자로서 제가 직접 경험한 바로는 깜짝 놀랄만한 산출물이 였던 겁니다. 특히, 저는 기반기술에 지식이 없어 감히 범접하지 못했던 코드들이 쏟아져 나오고 그것들을 지시대로 설정하고 첫 테스트를 했을 때는 그야말로 마법이 였습니다. 순식간에 대부분이 기능이 작성되고 테스트 되는 것을 보면서 2~3일이면 개발이 완료 될 것처럼 느껴 졌습니다.

그러나 “악마는 디테일에 있다”라는 말처럼 느닷없는 현상들이 발생하기 시작합니다. 그 경험을 아래 그림에 표시 해보았습니다. 즉, 감탄단계, 실망단계, 그리고 분노 단계 등입니다.

[그림-5] 바이브 코딩의 Journey와 그 단계들

맨 처음 경험은 (1)번 커브를 따라 갔습니다. 단 몇일만에 90% 이상의 코드가 완성 되었습니다. 정말로 감탄 단계에 있었던 것이지요, 이 기간에는 정말로 AI 가 사람보다도 신뢰가 가기 시작합니다. 그야말로 몇 개의 문장에 코드가 생성되고 실행가능한, 무결점의 코드가 나오니 그렇지 않았겠습니까? 그러나, 어느 순간부터 Token Limit 에 걸리기 시작합니다. 정확하지는 않지만 코드라인으로 볼 때 1,000 라인 정도에서 Limit이 문제가 되기 시작합니다. 이는 1,000 라인 정도이면 몇번의 대화를 하다 보면 Token Limit에 걸렸으니 세션을 다시 개시하라는 응답이 나옵니다. Token Limit에 걸리면 다시 세션을 개시해야 하는데 이럴 경우 지금까지 대화를 했던 컨텍스트를 잃어 버립니다. 다시 입력해야 합니다. 몇 개를 수정 했는 데 또 Limit에 걸렸다고 나옵니다. 하루 종일 반복합니다. 갑자기 너무 많이 일을 시켰으니 몇 시 까지는 이용할 수 없다는 메세지가 나타납니다. 아니 코딩을 뒤에서 사람이 했나? 왜 쉬는 시간을 주어야 하지. 서서히 실망단계로 접어 듭니다. LLM 제공회사의 구독 등급을 찾아 봅니다. 비싼 등급으로 올라가면 한도가 늘어난다고 되어 있습니다. 그래, 그러면 그렇지 방법이 있는 것이야. 돈 아끼지 않고 최 상급으로 등급 상향을 합니다. 역시 좋아 진 것 같습니다. 그러나 이내 실망 하고 맙니다. 약간의 차이가 있을 뿐 현상은 비슷합니다. 포기 할까, 역시 ‘기계가 개발한다는 것은 아직 무리야’하면서 포기 할려고 하다가, 이제까지 보낸 시간이 너무 아까워 다시 시도 해봅니다. 내일은 되겠지. 그러나 시간이 가면서 이제 더 큰 문제가 생기기 시작합니다. 너무 많은 재시도로 코드 간에 일관성이 떨어지는 현상이 나타나고, 가끔씩 환각현상(Hallucination) 이 나타납니다. 코드 생성을 했는데 잘못 이해해서 엉뚱한 코드가 생성 됩니다. 기존 코드를 누락 시켜 버리기 합니다. 품질이 점점 떨어집니다. 분노단계에 진입한 것 입니다. 아니 여태까지 믿고 왔는데 이게 말이 됩니까. 이제 LLM 이 자기가 생성한 코드가 맞다고 자발을 떱니다. 실제로 ‘Perfect’ 로직이라고 생성이 끝날 부분에 자신 있게 주장 하는 메세지를 같이 출력 합니다. 그런데, 컴파일 하면 140개 오류가 쏟아 집니다. 화가 납니다. 다른 코드와 일관상을 잃어 버렸습니다. 왜 코드가 안 맞느냐고 질문하면 깜박 잊었다고 능청 스럽게 이야기 합니다. 몇 번 감정 섞인 대화가 이어지면 여태 프로그램 단위별 또는 기능별 생성하더니 갑자기 나에게 고치라고 코드 일부만 출력 해줍니다. 몇 번째 라인을 수정하면 된다면서 코드를 주는데 라인 번호가 안 맞기 시작 합니다. 컴파일 오류를 던져 주면서 고치라고 하면 내가 수정을 잘못해서 그런다고 불평합니다. 이럴 수가,… 사람 같으면 해고라도 하고 싶었습니다. 더 이상 코드 품질 향성이 안됩니다, 마지막 체크 포인트 버젼으로 되돌아 갑니다. 2~3일을 허비 했습니다. 허탈 합니다.

자, 어떻게 커브를 바꿀 수 있을까요? 가능할까요? 적어도 (2)번 커브를 유지 하든지, 또는 바람직한 (3)번 커브를 만들 수는 있을까요? 예, 마침내 (3)번 커브를 찾았습니다. 어느정도 실망 단계를 지금은 피할 수는 없을 것 같습니다. 그러나 품질 100%, 즉 원하는 능력을 갖고 프로젝트를 종료 할 수는 있습니다. 그 비결은 이제부터 사람이 개발하는 방법에서 시간할당을 바꾸고, 무엇에 집중해야 할지를 분명히 하고, AI 와 일하는 방법을 배워야 한다는 것입니다.

 7. 세번째 커브 Journey 가 가능할까?

제가 Journey 라고 하는 단어를 사용하는 이유는 단순한 여행(가벼운 마음으로 풍광을 즐기는)이 아니고, 목적지를 가기 위해 계획하고, 난관에 맞서고, 해결하고, 한 발자국씩 나아가고, 경우에 따라서는 다시 중간지점에 되돌아 가서 우회하기도 하고, 마침내 목적지에 도착한 것 같지만 끝이 아니라 또다른 단계의 시작이 되기 때문입니다.

두번째 커브와 세번째 커브의 다른 점은 두번째 커브에서는 원하는 품질 수준에 도달하지 못하고 계속해서 프로그램 개선만 진행하는 것이고, 세번째 커브는 어느 시점에서 원하는 품질 수준을 얻고, 해당 능력을 갖춘 프로그램으로 마무리할 수 있다는 것입니다.

1)시스템적 사고

시스템적 사고는 어떤 시스템(최종 목적물)을 생각할 때 전체와 부분을 생각하는 것입니다. 이것은 인식론에서 매우 중요한 개념이며, 문제 해결 방법의 시작이라고 할 수 있습니다. 다음 그림에서 보듯이 하나의 목적은 왼쪽의 작은 원은 그 하위 구성요소로 이루어지고 있습니다. 그렇다고 해서 하위요소들 만을 갖고서 상위요소를 충족시킨다고 할 수는 없습니다. 즉, 상위 요소는 항상 Emergent Property(창발성 특성)이 추가 되기 때문입니다. 따라서 상위요소를 하위요소를 분해하고, 상위 요소가 가져야 할 창발성 특성을 이해 하여야 합니다. 즉, 자동차가 엔진, 샤시, 운전대, 대쉬보드, 문, 의자, 연료통 등으로 구성되지만, 이것들을 다가지고 있다고 해서 자동차라고 할 수 는 없습니다. 따라서 어떻게 구성했을 떄, 그것이 자동차가 될 수 있는지를 파악하고 그들의 구성요소에 이것을 합하여 자동차가 만들어지게 되는 것과 같습니다. “Systems Thinking: Managing Chaos and Complexity”, Jamshid Gharajedaghixity,은 시스템 사고를 하는데 도움이 될 것입니다.

[그림-6] 세번째 커브 Journey 를 위한 아키텍처적 사고

2) 아키텍처적 사고

아키텍처 사고에서 설명하고 싶은 것은 두가지가 있습니다. 하나는 리팩토링(Refactoring)이고, 또다른 하나는 Cross Cutting에 대한 것 입니다. 모든 시스템은 진행되거나 시간이 가면서 엔트로피가 증가하고, 변칙적인 상황이 많아 지게 됩니다. 이러한 상황을 해결하는 방법 중 하나는 프로그래밍에서는 리팩토링일 것 같습니다. 즉, 위의 그림에서 (1)의 단계에서는 하위 요소 간의 경계가 분명한 것 같습니다. 그런데 단계가 깊어 지면서 각 가지(Branch)간의 중복도가 늘어나게 됩니다. 제가 경험 한바로는 이러한 현상이 발생하기 시작하면 LLM 이 생성하는 코드의 품질이 빠르게 떨어지게 됩니다. 또한 이때부터 환각현상(Hallucination)이 증가하게 됩니다. 이러한 시점에 들어가기 전에 이러한 위험을 모니터링하여야 합니다. 또한 이러한 현상이 인지되는 즉시, 그림(2)와 같이 범위를 확정하고 ,(3)의 방향으로 리팩토링을 해야 합니다. 리팩토링의 기준은 기능강도(Functional Cohesiveness)와 낮은 결합도(Loosely Coupling) 입니다. 여기서 또다시 What을 마주하게 됩니다. LLM에게 리팩토링을 지시 할 수는 있습니다. 그러나 What이 명료 하지 않으면 바로 같은 문제를 마주하게 됩니다. 리팩토링 기준이 Cross Cutting 관점 입니다. 본 프로젝트를 하면서 초창기에 고생했던 중 하나는 리팩토링을 가볍게 생각하고 Depth First ,즉 각각의 기능을 깊은 레벨까지 별 생각 없이 생성한 거 였습니다. 리팩토링을 할 때 어떤 관점이 바람직할 것인지에 대한 충분한 고민이 있어야 할 것 입니다. 시중에는 많은 아키텍처 디자인 패턴에 관한 책들이 있음으로 적어도 한권 이상의 아키텍처 디자인 패턴 책을 읽으면 많은 도움이 될 것입니다.

3) 맥락적 사고

HOW를 나타내는 하위 요소는 Why(목적), What(능력)의 정의 따라서 바뀔 수 있습니다. 다시한번 생각해보면 하위 요소도 ‘하위요소의 하위요소’ 입장에서 보면 What 입니다. 말하자고자 하는 것은 How(하위요소)가 잘못 생성되면 그 이하는 모두 잘못 되어 버립니다. 따라서 (4)의 범위 처럼 항상 맥락적 사고와 일관성을 유지 하면서 AI 와 함께 작업해야 합니다. AI는 순식간에 How를 생성해 내지만 맥락적 일관성을 유지하는 데는 한계가 있습니다. 생성된 코드를 맥락적인 관점에서 검토하는 것을 누락하면 순식간에 다른 길로 접어 들게 되고 두번째 커브 또는 첫번쨰 커브의 Journey 를 경험하게 됩니다. 또한 맥락(Context)에 대한 분명한 이해가 있어야 할 것 입니다. 맥락자유(Context Free), 맥락인지(Context Aware), 맥락 주입(Context Injection), 맥락기반(Context Based)를 잘 이해하고 유지해야 합니다. 추상화와 구체화도 적절히 사용되어야 합니다. LLM은 기본적으로 누군가의 코드로 부터 학습한 내용을 기반으로 사용자(즉, 개발자)의 맥락적 사고에 따라 코드를 생성 합니다. 따라서 개발자가 맥락적 사고가 부족하다면 결과물은 그 수준에 생성 되게 됩니다. 그러나, 개발자가 맥락적 사고를 하고 있고, 이를 이용해 약간의 넛지(Nudge)만 해주어도 결과문의 수준은 대단히 달라지는 것을 많이 경험하였습니다. 세계 100대 공학자분 중에 한 분인 박창규 교수님이 쓴 “컨텐츠가 왕이면 컨텍스트는 신이다.” 라는 책 제목이 실감 납니다.

4) 언어에 대한 이해

LLM은 Large Language Model 입니다. 즉, 거대 언어 모델입니다. 언어에 대한 이해가 있으면 LLM을 효과적으로 사용하고, 보다 품질이 높은 답을 생성해 낼 수 있습니다. 즉, 동사, 명사, 형용사, 부사 등을 사용하여 문장을 작성하게 되는데 명사는 What 을 동사는 기대 가치를 나타내는 것으로 사용하였습니다. 가능한 형용사와 부사는 사용을 피하고, 이에 해당하는 참고자료 또는 숫자로 명시하였습니다. 명사에 대해서는 사용에 일관성을 유지 하는 것이 중요합니다. 물론 유사성에 따라 같은 의미로 파악 하여 결과물을 생성 하지만, 가끔은 일관성 결여로 한참 개발 단계가 흘러간 다음에 서로 다른 이야기를 하고 있다고 생각될 때가 있어 백업 해 놓았던 시점으로 되돌아 가는 경우가 예상외로 많았습니다. 즉, 미세한 각도의 차이가 단계가 진행됨에 따라 큰 원호를 그리기 된 것이지요. 동사에 대해서는 개발자가 원하는 기대 가치에 따라 적절한 동사를 찾아 나름의 표준처럼 사용 하는 게 좋습니다. 본 프로젝트의 시스템에서는 약 60개의 동사를 분류하고, 분류된 동사 그룹을 대표하는 동사를 선정하고, 그에 따른 질문 패턴을 정리하여 에이전트에 내장 시켜 사용 합니다. 그렇게 한 이유는 비판적 사고 관점에서 동사에 따른 기대 가치에 대한 표현이기 때문에, 보다 높은 생성물을 얻기 위해서 다양한 추가적인 질문을 Agent가 할 수 있도록 하고 있습니다. 같은 방식으로 제가 직접 AI 와 작업을 할 때 비슷한 방법으로 하였습니다. 만약 맥락적 질문에 익숙하지 않은 분은 “A More Beautiful Question: The Power of Inquiry to Spark Breakthrough Ideas”,Warren Beger 를 한번 읽어보도록 권해 드립니다.

 8. 바이브 코딩에서 얻은 교훈

바이브 코딩을 실천하면서 얻은 가장 중요한 교훈은 ‘개발은 단순한 기술 작업이 아니라 창의적 활동’이라는 점입니다. 코드는 단순히 기능을 구현하는 도구가 아니라, 개발자의 사고와 창의성을 표현하는 매체가 될 수 있다는 것을 깨닫게 됩니다. 또한 바이브 코딩을 하면서 시행 착오를 피 할 수 없다는 것도 알게 됩니다. LLM이 생성한 생성물은 대부분이 HOW에 해당되는 하위 요소들입니다. 그러한 하위 요소가 없으면 상위 요소를 만들 수 없습니다. 그렇다고 해서, 부품이 모두 갖추어 졌다고 해서 상위 요소가 되는 것도 아닙니다. 거기에는 개발자의 창발성(Emergent Property) 더해져야 합니다. 본 프로젝트를 진행하면서 느낀 점은 기본수준은 AI가 해 줄 수 있지만, 어느 정도의 어플리케이션 부터는 개발자의 수준에 맞는 정도의 생성물이 만들어 진다는 것입니다. 이에 더해서 바이브 코딩 프로젝트를 진행 하면서 실제로 수백번의 실패 끝에 배운 점(?)은 다음과 같습니다. 저의 근무시간 아침 8시부터 밤 9시까지 였습니다. 이중 간에 식사 시간 약 1시간(점심, 저녁) 그리고 2~3시간 정도의 운동시간이 있습니다.

1). 주기적인 백업 및 설계 공식화

앞에서 여러 번 설명한바와 같이 대부분의 어플리케이션 개발 과정에서는 감탄 단계에서 최종 생성물을 얻기는 어려울 거 같습니다. 두개 이상의 기능을 생성하고 몇 번 수정하게 되면 바로 실망 단계를 경험하게 됩니다. 이때는 바로 마지막 백업했던 체크 포인트로 롤백해야 합니다. 만약 백업이 없다면 낭패이지요. 그 판단을 잘해야 하지만, 가끔은 어찌어찌 수정해서 해볼까 하다가 분노의 단계로 들어 가는 경우가 생각 보다 많았습니다. 제 경험으로는 롤백이 실망과 분노 단계를 줄이는 방법이었습니다. 따라서 능력 또는 기능이 하나씩 완성 될 때마다 백업을 하는 것을 기본으로 하였습니다. 백업에는 물리적 코드 백업과 설계 백업이 있습니다. 물리적 백업은 완성된 코드를 백업 하는 것이고, 설계 백업은 프롬프트를 백업하는 것입니다. 여기서 코드 백업보다 중요한 것은 설계 백업입니다. 왜냐하면 코드는 How 라고 설명 했었습니다. 이러한 How는 Why 나 What이 바뀌면 바로 쓸모 없어 지게 됩니다. 그리면 지금 까지 했던 모든 작업의 결과가 쓸모 없어 집니다. 그렇지만 Why 와 What을 정의하고 지시했던 프롬프트가 정확하게 마지막 버젼으로 유지 되고 있다면 Why와 What이 변경되었다고 하더라도 쉽게 수정, How 를 수정할 수 있어 변경에 대한 수정이 매우 빠르게 진행 시킬 수 있습니다.

2) 명료화

개발자는 프롬프트를 작성해서 AI에 전달하고, 프롬프트 요구사항을 AI 가 해석해서 코드를 생성하는 방법으로 어플리케이션을 개발 하게 됩니다. 그러나 요구사항을 정확하게 전달하는 방법은 쉽지 않습니다. 그 이유는 개발자가 작성한 요구사항에도 일관성이 결여 되거나, 또는 불완전한 경우가 비일비재 합니다. 이러한 경우 생성된 코드는 당연히 기대와는 멀어지고, 기존에 완성되어 가던 어플리케이션을 첫번째 커브의 Journey로 가게 합니다. 본 프로젝트를 진행하면서 이러한 문제를 해결하기 위해 가능한 모델을 기반한 프롬프트, 즉 지시사항을 전달하고자 했습니다. 그럼에도 불구하고, 자주 불완전한 요구사항으로 인해 기본 코드가 오염되는 상황이 발생 했습니다. 세번째 커브를 유지하기 위해서 사용했던 방식이 요구사항을 정의 해주고, 코드를 생성하라는 지시문이 아닌 AI 에게 이해한 바를 설명하고, 부족한 요구사항을 알려 주고 승인이 있을 때 코드 생성을 하도록 유도 했습니다. 그렇게 함으로서 분노의 횟수가 현저하데 줄어들고, 실망의 단계 경험도 낮아 지기 시작 했습니다.

3) 완전한 코드집합

AI 도 기억에는 한계가 있습니다. 즉, LLM 은 모든 대화를 기억 할 수 있겠지만, 서비스 상용화 과정에서 자원의 효율적 이용을 위해 한계가 적용된 것 같은 느낌을 받았습니다. 특히, 문제가 발견되거나, 일부 기능 향상을 하기 위한 요구사항을 전달하면 그에 상응한 코드를 생산하게 됩니다. 그런데 이 코드가 완전한 집합이 아닐 경우가 자주 있습니다. 만약 개발자가 주의를 기울이지 않으면 바로 첫번째 커브Journey로 진입하게 됩니다. 그 이유는 문제가 있는 코드 또는 신기능에 집중하여 유사성 분석을 기반으로 생성이 이루어지기 때문에 기능 향상 또는 오류 해결에 관여 되지 않았던 정상적인 코드가 사라져 버리는 경우가 발생 하는 것 입니다. 어찌 보면 자원을 효율적으로 사용하기 위한 것이기도 하지만 개발자 입장에서는 조금만 주의를 하지 않으면 코드가 수정 되 버렸고, 백엎이 없으면 바로 분노의 단계로 진입하게 됩니다. 본 프로젝트에서는 초기에 수차례 이러한 상황을 겪었으며, 이후에는 새로운 코드가 생성되면 반드시 총 코드라인 수를 비교 하였습니다. 만약 코드 라인 수가 현저하게 다르면 바로 질문을 해서 그 이유가 무엇인지를 파악하였습니다. 이러한 질문때마다 AI 가 답하는 것은 능청스러운 ‘ I am sorry’ 였습니다. 이런 경우 어떻게 해야 할까요? 제가 했던 것은 ‘완전한 코드 집합을 작성하라’ 는 지시문 였습니다. 그런데 이 지시문을 입력 했는데 토큰 한도에 걸리면 어떻게 해야 할까요? 별수 없습니다. 세션을 다시 열고 컨텍스트 설정을 자시 해야 합니다. 이때가 중요 합니다. 어떻게 컨텍스트를 유지 할 수 있을까요? 다양한 방법으로 기존 컨텍스트를 연계시키기 시도 했지만 공식적인 답변은 앞 세션의 컨텍스트를 모른다는 것 입니다. (그런데 컨텍스트를 다시 설정 하기 위해 한참을 입력하고 대화 하다 보면 컨텍스트를 모른다는 것은 공식적인 것이고, 알고 있다는 느낌을 자주 받습니다.) 여러분도 해보세요. 컨텍스트를 모르니 다시 설정 해달라고 합니다. 정말 분노가 치밀어 오릅니다. 자 어떻게 할까요? 개발이 한참 진행 되었으니, 처음부터 대화 했던 것 생성물을 모두 다시 입력하게 되면, 두세번의 대화에서 다시 토큰 한도에 걸립니다. 그러면 또 다시 세션을 열어야 합니다. 울고 싶어 집니다. 어떻게 이 난관을 돌파해야 할까요? 어플리케이션이 어느정도 크면 완전한 컨텍스트를 다시 입력하기는 불가능 합니다. 여기에 다시 한번 아키텍처 사고가 필요한 시점입니다. [그림-6]에서 해당 노드를 기준으로 상위 노드들에 집중합니다. 그리고 리팩토링 했던 코드 셋(프로그램들) 만을 대상으로 컨텍스트를 입력 합니다. 그 컨텍스트를 입력할 필요도 없습니다. 일단 그림(4) 처럼 범위를 설정하고 프로그램을 Upload 하면 컨텍스트 갱신이 이루어 집니다. 그 이유는 그 프로그램들이 요구사항을 가장 완전하게 설명하고 있기 때문입니다. 자, 이제 통제 가능한 단계에 들어 온 것 같습니다. 그러나 리팩토링이 제대로 진행되지 않았다면 이 마저도 어렵습니다. 왜냐하면 Upload 해야 할 범위의 총 코드수가 커지게 되고 이는 또 다른 토큰 한도에 직접적인 영향을 주어서 첫번째 커브의 Journey를 따라 가게 됩니다.

4) 적절한 관점 제시

본 프로젝트를 진행 하면서 프롬프트 말(지시문 입력)로서 AI 함께 코드를 생성하는 방식은 대단히 새로운 방식 이면서 놀라운 경험을 경험하게 됩니다. 그러나 어느정도 익숙해지면서 생성된 코드와 설명을 보다 보면, 코드를 생성하는 것이지만 누군가의 코드를 가져오는 느낌을 받습니다. 즉, 로직과 설계가 이미 누군가가 했던 것을 본 프로젝트에 맞게 바꾸는 것을 느낍니다. 물론 당연한 결과이지만 약간 남의 다리를 긁는 느낌을 받을 때가 있습니다. 이런 느낌은 똑같은 What이지만 기대와는 다를 때 느끼게 됩니다. 이럴 때는 관점을 분명히 해주어야 합니다. 그 관점에는 여러가지가 있습니다. 추상화 수준, 소프트웨어 라이프 싸이클, 이해당사자 가치(예를 들어 테스트 담당자 관점), 아키텍처 등을 고려해서 관점을 지시문에 포함 입력합니다.

5) 힌트 또는 너지

LLM은 단어와 컨텍스트 유사성에 따라 생성되는 내용이 달라 집니다. 대부분은 지시문과 같이 입력된 컨텍스트, 그리고 세션 진행된 획득된 컨텍스트를 통해 생성물의 적절성이 결정됩니다. 그럼에도 불구하고 경우에 따라서는 컨텍스트나 지시문에 포함하기 어려운 구체적인 요구사항을 전달하기 위해서는 힌트나 너지를 사용하면 시간과 품질을 크게 개선하는 경우가 있습니다. 특히, 사용자 편의성 또는 화면 심미성(aesthetic)에 관련된 요구사항이라면 더욱 그렇습니다. 이럴 때는 원하는 화면의 사례를 이미지로 제공하거나, 이미 잘 알려진 사례를 힌트로 주면 빠르게 원하는 바를 얻을 수 있습니다. 본 프로젝트의 경우에서는 어플리케이션이 VS Code 에서 플러그인 형태로 작동 되는 것이기 때문에 자주 VS Code 표준을 힌트 또는 너지로 사용 하였습니다. 백 엔드 프로그램을 생성 할 때도 이러한 힌트 또는 너지를 사용하면서 큰 효과를 본 적이 많습니다. 물론 이러한 힌트나 너지는 앞에서 설명했던 사고 방식을 기반으로 다양하게 구사할 수 있습니다. 어떤 경우에는 코드 생성을 해서 테스트를 했는데도 비슷한 오류가 반복되는 경우가 있습니다. 이럴 때 직원이 오류를 반복할 때 지시 했던 것처럼 ‘코드를 철저하게 검토해서’ 라고 하는 문구를 넣어서 지시문을 넣으면 바로 알아차리고 반응이 옵니다.

6) 과도한 신뢰는 피하기

본 프로젝트를 진행하면서 느꼈던 것은 AI와 대화형식으로 요구사항을 지시하고, 그 결과를 검토하고 테스트 하다 보면, 이상하게 입장이 바뀌어 간다는 느낌을 받게 됩니다. 처음에는 개발자가 주도 한다는 느낌으로 대화 하게 되는데 점차 설계와 개발은 AI가 하게 되고 개발자는 테스터가 되가는 것을 느끼게 되고, 현실적으로 그렇게 되 버립니다. 예를 들어 처음 대화는 ‘화면을 작성해줘’라고 지시해서 화면 관련된 코드가 생성됩니다. 그러면 테스트를 주로 사람이 하게 됩니다. 그런데 개선 사항이나 오류가 있어서 다시 지시하면 그 다음 부터는 AI가 설계자, 개발자이고 사람 개발자는 AI 의 지시에 따라 테스트하고, 테스트 결과를 보고 하고, AI의 지시에 따라 로그를 확인하고, 설정을 하고 하는 일이 다반사로 일어 납니다. ‘시스템 유스케이스’가 ‘휴먼 유스케이스’로 바뀌는 시점입니다. 그 다음 부터는 AI 생성하고 지시하는 내용이 제대로 안될 때는 서서히 짜증이 나기 시작 합니다. 마치 AI는 절대 오류가 없는 같은 신뢰를 기반으로 과도하게 의지 하는 습관이 형성 되는 것 같습니다. 오늘 현재까지는 아직 그 정도 신뢰를 해서는 안됩니다. 과도한 신뢰를 하게 되면 첫번째 커브 Journey로 갈 가능성이 매우 높습니다. 항상 비판적 사고를 유지하고 AI가 생성한 코드에도 오류가 있다는 점을 간과 해서는 안됩니다. 특히 리팩토링이 제대로 안될 때는 사람이 개발할 때 겪는 문제를 그대로 답습합니다.

 9. 바이브 코딩의 그림자

바이브 코딩의 장점은 자세히 설명할 필요가 없을 것 같습니다. 너무 명확하다고 할 수 있습니다. 그러나 바이브 코딩에도 그림자가 있습니다. 가장 큰 위험은 ‘자기 합리화의 함정’입니다. 단순히 게으름이나 무계획을 바이브 코딩이라고 포장하는 경우가 있을 수 있습니다. 진정한 바이브 코딩은 자유로움 속에서도 목표와 품질을 잃지 않는 것이 중요합니다. 바이브 코딩을 하게 되면 큰 그림을 무시한채 바로 코딩으로 들어 가는 경우가 많을 것입니다. 왜냐하면, 프롬프트에 몇가지 요구사항과 지시문을 입력 하기만 했는 데도 환상적으로 코드가 작성되고( 많은 유투브에서 말 하듯이), 마치 어플리케이션 개발이 완료 된 것으로 착각하게 합니다. 즉, 감탄의 단계에 들어선 것이지요. 이러한 유혹을 뿌리치기 힘들 것입니다. 이러한 접근 방법은 실망의 단계를 거쳐, 분노의 단계로 가는 지름길 입니다. 또한 ‘성공적으로 어플리케이션을 개발했다’라고 해도 개발자는 어플리케이션 코드에 대한 지식이 부족해 지게 됩니다. 즉, 직접 개발한 코드를 수정 할 때와 다른 사람이 개발한 코드를 수정 할 때의 위험성이 다른 것과 같습니다. 이를 피하는 방법은 아키텍처에 대한 이해를 넓히고, 근본적인 목표, 필요 능력, 아키텍처를 연계하면서 바이브 코딩을 했을 때 비로소 관리 가능한 개발 방법이 될 것입니다.

전통적인 개발 방법에서는 어떻든 프로젝트에서 역할 이 분명하게 구분되어 있습니다. 즉, 아키텍트, 설계자, 프로그램 개발자, 테스터 등으로 나누어 지는 경우 가 많습니다. 또한 기반 기술도 데이터베이스 설계자, 배치 담당자 등으로 나누어 집니다. 그러나 바이브 코딩을 해보면 이러한 구분이 모호 해진다는 것을 알 수 있 수 있습니다. 즉, 루틴화 된 것, How 에 해당되는 것은 너무 쉽게, 너무 빠르게 이루어 집니다(자동으로).

[ 그림-7] 전통적인 개발과 바이브 코딩의 단계와 노력의 차이점

결과적으로 바이브 코딩을 이용하는 개발자로는 경험 있는(‘감’ 있는) 개발자가 적응을 더 잘 할 수 있다는 것입니다. 따라서 신입 개발자를 어떤 과정으로 빠르게 교육하여 ‘감’ 있는, 즉,’멀티 잡 개발자(진정한 린-Lean 개발자)로 키울 것인가’가 숙제가 될 것 같습니다.

 10. 더 나은 바이브 코딩을 위한 팁

소프트웨어 개발 방법은 컴퓨터가 처음 소개된 이후로 지속적으로 발전해 왔습니다. 지속적인 발전의 초점은 코드의 중요성에 더해서, 지속적으로 상위 단계로 이동되었습니다. 즉, 최초에는 코드화(Micro Code) 자체에서, 그 다음은 프로그래밍(Cobol), 그 다음은 설계(Structured Design), 그 다음은 분석(UML), 그 다음은 업무(Information Engineering), 그 다음은 고객 가치(Design Thinking, Customer Get Job Done)로 이동 되어 왔습니다. 본 프로젝트를 진행하면서 확신을 가질 수 있는 부분은 [그림-8] 에서 보듯이 생각보다 AI가 할 수 있는 부분이 크다는 것이 점차 녹색 부분으로 확대 되고 있다는 것 입니다. 과거의 소프트웨어 개발 과정이 그렇게 발전해 왔듯이 AI가 대체 할 수 있는 일(기여 할 수 있는 일)도 같은 패턴으로 이루어 진다는 것을 알 수 있습니다. 이것은 어플리케이션 개발 부문만 보았을 때이고, 본 프로젝트의 시스템이 하려고 하는 것 까지 포함하면 이러한 패러다임의 변화 급속하게 이루질 것이라는 것을 미루어 짐작 할 수 있습니다.

[그림-8] 개발 단계에 따른 영역구분

보다 바이브 코딩을 잘 하려면(다른 측면에서 보면 인간 개발자가 가치를 유지하기 위해서는) 무엇에 초점을 맞추어야 할까요? 첫째는 요구사항에 대한 정확한 이해 입니다. 요구사항은 비즈니스 요구사항과 IT 요구 사항이 있습니다. 비즈니스 요구사항은 외부 경쟁 환경의 변화(PESTNL-정치적,경제적,사회적,기술적,자연적,법률적) 변화, 고객가치, 사업 영역에서의 경쟁구도, 그리고 전략을 바탕으로 한 비즈니스 변화에 대한 이해를 바탕으로 비즈니스 모델의 재설계에 대한 요구이고, IT 요구사항은 이러한 비즈니스 요구사항이 운영 모델로 정착 할 수 있도록 기술 기반인 시스템을 개선 또는 구비하는 요구사항으로 볼 수 있습니다. 앞의 설명으로 보면 IT 요구사항은 IT아키텍처 연계가 더욱더 중요 하게 된다는 것을 알 수 있읍니다. IT 아키텍처를 정의 하는 것도 AI 의 지원을 받아 정의가 가능하나, 아키텍처는 전략을 실현하는 것이기 때문에 기업에 따라 달라 질 수 있는 부분입니다. 따라서 아키텍처에 대한 교육과 실천이 강화 되었을 때 바이브 코딩의 효과를 높일 수 있습니다. 더욱더 중요한 것은 비즈니스 모델 입니다. 기업은 비즈니스를 통해서 기업의 가치를 높입니다. 기업의 가치 정의, 제조, 전달, 획득에 관련 비즈니스가 잘 정의 되어 있으면 바이브 코딩의 효과가 극대화 됩니다. 본 프로젝트의 목표였던 비즈니스 능력 팩토리를 구축 하려고 했던 일차적인 목적은 잘 정의된 비지니스 모델을 기반으로 비즈니스를 직접 실행 시키는(아예 코딩이 필요 없는) 시스템을 구축 하는 것이 였습니다. 또한 이러한 시스템을 통해 기업의 대부분의 작업( IT 개발 및 업무 운영 프로세스)을 자동화 하는 것이 였습니다. 그러면 이것을 가능케 하는 것은 무엇일까요? 그것은 바로 기업의 디지털 트윈입니다. 기업의 디지털 트윈의 기업의 사업 모델에서 부터 매일 모든 직원들이 수행하는 모든 것(지식)들을 비즈니스 온톨로지 기반으로 상세화 및 정의하고 디지털화 한 것입니다 그렇기 때문에 본 프로젝트에 비지니스 능력 팩토리에서 프로세스가 바로 실행 가능하게 되는 것입니다. 이러한 디지털 트윈은 어떻게 구축 할 수 있을까요? 아직은 업무 전문가와 비즈니스 모델러가 이러한 작업을 할 수 있습니다. 아직은 이러한 작업을 AI가 완전히 대체 하기는 어려울 것으로 보고 있습니다. 그 이유는 기업마다 기업의 비전과 가치, 목표가 다르고 직원들의 능력 수준이 다르기 때문입니다. 국내에서는 아직 적용 사례를 알지 못하지만 해외에서는 많은 기업들이 비즈니스 온톨로지 모델을 구축하기 위한 노력들을 하고 있습니다. 저희는 이러한 프로젝트를 해외에서 10여년 전부터 하고 있으며 현재 약 20여개 이상의 기업 들에서 유사한 프로젝트가 진행되었습니다. 저희가 참여했던 어느 금융기관의 프로젝트를 예를 들면, 수천개의 고객 가치 정의, 천 여개의 가치 제조, 전달, 획득 활동, 약 4천개의 업무 타스크, 수천개의 의사 결정을 위한 보고서 및 데이터 리니지, 그리고 수백개의 업무 동사와 수만개의 업무 명사가 정의 되었습니다. 각각의 개념은 목적, 정의, 범위가 명확하게 정의 되고 이들 간의 관계가 다차원적으로 정의 되었습니다. 이러한 비즈니스 온톨로지 모델을 기반으로 비즈니스 혁신과 운영 모델변화(업무 개선과 IT 개발)에 민첩성과 고객 가치 극대화를 위해 노력하고 있습니다. 본 프로젝트는 이러한 비즈니스 혁신 및 모델 플랫폼에서 마치 프로그램을 전개 하듯이 , 업무 운영 프로세스를 직접 전개하여 실행하도록 하는 것을 목표로 하였습니다.

11. 결론

바이브 코딩은 현대 소프트웨어 개발 환경에서 개발자의 창의성과 지속 가능성을 높이는 새로운 패러다임입니다. 이는 단순한 개발 방법론을 넘어서, 개발자가 자신의 일에 가치를 더하고 더 나은 결과물을 만들어낼 수 있도록 돕는 방법입니다.

그럼에도 바이브 코딩은 개발자에게는 위협이 될 수도 있습니다. 개발자가 앞에서 소개 했던 사고방식에 적응하지 않으면 대체 될 수 있는 위험을 가지고 있습니다. 따라서 개발자들은 지금부터 새로운 사고와 작업 방식에 익숙해 져야 할 것입니다.

기업은 바이브 코딩이라는 새로운 개발방식에 많은 기회를 찾을 수 있습니다. 그러나 기업의 비즈니스가 투명하게 정의 되지 않으면 바이브 코딩은 다른 기업의 선진 기법일 뿐 효익을 누리는데 제약이 있게 됩니다. 질문 합니다. 귀사의 비즈니스는 어디 있습니까? 혹시, 직원들의 머리속이나 Legacy 프로그램에만 존재 하고 있는 것은 아닌가요? 이런 기업들은 아마 효과를 충분히 누릴 수 없습니다.

자, 지금부터 기업의 디지털 트윈 구축을 시작 하십시요. 개발자들은 새로운 사고와 메타 인지적 실행 방법에 대한 시도를 시작 하십시요. 새로운 패러다임의 파도가 생각보다 가까이 왔습니다. 여러분 모두 철저한 준비로 파도에서 생존하기를 바랍니다.

부록 : 전통적인 개발방식과 바이브 코딩의 차이점

참고 자료 :

1. 실제 실행 비디오 : Business Capability Factory-DREAMER
2. 참고 자료 : http://www.bmgovernance.com