39P by xguru 1달전 | favorite | 댓글 7개
  • 대규모 언어 모델(LLMs)은 이미지, 텍스트, 코드를 생성할 수 있게 되면서 창작 분야에서 큰 파장을 일으킴
  • 처음에는 사람의 손이 잘못 그려진 그림, 잘못된 사실을 말하는 등 웃긴 결과물이 많았지만, 점차 개선되고 있음
  • 이러한 모델들이 등장하기 전에는 기계가 창의적으로 생각할 수 없다는 것이 자동화에 대한 주된 반대 논리였으나, 이제 그 주장은 점점 약해지고 있음
  • 이제 어디로 가야할까?

Framework: 소프트웨어 개발 능력 수준

  • 소프트웨어 개발은 단순히 코드를 작성하는 것 이상임
  • 프로그래머의 이미지는 어두운 방에서 컴퓨터를 바라보며 열심히 코드를 타이핑하는 사람이지만, 실제로는 코드 작성보다 다른 작업에 더 많은 시간을 할애함
    • 비즈니스 사용자로부터 요구사항 수집
    • 요구사항을 코드로 모델링할 수 있도록 정제
    • 디자이너, 제품 관리자와 같은 팀원과 솔루션 시각화 및 계획 수립
    • 다른 개발자와 기술 설계 및 정제
    • 인프라 설정, 구성, 보일러플레이트 등
    • 실제 코드 작성
    • 디버깅, 타인의 코드 이해, 문서 작성 등
    • 프로덕션 배포
    • 프로덕션 이슈 대응
    • 그 외 많은 작업들
  • "AI가 개발자를 대체할 것이다"라는 말은 AI가 위의 모든 작업에 능숙해야 한다는 것을 의미함
  • 하지만 위 목록을 보면 이러한 작업 중 일부는 향후 자동화될 수도 있지만 아직은 자동화될 수 없는 것처럼 보임

자율주행 자동차의 자동화 수준 분류

  • 자율주행 자동차 분야는 자동화 수준을 분류하는 방법을 개발함
  • 이 분류는 현재 기술이 무엇을 할 수 있는지 명확하게 설명하고, 흑백논리를 피함
  • 이런 분류를 AI 기반 소프트웨어 개발에 대해 적용해 보면
    • 가장 낮은 단계는 이전에 우리가 가지고 있던 것, 즉 업무에 AI가 관여하지 않는 단계. 물론 컴파일러, 빌드 프로세스 등과 같은 다른 유형의 자동화가 있었지만 이는 AI가 아니라 사람이 작성한 결정론적 자동화에 해당
    • 그 다음 단계는 현재 우리가 가진 것
      • 개발자들이 ChatGPT 또는 GitHub Copilot을 사용하여 지원받는 것
      • 개발자들은 테스트 작성, 상용구 코드, 리팩토링, 코드/오류를 이해하기 위해 이를 사용
      • 채팅을 통해 동료 개발자와 대화하면서 질문하고 도움을 받을 수는 있지만 컴퓨터에 대한 액세스 권한이 없으므로 파일을 만들거나 빌드 명령을 실행하거나 프로덕션에 배포할 수는 없음
    • 가장 높은 단계는 프로젝트의 일부 또는 전체를 "AI 코더"에게 위임하는 것
      • AI 코더가 요구 사항을 받아 코드를 작성하고 오류를 수정한 후 최종 제품을 프로덕션에 배포
      • 아직 이런 일이 일어나기까지는 몇 달이 더 걸릴 것이라고 생각했지만, 지금은 간단한 개발 작업만 수행할 수 있지만 앞으로 개선될 가능성이 있다는 것이 Devin 데모를 통해 증명됨 Devin, 첫 번째 AI 소프트웨어 엔지니어
  • AI 모델의 능력 외에도 솔루션이 얼마나 정확한지 생각해봐야함
    • 이러한 모델은 환각에 취약하거나 원하는 것을 얻기 위해 특정 방식으로 프롬프트해야 하는 경향이 있음
    • 이로 인해 도입에 마찰이 발생하고 대부분의 사람들이 이 시점에서 AI 비서를 포기하게 됨
    • 하지만 이 역시 개선되고 있으며, 최신 모델에서는 이러한 수준의 프롬프트 엔지니어링이 필요하지 않음
  • 또한 모델은 학습 데이터에 의존하는 대신 웹을 탐색하여 '학습'할 수 있어야 함
    • 이는 새로운 버전의 라이브러리와 프로그래밍 언어가 도입됨에 따라 중요한 사항

Framework: 아웃소싱된 소프트웨어 개발

  • 이제 역량을 구축했으니 팀이나 조직 구조에 어떤 영향을 미칠까? 회사는 다양한 방식으로 소프트웨어 개발을 수행함:
    • 완전 인하우스
    • 소수의 벤더와 함께 대부분 인하우스
    • 다수의 벤더와 함께 조금만 인하우스
    • 완전 벤더
  • AI 코더를 아웃소싱된 소프트웨어 벤더/컨설턴트로 생각할 수 있음
  • 회사 내부 팀이 벤더의 작업을 감독하는 것이 중요함
    • 계약을 통해 이 문제를 해결할 수도 있지만, 계약은 일반적으로 특정 공급업체나 프로젝트에만 적용되며 이 방법으로는 장기적인 목표를 강제할 수 없음
    • 벤더를 안내할 수 있는 소규모의 사내 팀이라도 두는 것이 좋음
    • 마찬가지로, EC2 인스턴스처럼 AI 코더를 임대할 수 있는 경우에도 소프트웨어 개발자로 구성된 사내 팀이 작업을 감독하는 것이 유리

Framework: 소프트웨어 개발은 복잡성 모델링

  • 비즈니스 문제를 해결하는 것에 대해 이야기할 때, Excel을 예로 들 수 있음.
  • Excel은 진입장벽이 매우 낮아서 이걸로 데이터를 정리하고, 데이터 분석을 수행하거나, 일부 프로세스를 자동화 가능
  • 하지만, 세분화된 액세스 제어, 지원되지 않는 시스템과의 통합 기능, 테스트 가능성, 재사용성, 공급업체 종속성 등의 기능이 없기 때문에 복잡한 비즈니스 워크플로우에는 적합하지 않음
  • Power Automate 등과 같은 "로우 코드" 솔루션도 마찬가지
  • "비즈니스 사용자가 소프트웨어 개발자의 도움 없이 AI 코더를 사용하여 이러한 복잡한 워크플로우를 만들 수 있을까?"
  • 생각해 보면 Excel과 로우 코드 도구는 수십 년 동안 존재해 왔는데 소프트웨어 개발이라는 직업은 왜 여전히 존재할까?
  • 그것은 소프트웨어 개발을 단순히 코드를 작성하는 것으로 생각하기 때문
  • 복잡한 문제에는 이러한 복잡성을 효과적으로 관리하고 비즈니스 문제를 실제 도메인에서 디지털 모델로 변환할 수 있는 사람이 필요
  • 다시 말해, 토목 기술자의 도움 없이 유튜브 튜토리얼을 통해 나무 창고를 지을 수 있다고 해서 10층짜리 건물도 똑같이 지을 수 있고, 지어야 한다는 뜻은 아님
    • 이 일을 제대로 하는 방법을 배우다 보면 서서히 토목 기술자가 될 수 있음
    • 다만 제대로 배우기 위해 시간을 투자할 것인지, 아니면 숙련된 엔지니어를 고용할 것인지의 문제일 뿐
  • 따라서 Excel을 사용하든 최신 AI 코더를 사용하든, 복잡한 로직을 모델링하고 있다면 여전히 소프트웨어 개발자라고 생각
  • 다만 스프레드시트 수식, 코드, 프롬프트 등 비즈니스 요구 사항을 표현하는 도구가 다를 뿐

Framework: 파이의 크기

  • 이 주제를 둘러싼 대부분의 불안은 소프트웨어 개발 시장의 규모가 그대로 유지된다는 가정, 즉 AI 코더가 서서히 인간으로부터 '시장 점유율'을 빼앗아갈 것이라는 가정을 전제로 함
  • "비즈니스 문제 해결" 시장의 크기가 소프트웨어 개발보다 훨씬 크기 때문에 소프트웨어 개발이 곧 사라지지는 않을 것임

Framework: 형식적 비즈니스 논리 정의

  • 비즈니스 로직은 항상 명확한 형식으로 정의되어야 함
  • 그렇기 때문에 프로그래밍 언어는 'if', 'switch' 등과 같은 영어 단어를 사용하더라도 그 단어의 의미를 매우 엄격하게 정의하고 잘못된 단어를 사용하면 작동하지 않음. 생각해 보면 Excel 수식이나 로우 코드 흐름도 마찬가지
  • 미래에는 AI 코더가 대화형 영어로 주어진 명령어를 통해 소프트웨어 제품을 생성할 수 있다고 해도 백엔드에서 생성되는 비즈니스 로직에 대한 기본적인 공식 정의는 여전히 존재할 것이라고 생각
  • 오늘날 우리가 사용하는 언어나 프레임워크와는 매우 다르게 보일 수 있지만, 비즈니스 로직의 공식적인 정의는 '코드'와 매우 유사하게 들림
  • AI 코더가 이러한 비즈니스 로직을 결정론적인 방식으로 대화형 영어로 생성할 수 있을 때까지는 백엔드에서 생성된 코드를 이해하고 필요한 경우 변경할 수 있는 사람이 여전히 필요. 바로 소프트웨어 개발자

결론

  • 업무의 성격이 바뀌고 우리가 사용하는 도구가 지금과는 매우 달라지겠지만, 가까운 미래에도 소프트웨어 개발자를 위한 시장은 여전히 존재할 것이라고 생각

AI 프롬프트 중요성이 날로 부각되면서, 점점 더 명확한 스펙 정의와 요건 정리가 필수임을 각성하는 유저가 많아질것이고, 이것은 결국 향후 개발자가 작업하는데 유리한 방향으로 작용될 수 있을거 같네요.

"AI가 개발자를 대체할 것이다"라는 말은 AI가 위의 모든 작업에 능숙해야 한다는 것을 의미함

-> 사람이 하기 때문에 필요한 절차일 수 있고, 결국 저 절차들을 다 거쳤을 때, 나오는 코드라는 결과물은 특정한 패턴을 지닐 수 있다고 생각합니다. 마치 바둑에서도 포석이나 정석 같은 것이 필요하다고 생각했지만 그건 인간의 인지 영역 안에서 정보를 처리하기 위한 어쩔 수 없는 방법이었을 뿐이라는 게 밝혀졌듯이요.

OpenAI가 유명세를 타기 전까지만 해도 AI 도입이 가장 늦게 혹은 불가능하다고 여겼던 예술분유 부터 AI가 영역을 확장하는 것을 보면, 지금 '사람'만이 가능하다고 생각하는 것들이 '안전'하지 않을 수 있다는 생각이 문득 들었습니다.

본문과 https://news.hada.io/topic?id=13557 글 처럼
지금 개발자 파이는 분명 줄어들 것이고, 더 가속화 되겠죠?

코드는 사람을 위한 것이고, 기계가 코드를 작성한다는 건 사람이 여전히 필요하다는 것이니 먼 미래의 발전방향은 아니라고 생각합니다. 초기에 실험했던 backend-GPT (https://github.com/RootbeerComputer/backend-GPT) 처럼 일종의 블랙박스에 우리가 원하는 질문을 던져넣으면 DB 에 접근해서 데이터를 처리하고 그 앞뒤의 경험에는 사람이 일부 개입하는 형태로 발전할 거라고 봅니다.

chat GPT, Copilot 에 대해서 많이들 이야기 하는 부분중에 프롬프트 엔지니어링에 대해서 언급이 되는 것 같습니다. 우리가 주로 프로그래밍을 위해 회의를 하며, 말로써 빠르게 의사 전달을 하고 정리해서 확인하고 하는 과정들을 어떻게 AI 코더에게 효율적으로 전달하고 의사소통할 수 있는가도 중요한 요소라고 생각되네요 ^^.