▲

인간 개발자가 LLM보다 여전히 더 뛰어난 이유

 (antirez.com)
18P by GN⁺ 6일전 | ★ favorite | 댓글 7개
  • Redis 창시자 antirez는 AI와 LLM을 자주 활용하지만, 현시점에서 인간의 문제 해결 능력이 LLM보다 훨씬 앞선다고 생각
  • Redis 벡터 세트에서 발생한 복잡한 버그 수정 과정에서 LLM의 한계를 직접 경험함
  • LLM이 제안하는 알고리듬은 표준적이거나 단순한 해법에 그침
  • 인간 개발자의 창의적 접근이 LLM이 도달하기 어려운 혁신적 해결책 제시에 유리함
  • LLM은 아이디어 검증이나 대화 상대로 매우 유용하지만, 최종적인 창의성은 인간에게 있음

서론: 인간과 LLM의 비교

  • 나는 AI와 LLM에 대한 반감이 전혀 없는 입장임
  • 오랜 기간 LLM을 일상적으로 활용하며, 아이디어 테스트, 코드 리뷰, 대안 탐색 등 여러 방식으로 사용하고 있음
  • AI의 현 수준은 분명 실용적이고 뛰어난 점이 있으나, 인간 지능과의 격차가 여전히 크다는 사실을 강조함
  • 최근 균형 잡힌 AI 논의가 어려워질 만큼 이 필요성을 느끼고 글을 적음

Redis 벡터 세트 버그 사례

  • 최근 Redis 내 Vector Sets 관련 버그를 고치고 있었음
  • Redis 동료들이 부재 중, 파일 데이터 손상(RDB/RESTORE)에 대한 추가 보호 기능을 도입했음
    • 이는 기본적으로 꺼져있고, 체크섬이 통과해도 손상을 막으려는 추가 안전망임
  • 문제는 HNSW 구조체의 그래프 표현을 RDB에 직렬화하는 속도 최적화에서 발생함
    • 노드간 연결 리스트를 정수형으로 저장, 역직렬화 시 포인터로 복구하는 방식임
    • HNSW 자체 구현의 특징(상호 연결 보장) 때문에, 그래프/메모리 손상 시 아래 문제 발생 가능함
      • A가 B에 연결된다 저장되어 있지만, B가 A에 연결되지 않거나(넘버링 오류 등)
      • B 노드 삭제 시 상호 연결 위배로 인해, A→B 링크가 남아서 이후 B->A 탐색시 use-after-free 버그 발생
  • 데이터 로딩 후 모든 링크가 '상호 연결'을 만족하는지 검증 필요
    • 순수 알고리듬 적용시 O(N^2) 복잡도. 대량 데이터(~2천만 벡터)에서 로딩 속도가 45초→90초로 두 배 증가 확인

LLM 접목 및 한계

  • Gemini 2.5 PRO와 채팅하며 더 효율적인 방법을 묻고, LLM의 제안을 검토함
    • LLM의 제1제안: 이웃 노드 리스트 정렬 후 이진 탐색(binary search) 적용(이미 많이 알려진 방법)
    • 큰 개선 효과 없음을 이유로 추가 아이디어를 요청했으나, 더 나은 답변을 얻지 못함
  • 내가 제안한 대체 방식: 해시 테이블을 이용해 링크 쌍(A:B:X, 정렬 및 쌍방향 구분 제거) 등록 및 제거
    • LLM도 좋은 아이디어라고 평했으나, 키 생성 성능 및 해싱 성능 등을 단점으로 언급
    • snprintf 없이 고정 길이 키를 memcpy로 처리하여 효율 상승을 추가 제시함

인간의 창의성 vs LLM의 한계

  • 나는 해시 테이블 없이 누적자(accumulator)에 XOR 기법을 적용하는 아이디어를 제안
    • 포인터 쌍(및 레벨 정보)을 누적자에 XOR, 상호 연결시 상쇄(0), 누락시 패턴 남음
    • 단, 충돌 가능성 및 포인터 예측성을 지적(LLM도 여기에 동의)
  • 추가 개선: 무작위 시드/해싱(murmur-128 및 urandom 시드) 결합, 128비트 누적자에 XOR 적용
    • 마지막에 누적자 값이 0인지로 상호 연결 성립 여부 판단
    • LLM은 이 방식이 일반적 오류 및 외부 공격자에 대한 강인성도 높으며 효율적이라 평가

결론

  • 최종적으로 신뢰성 판단 후 도입 여부를 결정하기 위해 분석을 마침
  • 이 사례에서 인간 개발자의 창의적, 비표준적 접근이 LLM이 제공하는 제약된 답안보다 우수했음을 확인
  • LLM은 아이디어 검증 및 지적 대화자('스마트 오리' 역할) 로써 매우 유용
  • 그러나 최종 창의적 솔루션 도출 능력에서는 인간의 우위가 명확함
▲
nb13557 3일전  [-]

redis 곧 뒤쳐지겠네

답변달기
▲
aer0700 3일전  [-]

자전거랑 달리기 경쟁하는 느낌이네요.

답변달기
▲
ethanhur 6일전  [-]

antirez는 1% 인간 개발자죠. 1% 인간 개발자는 계속 LLM보다 뛰어날 것이라 생각합니다. 하지만 99%는 어떨지 모르겠네요.

답변달기
▲
softer 6일전  [-]

llm이 수준 높고 창의적이여보이는 건 그런 글을 학습했기 때문이고 그 결과를 높이기 위해 수많은 과학자들이 그 지식을 검증하며 학습 데이터의 수준을 높였기 때문이라 생각합니다

하지만 시간이 지나면서 트랜드가 바뀌거나 상황에 따라 다른 창의성이 필요하기 때문에 결국 사용하는 사람이 자신의 상황에 맞게 창의성을 발휘 해야하는 거 아닐까요..

답변달기
▲
spp00 6일전  [-]

AI 통해서 트러블슈팅 하려다가 전부 실패해서 결국 제가 스스로 문제를 해결한 적이 여러 번 있습니다.

답변달기
▲
GN⁺ 6일전  [-]
Hacker News 의견

  • 내 경험과 정확히 일치하는 부분이라는 생각. 사실 LLM 어시스턴트가 내게 주는 큰 가치는 꽤 지능적인 ‘러버덕’ 역할을 해주는 점. 가끔은 이 ‘덕’이 내 의견에 반박도 하고, 심지어 내 생각을 더 정교하게 만들어주기도 함. (러버덕 디버깅이란?) 그런데 모든 사람이 건너뛰고 싶은 핵심 질문은 ‘이런 가치가 앞으로 2년 뒤에도 계속될까?’라는 점이라고 생각. 나 역시 그 답은 모름

    • LLM은 나에게 러버덕이 아니라 ‘틀린 답변기’ 같은 존재. 인터넷 상에서 답을 얻는 가장 좋은 방법은 틀린 답변을 올리는 것이라는 말이 있는데, 내겐 딱 그 역할. LLM에 단순하지만 귀찮은 일을 시키면 엄청나게 틀린 결과를 내놔서, 오히려 내가 짜증이 나서 분노의 힘으로 직접 해버리게 됨

    • 지나치게 자신만만한 덕 역할, 실제 능력에 비해 너무 과한 확신을 보임. LLM과 얘기하며 길을 잃는 사람들 너무 많이 봤음

    • 내게는 LLM이 API는 잘 알지만 아키텍처에선 상식이 부족한 주니어 개발자가 내 밑에서 일하는 것과 비슷. 엉뚱한 실수를 걱정하며 대부분의 PR을 팀 리뷰로 넘기기 전에 무려 3~4번 검토를 돌림. 그 덕분에 뇌를 다른 문제로 돌릴 수 있다는 점은 좋음

    • 2년 뒤에도 이런 가치가 유지될지? 내게는 ‘이 대화를 넘어가고 싶다’는 문제보다, ‘우리는 2년 뒤까지 그때까지 갈 수 있을까?’라는 고민이 더 큼. 지금 세상은 너무 불안정해서 6개월 뒤 모습도 예측 불가능

    • 내겐 LLM이 페어 프로그래밍하는 동료 같은 느낌. 아이디어를 얘기해볼 수 있는 상대, 코드 리뷰·대안을 제시해주는 존재. 그리고 내가 몰랐던 기능을 써봐서 배울 수 있음

  • 이 댓글란을 보다 보니 ‘인간은 꼭 필요하다’, ‘LLM은 디버깅을 못한다’, ‘LLM이 길을 잘못 인도한다’ 같은 얘기에 다들 기대를 거는 분위기가 조금 있음. 물론 사실이긴 한데, 2년 전만 해도 불가능하던 코드 자동생성이 엄청 발전했고, 지금도 빠른 페이스 유지 중. 앞으로는 ‘파레토 법칙’처럼 개선 속도가 느려질 수 있지만 분명 계속 진보는 할 것이라고 봄. 최근 r/fpga에서 LLM으로 첫 버전 테스트벤치 제작에 성공한 경험을 얘기했다가, 해보지도 않은 사람들이 가능성 자체를 무시하는 걸 봤는데 굉장히 놀라웠음

    • 이런 태도는 전문직 종사자들 사이에 아주 흔함. /r/law(법률 서브레딧)에도 갔다가 Dario Amodei의 법률 분야 AI 관련 발언을 듣고 순간적으로 무시하는 분위기를 실감. 어쩌면 적응 기제이자 현실 안주일 수도 있지만, 경제·사회 변화에 대응하는 미래 대응력에 있어선 매우 안 좋은 일이라고 생각

    • 어셈블리가 기본이던 시절, 프로그래밍 언어 등장 당시 프로그래머들이 (사실과 별 상관없이) 비효율적, 융통성 부족, 지나치게 단순화됐다고 조롱했던 것과 비슷. 이런 현상은 새 기술의 실제 가치와는 별 관계 없이 자연스러운 반응

    • LLM이 잠시 급성장하더니 최근 모델들은 오히려 퇴보한 느낌도 있음. 테스트코드 생성엔 좋은 결과가 나오지만, LLM이 새로운 기능 구현 같은 작업에 너무 깊이 쓰이면 오히려 이상해짐. 새 프로젝트나 간단한 웹앱 개발에는 잘 먹히지만, 대규모 또는 레거시 코드 리팩터링, 기능 추가에는 효과가 크지 않음. 예를 들면 Claude나 ChatGPT가 D3 API 전체를 헛소리로 만들어내는 경우도 자주 목격함

    • 결국 당신은 스스로 자신의 대체자를 만드는 중이고, 동료들은 신중히 움직이는 모습

    • ChatGPT-4o가 VHDL 작성에 엄청난 능력 발휘. 오늘도 저수준 컨트롤러 프로토타입 제작에 놀라운 성과 체험 중

  • 진짜 소프트웨어를 제대로 짜기 위해 필요한 컨텍스트(맥락)가 LLM에는 너무 방대. 소프트웨어란 그 자체로 ‘비즈니스의 코드화’임. LLM이 영업팀이 고객에게 약속한 온갖 특별 조건, 부서별 암묵적 규칙을 어떻게 알겠음? 지금 LLM이 해결할 수 있는 범위는 일반적이고 국한적. 클래스 두 개 이상이거나 파일이 20~30개 넘어가면 최상위 LLM조차 길을 잃고 포커스를 잃음. 맥락 유지가 안 돼서 쓸데없이 코드 churn이 심해짐. LLM이 진짜 개발자를 대체하려면 훨씬 더 많은 맥락을 받아들이고, 조직 전체에서 맥락을 모으고, 장기간 프로젝트에서도 생각의 흐름을 유지해야 함. 이런 문제들이 실제로 해결 단계에 이르면 그때부터 진짜 걱정 시작 예정

    • Gemini 2.5 Pro의 1M 컨텍스트 윈도우 써보길 추천. 내 작은 ETL 프로젝트 전체 코드베이스(10만 토큰)를 집어넣어도 꽤 괜찮은 결과. 완벽하진 않지만, 시대의 변화를 보여주는 좋은 신호

  • LLM이 개발자를 대체할까 논의할 때마다 다들 잊는 게 있는데, 실제 소프트웨어 엔지니어링은 코드 작성 말고도 엄청 할 일이 많음. 코드 짜는 건 오히려 작은 부분. 중요한 것은 소셜 스킬, 요구분석, 실제 고객이 진짜 원한 것 찾아내기인데, 정작 고객조차 본인 원하는 걸 잘 몰라서 엔지니어가 그걸 파악하느라 고생. 인간도 힘든 거라면, LLM이 그걸 해낼 수 있을 리 없음

    • 결국 이건 피드백 루프, 즉 고객이 실제로 써보고 의견 주는 즉각적 반복 과정이라는 문제. 챗 UI는 고객 피드백 루프로 아주 뛰어나고, 에이전트는 빠르게 새 버전을 만들어냄. LLM은 추상화, 다양한 컴포넌트 시스템, 전체 구조 설계, 요구분석까지 충분히 할 수 있음. 핵심은 반복 속도가 얼마나 빠르냐는 것. 모델의 견고함과 IQ는 계속 좋아지고 있음. 소프트웨어 엔지니어링의 전체가 이미 자동화 단계에 진입. 아마 5년 후면 인간이 보조를 안 받으면 거대한 병목이 되겠음. AI와 깊이 통합하지 않으면 뒤쳐질 수밖에 없음

    • 00년대 오프쇼어링(해외 개발자 아웃소싱) 열풍 때도 있었던 문제가 바로 이거. 해외팀이 수정 요구나 문제 제기가 어려워서 시키는 대로 그냥 짜기만 했고, 결과적으로 쌓이고 쌓이기만 했음. AI에서도 비슷한 일이 벌어질 듯. 결과도 비슷하게 나올 것 같음

    • LLM은 애초에 소프트웨어 엔지니어링 자체를 하지 않음. 근데 그게 문제는 아님. 실제로 많은 성공적인 프로그램이 ‘소프트웨어 엔지니어링’ 없이도 잘 굴러감. 클라우드 비용 구조를 아무도 신경 안 쓰는 환경에서는 더욱 그럼. 오히려 앞으로 IT 비즈니스 파트너처럼 기술적 감각 있는 사람이 소프트웨어 엔지니어 도움 하나 없이 앱을 다 만들게 될 것으로 봄. 이미 그린 에너지 업계에선 매일 그게 현실. 단, 문제는 유지보수, 확장, 효율이 필요해질 때 터짐. 그때야 비로소 ‘파이썬에서 리스트 쓸지 제너레이터 쓸지’같은 게 중요해지니까 진짜 엔지니어링이 필요한 지점

    • 5년 후엔 코드 설계 거의 안 하게 될 가능성 있음. 이미 1년 전에 비해 코드 타이핑 양은 엄청 줄었음. 그렇지만 이건 프로세스의 일부분일 뿐 개발자가 다 사라질 일은 없음

    • 한편으로 그냥 ‘코더’의 역할은 많이 대체되고 있음. LLM이 잘 하는 영역이 바로 이 부분. 흔히 “이런 API 받아서 저런 값 내라”는 티켓만 보며 고객 요구 파악이나 분석은 아예 안 하는 뇌 없는 코더들이 많고, 이 부분을 빠르게 치우고 있음. 본격적인 소프트웨어 엔지니어링은 그와 전혀 다른 영역이지만 단순 코더의 수요는 엄청 컸다는 점 무시하면 안 됨

  • 인간만이 프로그램의 추상 개념과 창의적 문제 해결을 할 수 있는 능력을 가진다는 것이 매우 중요한 포인트. 프로그래머란 논리의 건축가이고, 컴퓨터는 인간 사고양식을 명령으로 바꿔주는 존재. 도구가 인간을 흉내내 특정 작업별 코드 생성은 잘하지만, 근본적인 추상 설계와 빌드 역할까지는 대체 못함. 모델이 코드 작성만이 아니라 명세서 따라 전체 프로젝트를 아예 만드는 기능을 갖추면, 개발자의 역할 자체가 또 바뀌게 될 것

  • 항상 ‘무엇이 더 나은가’는 작업별로 다르다는 접근이 필요. LLM은 반복적이고 공식 위주의 일(CSS 문법 맞추기, 유명 라이브러리 호출법 같은 것)에선 이미 나보다 훨씬 잘함. 이런 ‘잡다한 이벤트’들이 예전엔 내 시간을 많이 잡아먹었는데, 이제는 거의 즉시 처리돼서 매우 만족

    • 근본적인 스타일링(기본적인 CSS 이상)에는 LLM 결과가 오히려 별로임. 효과 자체를 명확히 설명하기 어렵거나, 일이 미묘해지면 제일 중요한 결과를 못 내놓고 한가지 방식에만 막히는 경우가 허다함

    • 내가 잘 못하는 것(SQL)엔 LLM이 훨씬 좋지만, 내가 잘 아는 것(CSS)엔 오히려 못함. 기준이 명확히 드러나는 셈

    • “대부분의 개발자보다 낫다”는 말이랑, CSS를 못하기 때문에 LLM이 더 나아 보인다는 말에 공감. 사실 CSS를 싫어해서 안 배우고 억지로 쓰는 사람 많아서 생기는 오해. 회사가 진짜 CSS 전문가 고용 못하고 싸게 넘어가려 하면 그때 LLM이 대안, 진짜 잘 쓰는 사람 구할 여력이 있으면 LLM은 당연히 비교불가. 결국 LLM의 경쟁상대는 실력 없는 개발자라는 결론

    • 주요 언어나 정확히 모르는 영역엔 LLM의 자동완성이 큰 도움이 됨. 다만 ‘반사적으로 기억하는 능력’을 기르지 않고 LLM에만 의존하면, 이 도구가 추천한 것을 평가하는 역량 부족으로 부실한 해결책에 머무를 위험이 큼

  • ‘좋은 코드’를 걱정하는 사람들이 많아 기쁘지만, 실제로는 의미가 없을까봐 두려움. 소프트웨어 업계가 이미 비즈니스 세계에 잠식당한 지 오래고, 어느 순간부터 그랬는지조차 확실치 않음(빌 게이츠가 1976년 오픈레터 썼을 때부터였나?). 진짜 문제는 주주·경영진이 코드를 덜 신경 쓰고 이익만 오르면 됐다는 점. 개발자나 사용자의 문화적 저항이 없으면 이 구조는 계속될 듯

    • 개발자/사용자 문화적 저항이 없으면 끝이라는 말에 대해, 기업 중에도 좋은 코드 만드는 곳 많고 모두 엉망진창은 아니라는 점을 얘기하고 싶음. 문제는 코드 품질 문제가 아니라 자본주의적 비즈니스 목표에 동의하느냐는 윤리적 문제. 아름다운 소프트웨어와 현실 사이 균형이 가장 중요. 나도 개발자이자 창업자로서 오픈소스, 엔지니어링 좋아하지만 동시에 충분히 편안히 살고 싶음

    • 코드는 비즈니스 동력. 나쁜 코드는 나쁜 비즈니스로 귀결. 호스팅팀(물리 파이어월, vmware, 프로시 등)과, 퍼블릭 클라우드(QEMU, 넷필터, 단순 장비 등) 간 확연한 차이. 누가 누굴 잠식했는지, 미래는 아무도 예측못함

  • 어젯밤 o3와 씨름하느라 시간을 다 썼음. 평생 Dockerfile 만들어 본 적이 없어서, 차라리 o3에 GitHub 저장소를 입력해 자동으로 해결하게 두려 했는데, 결과물 디버깅에 몇 시간을 허비. 존재하지도 않는 무언가를 덧붙이고, 없는 걸 지우거나 뒤섞기 일쑤, python3와 python 차이같은 기본 개념도 혼동. 결국 빡쳐서 구글 독스 찾아보니 금방 정리. AI도 훌륭한 도구지만 만능은 아니고, 누군가는 꼭 ‘깨어 있어야’ 한다는 교훈

    • 팁: Claude나 Gemini를 써보길 추천. 코딩 태스크에선 훨씬 덜 헛소리함. 아니면 o3에 인터넷 검색 옵션을 켜서 온라인 문서 참고 능력을 높일 수 있음. 적응에 시간이 걸리니 마법사로 기대하면 안 되고, 쓰기까지 학습 곡선이 높은 점은 vim/emacs 같은 다른 개발 도구와도 닮음. 그리고 ChatGPT도 ‘지구본 버튼’을 누르면 인터넷 검색 활용도가 올라감

  • LLM·AI로 직원 업무 생산성을 올리는 회사는 번창, 직원을 아예 대체하려는 회사는 실패 예측. 단기적으로는 CEO/임원이 단기 실적에 만족하며 미래 성장을 갉아먹는 선택을 할지도 모름

    • 정답은 바로 그거. 프로그래머의 어시스턴트로 LLM을 쓰는 게 맞고, 완전 대체는 무리. 기술을 적당히 받아들이는 게 옳은 길

    • 직원 대체로 단기적 가치를 올려서 회사에 이득이 돌아갈 수도 있다는 아이디어는 꽤 흥미롭다고 생각. 즉, 중장기으론 회사에 해가 되지만, 임시로 주가가 오르는 일은 생길 수 있음

    • 코드 어시스턴트는 필수 공통 도구이자, 사람을 대체할 무기는 아님. 경쟁사도 같은 AI 구독 살 수 있는 시대, 사람을 대체할 수 없음

  • 현장 경험 공유 - 예전 개발자에서 이제는 관리자이지만 여전히 코드 작성. LLM 어시스턴트는 도움도 되지만 가끔 불편. 예상치 못한 코드 제안을 냅다 쏟아낼 때 의도와 다른 방향으로 나아가기도 하고, 검토하는 시간이 소모됨. 아마 설정 문제인데, 직접 명령어로 호출할 때만 보이도록 기본값을 바꾸고 싶음. 한 가지 확실한 건, LLM에게 전체 코드나 함수 작성은 맡겨도 반드시 본인 리뷰 과정을 거침

    • Zed 에디터엔 이런 ‘은은한 제안’ 모드 기능 있음 (자세히 보기). 모든 에디터가 이런 모드 제공했으면 함

    • 요즘 스타트업에서 여러 일 하다 보니 LLM이 만든 UI를 별로 좋아하지 않음. 빌딩 블록 같은 기초는 유용하지만, Claude로 긴 코드블록을 통째로 맡기면 내가 원하는 결과에 도달하기까지 수많은 재작업이 필요

답변달기
▲
redcrash0721 6일전  [-]

https://freederia.com ai과학자사이트처럼 공존관계를 유지할겁니다.

답변달기