Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 AI 산출물의 낮은 품질에 대응하는 어려움과 '헛소리 비대칭 원칙'을 지적합니다. 특히 LLM이 기존 시스템의 구조를 이식하거나 기능을 덧붙이는 데 가치를 발휘하며, 성공적인 활용을 위해서는 기반 설계와 깊은 이해가 필수적임을 강조합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기이 글을 보니 저품질 AI 업무 산출물(workslop) 에 대응하기 어려운 이유가 다시 떠오름. 만드는 데는 노력이 거의 들지 않지만, 반박하려면 엄청난 노력이 필요함.
코드에만 초점을 맞추는 경향이 너무 강할 때가 있음. 코드나 정량 분석뿐 아니라 LLM이 내놓는 모든 답변에 해당하는 문제임.
전문가들이 누구에게 배웠는지 계보를 따지는 이유는 배운 내용의 세부 사항과 관점이 사고방식과 문제 접근법을 형성하기 때문임. 대부분의 일에는 유일한 정답이 아니라 여러 접근법이 있으며, 자신은 어떤 틀에도 갇히지 않고 자유롭게 사고한다고 믿는 건 초보적인 실수임.
특정 방식을 당연시하도록 부추기는 건 식탁에 팔꿈치를 올리지 말라는 사소한 예절을 절대적인 규칙으로 굳히는 것과 비슷함. 만들어내기는 쉽고 반박하기는 어려운데, 때로는 그 여파도 큼. 인종차별 역시 아무 저항 없이 관성대로 흘러가면서 그것이 자연스럽다고 우기는 방식으로 작동한다고 확신함.
내 전략은 문서를 훑어 의심스러운 부분을 찾고, 작성자의 신뢰도를 떨어뜨릴 만한 오류 하나부터 우선 반박하는 것임. 그 내용을 짚어 답장하면서, 시간을 더 투자하기 전에 문서의 문제들을 꼼꼼히 해결해야 한다고 정중하지만 단호하게 전달함.
상사가 보낸 문서에는 통하지 않지만, 다른 이들이 저품질 산출물을 보내기 전에 재고하게 만드는 데는 효과적임. 이런 문서를 내미는 건 성과를 보여주는 이익이 평판 손상 위험보다 크다고 믿기 때문임. 매번 걸려서 이메일 대화에 드러나면 빈도가 줄어듦.
AI가 확실히 하는 일이 있다면 비대칭을 증폭하는 것임. 해킹, 사기, 코드 품질 저하처럼 원래도 방어하기 어려운 문제를 더 어렵게 만드는 데 아주 능함.
헛소리 비대칭 원칙, 즉 브란돌리니의 법칙임. 헛소리를 반박하는 데 필요한 에너지는 만들어내는 데 필요한 에너지보다 한 자릿수 규모 더 큼.
여기서는 기존 시스템을 LLM으로 이식한 상황이라는 점을 짚을 필요가 있음. LLM에 이상적인 활용처이며, 필요한 사고의 90%는 기존 시스템 개발자들이 이미 해놓은 셈임.
AI 성공담 대부분은 이식 작업이거나, 시스템을 이해하는 사람이 의도적으로 설계한 구조 위에 AI로 기능을 덧붙이는 프로젝트에서 나오는 듯함. Linux 배포판에 기능과 드라이버를 추가하는 작업도 기반이 이미 마련돼 있어 AI가 특히 가치를 내기 좋은 영역으로 보임.
에이전트가 작성한 코드도 뒤엉키지 않으려면 이런 설계 기반이 필요하다는 글을 최근 작성함. 관심 있다면 읽어볼 만함. https://ljtn.github.io/epiq/blog/the-soft-fabric-of-agentic-...
먼저 테스트로 현재 동작을 명문화한 뒤, 그 테스트에 어떤 버그까지 정답으로 굳혀버렸는지 꼼꼼히 살펴보는 방식으로 시작할 수 있음.
이상적인 활용처라는 평가는 너무 과감함. 남은 10%가 글에서 짚은 문제들을 뜻한다면, 바로 그 부분이 구현하거나 이제 와서 고치는 데 가장 많은 시간과 노력이 드는 영역임. 이미 이식한 90%를 이해하고 수정하지 않고는 해결할 수도 없음.
시스템의 현재와 미래에 대해 충분한 근거를 갖고 결정하려면, 작업 중인 시스템을 그만큼 이해해야 함.
경우에 따라 코드를 읽지 않고도 넘어갈 수 있고 앞으로는 그런 경우가 늘어날 수도 있음. 하지만 지금은 AI에 판단을 넘기기보다 직접 코드를 읽거나 훑어보는 편을 선호함.
생각은 직접 해야 한다는 말이 논쟁거리가 되는 미래가 두려움.
자유로운 사고와 비판적 사고는 문명 초기부터 대부분의 인간 사회에서 금기이거나 엘리트의 전유물로 취급돼 왔음.
직장에서는 사실상 생각하는 행위 자체를 억제하고 있음. 모든 일에 AI 에이전트를 쓰지 않으면 일을 잘못하고 회사 시간을 낭비하는 것으로 취급함.
아무도 직접 코드를 작성하지 말아야 한다고 강조하며, AI 구현이 잘못됐다고 생각하면 확실한 근거를 제시해야 함. 그렇지 않으면 일을 방해하는 반AI 골칫거리로 낙인찍힘. 직접 내놓은 판단이 조금이라도 틀리거나 그저 대단한 성과가 아니기만 해도, 이후 검토에서 무시당하고 아무도 귀를 기울이지 않게 됨.
사고 과정을 살펴볼 수 있어 유익함. 실제 효율 향상을 측정할 벤치마크를 사전에 확정했다면 도움이 됐겠지만, 복잡한 시스템을 사람의 개입 없이 전면 재작성하는 방식은 아직 실전에 투입할 단계가 아님.
그 점은 솔직히 실망스러움. 작동하는 애플리케이션의 전체 코드와 가능하면 테스트까지 AI 에이전트에 주면, 다른 언어로 동등한 애플리케이션을 구현할 수 있어야 하지 않을까?
모호하거나 불완전한 프롬프트 때문에 실수하는 건 이해하지만, 이 작업은 프롬프트조차 필요 없어야 할 듯함. 필요한 정보가 모두 코드 안에 있지 않나?
이런 이식 프로젝트를 볼 때마다 새 기능은 누가 어느 코드베이스에 구현하는지 궁금함.
자동화된 테스트가 있다면 이식 자체는 쉬운 편이지만, 그다음에는 기존 코드에 기능을 추가하고 다시 이식하는 건가? 아니면 낯선 새 코드베이스에 직접 구현하는 건가? 그냥 Jira 티켓을 써놓고 에이전트가 알아서 밀어붙이게 하는 건가?
예시 몇 개로 에이전트에게 앱 이식을 시켜보는 실험에서 결과가 완벽하지 않았다는 사실은, 코딩에서 사고하거나 AI를 활용하는 방식을 의미 있게 판가름하는 시험이라고 생각함.
DHH가 Omarchy에 관심을 끌려고 의도적으로 논란을 만드는 것 아닌가 싶음.
정말 코드를 읽을 필요가 없다고 믿는다면 개발자를 전부 해고하고 디자이너에게 맡기면 될 일임. 아주 상위 수준의 기능 설명을 쓰고 반복 개선하게 하면 됨. 말한 대로 실제로 행동해볼 필요가 있음.
테스트는 여전히 해야 하지만, 내 경험상 고부하에서 불안정한 동작을 발견했다면 Claude에 증상을 말하는 것만으로 고부하 벤치마크를 만들고, 이 브로드캐스트 채널 문제를 찾아 고쳤을 것 같음.
직접 생각하면 결과가 좋아지는 건 분명하지만, 그래도 생각은 직접 해야 한다는 말이 실업으로부터 우리를 지켜줄 안전지대라고 보지는 않음.
글의 요지는 모든 결정이 “고부하에서도 코드가 안정적이어야 한다”처럼 명백하지는 않다는 것임. 어떤 결정은 분야 지식과 기술 전문성이 필요한 절충 판단임.