코드 생성이 저렴해질수록, 무엇을 만들지 결정하는 판단이 희소해진다
When Anyone Can Build Software, Who Decides What Not to Build?
생성형 AI가 코드 생성과 통합을 빠르게 처리하면서 엔터프라이즈 아키텍처의 가치가 흔들리고 있다. 저자는 아키텍처 산출물의 상당 부분이 자동화될 수 있다고 인정하지만, 진짜 가치는 '커밋 이전의 판단'에 있다고 주장한다. 코드는 대체 가능하지만 데이터, 통합, 규제 의무, 운영 프로세스 같은 상태는 오래 남는다. 로컬에서 합리적인 결정이 기업 전체의 불일치를 낳는 구조를 설명하며, 판단의 권한과 책임이 여전히 중앙에 남아야 한다고 말한다.
소프트웨어를 만드는 비용이 싸질수록, 불일치의 비용은 더 비싸진다.
HN 토론
34- deminature
LLM으로 양질의 소프트웨어를 만드는 일은 여전히 매우 시간이 많이 걸린다. 진입 장벽이 아무리 낮아도 대부분의 사람들은 귀찮아서 하지 않을 것이다. 시간은 공짜가 아니니까. 게다가 소프트웨어를 만드는 일은 대부분의 사람들에게 흥미롭지 않다. 전자제품 조립이 대부분의 사람들에게 흥미롭지 않은 것과 같은 이유다. 이는 대중적 매력이 제한적인 틈새 관심사다. 이 두 가지 이유로 소프트웨어 직업은 AI 이후에도 살아남을 것이다.
- OakNinja
이 문제는 새로운 게 아니다. 새로운 점은 누구나 개발팀을 끌어들이지 않고도 빠른 아이디어 구상과 신속한 프로토타이핑을 통해 해결하려는 핵심 문제를 이해할 수 있다는 것이다.
늘 그랬듯이, 무엇에 집중할지 우선순위를 정하는 것은 회사의 몫이다. 예나 지금이나 마찬가지다.
* 시간을 들였다는 이유만으로 아이디어나 프롬프트 출력에 집착하지 마라.
* 코드 작성은 쉽다. 유지보수가 어렵다.
* 시간을 절약하거나 수익을 창출하지 않는다면, 그것은 그저 비용일 뿐이다.
* 출력은 가치와 같지 않다.
- anonzzzies
우리 회사에는 40년에 걸쳐 수집한, 상상할 수 있는 모든 프로세스를 담은 기업용 LoB '베이스'가 있다. 이를 이용해 우리는 대기업들의 프로세스를 살펴보고 부서 단위로 자동화를 제안한다. 그래서 이사회 승인이나 IT 부서 승인 없이도 비용을 지불할 수 있다. SOTA AI는 우리 베이스와 함께라면 거의 스스로 하루나 이틀 만에 이를 해낼 수 있고, 우리는 부서 예산보다 약간 낮은 가격을 청구한다. 물론 이 중간 관리자들은 자신이 유용해 보이길 원하기 때문에, 우리는 수많은 회의에 짜증 섞인 '프로젝트 매니저/영업 사원'을 보내야 한다. 이런 회의는 우리에게 객관적으로 쓸모없지만 어쨌든 필요한 고통이다. 물론 이 (오프라인) 회의는 (단순한) 기술 부분보다 훨씬 더 비싸다. 프레임워크에 라이선스 및 SLA 비용으로 얼마간의 가치를 매긴다 해도 마찬가지다.
이 기업들, 대부분 다국적 기업이고 대개 미국, 인도, 중국 소유주가 있으며, 그들의 IT 부서는 말 그대로 모두 형편없다. 20년 전 Java나 C#에 얽매여 개선하거나 배우려는 의욕이 전혀 없다. AI에 대해 들어는 봤지만 아무것에도 활용하지 않는다.
이건 돈줄이다. 적절한 레벨로 진입한다면 어느 지역이든 수십억 달러 가치가 있다. 내 경험상 이런 부서의 사람들 대부분은 오늘날 아이폰에서 돌아가는 LLM으로 대체될 수 있고, LoB 앱은 수십 년 지식을 가진 유능한 컨설턴트 한 명만 있으면 꽤 지루한 일이기 때문에 이게 오래갈지는 모르겠다. 그들은 바로 그걸 하도록 LLM을 훈련시키고 있는 게 분명하다.
- CurleighBraces
적어도 지금으로서는 이보다 더 미묘하다고 느낀다.
누구나 소프트웨어를 만들 수 있다는 건 사실이지만, 그렇다고 소프트웨어가 좋아지는 건 아니고, 그것이 특별히 안목에 달려 있다는 말도 사실이 아니다.
예를 들어 나는 지금 코딩 경험이 전혀 없는 한 기업가와 일하고 있는데, 그는 성공적으로 제품을 만들었고 이미 중견 기업에 판매까지 했다.
하지만 내가 관여하지 않고 AI를 제대로 다룰 줄 몰랐다면, 최신 프런티어 모델들이 그가 말한 것을 이루기 위해 최선을 다했음에도 불구하고 소프트웨어는 필요한 성능을 내지 못했다.
적어도 지금으로서는 여전히 경험 많은 개발자가 필요하다.
- ma2kx
나는 다소 혼란스럽다. 흥미로운 글이긴 한데, 그가 말하는 'policy as code'가 정확히 어디로 가려는 건지 잘 모르겠다. 그는 "policy-as-code는 중앙 아키텍처 기능 없이도 기업의 일관성을 만들어낸다"고 결론짓는데, 나도 동의한다. 다만 그가 오늘날 인프라/company as code가 부족하다는 점을 놓치고 있다고 주장하고 싶다. 적어도 에이전트가 그가 처음에 제기한 문제를 해결하거나 최소한 인지하게 하려면 말이다. 정책은 우리 작업 환경의 경계를 정의하지만 작업 자체를 정의하지는 않는다. 이런 '노하우'는 대부분 사람들에게 암묵적이지만 LLM에게는 보이지 않으며, 에이전트가 작동하는 컨텍스트 프레임을 주어진 프롬프트(그리고 정책이 컨텍스트에 있다면 정책에 의해 제한될 수도 있는)로 제한한다.
예를 들어 그의 예시를 보자:
"현장 직원들이 필수 입력 항목을 건너뛰는 것은 그 프로세스가 모든 고객 상호작용에 15분의 마찰을 추가하기 때문일 수 있다."
첫째, 그 항목들이 필수인데도 건너뛸 수 있다면 그 항목에 대한 정책이 무엇인지 불분명하다. 둘째, 건너뛰는 것이 마찰을 줄일 뿐 다른 결과가 없다면 왜 필수인가? 모델은 그 항목에 대한 정책을 강제해야 하는지, 자동화를 코딩해야 하는지, 아니면 그냥 자발적으로 만들어야 하는지 어떻게 결정해야 하는가?