Hacker News 의견

• AI를 조직에 도입하는 것은 단순히 기술적 문제가 아니라 변화 관리 문제임을 강조함. 신뢰와 투명성을 바탕으로 한 유능한 팀이 인간의 전문성과 LLM의 강점을 균형 있게 결합하는 프로세스를 만들어야 진짜 효과를 볼 수 있음. 소규모 팀이 AI로 큰 성과를 내는 사례도 생기고 있음. 하지만 대부분의 조직, 특히 대기업은 건강한 조직문화를 갖추지 못해 AI가 오히려 이 독성을 증폭시키는 현상이 나타남. 기업 임원 중에는 "Story Point"를 단순히 시간 단위로 오해해 AI가 모든 걸 반으로 줄여주는 도구로만 바라보는 경우도 있음. 근본적으로는 유지보수가 가능한 소프트웨어를 만드는 과정 자체와 동떨어져 있어 AI를 얼렁뚱땅 수익만 올려주는 통로로 인식함. 최근 AI 파일럿 프로젝트의 95%가 ROI를 달성하지 못했다는 연구 결과 역시, 현대 경영진의 무능함을 보여주는 사례임

  • 어쩌면 AI가 과대평가된 것뿐임을 지적함. "소규모 팀이 AI로 큰 성과"라는 주장은 어떤 구체적인 팀 얘기하는 건지 궁금함을 밝힘
  • AI의 문제를 단순히 "애초에 있던 문제일 뿐"이라며 면죄부를 주는 태도에 지침을 전달함. AI로 인한 정신 건강 악화나 조직 문화 문제도 도구 자체의 책임이 있다고 봄. 도구와 시스템이 무책임하다는 생각과 달리, 실제로 도구와 환경 역시 영향을 준다고 생각함
  • "소규모 팀이 큰 일을 한다"는 주장에 구체적인 사례 없이 성공담만 들려 아쉽다는 생각임
  • 관리자 조직이 이미 엉망인 곳에 AI를 도입하는 것은 바이킹 무리에 자동소총을 쥐여주는 것과 같다고 봄. 조직이 망하는 시기를 앞당기는 역할만 할 뿐임. 기술이 문제의 핵심이라기보단, 다수 구성원(또는 소수 핵심 관리자)의 사회적∙윤리적 실패가 진정한 원인임을 강조함
  • "Story Point"를 시간으로 오해하는 경영진이 많다고 언급하며, 지금까지 만난 모든 역할(개발, QA, PM, 임원)에서 이 실수를 본 경험임

• "Prompstitudes(프롬프트에만 의존하는 직장인)"의 등장에 대해 이야기함. 동료가 내 의견을 유추한 ChatGPT의 답변만 던졌던 적이 있고, 마치 기사에서 말하는 "침범당한 기분"을 느꼈음. 이들은 무능하다기보다 LLM에 너무 의존해, 마치 슬롯머신만 계속 돌리는 카지노의 노인과 같다고 느낌

• 최근 동료와 대화할 때 명확히 ChatGPT의 결과가 돌아왔다는 사실 때문인지 찝찝함을 느낀 경험을 공유함. 차라리 무시당하는 게 나았다고 생각함. 특히 LLM이 자신만만하게 틀린 소리를 강하게 주장해서 더 문제였음. 작은 부분(예: 설정과 구현에서 이름만 조금 달라도)이 LLM을 완전히 헷갈리게 할 수 있음. 인간과 달리, LLM이 실수에 대해 배우거나 깨닫지 않으니 지속적으로 잘못된 방향으로 흘러가는 현상이 있음. 차라리 나쁜 인간 코드와 씨름하는 게 마음적으로 낫다고 느낌

  • 예전에 AI로 PRD 쓰는 PM과 일한 적 있음. 내용을 물어보면 "본인이 모른다, AI가 쓴 거라서"라고 답했음. 결국 PM은 실제 아이디어 전달은 포기하고, 문서 작성 퍼포먼스만 하게 됨. 요구 사항의 이해와 해석까지 전부 내 몫이 돼서 팀을 나옴
  • "LLM이 자신감 넘치게 틀렸다"라는 부분에 공감을 표시함. 주변에 아는 척 카리스마 있는 동료처럼, LLM도 그럴듯하게 틀린 말을 하는 경우가 많음
  • 이번 주에 매우 기이한 경험을 했음. 자기 자신도 잘 모르는 전문 사양 관련해서 Claude에게 내부 제안을 검토하게 했더니 많은 오류를 지적했음. 그걸 해당 사양의 사내 담당자에게 "이건 LLM이 제안한 거라 헛소리일 수도 있다"라고 전달했더니, 그 사람도 LLM에 내 메시지를 넣고 답변을 받아 다시 내게 보내 물어봄. 결과적으로 우리 모두가 AI의 어시스턴트 역할만 하게 됐다는 생각임. 이런 미래가 소프트웨어 개발의 현실이라면 내키지 않음
  • 나쁜 인간 코드가 나쁜 LLM 코드보다 훨씬 낫다고 생각함. 인간 코드는 뭘 하려고 했는지 맥락이라도 추론 가능함. 반면, LLM이 만들어낸 코드는 처음부터 끝까지 망가져 있을 때가 있고, 아예 존재하지도 않는 함수나 개념을 막 만들어내기도 함. 인간은 보통 이 정도로 현실과 동떨어진 코드를 만들지 않음. LLM 코드를 이해하려면 코드베이스 전체를 다시 배워야 할 정도임
  • LLM이 "자신이 실수하지 않는다고 믿는다"는 표현에 대해, LLM은 애초에 믿거나 생각하거나 느끼지 못하는 존재임을 지적함. 그저 통계적으로 가장 그럴듯한 언어 토큰을 이어붙이고, 약간의 랜덤 요소를 더해 창의성을 흉내낼 뿐임

• "AI 도구가 정말 쓸모가 있을까?"라는 질문에 대해, 본인은 남들과 다르게 써서 도움이 된다고 생각함. 1983년부터 개발을 했고, 현재는 은퇴해서 혼자 작업하는 경우가 많음. 여러 도구를 써봤으나 지금은 ChatGPT와 Perplexity만 활용함. 직접 코드를 짜게 하진 않고, LLM이 제시한 코드를 참고하며 시작점으로 활용함. 가끔 통째로 쓰기도 하지만, 대부분 수정과 재작성 과정을 거침. LLM이 점점 더 못된 결과를 낼 때는 그냥 끊고 새 접근을 시도함. 이 흐름 속에서 초보 엔지니어가 LLM 코드만 따라쓴다고 상상하면 떨림. 본인에게 가장 큰 가치는 "즉시 대응해주는 StackOverflow" 같은 느낌임. 어떤 바보 같은 질문도 부끄러움 없이 물어볼 수 있고, 빠르게 괜찮은 답을 얻을 수 있음. 최근 iOS에서 PassKey 구현을 배우면서 ChatGPT 예제 코드를 그대로 시작점으로 삼아 한 줄 한 줄 이해하며 공부했음. 처음 썼던 코드와 지금의 완성 코드는 완전히 달라졌고, 이 과정을 통해 기술 이해가 깊어졌음

  • 본인도 똑같이 AI를 활용함. 아무것도 몰랐던 개인 프로젝트를 거의 마무리해가는데, 이제는 코드베이스를 충분히 이해하는 중임
  • 본인도 소규모 업무나 개인 프로젝트에서 비슷하게 씀. LLM이 첫 번째로 "버리는 코드"를 써주고, 그 한계를 탐색하며 문제 도메인을 더 잘 이해할 수 있음. 결국 더 자신감 있게 직접 구현할 수 있게 됨

• LLM이 기술 질문에 답하거나 새로운 접근을 제안하는 데 매우 뛰어나다고 느낌. 초보자라도 stackoverflow처럼 평가받거나 벽에 부딪히지 않고 자유롭게 질문 가능함. Copilot은 자동완성 기능이 뛰어나 코드 작성 속도를 높이고, 문서 주석이나 코드 라인을 자동 완성해줌. 이런 작은 도움들은 쉽게 검토 가능함. 그러나 LLM에게 복잡한 코드를 통째로 맡기면 혼돈이 발생하고, 오히려 디버깅에 시달리는 경험이 있음. 초보자가 LLM에 지나치게 의존하면 제대로 된 개발 역량을 키우기 어렵다고 생각함

• 개인적으로 Zed를 취미 개발에 사용하는 이유는 AI가 지나치게 똑똑한 척 나서지 않기 때문임. 필요할 때만 AI 기능을 부드럽게 호출할 수 있고, 평소엔 그냥 내가 코딩함. 직장에서는 VSCode AI 때문에 방해를 너무 많이 받음. 두 가지 점에서 문제임: 첫째, 인터랙션이 너무 깨지기 쉬움(Popup 클릭, 실수로 거대한 자동완성 삽입), 둘째, 흐름이 끊긴다는 점임. AI 자동완성이 유용할 때도 있지만(약 1/3 비율), 나머지 시간에는 본래 생각 흐름이 깨지고 AI 결과를 확인하느라 집중이 흐려짐. Zed에서는 이런 문제가 없어서 다시 프로그래밍의 즐거움을 되찾았다고 생각함. 결국 문제는 AI 기능 그 자체보다 구현 방식에서 발생함

  • 본인도 Zed에 깊이 공감함. JupyterLab이나 Kate에서 놀다가 Zed를 쓴 후로 바뀌었음. Zed는 IDE/에디터가 중심이고, AI나 Jupyter 커널 등 부가 기능은 필요할 때만 조용히 지원하는 느낌임. 이런 추가 기능이 본연의 텍스트 편집/코딩을 방해하지 않음. Zed 팀이 좋은 균형을 잡았다고 생각함

• AI는 UX 프로토타입 만들기에 아주 유용하다고 느낌. 짧은 시간 안에 클릭 가능한 결과물을 바로 만들어서, 여러 번 반복하며 방향만 잡고 나중엔 이런 코드는 버리고 새로 개발함. 이 방식이 잘못된 방향으로 일찍부터 많은 시간을 낭비하지 않게 도와줌. 다만, 아직 AI로 유의미한 앱 전체를 통째로 만드는 건 멀었다고 생각함

  • 평소에 잘 다루지 않던 영역(예: 파워쉘 스크립트)에서 AI의 도움을 많이 받음. 예전에 레지스트리 설정 리포트용 스크립트가 필요했을 때, Claude가 완벽하게 짜줘서 한 시간 아낀 경험 있음
  • 본인도 비슷하게 AI가 오류 설명에 탁월하다고 느낌. 정확한 해결책을 찾거나 새로운 아이디어를 떠올리게 해줘 많은 도움이 됨
  • "프로토타입을 버리고 새로 개발"이 중요하다고 언급하는데, 현실에서는 PM이 이 부분을 잊어버려 프로토타입이 실제 서비스에 들어가는 일이 많다고 지적함. 그래도 본인이 잘 쓰는 방식이 있다면 그건 좋은 일임
  • 이 사용 사례와 프로세스, 도구에 대해 더 자세히 듣고 싶다고 질문함. 본인과 팀에게 실질적으로 도움 될 수 있을 것 같기 때문임

• AI는 본인에게 그저 하나의 도구일 뿐이라고 봄. 본인은 하이레벨 개발자가 아니지만, 개인 프로젝트 중 막히는 부분에서 AI에게 아이디어와 피드백을 요청하는 방식으로 사용함. 중요한 점은, 코드 작성은 AI에게 맡기지 않는다는 것임(아주 단순한 보일러플레이트 정도만 제외). 내가 직접 코드를 짜는 것은 문제 해결과 창작, 그리고 배우는 과정에서 얻는 기쁨 때문임

  • 최근 프로젝트는 AI가 직접 코드를 짜주지 않았다면 완성하지 못했음. 전체 리포지토리 셋업부터 PoC까지 엉성하더라도 가능하게 해줌. Django, JS, 웹개발 경험 없는 상태에서 AI 덕분에 처음엔 제대로 된 것은 아니지만 동작하는 결과를 얻고, 점진적으로 개선하며 이해도를 높이는 중임

• 최근 동료 코드 리뷰 중 "prepareData"라는 다차원 배열을 섞고 필터링하는 복잡한 함수를 봤는데, 해당 동료에게 "이게 무슨 역할이냐"라고 물으니, 시간을 아끼라고 LLM에 물어보라고 하여 당황스러웠던 에피소드임. 코드 리뷰를 위한 가장 기본적인 질문조차 답하지 않는 태도에 실망함

  • LLM에 물어서 대답을 그냥 동료에게 돌려주고, 20번 피드백 주고받으면 그가 이해를 못할 때 너도 LLM에 물어보라고 하면 되지 않겠냐고 약간 유머러스하게 제안함

• 10년 후 신입 개발자들이 직접 코드 쓰는 경험 없이 바로 시니어가 되려는 현상을 우려함

  • 사실 이 현상은 AI 이전부터 시작됐음. 10년 이상 경력이 없으면 입사도 어려운 구조였고, 젊은 세대의 업스킬링에 업계가 실패함. 회사에서 꾸준히 신입 양성하려 해도 위기 때마다 신입부터 정리해고하고 다시 시니어만 급하게 뽑는 악순환이 반복됨
  • 이제는 시니어가 3년 차만 되어도 된다는 농담과 함께, 10년이 아니라 3년이면 금방 스태프 개발자가 된다는 분위기를 언급함
  • "Vibe coding"이라는 개념이 9개월 전부터 등장했고, 앞으로 2년도 안 돼서 사람들이 코드를 직접 쓰거나 유지보수하지 않게 될 것 같다는 전망임
  • 그래도 전문성을 가진 개발자가 쓴 소프트웨어는 항상 존재할 것이고, LLM 코드가 완벽하지 않은 한 고품질 코드에 대한 수요는 계속될 것임
  • 주니어 개발자가 너무 많고 실제 경험을 얻을 가치 있는 문제가 많지 않기 때문에, 이들이 다음 단계로 성장하기 어렵다고 봄. 예전엔 저렴하게 PoC나 스크립트 작업이라도 맡길 수 있었지만, AI가 그런 역할을 적당히 해내는 지금은 기회가 줄고 있음. 그때도 주니어는 많고 자리는 부족했다고 첨언함