최근 바이브 코딩이다 뭐다 난리였지만,
geeknews 같은 사이트에 올라오는 의견이나 저의 회사에서의 경험을 종합해 보자면
바이브 코딩으로 만들어진 코드를 프로덕션에서 본격적으로 쓴다는 것은 자살행위라는 것입니다.
상업 서비스에 직접적으로 사용할 수 없다는 것이 대체적으로 모여지는 결론입니다.
제 경험에 의하면 툴 개발 정도는 ai에게 온전히 맡길 수 있었고 작성한 코드의 버그를 찾는 데는 유용했습니다만,
서비스 로직을 온전히 AI 를 통해서 만들어서 상업서비스를 한다는 것은 현재로서는 너무 리스크가 큽니다. 거의 불가능하다고 봐야 할 것 같습니다.
AI가 만든 코드를 검증하는데도 시간이 많이 걸리므로 그럴 바엔 숙련된 개발자가 코드를 만들고 AI 에게 검토 및 버그 찾기만 시키는 식으로 현업이 돌아가는 추세입니다.
덕분에 시니어 개발자의 수명은 연장된 거 같네요.
여담인데, 제 생각에 LLM 기반으로 초지능은 구현이 안될 거 같습니다. LLM 트랜스포머 구조의 벽을 넘지 못하면 다시 AI의 긴 정체기가 올 가능성이 높습니다.
예전같았으면 개발자에게 맡길 것들을 디자이너인 제가 대체해서 비용을 정말 많이 줄였습니다.
그치만 앱서비스같은 댑스가 많은 서비스들은 엄두가 나지 않는 것 같습니다. 구조가 커질 수록 쓰기가 무섭더라고요.
그래서 오브젝트별로 스크립트를 최대한 분산해서 관리하고 연계되는 것들만 GPT에게 시켜서 수정합니다.
다른 방식을 찾아내거나 개선할 가능성은 없을까요?
아직, AI에서 AGI로도 안되었는데...
ASI로는 Beyond인 경향이라...
지금의 한계는 리펙토링이 어렵고 비즈니스 로직의 대폭의 변화가 있을 경우엔 새로 만드는게 더 빠르다는 것인데... 기존에 잘 돌아가던 부분이 새로운 것으로 대체 되었을때 API의 일관성이 다소 떨어지기 때문에 SaaS형태로 외부 서비스하기에는 아직 어려운것은 사실인듯 합니다.
거시적 서비스 구성은 현재 AI 에이전트를 병행해서 하는 것으로는 아직 어려운거 같고, 지금 당장으로 간단한 아이디어 서비스 같은 경우엔 이런 방법이 매우 널리 쓰이고 있더라구요.
지금 속도로 볼때.. 사람이 유지보수 하지 않는 대형 서비스 아키텍처가 곧 나오거나 시도 하는 사람이 있을거라 생각합니다.... 지금도 모델 자체의 역량이 부족하거나 LLM 의 한계때문에 해결이 안되는 문제들도 있지만 결국은 사람이 프롬프트를 잘 못 짜거나 모델에 대한 이해가 부족해서 활용을 못하는 부분이 더 크다고 보거든요.
설계안된다 도메인지식 기타등등이요ㅎㅎ
말씀하시는 보안문제나 qa 그런것들도 이미 oai에서 클로즈베타중입니다.
그리고 llm기반한 재귀개선이 가능한 논문들이 이미 출현중입니다
스스로를 진화시키는 llm이 나올거라서 시간문제일 뿐이고
만약 그렇다면 llm이 초지능의 시작이라고 볼 수도 있겠죠ㅎㅎ
그렇다고 해서 커즈와일이 얘기했듯 싱귤레리티가 과연 단시일에 올 것인가? 하면 그렇지는 않을 듯합니다.
인공지능은 아직 인간이 제시한 과업을 수행하는 도구입니다.
인공지능은 아직 욕망을 갖지 못하므로 의지도 갖을 수 없어 모든 면에서 인간을 대신해 결정할 입장은 안 될 것 같습니다.
하지만 일정한 기능, 특히 프로그래밍과 같은 작업은 일정한 패턴이 있고, 그 패턴이 고도화되면 전문적인 숙련자가 필요하겠지만, 하위 수준에서는 분명히 인간을 대체하고 있습니다. 아직까지는 모든 단계를 인공지능에 전적으로 맡길 처지가 아니겠지요.
프롬프트 하나로 코딩하는걸 상상한다면 당연히 불가능하겠지만 바이브 코딩 하시는 분들 이렇게 작업을 안합니다.
기능을 잘게 나누고 개별적으로 바이브 코딩 후 리팩토닝도 바이브로 진행을 합니다.
그리고 결합 역시 바이브로 진행을 하구요.
그럼 전체 코드 기준으로 봤을때 개발자는 실제로 코딩 거의 없이 상업용에서 사용 가능한 코드 생성이 가능합니다.
암튼, 결론적으로는 가능합니다.
트랜스포머 모델과는 방식이 다른 모델이 나와야 하는데 그게 단시일에 이루어지긴 힘들어 보입니다.
일단 인공지능은 "속도" 면에서 인간을 초월했어요. 결과물에서 항상 인간을 초월하지는 못하더라도, "속도" 그 자체는 매우 중요한 요소라고 봅니다.
그 효율이 몇십명까지는 힘들 것 같아요.
상업 프로그램에 쓰려면 그 시니어가 문제없는지 리뷰를 꼼꼼하게 해야되는데
리뷰하는게 시간이 적게 든다고 해도 몇명분 이상이 되면 감당이 안될것같네요.
그러니까 주니어들을 계속 뽑아서 키워야 한다 (?)
--
두번째 줄을 회사가 과연 해줄지 의문입니다
전 결국 믿게 될거라고 봅니다.
제가 시니어이고 젊은 개발자들이 10명정도 되는 조직인데요. 2년짜리 과제를 4개월로 줄이는 계기가 되었습니다.
전혀 개발해 본 적 없는 낯선 비전 AI(객체인식, 얼굴인식 등...) 개발을 수행하는 과제에서 코드 에이전트가 톡톡히 역할을 했습니다. YOLO 모델, SAM2, Re-ID 같은 모델을 불러와서 붙이고 최적화 하는데 꽤 빠른 속도를 보여 주었죠. 물론 시행착오는 꽤 거쳤지만 그래봐야 두세달 정도였구요. 디테일한 알고리즘을 개발한다기 보다는 전체적인 워크플로우, 파이프라인 개발 및 구성, 동작 속도 최적화에 좀 집중되어 있었습니다.
개발이 성공적이었던 주요 요인 가운데 세밀한 테스트 시나리오 및 코드에 대한 다양한 구조적 모순이나 결함을 검출해 내는 프롬프트 였습니다. 시스템 설계가 자동화 되면 될 수록 개발자가 할 일은 시나리오 및 테스트에 대한 검증이 될거 같습니다.
요즘은 200억개의 트렌지스터가 박혀 있는 프로세서가 탑재된 컴퓨터를 사용하는 세상입니다. 반도체 설계 또한 많은 영역이 자동 설계를 할 수 밖에 없습니다. 복잡도가 매우 높거든요. 그런데 자동설계 툴을 썼다고 CPU 쓰기가 너무 겁다다는 얘기는 들어본 적이 없을겁니다. 그 고민을 할 시기가 한참 전에 지났기 때문입니다.
소프트웨어 개발도 과도기를 거치고 나면, 테스트 자동화 기술 또한 높은 퀄리티로 제공 될거라서 동작 검증 및 안정성 평가가 끝난 소프트웨어는 사람이 개발한 소프트웨어 보다 좀 더 적은 버그를 내포한 채로 잘 사용될 것 같습니다.
AI로 짤렸던 시니어를 다시 급하게 구하고 있는 시기임.
이미 현재입니다. 어느정도 대체할건지의 문제죠. 그리고 시간이 갈수록 그 %는 더 높아질거고..
가장 최신의 ai는 연구하는 AI랩들의 수장들은 전부 AGI가 언제 올거냐의 문제지 오냐 안오야는 이미 문제가 아닙니다.
저희는 프로덕션에서 너무 잘 쓰고 있습니다.
모르는 영역에 대해서는 주변분들에게 도움을 받고 이해한 다음에 진행하면 되구요.
결국 도메인지식이 어느정도 갖춰진 상태에서 AI 를 이용한다면 꽤 괜찮은 물건 만들 수 있습니다.
대체되는건 저도 확언할 수 없지만, 오히려 더 많은 제품들이 더 짧은시간에 튀어나올겁니다.