"AI는 셰프가 아니라 스테이크 굽는 기계일 뿐": AI 코딩을 스테이크 비유로 풀어낸 에세이
- 글쓴이는 스테이크 굽기와 AI로 소프트웨어 만들기를 비교함: 둘 다 기본 결과물은 쉽게 나오지만 일관되게 좋은 품질을 내는 건 완전히 다른 문제라고 주장
- AI는 레시피를 따르는 기계일 뿐 사용자가 실제로 원하는 그림을 스스로 알지 못하며, 요구사항과 제약, 테스트, 피드백으로 일일이 번역해줘야만 움직인다는 점을 지적
- 비싼 AI 제품이나 에이전시, 새 프레임워크로 옮겨봐도 결국 '같은 AI 요리사를 고용한 식당'처럼 동일한 결과물이 나올 수 있다고 경고
- 결론으로 소프트웨어를 잘 만들려면 AI에 기대기보다 직접 소프트웨어를 이해하는 법을 배워야 하며, 언제 AI가 자신만만하게 숯덩이를 내놓는지 판별할 줄 알아야 한다고 주장
Hacker News opinions
글 잘 썼네
동의하는데 진짜 문제는 경영진이 손익계산서만 보고 '그냥 먹을 만한 스테이크'로도 고객이 돈을 낸다는 걸 알면 셰프를 줄인다는 거임. 완벽한 스테이크에 대한 기대 자체가 사업적으로는 뒷전이 됨
그게 경제 전체가 원래 하는 짓임. 사람들이 그래도 돈 낼 최저 수준으로 맞추는 거지
그냥 먹을만한 정도가 아니라 아예 못 먹을 정도로 망쳐서 버려야 하는 경우도 넣어야 함. 팬이 망가지고 결국 빚져서 망하는 시나리오도 있음
그게 왜 문제임? 난 동네에 별로였던 스테이크 하우스도 수십 년 장사했음. 훌륭한 스테이크는 가끔 즐기는 사치고, '그냥 먹을 만한' 건 매일 먹는 밥임
50달러짜리 리브아이는 마블링 보고 고온에서 제대로 구운 거고, 20달러짜리 데니스 티본은 팬케이크 굽던 그릴에 대충 구운 거임. 회사는 '그냥 먹을 만함'의 기준을 자기 맘대로 정할 수 없음, 결국 손님이 판단함
나는 집에서도 굽고 밖에서도 사먹는데, 요즘 경영진들 사이에서도 이 감성이 조금씩 이해받는 것 같음
아파트에서 스테이크 구우면 화재경보기 울릴 각오해야 함ㅋㅋ 그리고 많은 경영진이 자기가 이끄는 사업을 실제로 잘 모름. 기술 배경 없는 CEO들이 비용절감에 너무 열올리다가 애를 목욕물이랑 같이 버리는 경우가 흔함. 보잉이 그래서 망가졌고 인텔도 그래서 혁신 리더 자리를 엔비디아랑 애플한테 뺏김. IBM도 이제 컨설팅 회사가 됨
이 글의 진짜 문제는 대부분의 경우 훌륭한 스테이크가 필요 없다는 거임. 그냥 배고픔만 해결하면 됨. 사람이 쓴 코드의 85~90%도 어차피 쓰레기고, 대부분 고객은 코드 품질 신경 안 씀. 바이브 코딩의 장점은 문제 생기면 1분 안에 고쳐달라고 하면 되는 거고, 외주팀에 요청 보내고 시간당 요금 흥정하고 스펙 안 지켜서 다시 받아오는 것보다 훨씬 나음
맞는 말인데 환영받을 얘기는 아니지. 나도 수십 년 코드 짜면서 좋은 것도 형편없는 것도 만들어봤음. LLM 코드생성도 결국 예전 도구들이랑 비슷한 비율로 좋고 나쁨이 섞여 나옴, 다만 양이 좀 더 많아짐
프로그래머는 비싼 제품 만드는 고급 셰프임. AI 툴은 AppleScript, VB스크립트, IFTTT 같은 실패한 노코드 도구들의 약속을 드디어 제대로 실현해줄 거임. 전문가용 대형 소프트웨어보다 오히려 전에는 아예 안 만들어졌을 소프트웨어들이 쏟아지는 게 진짜 이득임
나는 프로토타이핑 많이 하는데 AI 덕분에 속도가 몇 배 빨라지고 품질도 오히려 좋아짐. 완벽한 미디엄레어까진 아니어도 부리토 데우는 시간에 스테이크를 구워내는 셈임
결국 코드는 자기표현이나 완벽한 아키텍처 짓기가 아니라 돈 낸 사람이 필요한 일을 해주는 게 목적임. 그 일만 충분히 잘 하면 고객 입장에선 그걸로 끝인데, 많은 개발자가 이 핵심을 일부러 무시함
저자가 '우리'라고 뭉뚱그려서 소프트웨어 엔지니어 전체의 낮은 품질관리 기준을 인정하는 게 마음에 안 듦. 버그를 귀엽게 포장하지 말고 항공업계 '그렘린' 사태처럼 진지하게 반성할 때가 됨
이건 왕의 '우리'가 아니라 진짜 여러 사람을 가리키는 일반적인 '우리'임. 저자가 실제로 소프트웨어 엔지니어 전체를 대변하려 한 거니까