음악의 구조는 구독 서비스에 의해 변했다

음악의 소비 구조는 구독 서비스(Subscription)에 의해 변화했다.

이전의 음악 경험에서는 앨범이나 곡 전체의 흐름 속에서 음악적 구조가 배치되어 있었다.

하지만 구독 서비스가 융성한 이후에는 상황이 바뀌었다.

대량의 곡이 나열되어 있고, 사용자는 언제든 다음 곡으로 이동할 수 있다.

그 결과, 처음 몇 초 만에 "계속 들을 가치가 있는가"가 판단되게 되었다.

곡은 가장 가치를 느끼게 하고 싶은 부분을 빠르게 제시하는 방향으로 변화했다.

이른바 "후렴구부터 시작하기(サビ始まり)"이다.

하지만 여기서 중요한 것은,

후렴구부터 시작하는 것과, 후렴구만으로 곡이 완성되는 것은 별개이다

라는 점이다.

후렴구부터 시작하는 곡에도 당연히 곡 전체를 성립시키는 구조가 존재한다.

변한 것은 가치를 제시하는 순서이지, 가치를 성립시키는 구조 그 자체가 아니다.

그렇다면 엔지니어링(Engineering)은 어떠할까.

AI 시대의 "후렴구부터 시작하기"

AI에 의해 소프트웨어 개발의 풍경은 크게 변화하고 있다.

프로토타입(Prototype)이나 MVP를 만드는 속도는 이전과는 비교할 수 없을 정도로 향상되었다.

화면을 만들고, API를 만들고, 데이터를 연결한다.

일련의 조작이 가능한 것을 단시간에 생성할 수 있다.

이것은 큰 가치이다.

아이디어를 형상화하기까지의 거리는 짧아졌고, 가설 검증의 속도는 올라갔다.

하지만 여기서 생각해야 할 질문이 있다.

그 "작동하는 것"은 정말로 완성품일까.

MVP는 완성품이 아니다

MVP라는 용어는 종종 오해받는다.

MVP는 "완성품을 작게 만든 것"이 아니다.

불확실성을 줄이기 위한 검증물이다.

MVP에는 의도적으로 존재하지 않는 것들이 있다.

• 확장성 (Scalability)
• 운용 설계 (Operational Design)
• 장애 대응 (Fault Tolerance)
• 보안 설계 (Security Design)
• 비기능 요구사항 (Non-functional Requirements)
• 유지보수성 (Maintainability)

그것은 결함이 아니라, 목적에 맞춘 판단이다.

문제는 MVP를 만드는 것이 아니라, MVP가 완성품으로 인식되는 것이다.

작동하는 것이 가진 강렬한 설득력

인간은 존재하지 않는 리스크보다 존재하는 성과물을 평가한다.

설계서에 적힌 미래의 문제보다 눈앞에서 작동하는 화면이 더 강한 설득력을 가진다.

이것은 합리성이 아니라 인간의 인지 특성이다.

그렇기에 AI 시대의 문제는 "만들 수 있다는 것"이 아니다.

만들어 버린 것이 실제 이상의 가치를 지닌 것으로 평가받는 것이다.

작동하는 화면이 있다, 조작할 수 있다, 데모(Demo)할 수 있다, 가치가 보인다.

이 사실은 매우 강력하다.

그러면 자연스럽게 다음과 같은 인식이 생긴다.

"이제 쓸 수 있는 것 아닌가"

"이것으로 충분한 것 아닌가"

"이렇게 빨리 만들 수 있다면 개발 비용도 낮출 수 있는 것 아닌가"

이는 스테이크홀더(Stakeholder)의 이해 부족만이 원인은 아니다.

기업 활동에서 속도나 비용을 평가하는 것은 당연하다.

문제는 평가 대상이 "보이는 성과물"뿐이 되어버리는 것이다.

보이지 않는 가치는 불필요한 것이 아니다

소프트웨어에는 작동하는 화면만으로는 보이지 않는 가치가 존재한다.

상징적인 것이 PoC나 MVP에서 본 운영으로 이행하는 단계이다.

기술 검증 단계에서는 목적을 달성하기 위해 필요한 최소한의 구현으로 충분한 경우가 있다.

데이터를 취득할 수 있다, 처리가 실행될 수 있다, 화면상에서 결과를 확인할 수 있다.

그것만으로 가설 검증으로서는 성공이다.

하지만 그것을 실제 서비스로 제공할 경우 요구되는 조건은 달라진다.

• 장애가 발생했을 때 복구할 수 있는가
• 예상치 못한 입력에 대해 안전하게 동작하는가
• 데이터의 정합성(Integrity)을 유지할 수 있는가
• 적절한 권한 관리가 이루어지고 있는가
• 장래의 변경을 견딜 수 있는 구조로 되어 있는가

이것들은 처음에 작동하는 것을 만든 단계에서는 보기 어렵다.

하지만 프로덕트(Product)를 지속적으로 이용하기 위해서는 불가결한 요소이다.

작동하는 것은 필요조건이다.

하지만 그것만으로는 충분조건이 아니다.

가장 위험한 것은 평가 축의 단락

AI에 의해 개발 속도가 향상되는 것 자체는 문제가 아니다.

문제는 작동하는 것이 존재하는 순간, 그 안에 포함되어 있지 않은 것까지 "불필요했던 것"으로 평가되어 버리는 것이다.

본래 MVP에 존재하지 않는 것은 가치가 없는 것이 아니다.

검증 단계에서는 필요하지 않았을 뿐이며,

프로덕트로서 성립시키는 단계에서는 필요하게 된다.

하지만 완성품으로 인식된 순간,

그것들은 "추가 작업"으로 취급되게 된다.

본래는,

MVP를 만든다
↓
가치를 검증한다
...

가 되어야 할 것을,

MVP를 만든다
↓
작동했다
...

로 해버리면 이야기는 달라진다.

그리고 인식도 바뀐다.

그 영향은 스테이크홀더뿐만이 아니다.

엔지니어 자신에게도 일어날 수 있다.

"이 정도면 충분할지도 모른다"

라는 판단이다.

완성(Completion)이란 무엇인가를 정의하기

AI에 의해 결과물(Artifact)을 만드는 속도는 크게 향상되었다.

하지만 그로 인해 "만드는 것"과 "완성하는 것" 사이의 거리가 좁혀진 것은 아니다.

오히려 그 사이에 존재하는 판단의 중요성은 커지고 있다.

그 결과물은 무엇을 충족하고 있는가.

무엇을 충족하지 못하고 있는가.

어떤 조건을 충족해야 실운영(Production) 환경에서 성립하는가.

이를 판단하고 관계자들과 인식을 맞추는 것이 필요해진다.

MVP를 제시하는 것 자체에는 문제가 없다.

문제는 MVP임을 설명하지 않고, 그것이 완성품인 것처럼 취급되는 것이다.

작동하는 것을 만드는 능력뿐만 아니라, 작동하는 것이 무엇을 의미하는지를 정의하는 능력.

AI 시대에 엔지니어에게 요구되는 것은 바로 그 지점에 있다.

MVP를 완성품으로 취급하는 개발 플로우(Development Flow) 너머에 있는 것

"우선 작동하는 것을 만들면 된다"

"부족한 부분은 나중에 생각하면 된다"

이 사고방식 자체는 MVP라는 방법론 안에서는 틀리지 않다.

문제는 그것이 개발 프로세스(Process) 전체의 전제가 되어버리는 것이다.

MVP를 완성품으로 취급하는 문화가 정착되면, 개발에서의 평가 기준 자체가 변한다.

빨리 작동하는 것을 내놓을 수 있는 사람이 평가받는다.

하지만 그 속도는 본래 불확실성을 줄이기 위한 속도이다.

그것이 어느샌가 완성품을 만드는 속도로 취급되게 된다.

그러면 설계나 검증에 필요한 시간은 가치를 창출하는 공정이 아니라, 지연 요인으로 인식된다.

여기서 비로소 문제는 개별적인 구현 품질이 아니라, 개발 문화 그 자체가 된다.

그렇게 되면 엔지니어링(Engineering)의 대상 자체가 변질된다.

본래 소프트웨어 개발이란 현실의 업무나 사용자 사이에서 장기간 성립하는 메커니즘을 만드는 것이다.

하지만 MVP를 완성품으로 취급하는 문화에서는 "지금 작동하는 것을 만드는 것"이 목적이 된다.

그 결과, 나중에 필요해지는 판단이나 설계는 추가 비용(Additional Cost)으로 취급된다.

하지만 그것들은 본래 절감할 수 있는 비용이 아니다.

프로덕트(Product)를 성립시키기 위해 필요한 공정이다.

지금 필요한 것

AI에 의해 단시간에 결과물을 만들 수 있는 시대이기에 더욱, 무엇을 만들었는가뿐만 아니라 무엇을 만들지 않았는가를 인식하는 것이 중요해진다.

AI 시대에 필요한 것은 결과물을 만드는 능력만이 아니다.

눈앞에 있는 결과물이 무엇을 충족하고 있고, 무엇을 충족하지 못하고 있는가.

그 차이(Difference)를 인식할 수 있는 것이 중요해진다.

왜냐하면 앞으로 늘어날 문제는 "만들 수 없는 문제"가 아니라, **"만들어 버린 것을 잘못 평가하는 문제"**이기 때문이다.

인간은 AI가 만들어낸 결과물을 그대로 받아들이는 것이 아니라, 현실의 요구사항이나 제약 조건에 비추어 평가해야 한다.

그곳에서부터 생성된 결과물을 프로덕트로 성립시키기 위한 엔지니어링이 시작된다.

후렴구를 만드는 것과 곡을 완성하는 것은 다르다

AI에 의해 후렴구(Chorus)를 만드는 속도는 올라갔다.

이것은 놀라운 변화다.

하지만 후렴구를 만드는 속도와 프로덕트를 성립시키는 속도는 같지 않다.

후렴구부터 엔지니어링을 시작하는 것이 문제는 아니다.

문제는,

"후렴구를 듣는 것만으로 그 곡 전체가 완성되었다고 생각하게 되는 것"

이다.

후렴구만 듣고 판단하며 만족한다.

음악을 즐기는 맥락에서는 이것이 허용된다.

하지만 그 구조는 엔지니어링에서는 허용되지 않는다.

Discussion