오래된 SW 엔지니어의 평생 공부

아키텍처 드라이버는 시스템의 아키텍처에 영향을 미치는 주요 요인(Driver)이다. 이러한 드라이버는 아키텍처 결정을 내리는 데 중요한 역할을 하며, 요구사항(Requirement), 제약사항(Constraint), 원칙(Principle) 등을 포함할 수 있다. 소프트웨어 아키텍처 분야의 다양한 전문가와 저자들은 아키텍처 드라이버에 대해 논의하였는데 주요한 내용들을 정리해 보자.

아키텍처 드라이버를 언급하는 주요 인물들

1. 그래디 부치 (Grady Booch)
   • 공통점:
     • 요구사항(Requirement)과 제약사항(Constraint)을 이해하는 것이 중요하다고 강조한다.
     • 성능, 확장성, 보안과 같은 품질 속성(Quality Attribute)의 역할을 강조한다.
   • 차이점:
     • 아키텍처 결정 과정과 UML과 같은 모델링 언어 사용에 더 중점을 둔다.
2. 메리 쇼와 데이비드 갈란 (Mary Shaw and David Garlan)
   • 공통점:
     • 아키텍처 스타일(Architectural Style)과 패턴(Pattern)이 아키텍처 드라이버의 일부임을 강조합니다.
     • 기능적 요구사항(Functional Requirement)과 비기능적 요구사항(Non-functional Requirement 혹은 Quality Attribute) 모두를 다룰 필요성을 강조한다.
   • 차이점:
     • 아키텍처 스타일을 분류하고 이해하는 데 중점을 두는 더 학문적이고 이론적인 관점을 제공한다.
3. 바스, 클레멘츠, 카즈먼 (Bass, Clements, and Kazman) - "Software Architecture in Practice" 저자들
   • 공통점:
     • 품질 속성(Qaulity Attribute)이 아키텍처 결정에 중요한 역할을 한다고 강조한다.
     • 이해관계자의 우려가 아키텍처를 형성하는 데 중요한 역할을 한다고 강조한다.
   • 차이점:
     • Attribute-Driven Design (ADD) 방법 등 아키텍처 결정을 평가하고 문서화하는 자세한 프레임워크를 제공한s다.
4. 마틴 파울러 (Martin Fowler)
   • 공통점:
     • 요구사항과 제약사항이 아키텍처 결정에 중요한 역할을 한다고 인정한다.
     • 아키텍처의 유연성을 유지하여 변화하는 드라이버에 적응하는 것이 중요하다고 강조한다.
   • 차이점:
     • 실무 경험과 애자일 방법론을 통해 아키텍처 드라이버를 다루는 데 더 중점을 둔다.

공통점

• 품질 속성(Quality Attribute): 모든 저자는 품질 속성(예: 성능, 보안, 유지보수성)이 중요한 아키텍처 드라이버임을 강조한다.
• 이해관계자의 우려: 다양한 이해관계자의 우려를 이해하고 해결하는 것이 중요하다고 일관되게 강조한다.
• 기능적 및 비기능적 요구사항: 두 가지 요구사항 모두 아키텍처 결정을 내리는 데 기본적이라고 인식한다.

차이점

• 방법론 및 프레임워크:
  • 그래디 부치는 모델링 언어와 프로세스에 중점을 둔다.
  • 바스, 클레멘츠, 카즈먼은 ADD와 같은 특정 프레임워크를 제공한다.
  • 마틴 파울러는 애자일 실천과 현실 세계의 적응성을 강조한다.
• 관점:
  • 카네기 멜론대 소프트웨어 엔지니어링 인스티튜트(Carnegie Mellon University Software Engineering Institue, CMU SEI)의 메리 쇼와 데이비드 갈란은 더 이론적이고 학문적인 접근을 취한다.
  • 마틴 파울러는 실무자 지향적 관점을 제공한다.
• 프로세스 vs. 패턴에 대한 강조:
  • 그라디 부치와 마틴 파울러는 프로세스와 적응성에 중점을 둔다.
  • 메리 쇼와 데이비드 갈란, 바스 등은 아키텍처 스타일과 패턴을 이해하고 활용하는 데 중점을 둔다.

요약

요약하자면, 품질 속성, 이해관계자의 우려, 기능적 및 비기능적 요구사항의 중요성에 대한 공통점이 있지만, 방법론, 관점, 특정 강조점에서 차이가 있다. 그라디 부치는 프로세스와 모델링에 중점을 두고, 메리 쇼와 데이비드 갈란은 이론적 이해를, 바스 등은 프레임워크를, 마틴 파울러는 실무와 애자일 방법론을 강조한다.

소프트웨어 아키텍처를 고려할 때 주요한 무기 중 하나가 추상화(abstraction)이다[1]. 추상화는 문제를 축소하여 해결하기 더 쉬운 작은 문제로 만들어 규모와 복잡성의 문제를 효과적으로 해결하게 한다. 여기서도 LLM(Large Language Model)의 여러 측면에서의 추상화를 통해서 이를 활용하는 Software Architecture에 대해서 이해도도 높이고 이를 활용해 설계하는데도 도움이 될 수 있기를 기대해 본다.

프로그래밍 모델로서의 LLM

LLM을 가지고 Prompt를 작성해서 작업을 하는 것은 마치 우리가 컴퓨터 프로그래밍하는 것과 비교가 가능하다. 아래 그림[2]이 이 부분을 잘 보여 준다. LLM은 이미 트레이닝을 마치거나 우리가 원하는데로 파인 튜닝을 마친 것이라고 볼 수 있다. 여기에 사용자의 Prompt를 전달하는 것까지 프로그래밍하는 것과 유사하다는 비교를 볼 수 있다. 물론, Prompt가 자연어에 가깝고 결과가 프로그래밍과는 조금 다르게 나올 수 있지만 LLM과 Prompt를 컴퓨터 프로그래밍과 매치 시켜보는 구조는 LLM을 가지고 원하는 작업하는 것에 대한 가장 간단한 추상화로 볼 수 있다.

인간 인지 구조와 비교

LLM과 비교하기 위해서 인간 인지 메모리 모델을 살펴보자[3]. 결국은 기억/메모리 구조인데, 감각기억 (Sensory Memory), 단기기억 (Short-term Memory), 장기기억 (Long-term Memory)으로 구성된다.

감각기억 (Sensory Memory)은 시각, 청각 그리고 촉각과 같은 감각 기관에서 입수된 정보를 잠시 저장했다가 단기 기억으로 저장되는데 일부는 장기기억으로 전달 된다고 한다.이 단기 기억은 정보가 짧은 시간 동안 저장되고 처리되는데. 작업기억(Working Memory)으로 불리며, 정보의 일시적 저장과 조작을 담당한다. 장기 기억은 정보를 오랜 기간 동안 저장하는데, 크게는 명시적 기억(Explicit Memory)과 암묵적 기억(Implicit Memory)으로 나뉜다.

LLM은 구조적으로는 비슷해 보인다. 사용자가 LLM에 입력으로 Prompt를 제공하면 이는 마치 사람의 작업 기억 처럼 컨텍스트 윈도우(Contexnt Windows) 내의 내용만 참조하고 처리한다. LLM이 많은 내용을 학습하고 이를 통계적인 절차를 통해서 말이 되도록 생성한다. 

다시 말하자면, LLM이 사람의 장기기억 처럼 동작하지는 않지만, 유사성이 있기 때문에 이를 잘 활용하는 것이 필요하다. 첫 째로 대량의 정보를 저장하고 있다. 즉, 대량의 텍트스 데이터를 학습하여 패턴과 지식을 내재화하였다. 그리고, 학습을 통해서 지식이 형성되어 있기 때문에 사용자의 입력에 대해 예측하고 그 결과를 제공한다. 그렇기 때문에, LLM을 "말많은 뉴비(Newbie)"로 비유되기도 한다.

LLM 애플리케이션 아키텍처

LLM 어플리케이션의 레퍼런스 아키텍처의 구성 요소를 [5]에서 잘 보여 준다. 하지만, 여러 항목이 있어서 너무 복잡해 보이기도 한다. 이를 간략화 하면 아래와 같다고 볼 수 있다.

LLM의 경우는 미리 트레이닝을 해야 하기 때문에 최신 자료들에 대해서 처리하지 못한다. 24년 6월의 경우도, 23년 10월까지 업데이트 되어 있다고 한다. 이 부분의 한계를 극복하기 위한 것이 Retrieval Augmented Generation (RAG)이다. [5]에도 있지만, Embedding Model, Vector Database와 같은 개념이 포함된다. 이 부분에 대해서는 따로 더 자세히 다뤄 보겠다. LLM의 경우도, 상용화를 위한 Foundatation Model 뿐만 아니라 사용자와 interaction을 위한 Cache 그리고 부적절한 생성 내용을 filtering하기 위한 모듈도 포함되어 있.

마치며.

LLM과 관련된 작업 혹은 어플리케이션의 추상화를 통해서 구조적인 측면을 프로그래밍 언어 관점, 인간의 인지적 모델과 비교, 최근의 LLM 기반 어플리케이션 모델의 관점에서 살펴보았다. 어플리케이션의 관점이나 문제의 관점에서 또한 추상화와 구조의 변경이 필요하겠지만, LLM을 기반으로 하는 시스템의 소프트웨어 아키텍처 관점에서 좋은 시작점이 될 수 있지 않을까 기대해 본다.

참고문서

[1] 조지 페어뱅크스 저/이승범 역, "적정 소프트웨어 아키텍처-리스크 주도 접근법" 한빛미디어

[2] Prompt Engineering이란?, https://velog.io/@w0_0727/i4uh3e4e

[3] Eduardo Camina,and Francisco Güell, " Psychological Basis of Memory: Current Models and Their Origins," https://www.frontiersin.org/journals/pharmacology/articles/10.3389/fphar.2017.00438/full

https://a16z.com/emerging-architectures-for-llm-applications/

[4] Sunil Ramlochan, "Statistical or Sentient? Understanding the LLM Mind - Part 1 - Memory" https://promptengineering.org/statistical-or-sentient-understanding-the-llm-mind/

[5] Nicole Choi, "The architecture of today’s LLM applications", https://github.blog/2023-10-30-the-architecture-of-todays-llm-applications/?fbclid=IwAR2daV0oLZAU8ZS45SeL5Wh7aVDcscJBL1hsEBBRVXW2rywoeqd6AnfwzJg

[1]에서 가장 와닫는 말은 "나는 밥 먹기 전에 설거지하는 전략을 섞어서 쓴다. 보통은 밥 먹고 나서 설거지하는 것이 좋은 생활 습관이지만, 설거지한 이득은 다음 밥 먹을 때가 되야 발생한다. " 이다. 그렇지만, under-engineering이 당연히 좋다고 하는 것만 같아서 약간은 불편했다. 맞는 것일까? 그렇다고, 나는 over-engineering을 추종하는 것인가라고 질문했을 때도 불편했다. 그러면서도, 내가 아는 것은 무엇일까 하면서 시간이 상당히 흘렀다. 글을 쓸 거라고 생각했지만, 생각이 충분히 자라지 못하고 있었다. 비 오는 아침에 떠오르는 것이 적어 본다.  
  
아내와 결혼하고 여러가지로 달랐다. 설거지 측면에서는 나는 요리를 하면서도 치워가면서 해야 했다. 그렇지만, 아내는 설거지는 가능한 늦게 하는 것이 좋다고 생각하는 것으로 보였다. 내가 요리하기 위해서 싱크대를 보면 시작하기 힘들어 보여 못하는 경우도 있었다. 그렇다고 해서, 나는 완벽했는가 생각해보면 그렇지 않다. 설거지 관련해서 아내가 나에게 핀잔을 주는 경우도 많았기 때문이다. 단지 달랐다고 해야 할 것 같다.  
  
"Hacker News"에서 진행된 "over-engineering과  under-engineering 사이의 균형 찾기"[2] 에 관한 토론에서 보아도 여러 의견이 있지만 여전히 under engineering이 우세인 것처럼 보인다. 미래는 예측하기 어렵고 복잡하고 성급한 일반화가 문제 될 수 있다는 것이다. 그러면서도, 조심스럽게 이야기 하는 것은 실용적 한계 내의 균형(balance)이다. 그렇다면, over-engineering은 무엇이고 under-engineering은 어떤 것인가? 우리는 어떻게 판단할 수 있는 것인가?  
  
앞의 에피소드에서도 이야기했지만, 배가 고파서 뭔가 해먹어야 하는데 설거지 때문에 아무것도 못하고 결국 시켜먹는다면 그것은 좋은 상황일까? 개발할 때에도 한걸음도 나아가기 어렵다면 이 상황과 비슷한 것 같다. 요구사항이 있고 진행을 해야 하는데 못하고 있다면 고민해야 한다. 내가 해야 하는 일이 한걸음도 나아가기 어렵다면? 팀이 해야 하는 일이 있는데 못한다는 결론만 난다면? 설거지 거리가 산더미처럼 쌓여 있는 것이 아닐까? 조금이라도 진전을 만들어야 한다.  
  
  
산더미 같은 설거지를 보고 힘이 빠지지만, 애자일 마인드를 장착하고 지금 보다는 좋게 만들자라고 생각하고 더 개선을 한 다음 요리를 해 먹는 것은 어떤가? 여러 가지 전략이 있겠지만, 요즈음 공감이 가는 문구[3]가 있다. "First do it, then do it right, then do it better"이 그것이다. 나는 동작하는 소프트웨어가 정말 중요하다고 생각한다. 동작하지 않는 것을 고쳐서 동작하게 되어도 배우지만, 쉽지 않고 어렵다. 동작한다면 조금 더 쉽게 배우고 더 좋게 만들 수 있다.  
  
다시 설거지로 돌아가 보자. 단순하게 하자. 우선 설거지를 하긴 해야 한다. 내가 요리하기 위한 공간도 만들어야 하고, 요리에 필요한 조리 도구도 정리해야 한다. 그것을 위해 고민하는 것 자체가 요리를 위한 설계이다. 혹시, 저녁까지 요리할 거라면 여력이 있다면 그것까지 고민하는 것이 좋겠다. 가족들과 함께할 것이라면 어떤 요리를 어느 정도 할 것 인지도 가족들과 이야기 하고 나눠야 한다. 그러고 나면, 설거지를 어느 정도 할지 정리가 된다. 이러한 상황을 개발과 빗대어 보면, 내가 under-engineering한 것인가? over-engineering한 것인가? 나 스스로와 팀과 밸런스를 맞춘 것이다.  
  
개발도 요리처럼 느껴진다. 나 혼자를 위해 요리하기도 하지만, 나와 아내 그리고 아이를 포함한 가족을 위해 하기도 한다. 정리해 보면, 포인트는 나 그리고 팀에 맞는 방법을 쓰고 있는가, 지금 하고 있는게 밸런스에 맞다는 걸 아는가 이겠다.  흑백논리로 under-engineering과 over-engineering으로 나누기 보다는 동작하는 소프트웨어를 통해서 나와 팀이 이 미묘한 밸런스를 배우고 찾아가고 있는가가 더 중요할 수도 있겠다.   
  
참고문헌  

[1] Youngrok Pak, "Simple Design" [https://youngrok.com/Simple%20Design](https://youngrok.com/Simple%20Design) 
[2] "Striking the Right Balance: Over-Engineering vs. Under-Engineering Software", [https://news.ycombinator.com/item?id=37063643](https://news.ycombinator.com/item?id=37063643) 
[3] Addy Osmani, "First do it, then do it right, then do it better" [https://x.com/addyosmani/status/314785735171518464?fbclid=IwZXh0bgNhZW0CMTEAAR0lMbyKE58a-O4zoeW9e3CNA03g0Sc7J5knTvnB_HZsvLqyohsG3RHoD0g_aem_igNvyHYBauJqmZckFYChjg](https://x.com/addyosmani/status/314785735171518464?fbclid=IwZXh0bgNhZW0CMTEAAR0lMbyKE58a-O4zoeW9e3CNA03g0Sc7J5knTvnB_HZsvLqyohsG3RHoD0g_aem_igNvyHYBauJqmZckFYChjg)