미래의 소프트웨어 공학을 꿈꾸기
- 2025-12-22 (modified: 2025-12-23)
- 저자: AK
미래의 소프트웨어 공학을 꿈꾸기
AI를 잘 써서 소프트웨어 생산 공정을 개선하는 방법, 그래서 더 나은 소프트웨어를 만드는 방법에 대한 상상
2025-12-23
이 얘기를 왜 하나
동료들과 비슷한 꿈을 꾸기
피드백 받고 꿈 고쳐 꾸기
시점
현재-근미래 사이: AI가 소프트웨어를 완전히 대신 만들게 되기 전까지 우리는 뭘 할까? ← 이 시점
먼 미래 (희망편): AI+로봇이 모든 노동과 생산을 담당하고 분배가 정의롭게 되어서 사람들은 행복하게 각자의 가치를 추구하며 살아간다.
먼 미래 (절망편): 생략
전제
모두가 AI를 써서 생산성을 극대화하려 한다. 이 게임에 참가하지 않는 건 좋은 전략이 아니다.
기왕 할 거면 무턱대고 따라갈 게 아니라 세상을 조금이라도 내가 꿈꾸는 방향으로 바꿀 목적을 품고 주도해보자.
꿈꾸기?
- ❌ 예언, 예측
- ✅ 바라는 바가 있고 그렇게 되게끔 노력하기
우화
상상은 어렵다.
본인의 전문 분야일수록 더 그렇다.
지금 하고 있는 방식이 당연하게 여겨지고, 새로운 기술의 가능성에 대한 상상은 제한적일 수 있다.
소프트웨어 공정
현대의 소프트웨어는 야만적이다.
- 풀어야 할 문제들이 충분히 풀리지 않아서
- 소프트웨어 공정에 참여한 사람들(기획자, 디자이너, 프로그래머, 테스트 등)은 비인간적인 노동을 하고 있기에
- 소프트웨어는 극도로 타협한 상태로 세상에 출시되고
- 주변화된 상황에 놓인 이들이 상대적으로 더 많은 문제를 겪게 만드는 야만적인 상황이 확대재생산된다.
대체 무슨 문제가 안풀렸나? 우리가 비인간적인 노동을 하고 있다고?
사례 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
자연어로 작성된 명세서의 한계
사례 2. 디자인
width: 1024px vs. max-inline-size: 60rem
캔버스에 요소를 배치하기 vs. 의도를 선언하기
시도 1. 코드 품질 관리
선순환:
- LLM을 잘 조이면 좋은 코드베이스를 유지할 수 있다.
- 좋은 코드베이스에서는 LLM에 좋은 코드를 생산한다.
시도 2. 베스트 프랙티스 따라하게 시키기
2025년 3-4월
현황+느낀점
- LLM에게 TDD 제대로 시키기 참 어렵다 (지금은 더 잘할지도?)
- 근데 LLM에게 테스트를 왜 시키지? → AI 시대의 소프트웨어 공학
시도 3. 선행설계, 추적가능성
2025년 4월-7월
- YAML 파일 기반의 구조화된 명세서
- s4 CLI: 해당 명세서를 기반으로 컨텍스트 관리 및 지시를 해주는 CLI 도구
현황+느낀점
- Design is beneficially relating elements: 인간+코드+LLM을 이롭게 연결하기
- 퀄리티 높은 코드를 만들어주기 때문에 CLI, API 서버 등을 만드는 상황에서는 코드를 볼 필요가 거의 없었음
- 상태없는 AI-인간 인터랙션이 가능해짐
- 명세서를 자연어만으로 기술하는 점이 마음에 들지 않음
- 명세서와 인수 테스트 사이의 연결고리가 약함
- 다시 만든다면 SKILLS.md 기반으로
시도 4. specdown
2025년 11월-현재
- 마크다운과 Alloy 코드가 Literate programming 스타일로 섞인 문서
- specdown CLI: 해당 명세서에서 Alloy 코드를 추출해서 실행해주는 CLI 도구
- specdown skill: 위 도구를 이용해서 점진적인 명세서 작성을 도와주는 Claude Code 스킬
현황+느낀점
- 이런저런 명세서를 만들어보며 쓸만한지 테스트 중. 되는 것 같은 느낌 💃🕺
- 명세서의 모델로부터 테스트케이스 만들어내는 시도 중
주의
무거운 하네스 + 갈라파고스
- 하네스 (마크다운 포함) 줄이기
- 남들이 많이 쓰는 쓸만한 도구 가져다 쓰기