•
관심가지게 된 계기
1.
메모를 어떻게 재사용할까 고민하다가 관심을 가지게 되었다. 아래 글에서는 메모라는 행위와 소프트웨어공학이 어떤 연관이 있는지에 대해 이야기한다.
2.
정확하게 요청하지 못했기 때문에 LLM이 작성한 코드 결과물에 아쉬움이 남는다는 생각이 들었다. 정보처리기사 시험을 공부하다 보면 ‘도대체 이렇게까지 용어를 정의해야 하는 이유가 무엇일까’ 싶은 것들이 많다. 이들은 잘 정의된 용어로 AI 대신 사람에게 요청했던 것이다. AI도 마찬가지로 명확한 입력을 주어야 명확한 출력이 나온다.
3.
프로토타이핑 중 개발을 해야만 하는 상황까지 갔거나, 실제로 개발 프로젝트에 착수해야 하는 상황이 있을지도 모른다. 이런 상황에는 어떤 순서로 생각을 해나갈 것인가.
4.
실질적으로 소프트웨어를 개발하려면 무엇부터 해야 하는가? 이 질문에 막막한 경우가 많았다. 이참에 뼈대를 만들어 두자.
•
AI가 코드를 잘 짜도 이것을 개선하려면 AI에게 코드를 잘 짜라고 오더해야 한다. AI가 코드를 잘 짜도 구조적으로 어떻게 만들어진 것인지 이해할 수 있어야 한다.
•
LLM과 함께하는 소프트웨어 개발 워크플로를 커다란 틀에서 바라보면 다음과 같이 두 단계로 구성된다.
•
실제 개발 순서를 기준으로 도구들을 다시 정리한다면 다음과 같다.
1.
요구사항 정리, 기능 정리, 일정 추산
•
필수: 프로토타입 모형을 기본으로 하나, 혹시 나선형 프로젝트를 하는 것은 아닌지 판단한다.
법적 리스크 낮음 | 법적 리스크, 개발 난이도 높음 | |
실 사용자 상호작용 보장됨 | 프로토타입 | |
실 사용자 상호작용 보장 안 됨 | 나선형(e.g. 자율주행) |
•
필수: UML 동적(행위) 다이어그램 중 유즈케이스 다이어그램을 그린다.
◦
’무엇을 만들지 구체적으로 정의하는 과정‘에서 강조하듯, 지나친 확장성 고려를 막고 개발을 최소화하기 위해 필요하다.
◦
단순히 그리는 행위가 중요한 것이 아니다. ‘확장성 고려를 막고 개발을 최소화하기 위해’ 글로 하는 것이 훨씬 효과적일 수 있다. 그림이 중요하다면 Mermaid같은 마크업 언어를 사용하라. LLM이 읽기도 편하고, 사람도 보기 편해 두 마리 토끼를 모두 잡을 수 있다.
▪
◦
이 과정에서 떠오르는 사용자의 인터페이스 관련 아이디어는 따로 잘 정리해 둔다.
◦
이 과정에서 발견되는 비즈니스 제약 조건(비즈니스 규칙, 비즈니스 불변조건)들은 따로 잘 정리해 둔다.
기타 선택할 수 있는 도구/단계
2.
소프트웨어 모델링
•
대부분의 경우 DDD는 나쁘지 않은 소프트웨어 개발 방법론이다. 이 단계에서는 비즈니스 제약 조건을 고려하여 현실의 문제를 소프트웨어로 옮기는 작업이 이루어진다. 이 작업을 한방에 완벽하게 하는 것은 불가능하지만, 특히 신경써서 해 두면 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?
기타 선택할 수 있는 도구/단계
3.
컴포넌트, 알고리즘 고민
기타 선택할 수 있는 도구/단계
4.
개발환경 세팅
•
필수: git, lint, formater 등 기본적인 개발시스템 템플릿, 프롬프트 로드
기타 선택할 수 있는 도구/단계
5.
소스코드 작성
기타 선택할 수 있는 도구/단계