요약
좋은 제품에는 만든 사람의 관점이 배어 있고, 공장식 개발은 그 개성을 지웁니다.
Linear를 만든 카리 사리넨이 개인 블로그에 쓴 글입니다. 성공한 회사의 제품마저 어수선해지는 이유를 짚으며, 소프트웨어 뒤에 있는 사람의 판단이 왜 중요한지 말합니다.
왜 중요한가
- AI 에이전트(스스로 코드를 고치고 실행하는 AI 도구)로 기능을 붙이기 쉬워질수록 제품의 일관성은 오히려 깨지기 쉽다는 경고입니다.
- 요구 사항을 모아 기능을 만들고 측정하는 공장식 흐름을 자동화하는 것만으로는 좋은 제품이 나오지 않는다고 봅니다.
핵심 내용
- 제품의 개성은 무엇에 집중하고, 무엇을 만들지 않고, 무엇을 끝까지 다듬느냐는 선택에서 나온다고 했습니다.
- 잘 작동하는 기능도 제품을 해칠 수 있어서, 제품이 어떠해야 하는지 판단하는 사람이 있어야 한다고 했습니다.
- 기존 기능을 다시 생각하기보다 새 기능을 덧붙이기가 쉬워서, 제품이 관점 없는 기능 모음이 된다고 진단했습니다.
- 개인이 에이전트로 각자 고친 결과는 하나씩은 말이 되지만, 모이면 조각상이 아니라 프랑켄슈타인의 괴물이 된다고 했습니다.
- Linear는 데이터 뒤에 숨기보다 경험과 고객과의 대화, 실수에서 쌓인 직관을 믿는다고 밝혔습니다.
HN 반응
- AI가 코드는 더 잘 짜도 무엇을 만들지는 사람이 정해야 한다는 공감에, 코드를 잘 짠다면 제품 판단은 왜 못 하느냐는 반문이 맞섰습니다.
- AI에도 취향이 있다는 주장이 나왔지만, 그 취향은 누구에게나 똑같은 기본값이라 금세 티가 난다는 반론이 이어졌습니다.
SaaS를 만드는 사람으로서 전적으로 동감합니다. 제가 보는 제 일은 이렇습니다. 가치는 코드에 있지 않습니다(지금은 AI가 저보다 코드를 잘 짭니다). 소프트웨어 아키텍처에 있지도 않습니다(AI가 저보다 나아지는 시점에 막 접어들고 있습니다). 가치는 무엇을 만들고 무엇을 만들지 않을지 정하는 데, 제품 전체의 성격과 비전을 잡는 데, 화면 하나하나를 보면서 "이게 고객이 일하는 데 어떻게 도움이 되지?"를 따져 보는 데 있습니다.
안타깝게도 이런 일은 시간이 걸립니다. 처음엔 좋아 보였던 아이디어가 막상 그렇지 않은 경우가 많아서 몇 번이고 처음부터 다시 시작해야 하거든요. 그 결과로 나오는 소프트웨어는 "고집이 센" 제품이라고 불리고, "업계"의 관행을 따르지 않는 경우도 많습니다.
AI가 코드를 더 잘 짜고 아키텍처도 더 잘 설계할 수 있다면, 제품 결정은 왜 더 잘 못 내린다는 거죠? 근본적으로 뭐가 다른지 모르겠네요.
LLM에게는 몸이 없습니다. 그런데 제품은 결국 거래의 양쪽 끝에 있는 몸 달린 사람들이 쓰고, 그들을 위해 만드는 것입니다. LLM과 몸 사이의 순환 고리는 지금으로선 원시적입니다. 그래서 제품에는 몸의 언어로 말하면서 AI를 위해 통역해 줄 사람이 필요합니다.
그리고 AI가 운영하는 스타트업은 다 어디 있죠?? 왜 아무도 openclaw로 굴리는 사업을 다국적 기업으로 키우지 못했을까요?
이메일이랑 사업 기록을 자꾸 지워버려서 그런 거 아닐까요.
https://www.pcmag.com/news/meta-security-researchers-openclaw-ai-agent-accidentally-deleted-her-emails
방금 찾아보니 이런 페이지가 꽤 많은 걸 보면, 꽤 자주 일어나는 일인 것 같습니다.
https://drecov.pandaoffice.com/data-recovery/how-to-fix-openclaw-file-loss-a-complete-recovery-guide.html
사람들이 쓰는 제품을 만들려면 개발자가 자신이 그 사용자라고 상상할 수 있어야 합니다. 시각적인 대시보드든 음성 에이전트로 돌아가는 자동화든 사용자 인터페이스를 만드는 사람들은 이걸 "사용자에 대한 공감"이라고 부릅니다.
AI는 공감할 수 없습니다.
AI는 좋은 취향을 가질 수 없습니다.
그러니까 정리하면, 페이지 하나 길이의 지독한 정규식을 상상으로 써내고, 복잡한 API가 어떻게 동작하고 특정 호출을 하면 어떻게 될지 상상하고, 디스어셈블된 코드만 읽고도 바이너리가 정확히 어떻게 동작하는지 상상하는 건 되는데, 사용자 경험을 두고 사람이 어떻게 느낄지는 절대 상상하지 못한다는 건가요?
실험을 하나 제안할게요. 정말, 정말 못 만든 디자인이든 너무 어수선한 화면이든, 여러분이 "못 만들었다"고 생각하는 기준에 맞는 사례를 하나 찾아서 Claude에게 뭐가 문제고 어떻게 고쳐야 하는지 물어보세요.
좋아요, 그 사고 실험에서 Claude가 해법을 만들어 낸 다음에, 그걸 프롬프트로 더 개선시킬 수 있을 확률은 얼마나 될까요? 아니면 Claude가 이미 완벽에 도달했나요?
AI는 "상상"을 아예 하지 않습니다.
이건 TV 안에 작은 사람들이 들어 있는 게 아니라고, 영화가 뭔지 설명해 줬더니 "그래도 가끔은 말만 하는 게 아니라 재채기도 하잖아요, 재채기는 연기로 못 하는 거라고 기사에서 읽었어요"라고 받아치는 것과 같습니다.
네, 맞습니다. 정말 못 해요. 저는 프로덕트 매니저인데, 제품 업무용 하네스를 만들려고 정말 고군분투하고 있어요. LLM 모델은 사용자의 마음가짐을 제대로 모델링하지 못하고, 뻔히 나쁜 선택을 일관되게 내립니다(게다가 세대가 새로워질수록 더 나빠지고 있고요). 코드는 계속 나아지고 있어서 그쪽은 신경 쓰이지 않습니다. 하지만 사용자와 대화하며 무엇을 만들어야 하는지 파악하는 일은 AI가 정복하기엔 아직 한참 멀었습니다.
AI는 코드는 잘 짜지만 글쓰기는 못 합니다. 그런데 코드를 잘 짠다고 해서 제품 결정까지 잘할 거라고 생각하는 근거가 뭔가요?
AI는 글을 아주 잘 씁니다. 다른 변수를 배제하고 보면요. AI가 쓴 글의 문제는 품질이 아닙니다. 1) 프롬프트를 쓴 사람이 잘 다듬어진 글에서 기대되는 만큼 공을 들이지 않았고 초보적인 실수를 했다는 걸 드러내고, 2) 지금은 너무 쉽게 알아볼 수 있어서 거슬리는 상투어를 쓴다는 겁니다. 1990년에 LLM이 쓴 글을 웹사이트나 신문에 투고했다면 기술적으로 못 쓴 글이라고 할 사람은 아무도 없을 겁니다.
이번 10년의 거짓말이죠. 하루빨리 정신 차렸으면 좋겠네요.
코드를 LLM보다 잘 짜고 아키텍처를 더 잘 설계하는 사람에게는 여전히 고유한 가치가 있습니다. 당신이 그렇게 못 한다 해도요.
요즘 많이 생각하는 건, 결국 AI에게는 가치관도, 의도도, 취향도 없다는 점입니다. 사람도 저마다 가치관, 의도, 취향이 다르지만, 공유하는 부분도 많습니다. 살아 있는 인간으로서 우리에게는 생물학적이거나 문화적인 욕구가 있고, 이 땅에 사는 동안 이루고 싶은 저마다의 목표가 있습니다.
예술이든 제품이든 무언가를 만들 때 그 결과물은 만드는 사람 고유의 가치관과 취향의 산물이고, 그것들이 만드는 대상에 어떤 목적을 부여합니다. 만드는 것은 대체로 다른 사람이 쓰거나 즐기도록 하는 것(간접적이라 해도)이고, 우리는 대개 그 사람들에게 공감하며 그들이 우리가 만든 것으로 좋은 경험을 하기를 바랍니다. 청중을 생각하고 그들의 필요를 저울질합니다.
좋은 소프트웨어를 쓰다 보면 만든 사람의 의도가 느껴집니다. 만든 사람(또는 팀)이 자기만의 관점과 사용자의 목표를 하나로 엮어 낸 것이죠. 지금 시점에서 에이전트 코딩이 그걸 줄 수 있다고는 생각하지 않습니다. 적어도 완전하게는요. 학습 데이터 덕분에 공통된 가치와 흔한 것들은 대부분 맞힐지 모르지만, 결과물을 손보거나 좋은 방향으로 이끄는 일은 여전히 사람이 해야 합니다. 그 방향은 그 사람만 볼 수 있고, 더 큰 비전의 일부이기 때문입니다. 단순한 요구에서는 취향과 가치관이 덜 중요하겠지만, 더 복잡한 일에서는 차이를 만든다고 생각합니다.
취향이란 본질적으로, 당신과 당신이 배운 사람들에게 효과가 있었던 것이 무엇인지, 그리고 지금 상황의 세부 사항이 거기에 어떻게 반영되는지에 대한 휴리스틱의 집합입니다. AI는 취향밖에 없다고 주장할 수도 있습니다.
당신의 취향이 아닐 수는 있어도 AI에게 취향이 있는 건 분명하고, 그 취향은 학습을 더 할수록 좋아지기만 할 겁니다. 반면 AI를 쓰는 당신의 취향은 퇴화할 겁니다. 당신이 마주하는 문제의 세부 사항과 접촉하는 일이 줄어드니까요.
에이전트 코딩은 당신의 주체성(agency)을 대체하는 것입니다.
좋은 지적입니다. 제가 생각한 건 아마 개인의 취향에 더 가까울 겁니다. 학습된 AI는 일종의 여러 취향의 집합이니까요. 궁금한 건 "집단"의 취향이 그것만으로 좋은 제품을 만들어 낼 수 있느냐입니다. 위원회가 설계하면 관점이 서로 충돌하는 결과물이 나오는 경우가 많죠. 학습된 AI는 위원회 설계보다 잘할 수 있을까요? 분명 위원회도 아니고, (인간적인 의미에서의) 개인도 아닙니다. 일반 원칙을 따른다는 데 제품을 만들 때 특정한 관점을 갖기 어렵게 하는 본질적인 무언가가 있을까요? 제 생각에는 AI가 이를테면 "애플 취향"을 갖도록 학습시켜서 애플다운 좋은 제품을 만들게 하는 건 아마 가능하겠지만, 그 취향이 특정 제품이나 요구에는 맞지 않을 수 있습니다. "리눅스 취향"은 어떤 데는 더 낫고 어떤 데는 아니겠죠. 그런 식으로요. 거기까지 간다 해도 어떤 "취향의 모자"를 쓸지 고르는 선택은 여전히 필요할 테고, 그것조차 AI가 학습해서 할 수 있을 가능성이 높습니다. 어쨌든 곱씹어 볼 만한 흥미로운 주제입니다!
제가 보기에 AI에게는 개인적인 취향(심지어 "성격"까지)이 있습니다. 다만 같은 모델로 학습된 모든 인스턴스가 똑같이 단조로운 취향을 가졌다는 게 문제죠. 그 압도적인 반복 규모 때문에 취향이 다들 질색하는 클리셰가 되어 버립니다. 슬롭 같은 글, 다이어그램, 웹사이트 등을 우리가 바로 알아보는 것처럼요.
독특한 말투를 쓰거나 특정 표현을 유난히 자주 반복하는 사람을 다들 만나 봤을 텐데, 그래도 "솔직한 진실은.."이나 "load-bearing.." 같은 표현만큼 거슬리진 않잖아요.
60년대 TV가 이랬겠네요. 채널이 몇 개 없으니까 다음 날 학교나 직장에서 다들 똑같은 농담을 했잖아요. 우리 모두 같은 에피소드를 봤으니까요.
이런 식으로 ChatGPT나 Claude가 새로 나올 때마다 새로운 밈 같은 어법이 놀라운 속도로 인간의 정신에 퍼집니다.
글쎄요? 그 몇 안 되는 채널 전체의 시청자 수가 90년대 «프렌즈» 한 편보다 적었을 텐데요.
그리고 사람들이 텔레비전을 덜 보고 다른 활동을 했을 테니, 자기만의 농담을 만들어 내기도 했을 것 같아요.
(말씀하신 요지와는 별 상관 없는 얘기네요, 죄송합니다)
"더 많은 학습"이 만능 해결책이라는 데는 동의하기 어렵습니다. "당신과 당신이 배운 사람들"이라는 건 잠재적 학습 데이터 세계의 부분집합이고, 어쩌면 아주 작은 부분일 수도 있으니까요.
새 모델 세대로 넘어가도, 더 큰 노력을 들일수록 "의도를 갖고 조율한 목표"보다 "기본 선택"으로 되돌아가는 경향이 여전히 보입니다.
여러 분야에서 "좋은" 취향은 모든 것이 기본 스타일이 되면 더 이상 특별히 좋은 것이 아닙니다.
그러면 강점은 (a) 기본값이 아닌 방식으로 더 잘 응대할 수 있고 (b) 그쪽을 겨냥할 만한 경제적 특성이 있는 틈새를 찾는 데서 나옵니다.
모든 걸 하나로 해결하는 거대한 규모에 막대한 ROI를 내는 SaaS 맥가이버 칼의 시대는 얼마 남지 않았다고 봅니다. 하지만 그 자리를 대체하는 세상은 훨씬 다양한 플레이어가 있는 훨씬 활기찬 생태계가 될 수 있을 겁니다.
AGENTS.md에 가치관을 적어 넣으면 AI가 일하는 방식에 영향을 줍니다. 예를 들어 "이 프로젝트에서 최우선 가치는 프론트엔드 코드를 최대한 빠르게 만드는 것"이라고 쓰면, "이 프로젝트에서 최우선 가치는 프론트엔드를 최대한 단순하게 만드는 것"이라고 쓸 때와는 다른 결과가 나옵니다.
이게 뭐가 다른지 모르겠네요. 입력이 컨텍스트의 다른 구간에, 어쩌면 생성 뒤가 아니라 앞에 들어갈 뿐이지, 사람의 취향이 필요하다는 사실은 달라지지 않잖아요.
같은 종류의 가치라고는 생각하지 않아요. AI는 당신의 문제를 풀고 싶어 하지, 당신(이나 당신의 사용자)에게는 관심이 없어요. 사랑이나 상실이 어떤 느낌인지도 모르고요. 하루 종일 설명해 봐야 사람처럼 마음 써 주지 않아요. 이유도 모르고, 이유에 관심도 없어요.
저는 AGENTS.md에 "체이닝된 삼항 연산자를 쓰지 말 것"이라고 적어 놨어요. 아직도 효과가 나타나길 기다리고 있어요.
에이전트에게 뭔가를 하지 말라고 하면 대부분 그걸 하는 방법을 알려 주는 꼴이 되고, 그렇게 하지 말라는 부분은 사라져 버리더라고요. 뭐, 그걸 해 놓고 사과할 때 써먹기엔 아주 접근하기 쉽긴 하죠.
그래서 이제는 원하는 방식의 예시만 주고, 나쁜 짓을 하면 불평하는 훅(hook)을 걸어 둡니다(그 불평에서도 나쁜 짓이 뭔지는 언급하지 않고요).
저는 좌변이 중복되는 장황한 if/else 식보다 체이닝된 삼항 연산자가 차라리 더 좋은데요, 이것도 결국 "취향" 논쟁으로 돌아가네요.
이게 제가 Rust를 좋아하는 이유 중 하나예요. 둘 다 쓸 수 있거든요.
안타깝게도 모든 언어가 Rust는 아니죠.
이게 아래보다 더 간결하진 않은데요.
하지만 더 읽기 쉽고, 중요한 건 그거죠.
빈 줄과 쓸데없는 공백이 늘어난다고 "더 읽기 쉽다"고는 전혀 생각하지 않습니다. 또다시 "취향" 논쟁으로 돌아오네요.