# Dreaming a future of software engineering

> ## 미래의 소프트웨어 공학을 꿈꾸기

## 미래의 소프트웨어 공학을 꿈꾸기

AI를 잘 써서 소프트웨어 생산 공정을 개선하는 방법, 그래서 더 나은 소프트웨어를 만드는 방법에 대한 상상

2025-12-23

## 이 얘기를 왜 하나

동료들과 비슷한 꿈을 꾸기

피드백 받고 꿈 고쳐 꾸기

## 시점

**현재-근미래 사이**: AI가 소프트웨어를 완전히 대신 만들게 되기 전까지 우리는 뭘 할까? ← 이 시점

**먼 미래 (희망편)**: AI+로봇이 모든 노동과 생산을 담당하고 분배가 정의롭게 되어서 사람들은 행복하게 각자의 가치를 추구하며 살아간다.

**먼 미래 (절망편)**: 생략

## 전제

모두가 AI를 써서 생산성을 극대화하려 한다. 이 게임에 참가하지 않는 건 좋은 전략이 아니다.

기왕 할 거면 무턱대고 따라갈 게 아니라 세상을 조금이라도 내가 꿈꾸는 방향으로 바꿀 목적을 품고 주도해보자.

꿈꾸기?

- ❌ 예언, 예측
- ✅ 바라는 바가 있고 그렇게 되게끔 노력하기

## 우화

[검색어를 입력하면 한 달 뒤에 결과가 나오는 세상](https://wiki.g15e.com/pages/When%20Searches%20Take%20a%20Month.txt)

상상은 어렵다.

본인의 전문 분야일수록 더 그렇다.

지금 하고 있는 방식이 당연하게 여겨지고, 새로운 기술의 가능성에 대한 상상은 제한적일 수 있다.

## 소프트웨어 공정

현대의 소프트웨어는 야만적이다.

1. 풀어야 할 문제들이 충분히 풀리지 않아서
2. 소프트웨어 공정에 참여한 사람들(기획자, 디자이너, 프로그래머, 테스트 등)은 비인간적인 노동을 하고 있기에
3. 소프트웨어는 극도로 타협한 상태로 세상에 출시되고
4. [주변화된 상황에 놓인 이들](https://wiki.g15e.com/pages/Marginalized%20groups.txt)이 상대적으로 더 많은 문제를 겪게 만드는 야만적인 상황이 확대재생산된다.

대체 무슨 문제가 안풀렸나? 우리가 비인간적인 노동을 하고 있다고?

## 사례 1. 기획 혹은 시스템 설계

> What you write down doesn't mean exactly what you think it means. And when it does, it doesn't have the consequences you expected. --<Daniel Jackson>, [Software Abstractions: Logic, Language, and Analysis](https://wiki.g15e.com/pages/Software%20Abstractions%20-%20Logic,%20Language,%20and%20Analysis.txt)

[자연어로 작성된 명세서](https://wiki.g15e.com/pages/Specification%20written%20in%20natural%20language.txt)의 한계

## 사례 2. 디자인

`width: 1024px` vs. `max-inline-size: 60rem`

캔버스에 요소를 배치하기 vs. 의도를 선언하기

[선언적 디자인과 디자인 런타임](https://wiki.g15e.com/pages/Declarative%20design%20and%20design%20runtime.txt)

## 시도 1. 코드 품질 관리

[AI 시대의 소스코드 품질](https://wiki.g15e.com/pages/Source%20code%20quality%20in%20the%20AI%20era.txt)

선순환:

- LLM을 잘 조이면 좋은 코드베이스를 유지할 수 있다.
- 좋은 코드베이스에서는 LLM에 좋은 코드를 생산한다.

## 시도 2. 베스트 프랙티스 따라하게 시키기

2025년 3-4월

[에이전트 기반 코딩 실험 1](https://wiki.g15e.com/pages/Agentic%20coding%20experiment%201.txt)

현황+느낀점

- LLM에게 TDD 제대로 시키기 참 어렵다 (지금은 더 잘할지도?)
- 근데 LLM에게 테스트를 왜 시키지? → [AI 시대의 소프트웨어 공학](https://wiki.g15e.com/pages/Software%20engineering%20in%20AI%20era.txt)

## 시도 3. 선행설계, 추적가능성

2025년 4월-7월

[Semi-structured software spec](https://wiki.g15e.com/pages/Semi-structured%20software%20spec.txt)

- <YAML> 파일 기반의 구조화된 명세서
- s4 CLI: 해당 명세서를 기반으로 컨텍스트 관리 및 지시를 해주는 CLI 도구

현황+느낀점

- [Design is beneficially relating elements](https://wiki.g15e.com/pages/Design%20is%20beneficially%20relating%20elements.txt): 인간+코드+LLM을 이롭게 연결하기
- 퀄리티 높은 코드를 만들어주기 때문에 CLI, API 서버 등을 만드는 상황에서는 코드를 볼 필요가 거의 없었음
- [상태없는 AI-인간 인터랙션](https://wiki.g15e.com/pages/Stateless%20AI-Human%20Interaction.txt)이 가능해짐
- 명세서를 자연어만으로 기술하는 점이 마음에 들지 않음
- 명세서와 인수 테스트 사이의 연결고리가 약함
- 다시 만든다면 SKILLS.md 기반으로

## 시도 4. specdown

2025년 11월-현재

- 마크다운과 Alloy 코드가 Literate programming 스타일로 섞인 문서
- specdown CLI: 해당 명세서에서 Alloy 코드를 추출해서 실행해주는 CLI 도구
- specdown skill: 위 도구를 이용해서 점진적인 명세서 작성을 도와주는 Claude Code 스킬

현황+느낀점

- 이런저런 명세서를 만들어보며 쓸만한지 테스트 중. 되는 것 같은 느낌 💃🕺
- 명세서의 모델로부터 테스트케이스 만들어내는 시도 중

## 주의

무거운 하네스 + 갈라파고스

- 하네스 (마크다운 포함) 줄이기
- 남들이 많이 쓰는 쓸만한 도구 가져다 쓰기