그림(ref1)

해결할 문제를 소프트웨어로 어떻게 표현할 것인지를 고민하는 일을 모델링이라고 부른다. 다이어그램은 모델링 결과물을 시각화(일러스트레이팅)한 결과물이다(ref1). 소프트웨어 개발 프로젝트 초기에 집중해야 하는 것은 다이어그램이 아니라 모델링이다.

AI에게 도메인 모델에 대해 LLM에게 잘 정리해 설명할 수 있는 능력이 있더라도, 도메인 모델을 만드는 방법을 전혀 모르기 때문에 병목이 되고 있음을 느끼는 최근이다. 내가 인식한 현실 세상의 모델과 LLM이 인식한 문제해결 범위를 동일하게 맞추고 구현을 위임하기 위해서는 도메인 모델을 잘 만드는 것이 중요하다. 명세에 포함되지 않은 중요한 제약조건으로 인해 나와 LLM의 인식에 차이가 발생하고, 이렇게 작성된 LLM의 코드를 고치며 소비하는 시간을 줄일 수 있다.

parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료을 보관해 두는 영역입니다.

1. None

from : 과거의 어떤 원자적 생각이 이 생각을 만들었는지 연결하고 설명합니다.

1. [a0_4.1_1.2. title: 내가 소프트웨어를 만드는 속도가 느린 이유는 아직 무엇을 만들지(문제와 핵심 로직에 대한 인식), 가진 도구들을 가지고 할 수 있는 일은 무엇인지(사용하는 도구의 핵심 코드 조각) 명확하지 않은 상태에서 코드를 작성하기 때문이다. 이런 상황에서, 코드가 점진적으로 확장할 것을 지나치게 염두에 두면 과한 추상화가 된다. 무엇을 만들지와 무엇이 가능한지가 명확하지 않으면 패턴이나 클린 코드같은 단어를 머리에서 지워라.](https://janghoo.notion.site/a0_4-1_1-2-title-1b0547ddc2ba80a9bf02f036c152f5e6)
   • 앞의 글은 ‘무엇을 만들지 정의하는 일’이 중요하다고 했지만 이는 조금 모호하다. 무엇을 만들지는 한 문장으로도 표현할 수 있다. 그러면 이것을 어디까지 정의해야 하는가, 어떻게 정의해야 하는가? 조금 더 다듬어진 표현으로 중요한 것은 ‘모델링’이다.
2. a0_4.1_1. [entry] title: 생성형 AI와 포멀하고 딱딱한 소프트웨어공학의 조합
   • 이 글을 작성하기 전, 앞의 엔트리포인트에서 정리해 둔 소프트웨어 설계 과정은 다이어그램 중심이었다. 이 다이어그램을 그리고, 저 다이어그램을 그리고, … 하지만 그럼에도 나는 막상 다이어그램을 그리는 것을 피하게 되고, 쉽지도 않았다. 모델링과 다이어그램 일러스트레이팅이 다른 것이라고 생각해보면 그 이유를 알 것 같기도 하다. 다이어그램을 그리는 작업은 대부분 표준을 공유하는 사람들끼리 쉽게 알아볼 수 있게 만드는 일에 주안점을 둔다. 그 전에 모델링은 어떻게 하면 잘 할 수 있을까를 고민하면 문제에 접근하는 것이 훨씬 수월하다.

supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는지 연결합니다.

1. ‣

opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는지 연결합니다.

1. None

to : 이 문서에 작성된 생각이 어떤 생각으로 발전되거나 이어지는지를 작성하는 영역입니다.

1. None