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

• 글 작성자는 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은 아이디어 검증 및 지적 대화자('스마트 오리' 역할) 로써 매우 유용
• 그러나 최종 창의적 솔루션 도출 능력에서는 인간의 우위가 명확함