foriequal0 10 karma 가입일 2024-10-23 최근 활동 최근 작성한 댓글 전체 보기 저도 동감합니다. Mechanical sympathy 이나 개발 완급 조절에 중요한 직감을 주는 자료라고 생각합니다. "Latency Numbers Every Programmer Should Know" 처럼요. 그리고 저는 이 글이 특정 방향이 무조건적으로 낫다고 읽히진 않았습니다. 오히려 글에 언급된 모든 방식들이 보여준 숫자가 "대부분의 비즈니스에서 차고 코드를 손으로 짜는 과정에서 개발자는 자연스럽게 기획도 하고, 설계도 하고, 탐색도 하고, 이해도 하고, 테스트도 하고, 자가리뷰도 하고, 문제가 발생했을 때 사후대응 할 과정을 암시적으로, 병렬적으로 하면서 자연스럽게 각 측면이 조정되기 마련입니다. 그러니까 테스트나, 리뷰가 부족해도 어느정도 돌아갔던거라고 생각합니다. 그런데 손으로 짜는 과정을 없애버리면 암시적으로 있던 과정들을 명 DIY, 메이커운동, 인디, 펑크, 오픈소스 모두 산업화, 자본주의, 소비주의에 대한 반론인데, 그것의 한계를 극복하는게 소비주의를 받아들이는거라니. 바이브코딩이 소비 프레임에 걸맞는다는거에는 동의합니다. 최근에 유행하던 테무깡, 알리깡 (https://www.asiae.co.kr/article/2024053117460950053) 의 코딩버전이라고 생각이 듭니다. 그런데 소비 프레임이 메이커운동의 실패를 반복하지 않을 방법이라고 하면 HN의 댓글처럼 여러모로 동의할 수 없네요. AI 프로그래밍이 추상화나 자동화라기보다 오히려 외부화/외주화에 가까운 것 같습니다. 설계 및 검증이 고도화와 정밀화를 위한 요소라기보다 저신뢰사회를 간신히 붙들어매는 규제같은 요소로 도입되는 느낌이구요. 전체 배지 GeekAward 추천받은 댓글 장기 활동 스페셜 더 많은 GeekBadge가 있습니다. 활동을 통해 모으거나, GeekGold로 구매해 보세요.
