• 관심가지게 된 계기
    1. 메모를 어떻게 재사용할까 고민하다가 관심을 가지게 되었다. 아래 글에서는 메모라는 행위와 소프트웨어공학이 어떤 연관이 있는지에 대해 이야기한다.
      • a0_4.1. title: 제텔카스텐 엔트리포인트 메모는 추상화된 생각 덩어리이다. 소프트웨어공학의 기본 원칙의 아이디어와 동일하다.
    2. 정확하게 요청하지 못했기 때문에 LLM이 작성한 코드 결과물에 아쉬움이 남는다는 생각이 들었다. 정보처리기사 시험을 공부하다 보면 ‘도대체 이렇게까지 용어를 정의해야 하는 이유가 무엇일까’ 싶은 것들이 많다. 이들은 잘 정의된 용어로 AI 대신 사람에게 요청했던 것이다. AI도 마찬가지로 명확한 입력을 주어야 명확한 출력이 나온다.
      • 3_3_8. title: 용어가 잘 정의되었음은 언어의 사회성을 만족했음을 의미한다. 프롬프트 엔지니어링의 본질은 잘 정의된 용어들로 얻고자 하는 것을 정확히 서술하는 것이다.
    3. 프로토타이핑 중 개발을 해야만 하는 상황까지 갔거나, 실제로 개발 프로젝트에 착수해야 하는 상황이 있을지도 모른다. 이런 상황에는 어떤 순서로 생각을 해나갈 것인가.
      • 9_2.1_2. [entry] title: 디자인씽킹의 단계와 목적이라는 추상화에 따라 창업 도구들을 정리한 엔트리
    4. 실질적으로 소프트웨어를 개발하려면 무엇부터 해야 하는가? 이 질문에 막막한 경우가 많았다. 이참에 뼈대를 만들어 두자.
      • bb6_1. title: 작업 흐름에서 이탈했을 때 시스템의 문제인지 내가 비효율적인 행위를 하고 있는지 성찰하기 위해, 어떠한 일을 꾸준히 지속하는 일에 막막함을 걷어내고 노하우를 축적하기 위해 시스템(워크플로)가 필요하다.
  • AI가 코드를 잘 짜도 이것을 개선하려면 AI에게 코드를 잘 짜라고 오더해야 한다. AI가 코드를 잘 짜도 구조적으로 어떻게 만들어진 것인지 이해할 수 있어야 한다.
  • LLM과 함께하는 소프트웨어 개발 워크플로를 커다란 틀에서 바라보면 다음과 같이 두 단계로 구성된다.
    1. 무엇을 만들지 구체적으로 정의하는 과정
      • [a0_4.1_1.2. title: 내가 소프트웨어를 만드는 속도가 느린 이유는 아직 무엇을 만들지(문제와 핵심 로직에 대한 인식), 가진 도구들을 가지고 할 수 있는 일은 무엇인지(사용하는 도구의 핵심 코드 조각) 명확하지 않은 상태에서 코드를 작성하기 때문이다. 이런 상황에서, 코드가 점진적으로 확장할 것을 지나치게 염두에 두면 과한 추상화가 된다. 무엇을 만들지와 무엇이 가능한지가 명확하지 않으면 패턴이나 클린 코드같은 단어를 머리에서 지워라.](https://janghoo.notion.site/a0_4-1_1-2-title-1b0547ddc2ba80a9bf02f036c152f5e6)
    2. LLM과 함께 만드는 과정
      • 3_3_8.1. title: LLM 시대에 디자인패턴과 아키텍처에 익숙해진다는 것은 LLM과 공유하는 유비쿼터스 언어를 가지는 것이다.
  • 실제 개발 순서를 기준으로 도구들을 다시 정리한다면 다음과 같다.
    1. 요구사항 정리, 기능 정리, 일정 추산

      • 필수: 프로토타입 모형을 기본으로 하나, 혹시 나선형 프로젝트를 하는 것은 아닌지 판단한다.

        법적 리스크 낮음 법적 리스크, 개발 난이도 높음
        실 사용자 상호작용 보장됨 프로토타입
        실 사용자 상호작용 보장 안 됨 나선형(e.g. 자율주행)

      • 필수: UML 동적(행위) 다이어그램 중 유즈케이스 다이어그램을 그린다.

        • ’무엇을 만들지 구체적으로 정의하는 과정‘에서 강조하듯, 지나친 확장성 고려를 막고 개발을 최소화하기 위해 필요하다.
        • 단순히 그리는 행위가 중요한 것이 아니다. ‘확장성 고려를 막고 개발을 최소화하기 위해’ 글로 하는 것이 훨씬 효과적일 수 있다. 그림이 중요하다면 Mermaid같은 마크업 언어를 사용하라. LLM이 읽기도 편하고, 사람도 보기 편해 두 마리 토끼를 모두 잡을 수 있다.
          • ‣
        • 이 과정에서 떠오르는 사용자의 인터페이스 관련 아이디어는 따로 잘 정리해 둔다.
        • 이 과정에서 발견되는 비즈니스 제약 조건(비즈니스 규칙, 비즈니스 불변조건)들은 따로 잘 정리해 둔다.

      • 기타 선택할 수 있는 도구/단계

    2. 소프트웨어 모델링
      • 대부분의 경우 DDD는 나쁘지 않은 소프트웨어 개발 방법론이다. 이 단계에서는 비즈니스 제약 조건을 고려하여 현실의 문제를 소프트웨어로 옮기는 작업이 이루어진다. 이 작업을 한방에 완벽하게 하는 것은 불가능하지만, 특히 신경써서 해 두면 LLM을 강력한 코더로 사용할 수 있다.
        • a0_4.1_1.2_1. title: 만들고자 하는 것을 소프트웨어 요소로 표현하는 일을 모델링이라고 부른다. 다이어그램은 모델링 결과물을 시각화(일러스트레이팅)한 결과물이다. 소프트웨어 개발 프로젝트 초기에 집중해야 하는 것은 다이어그램이 아니라 모델링이다. 내가 인식한 현실 세상의 모델과 LLM이 인식한 문제해결 범위를 동일하게 맞추기 위해서도 중요하다.
      • 전략적 패턴 → 전술적 패턴을 따른다.
        • 관련근거 및 주의사항
          • ‣
        • 전략적 패턴을 확인한다.
          • 프로젝트가 충분히 작아 Bounded Context은 하나로도 충분한가?
          • 우리가 자주 사용하는 용어들은 무엇이고, 그것의 정의는 무엇인가?
            • 이 과정에서 발견되는 비즈니스 제약 조건(비즈니스 규칙, 비즈니스 불변조건)들은 따로 잘 정리해 둔다.
        • 전술적 패턴을 확인한다.
          • 만약 다중 Bounded Context라면, 가장 이해가 잘 되는 하나를 고른다.
          • 지금까지 발견된 모든 비즈니스 제약 조건들을 모아 엔티티와 애그리게이트를 만든다.
          • 전략적 패턴 모델링을 돕기 위해 고려할 수 있는 다이어그램들을 활용하는 것도 좋다.
            • 어떤 기능이 무엇을 입력으로 먹어서, 무엇을 출력으로 뱉어야 하는지를 표현해야 하는 경우 - DFD(Data Flow Diagram)
              • 럼바우의 객체지향 분석 기법 중 기능(functional) 모델링. DFD가 무엇인지 빠르게 상상되지 않는다면 아래 글을 참고하라. 그리기도 쉽고, DFD에 익숙하지 않은 사람도 같이 그림을 펴놓고 이야기하는 데 어려움이 없을 만큼 간단하다.
                • 정보처리기사에서 배우는 소프트웨어공학
              • DFD를 구성하는 요소들에서 입출력되는 대상이 무엇인지 명확히 추상화해서 정의하려고 노력하는 과정이 필요하다. 이는 DDD(Domain Driven Design)에서 ‘유비쿼터스 언어’라고 표현하는데, 유비쿼터스 언어를 정의하면 나 스스로도 논리를 설명하는 것이 굉장히 간단해지고(사례), 무엇을 집중적으로 추상화해야 할지 명확해진다는 점에서 오버엔지니어링을 막을 수 있다.
            • ERD
      • 필수: 시스템 단위 아키텍처 패턴과 제품 선정 및 리서치
        • 라이브러리 또는 제품 선택 e.g.
          • SQLite vs Supabase?
          • Frontend vs Streamlit?
          • Managed Cloud vs Self Hosting?
          • Docker Compose vs Kubernetess?
          • n8n trigger vs AWS Lambda w/Cloudwatch?
        • 이미 있는 라이브러리나 제품이 제공하는 추상화 수준과 기능들
          • [a0_4.1_1.2. title: 내가 소프트웨어를 만드는 속도가 느린 이유는 아직 무엇을 만들지(문제와 핵심 로직에 대한 인식), 가진 도구들을 가지고 할 수 있는 일은 무엇인지(사용하는 도구의 핵심 코드 조각) 명확하지 않은 상태에서 코드를 작성하기 때문이다. 이런 상황에서, 코드가 점진적으로 확장할 것을 지나치게 염두에 두면 과한 추상화가 된다. 무엇을 만들지와 무엇이 가능한지가 명확하지 않으면 패턴이나 클린 코드같은 단어를 머리에서 지워라.](https://janghoo.notion.site/a0_4-1_1-2-title-1b0547ddc2ba80a9bf02f036c152f5e6)
      • 기타 선택할 수 있는 도구/단계
    3. 컴포넌트, 알고리즘 고민
      • 기타 선택할 수 있는 도구/단계
    4. 개발환경 세팅
      • 필수: git, lint, formater 등 기본적인 개발시스템 템플릿, 프롬프트 로드
        • 클린 아키텍처를 유지하며 FastAPI 코드 작성을 LLM에게 위임하기 위한 프롬프트
      • 기타 선택할 수 있는 도구/단계
    5. 소스코드 작성
      • 기타 선택할 수 있는 도구/단계