•
관심가지게 된 계기
1.
메모를 어떻게 재사용할까 고민하다가 관심을 가지게 되었다. 아래 글에서는 메모라는 행위와 소프트웨어공학이 어떤 연관이 있는지에 대해 이야기한다.
2.
요청한 코드에 대한 결과물에 항상 아쉬움이 느껴지는데, 그 이유는 정확하게 요청하지 못했기 때문이라는 생각이 들었다. 정보처리기사 시험을 공부하다 보면 도대체 이렇게까지 용어를 정의해야 하는 이유가 무엇일까 싶은 생각이 들기까지 한다. 이들은 결국 AI 대신 사람을 사용했던 것이다. 사람이나 AI나, 명확한 입력을 주어야 명확한 출력이 나온다.
3.
프로토타이핑 중 개발을 해야만 하는 상황까지 갔거나, 실제로 개발 프로젝트에 착수해야 하는 상황이 있을지도 모른다. 이런 상황에는 어떤 순서로 생각을 해나갈 것인가.
4.
실질적으로 소프트웨어를 개발하려면 무엇부터 해야 하는가? 이 질문에 막막한 경우가 많았다. 이참에 뼈대를 만들어 두자.
•
AI가 코드를 잘 짜도 이것을 개선하려면 AI에게 코드를 잘 짜라고 오더해야 한다. AI가 코드를 잘 짜도 구조적으로 어떻게 만들어진 것인지 이해할 수 있어야 한다.
•
LLM과 함께하는 소프트웨어 개발 워크플로를 커다란 틀에서 바라보면 다음과 같이 두 단계로 구성된다.
2.
•
실제 개발 순서를 기준으로 도구들을 다시 정리한다면 다음과 같다.
1.
요구사항 정리, 기능 정리, 일정 추산
•
필수: 프로토타입 모형을 기본으로 하나, 혹시 나선형 프로젝트를 하는 것은 아닌지 판단한다.
법적 리스크 낮음 | 법적 리스크, 개발 난이도 높음 | |
실 사용자 상호작용 보장됨 | 프로토타입 | |
실 사용자 상호작용 보장 안 됨 | 나선형(e.g. 자율주행) |
•
필수: UML 동적(행위) 다이어그램 중 유즈케이스 다이어그램을 그린다.
◦
’무엇을 만들지 구체적으로 정의하는 과정‘에서 강조하듯, 지나친 확장성 고려를 막고 개발을 최소화하기 위해 필요하다.
◦
단순히 그리는 행위가 중요한 것이 아니다. 상기 목적을 달성하기 위해서 글로 하는 것이 훨씬 효과적일 수 있다. 그림이 중요하다면 Mermaid같은 마크업 언어를 사용하라. LLM이 읽기도 편하고, 사람도 보기 편해 두 마리 토끼를 모두 잡을 수 있다.
▪
◦
이 타이밍에 최종 사용자의 인터페이스를 고민해볼 수 있다.
기타 선택할 수 있는 도구/단계
2.
고수준 기능 정의, 고수준 아키텍처 고민, 인터페이스 정의
•
필수: 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.
소스코드 작성
기타 선택할 수 있는 도구/단계