# Software assets in the AI era

> 에이전틱 엔지니어링 덕에 코드의 비용이 점점 0에 가까워지고 있다. 이런 시대에도 여전히 가치가 있는 소프트웨어 자산이란 뭘까?

[에이전틱 엔지니어링](https://wiki.g15e.com/pages/Agentic%20software%20engineering.txt) 덕에 코드의 비용이 점점 0에 가까워지고 있다. 이런 시대에도 여전히 가치가 있는 소프트웨어 자산이란 뭘까?

## 소스코드는 유도 가능한 산출물이다

<소스 코드>만 있으면 컴파일하여 바이너리 파일을 만들어낼 수 있으므로 보통은 소스 코드를 중요한 자산으로 친다. <오픈 소스> 운동은 있지만 오픈 바이너리 운동은 없는 이유다. (근데 정말 없나? 혹시 찾아보면 있을지도)

하지만 이제 잘 만들어진 테스트 모음이 있으면 소스 코드를 만들어내는 게 점점 더 쉬운 일이 되고 있다. [BDD](https://wiki.g15e.com/pages/Behavior-driven%20development.txt) 관점에서 보면 테스트 모음은 실행 가능한 명세서다. 즉, 잘 작성된 실행 가능한 명세서가 있으면 소스코드는 거의 공짜가 되어가고 있다.

## 테스트 및 명세서는 가치가 있을까

그러면 테스트가 가치 있는 산출물일까?

아닌 것 같다. 테스트로부터 소스 코드를 만드는 것도 가능하지만 소스 코드로부터 테스트를 만드는 것도 가능하기 때문이다.

물론 이렇게 만들어지는 테스트는 "시스템이 어떻게 동작해야 하는가(즉, 명세서)"가 아니라 "시스템이 현재 어떻게 동작하고 있는가(버그 포함)"를 담는다는 점에서 좀 차이가 있겠다. [Working effectively with legacy code](https://wiki.g15e.com/pages/Working%20effectively%20with%20legacy%20code.txt)에서는 이런 종류의 테스트를 [Characterization test](https://wiki.g15e.com/pages/Characterization%20test.txt)라고 부른다. 레거시 시스템을 다룰 때 특히 유용하다. 이런 면에서는 테스트도 딱히 가치있는 산출물이 아닌 것 같다.

게다가 바이너리 파일을 [역컴파일](https://wiki.g15e.com/pages/Decompilation.txt)하면 소스 코드를 얻어낼 수 있다. 주석이 남아 있지 않고 복구되지 않는 심볼들이 많다는 등의 문제가 있지만 AI 덕에 읽기 쉽게 만드는 일도 어느 정도 쉬워졌다. 즉, 바이너리 파일만 있으면 소스 코드를 얻어낼 수 있고, 소스 코드가 있으면 [Characterization test](https://wiki.g15e.com/pages/Characterization%20test.txt)를 얻어낼 수 있으므로, 셋 중 아무거나 있으면 나머지 두 개를 비교적 쉽게 얻어낼 수 있게 됐다. (혹은 그렇게 되어가는 중이다. <2026-03-01> 기준)

## 그럼 뭐가 남나

명세서에 미처 다 담기지 않은 의도들, 의사결정 및 실행의 궤적들, 의사결정 및 의도의 뒤편에 있는 제작자의 취향과 사용자 피드백(VoC, 행동 데이터 등), 이런 게 남는 것 같다.

역시 취향이 중요하다. (참고: [취향이 있는 소프트웨어](https://wiki.g15e.com/pages/Tasteful%20software.txt))