나는 AI 의견 자체로 “Brilliant” 코드를 발명해 AI를 압도했다

Source: Dev.to

배경

나는 간단한 API 클라이언트를 설명하는 것으로 시작했고, 그 후 mixin을 실험하기 시작했다. 나는 ts-mixer보다 빠른 나만의 mixin 라이브러리를 만들고 싶었다. 벤치마크를 설정한 뒤, 몇 시간 동안 테스트에 지쳐 대형 언어 모델(LLM)에 도움을 청했다.

AI와의 실험

AI에게 구현을 가능한 한 빠르게 만들고, AI가 “내 일을 빼앗아 갈” 수 있도록 적절한 테스트와 벤치마크를 설정해 달라고 요청했다. 내가 빵을 사러 나간 사이 모델은 코드를 반복해서 수정했다. 성능은 향상됐지만, 일부 사양과 정확성을 포기하라고 제안했는데, 나는 이를 받아들일 수 없었다.

반복적인 시도에서 AI는 몇 가지 유사한 구현을 순환하며 내 메모를 무시하고 실수를 도입했다가 다시 고치는 식이었다. 결국 나는 AI를 포기하고 스스로 작업을 계속했으며, 추가적인 빵 없이도 많은 시간을 더 소비했다.

나만의 구현

다음 날 새로운 마음가짐으로 나는 단 40줄로 CompositeMap을 만들었고, 이는 매우 빠르다. 이 맵은 키 순서를 특별하게 취급한다: [A, B]는 [B, A]와 동일하지 않다. 기존 라이브러리와 복합 키에 대한 TC39 제안이 존재하지만, 내 요구에 충분히 빠르지는 않다.

작동 방식

• 각 객체는 증가하는 ID를 부여받는다.
• 모든 키는 비트마스크로 해시되어 조회가 매우 빠르고 순서에 민감하지 않다.
• 비트마스크 기법은 플래그 처리와 게임 개발에서 흔히 사용된다.
• 믹스인 수가 표준 정수의 32비트를 초과하면 구현이 BigInt으로 전환되며, 이는 다른 라이브러리보다 여전히 빠르다.
• 실제로 32개 이상의 믹스인 변형이 있는 경우는 드물기 때문에 이 솔루션은 대부분의 경우에 잘 작동한다.

소스 코드는 여기에서 확인할 수 있다:

AI에 대한 성찰

AI는 최종 코드를 “훌륭하다”며 “Performance Masterclass”라고 칭찬했지만, 스스로 해결책을 만들어내지는 못했다. 이는 과거 인간 작업을 학습한 AI가 아직 문서화되지 않은 진정으로 새로운 접근 방식을 발명할 수 없음을 보여준다.

• AI보다 더 나을 수 있나요? 예—인간의 창의성과 깊은 이해는 현재 LLM이 생산할 수 있는 것보다 여전히 뛰어나다.
• 코딩 능력이 대체될 수 있나요? LLM에 의존하지 않고 코딩할 수 없게 될 때만 대체 가능하다.
• LLM을 사용해 시간을 절약했나요? 이번 경우에는 아니다. 모델에 프롬프트를 주는 데 길고 힘든 세션이 필요했으며, 직접 코딩했으면 더 빨리 결과에 도달했을 것이다.

결론

AI가 점진적인 개선을 도울 수는 있지만, 획기적인 성능 향상은 여전히 인간의 통찰이 필요하다. 실험과 약간의 유머(밈)를 결합하면 이러한 “진지한” 주제도 더 흥미롭게 만들 수 있다.