링크드인 실험실 LLM 한계와 개발자 역할

Share

링크드인은 실험실: LLM의 한계와 가능성, 그리고 개발자의 역할

링크드인이 과거 트위터의 역할을 넘어, IT 업계의 뜨거운 감자들이 격돌하는 새로운 실험실로 변모하고 있습니다. 생성형 AI에 대한 과도한 자신감부터 회의적인 시각까지, 다양한 의견이 오가며 기술의 발전 방향을 논하는 장이 된 것이죠. 최근 링크드인에서 벌어진 논쟁을 통해, LLM(대형 언어 모델)의 현실적인 능력과 한계, 그리고 개발자의 역할에 대해 깊이 생각해 볼 필요가 있습니다.

에이전트형 개발, 꿈과 현실 사이

최근 링크드인에서는 에이전트형 개발에 대한 뜨거운 논쟁이 있었습니다. 한 개발자가 생성형 AI만으로 iOS나 안드로이드 수준의 운영체제를 만들겠다는 과감한 주장을 펼쳤죠. 물론 이러한 시도는 혁신적인 아이디어에서 출발했지만, 현실적인 어려움이 존재합니다. LLM이 아무리 발전했더라도, 복잡한 운영체제 개발에는 수많은 장애물이 도사리고 있기 때문입니다.

LLM, 풀 리퀘스트 자동 생성의 허와 실

LLM이 사람보다 더 많은 풀 리퀘스트(PR)를 생성하고, 승인율도 높다는 주장이 제기되기도 했습니다. 하지만 실제 사례를 살펴보면, 대부분 개인 프로젝트에서 생성형 AI가 생성한 PR을 YOLO(You Only Look Once) 방식으로 무조건 승인한 경우가 많았습니다. 불필요한 문서화나 사소한 수정 사항이 대부분이었고, 코드 품질 자체는 그다지 높지 않았죠. LLM을 활용하는 것은 긍정적이지만, 맹목적인 수용은 경계해야 합니다.

LLM 기반 개발 도구, 불편함과의 싸움

현재 LLM 기반 개발 도구는 분명 유용하지만, 동시에 여러 가지 제약과 불편함이 존재합니다. 그래서 필자는 직접 패치 시스템을 만들기로 결심했습니다. LLM이 스스로 생성한 패치를 받아들이는 시스템을 구축하려 했지만, 생각보다 훨씬 복잡한 문제에 직면했죠. 디프(diff)와 패치(patch)의 복잡성, 정제되지 않은 패치를 처리해야 하는 어려움, 다양한 모델을 지원해야 하는 난관 등 해결해야 할 과제가 산더미였습니다. 결국 직접 개발을 포기하고, 이미 잘 만들어진 시스템을 벤치마킹하기로 방향을 틀었습니다.

성공적인 패치 시스템: 에이더 AI 벤치마킹

여러 시행착오 끝에, 에이더 AI의 패치 시스템이 가장 뛰어난 성능을 보였습니다. 에이더는 최신 기술이나 도구 호출 없이, 거의 수작업으로 만든 파이썬 코드를 사용하고 있었습니다. 필자는 에이더의 시스템을 타입스크립트로 포팅하여 VS Code 플러그인에 적용하기로 결정했습니다. 또한, 오픈AI의 o3와 앤트로픽의 클로드 오퍼스 4에게 서로의 계획을 평가하게 하는 실험도 진행했습니다. 결과는 참담했지만, LLM의 장단점을 파악하는 데 도움이 되었습니다.

LLM 활용, 어디까지 가능할까?

결국 타입스크립트용 패치 시스템은 클로드에게 에이더 구현의 주석을 옮기게 하고, 테스트 코드 형태로 메인 메서드를 작성하게 한 후, 하나씩 포팅하는 방식으로 완성했습니다. 이 과정은 결코 '바이브 코딩'과는 거리가 멀었고, 오히려 직접 코딩하는 것보다 시간이 더 오래 걸렸습니다. LLM은 CRUD 웹앱 코드처럼 대량의 학습 데이터가 있는 분야에서는 뛰어난 성능을 보이지만, 알고리즘 설계처럼 깊이 있는 영역에서는 한계가 분명합니다.

LLM의 한계, 연구 결과도 뒷받침

이러한 분석은 개인적인 경험에만 국한되지 않습니다. 여러 연구 결과에서도 LLM은 널리 알려진 템플릿을 조합할 수 없는 중간 및 고난도 문제에서는 실패하며, 문제의 길이가 길어질수록 성능이 급격히 저하된다는 사실이 밝혀졌습니다. LLM은 문제를 작은 단위로 쪼개고, 모델이 전체 맥락을 이해하지 않고도 특정 설계에 맞춰 작업하도록 유도하는 방식으로 활용하는 것이 효과적입니다.

과대광고를 경계하고, LLM을 현명하게 활용해야

LLM은 분명 유용한 도구이지만, 완전한 자율형 에이전트가 실제 서비스 수준의 코드를 작성하는 단계에는 아직 도달하지 못했습니다. LLM은 반복적이고, 이미 널리 이해된 소프트웨어 개발 영역에서 가장 뛰어난 성능을 보입니다. 새로운 개념이나 고유한 알고리즘 설계에는 실패할 가능성이 높죠. 하지만 그렇다고 해서 LLM을 완전히 무시할 필요는 없습니다. CSS와 HTML, CRUD 코드처럼 반복적인 작업은 LLM에게 맡기고, 개발자는 더욱 창의적인 작업에 집중할 수 있습니다.

맺음말

LLM은 분명 개발 생산성을 향상시키는 강력한 도구입니다. 하지만 과도한 기대는 금물입니다. LLM의 한계를 명확히 인식하고, 적절한 수준에서 활용해야 진정한 시너지 효과를 얻을 수 있습니다. 결국, 핵심은 개발자의 숙련된 지식과 끊임없는 노력이 뒷받침되어야 한다는 것입니다.

이것도 좋아하실 수 있습니다...