온라인 세미나 – Generative Analysis – 첫 번째 서문, 1장
Generative Analysis – The Power of Generative AI for Object-Oriented Software Engineering with UML
서문
| 우리는 소프트웨어 공학의 주요 혁명의 시작점에 서 있습니다. 그 이유는 생성형 인공지능(Generative AI)으로 알려진 소프트웨어 시스템이 코드를 작성하고 있기 때문입니다.
2023년에 일어난 일은 우리가 자연어로 컴퓨터에게 원하는 소프트웨어를 말하면, 그것을 만들어 줄 수 있는 단계에 도달했다는 것입니다. 우리는 이러한 새로운 생성형 AI 시스템이 코드의 수동 작성에서 벗어나 생성형 AI 시스템에 입력할 수 있는 다른 산출물을 만드는 방향으로 전환을 강요할 것이라고 믿습니다.
생성적 AI의 맥락에서 원형 패턴의 특별한 점은 그것들이 추상적인 분석 패턴이면서도 비즈니스 사람들이 쉽게 이해할 수 있을 만큼 구체적이라는 점입니다. 이를 달성하기 위해, 우리는 비즈니스 분석과 코드 생성의 경계를 넘나드는 매우 특정한 수준의 추상화를 정의했습니다. 또한, 원형 패턴은 텍스트로 패턴을 설명하는 정확한 서술인 문서화 모델(Literate Model)로 패키징됩니다. 이것이 바로 생성적 AI 코드 생성기에 필요한 입력입니다. 우리는 패턴 자체보다 패턴을 어떻게 만들었는지가 훨씬 더 중요하다고 생각합니다. 생성적 분석은 소프트웨어 시스템을 충분히 상세하게 설명하여 코드와 기타 산출물을 생성할 수 있는 매우 정확한 서술을 만들 수 있게 해주는 도구와 기법의 세트입니다. 분명히, 이는 새로운 생성적 AI 코드 생성기와 자연스럽게 맞아떨어집니다. 이 책의 목적은 당신이 누구든지 간에 생성적 분석을 가르치는 것입니다. 만약 당신이 프로그래머로서 미래에 대해 걱정하고 있다면, 생성적 분석은 당신이 AI 미래에 대비하여 더 높은 수준의 추상화에서 일하고 생각할 수 있게 해줄 것입니다. 이는 도전적일 수 있습니다. 만약 당신이 비즈니스 분석가라면, 이미 높은 수준의 추상화에서 일하는 데 익숙할 것입니다. 그러나 그 수준은 현재 생성적 AI의 범위를 약간 벗어날 수 있습니다. 당신은 반드시 더 낮은 수준의 추상화에서 생각하는 법을 배울 필요는 없지만, 훨씬 더 정확해지는 법을 배워야 할 것입니다. 이상적인 사고방식은 프로그래머와 비즈니스 분석가의 중간 어딘가에 있습니다. 세부 사항에 대한 거의 고통스러운 수준의 주의력과 높은 수준의 추상화에서 생각하고 일할 수 있는 능력입니다. 일부 사람들은 이 두 가지가 상호 배타적이라고 생각하지만, 그렇지 않으며 결코 그렇지 않았습니다. 최고의 모델은 우리가 “Enterprise Patterns and MDA”에서 입증했듯이 추상적이면서도 정확합니다. 좋은 소식은 프로그래머와 분석가 모두 이미 필요한 많은 기술과 태도를 가지고 있다는 것입니다. 비록 각자가 다른 방향에서 문제에 접근하더라도 말입니다. |
Chapter 1. Generative Analysis for Generative AI
대부분의 소프트웨어는 누군가의 문제를 해결하기 위해 개발합니다. 문제 영역, 다루어야 할 문제 영역, 도메인이 있다는 것입니다. 해결책을 만들 때 문제 영역에 사는 사람들이 직접 해결책도 만들면 커뮤니케이션 문제가 없겠지만 소프트웨어를 만드는 사람들을 문제 영역에 살지 않고 문제 영역도 잘 모르기 때문에, 커뮤니케이션이 쉽지 않습니다.
UML은 이를 위해 그래픽 표현을 가지고 등장했지만, 현실 적용은 여러 가지 이유로 그리 평탄하지만은 않는 거 같습니다. 많은 부분 자동으로 코드 생성을 해 주는 도구도 많이 있지만, 노력 대비 만족도는 그리 높지 않은 것이 현실입니다.
저자들은 생성형 분석을 이야기 해 왔는데, 생성형 AI를 만나 그들의 주장을 현실화 할 수 있다고 보는 것 같습니다.
생성형 분석을 알고 이를 생성형 AI에 적용하는 것이 저자들의 목표일 거라고 생각하고 지지 합니다.
| 생성형 분석의 세 가지 주요 원칙 – 소통, 모델링, 추상화
생성적 분석은 소통에서 시작됩니다.
추상화는 생성적 분석과 소프트웨어 공학 전반을 이끄는 근본적인 과정입니다. |
문제 영역의 사람들과 해결책 영역이 사람들이 다른, 소프트웨어 개발은 소통에서 시작됩니다.
생성형 AI에 있어서 소통 또한 중요합니다. 질의나 지시를 작성한 프롬프트로 LLM과 소통해야 합니다. 소통을 잘 해야 원하는 결과를 얻을 수 있습니다. 흥미나 재미 수준에서는 대충 하면 되겠지 할 수도 있지만, 업무에서 생산성을 높이려면 소통은 대충해도 되는 게 아닌 게 됩니다. 프롬프트 엔지니어링이란 결국 LLM과 소통을 잘 할 수 있는 방법을 다루는 것입니다.
| 많은 프로그래머들이 자신들이 모델을 만들고 있지 않다고 생각하는 것이 재미있습니다. 프로그램은 문제 도메인의 관련 측면을 모델링하는 것으로, UML 모델, 정확한 언어적 설명, 비즈니스 분석 문서와 마찬가지로 하나의 모델입니다. 모델링이란 특정 특징을 포착하고 다른 것들을 무시하는 어떤 것의 표현을 만드는 것입니다. 이는 추상화의 과정입니다. 인간의 뇌가 작동하는 방식 때문에 우리는 모두 모델러입니다. 우리는 이를 피할 수 없습니다.
왜곡, 삭제, 그리고 일반화는 생성적 분석(Generative Analysis)의 핵심 개념입니다. • 왜곡: 지도가 정확하지 않으며, 환각적인 요소가 포함되어 있습니다. • 삭제: 지도가 완전하지 않으며, 정보가 누락되어 있습니다. • 일반화: 특정 세부 사항이 지도에서 제거되고 규칙과 신념으로 대체됩니다.
왜곡, 삭제, 그리고 일반화는 다소 역설적이게도 정신적 지도를 효율적으로 만드는 방법입니다. 최소한의 자원으로 일을 수행할 수 있을 만큼 충분히 좋은 상태로 만드는 것입니다. 왜곡은 존재하지 않는 것을 환각하는 과정입니다. 삭제는 항상 일어나고 있습니다. 삭제는 우리가 주의를 기울이지 않는 것들을 걸러낼 수 있게 해 줍니다. 일반화는 “정신적 지름길”이며, 시간을 크게 절약해줍니다. 모든 세부 사항에 주의를 기울이는 대신, 종종 규칙과 신념을 적용하는 것만으로도 충분하기 때문입니다. 왜곡, 삭제, 그리고 일반화는 인간에게 주어진 기본적인 특성으로 보이며, 자연 언어에도 반영됩니다. 생성적 AI는 대규모 언어 모델(Large Language Models)을 기반으로 하기 때문에 이러한 과정에 영향을 받습니다. 소프트웨어 엔지니어링에서 생성적 AI를 사용할 때, 왜곡이 아마도 가장 큰 문제일 것입니다. 생성적 AI가 종종 질문에 대한 답을 그냥 만들어내는 것이 잘 알려져 있기 때문입니다. 삭제도 꽤 흔합니다. 예를 들어, “각 부서에는 한 명 이상의 직원이 있다”는 규칙을 명시하고 생성적 AI에게 그에 기반한 코드를 생성하도록 하면, 생성된 코드에서 “한 명 이상”이라는 비즈니스 규칙이 “0명 이상”으로 축소될 수 있습니다. 일반화도 AI가 프롬프트를 제안하도록 허용하면 큰 문제가 될 수 있습니다. 곧 보게 될 예로는 AI가 세금을 계산하는 코드를 생성하면서 세율을 고정하고 하드코딩하는 것입니다.
추상화 – “특정 맥락에서 중요한 세부 사항의 선택”. 우리의 정의는 추상화가 선택의 과정, 즉 문제와 관련하여 중요한 세부 사항을 선택하는 과정임을 강조합니다. 모든 다른 세부 사항은 자동으로 버려집니다. |
| 추상화는 최소한 하나의 중요한 목표를 가져야 하지만, 일반적으로 여러 관련된 하위 목표가 있습니다. 나중에 살펴볼 다양한 형식적인 표현 방법이 있습니다. 일반적으로 목표는 열 개 미만이어야 합니다. 목표가 너무 많다면, 이는 아마도 다른 추상화가 필요하다는 것을 나타냅니다. 특정, 측정 가능한 혜택이 식별 가능한 당사자에게 있는 경우에만 추상화에 목적이 있다고 가정합니다.
중요한 세부 사항은 추상화의 목적과 관련하여 유용한 세부 사항으로 정의할 수 있습니다. 반대로, 관련 없는 세부 사항은 추상화의 목적과 관련하여 유용하지 않은 세부 사항입니다. 이를 통해 세부 사항을 추상화의 목적에 유용한 것과 그렇지 않은 것으로 나눌 수 있습니다. 우리는 유용한 세부 사항만 포함하고, 유용하지 않은 모든 것을 생략합니다. 확실하지 않은 것이 있다면 생략하고 필요할 때 다시 추가합니다.
목적과 유용성의 개념은 특정 수준의 추상화를 정의합니다.
많은 비즈니스 분석가와 소프트웨어 엔지니어가 추상화를 종종 모호하거나 불분명하게 만드는 것으로 보는 다소 다른 견해를 가지고 있다는 것을 알고 있습니다. 그러나 이것은 단순히 사실이 아닙니다. 세부 사항은 목적에 따라 포함되거나 포함되지 않지만, 아무것도 모호하게 만들지 않습니다! 추상화 수준은 목적과 유용성 측면에서 매우 정확하게 정의될 수 있으며, 주어진 문제에 대한 “올바른” 추상화 수준은 임의적이지 않습니다. 그것은 목적에 의해 정확하게 정의됩니다. 그러나 추상화 수준이 정확하게 정의되지 않으면 전체 모델이 모호하게 보일 수 있습니다. 한 부분에서 특정 수준의 세부 사항을 보고 다른 부분에서도 동일한 수준의 세부 사항을 기대하지만, 그것이 없기 때문입니다. 따라서 전체가 “모호하게” 보입니다. 이것은 좋은 테스트입니다—어떤 종류의 모델을 보고 그것이 “모호하게” 보인다면, 이는 혼합된 추상화 수준이 있으며 추상화의 목적이 잘 정의되지 않았거나 심지어 의식적으로 고려되지 않았음을 나타냅니다. 추상화의 목적을 정의하는 것은 종종 간과되는 단계입니다. 그러나 추상화의 목적을 정의하지 않았다면, 정의상 그것은 목적에 맞지 않을 수 없습니다. 그럼에도 불구하고 우리는 추상화의 목적이 전혀 정의되지 않았거나 심지어 생각조차 하지 않은 모델(종종 UML 모델 또는 비즈니스 모델)을 반복해서 봅니다. 이러한 모델은 많은 추상화 수준의 혼합이 되는 경향이 있으며, 아무도 만족시키지 못합니다. 어떤 부분에서는 너무 낮은 수준이고, 다른 부분에서는 너무 높은 수준이며, 유용한 정보를 전달할 수는 있지만, 더 자주 혼란스럽습니다. 이것이 일부에서 모델링에 대한 나쁜 평판을 준 이유입니다. 추상화 수준의 문제는 어떤 면에서는 추상화에서 달성하고자 하는 것을 깊이 생각해야 하는 미묘한 문제입니다. 이것이 프로그래머들이 때때로 어려움을 겪는 이유라고 생각합니다. 프로그래밍에서는 매우 구체적이고 잘 정의된 추상화 수준, 즉 소스 코드 수준에서 작업하는 법을 배우며, 이에 대해 생각할 필요가 없습니다. 이 추상화 수준은 컴파일러나 인터프리터 및 테스트에 의해 자동으로 확인됩니다. 분석 모델로 한 단계 올라가는 것은 낯설게 느껴질 수 있으며, 어셈블러로 한 단계 내려가는 것도 마찬가지입니다. 이는 문제를 다른 방식으로 생각해야 하는 낯선 추상화 수준이기 때문입니다: 전자에서는 더 적은 세부 사항을 포함하고, 후자에서는 더 많은 세부 사항을 포함해야 합니다. 그러나 추상화 수준을 전환하는 정신적 유연성은 생성적 AI가 가능하게 하는 소프트웨어 엔지니어링으로 나아가면서 점점 더 중요해질 것입니다. 종종 동시에, 다른 하지만 잘 정의된 추상화 수준에서 작업할 수 있는 능력은 필수적인 기술이 될 것입니다.
모델은 생성적 AI가 이를 코드로 변환할 수 있을 만큼 충분히 정확하게 만들어져야 합니다. 우리는 UML과 같은 형식적 모델링 언어를 사용한 모델링 교육이 모든 비즈니스 분석가의 도구 상자에 포함되어야 한다고 믿습니다. 이를 통해 그들이 자신의 아이디어를 더 정확하게 표현할 수 있도록 배울 수 있습니다.
다음은 추상화 수준을 이해하는 데 도움이 될 수 있는 유용한 은유입니다. NLP/일반 의미론에서 추상화를 다음과 같이 정의할 수 있습니다: 어떤 면에서는 이것이 우리가 가장 좋아하는 정의입니다. 지도 은유는 정의의 정신적 이미지를 형성할 수 있게 해주며, 이는 재미있고 유용합니다. “특정 맥락”은 지도, 즉 추상화가 목적을 가지고 있음을 강조합니다.
[생성형 AI를 위한 적절한 추상화 수준 찾기] 문서화된 모델은 UML 모델을 직접 참조하며 작성된 서술로 구성됩니다. 목표는 UML을 모르는 사람들까지도 포함하여 가능한 많은 이해관계자에게 UML 모델에 암호화된 정보를 정확한 사람이 읽을 수 있는 서술을 통해 제공하는 것입니다. |
