AI 코딩의 숨겨진 비용

• AI 코딩 도구 사용이 생산성은 높이지만, 개발자들이 느끼던 몰입과 창조의 기쁨은 줄어드는 현상에 대한 우려를 제기함
• 과거 ‘몰입(flow)’ 상태에서의 코딩 경험이 개발자들에게 큰 만족감을 주었음
• 현재는 AI가 코드 생성을 대신하며, 개발자는 설명하고 평가하는 ‘큐레이터’ 역할에 머무는 경우가 많음
• 이러한 변화로 인해 장기적인 행복감과 직업 만족도 하락 가능성이 제기됨
• 해결책으로는 의도적으로 ‘직접 코딩’의 공간을 남겨두는 노력과 새로운 형태의 만족감 찾기가 필요함

코딩의 즐거움은 어디로 갔을까

• 작성자는 AI 기술의 발전과 긍정적인 측면을 인정하면서도, 개발자로서의 즐거움이 사라지고 있음을 고백함
• 과거에는 헤드폰을 끼고 네오빔을 켜고, 시간 가는 줄 모르고 몰입하던 코딩의 순간들이 있었음
• 단순한 효율이나 보상이 아니라, 문제를 해결하며 무언가를 만들어내는 경험 자체가 본질적인 동기였음

심리학에서 말하는 ‘몰입(flow)’의 가치

• 심리학자 Mihaly Csikszentmihalyi의 이론에 따르면, 몰입 상태는 도전과 기술이 적절히 균형 잡힌 순간에 발생
• 개발자에게 이 몰입은 코드와 하나 되는 순간, 문제가 퍼즐처럼 느껴지고, 시간 감각이 사라지는 경험으로 나타남
• 이런 순간들은 단순한 작업이 아니라, 창조성과 직업적 행복감의 핵심임

AI 도구가 바꾼 개발자의 역할

• 현재는 AI 기반 코딩 도구(Copilot, Cursor 등) 덕분에 직접 작성하지 않아도 많은 코드가 생성 가능
• 개발자는 이제 프롬프트 작성, AI 결과 검토, 약간의 수정에 집중하게 됨
• 이로 인해, 과거의 몰입 경험과 창작의 기쁨이 줄어들고 있음
• AI 사용은 생산성은 향상되지만, 그 과정은 더 수동적이고 감정적으로 거리감 있는 경험이 될 수 있음

진짜 걱정: 몰입이 사라진다면?

• 생산성은 향상되지만, 기쁨은 감소하는 이중적 현상은 장기적으로 개발자 만족도에 영향을 줄 수 있음
• 코딩 과정에서의 도전, 창의적 해결, 직접 작성의 성취감이 사라지면, 일 자체의 의미도 흐려질 수 있음
• "프롬프트 엔지니어링"이 새로운 몰입의 대상이 될 수 있을까? 에 대한 의문도 제기됨

새로운 몰입의 방식 찾기

• 미래에는 직접 코딩보다 시스템 설계, 제품 아이디어 구상 등에서 만족감을 찾게 될 수도 있음
• 또는, 의도적으로 비효율적인 ‘손코딩’의 시간을 확보함으로써 몰입 공간을 유지할 수도 있음
• 중요한 것은, AI 시대에도 개발자로서의 행복과 몰입을 지키기 위한 의식적인 선택이 필요하다는 것

https://terriblesoftware.org/2025/04/23/the-hidden-cost-of-ai-coding/

The Hidden Cost of AI Coding

AI 시대의 기술 위축을 피하는 방법

최고의 미래 개발자는, 오늘날의 AI로 인해, 스스로 생각하는 법을 잊지 않은 사람이 될 것임

https://addyo.substack.com/p/avoiding-skill-atrophy-in-the-age

• AI 도구로 인한 생산성 증가는 개발자들의 핵심 기술 쇠퇴(skill atrophy) 위험을 초래함
• AI를 과도하게 의존하면 비판적 사고와 문제 해결 능력이 점점 약화됨
• 디버깅, 아키텍처 설계, 기억력 등 중요한 기술이 점차 퇴화할 수 있음
• AI를 도구로 삼되, 스스로 사고하고 학습하는 습관을 반드시 유지해야 함
• AI와 협력하는 방식으로 사용하면, 생산성과 기술 숙련도를 모두 향상시킬 수 있음

AI 시대에 기술 쇠퇴를 피하는 방법

• 코딩 분야에서 AI 도우미의 부상은 생산성 향상과 함께 기술 쇠퇴(skill atrophy) 위험을 초래함
  • 기술 쇠퇴는 사용 부족이나 연습 부재로 인해 시간이 지남에 따라 기술이 약화되는 현상을 의미함
• 반복적 작업을 AI에 맡기는 것은 유익할 수 있지만, 과도하면 핵심 능력 상실로 이어질 수 있음
• 인지적 오프로드(cognitive offloading) 현상으로 인해, 문서나 튜토리얼을 스스로 학습하는 대신 AI에 의존하는 경향이 강해짐
• 예를 들어, GPS 사용이 길 찾기 능력을 약화시킨 것처럼, AI 자동완성과 코드 생성 기능이 사고력을 저하시킬 수 있음
• AI가 보일러플레이트 코드를 처리해줌으로써 대규모 프로젝트에 도전할 수 있는 기회가 생겼지만, 자동화와 기술 쇠퇴 사이 경계 설정이 중요함

비판적 사고가 희생양이 되고 있는가?

• Microsoft와 Carnegie Mellon 연구팀의 2025년 연구에 따르면, AI 의존도가 높을수록 비판적 사고 감소 현상이 발생함
• AI에 대한 과신은 사람들이 스스로 사고하는 대신 자동 조종 상태로 전환하게 만듦
• 쉬운 작업일수록 더욱 경계를 풀게 되고, 이로 인해 장기적인 독립 문제 해결 능력 감소가 초래됨
• AI 도움을 받는 작업자는 동일 문제에 대해 덜 다양한 해결책을 제시하는 경향이 있으며, 이는 사고력 균질화로 이어짐
• 연구진은 이를 비판적 사고의 저하로 정의함
• 비판적 사고를 저해하는 장벽들
  • 인지적 장벽: 반복적인 작업일수록 AI에 과도하게 의존하는 경향
  • 동기적 장벽: 시간 압박이나 직무 범위 제약으로 깊은 사고를 회피하게 됨
  • 능력적 장벽: AI의 답변을 스스로 검증하거나 개선하는 데 어려움을 느낌
• 한 엔지니어는 12년 경력에도 불구하고 AI의 즉각적 도움으로 인해 스스로를 더 못하는 개발자로 느끼게 되었음을 고백함
  • 문서 읽기 중단: LLM이 즉각 설명해주기 때문에 공식 문서를 읽을 필요성을 느끼지 않음
  • 디버깅 능력 감소: 스택 트레이스나 에러 메시지를 직접 분석하는 대신 AI에 복붙하여 해결하려 함
  • 깊이 있는 이해 상실: 문제를 진정으로 이해하려는 노력 없이 AI 제안만 반복 적용하게 됨
  • 감정적 반응 변화: 과거에는 버그를 해결하는 데서 얻던 기쁨이, 이제는 AI가 5분 안에 답을 못 주면 좌절로 바뀜
• LLM에게 사고를 위탁하면서, 개발자는 장기적 숙련도를 잃고 단기적 편리성을 얻는 교환을 하게 됨"우리는 AI 덕분에 10배 개발자가 된 것이 아니라, AI에 10배 더 의존하게 된 것"
  "우리가 스스로 해결할 수 있는 문제를 AI가 해결하도록 할 때마다, 우리는 장기적인 이해를 단기적인 생산성으로 바꾸고 있음"

기술 쇠퇴의 미묘한 징후들

• AI 의존이 단순한 가설이 아니라 실제로 개발 기술의 약화로 이어질 수 있음
• 몇 가지 뚜렷한 징후를 통해 자신의 기술 쇠퇴 여부를 점검할 수 있음
• 디버깅 포기 현상
  • 에러가 발생할 때 디버거를 사용하거나 스택 트레이스를 직접 읽지 않고, 바로 AI에 의존하는 경향
  • 과거에는 버그를 직접 분석하고 해결하면서 성장했지만, 이제는 그 과정을 AI에 전가하는 경우가 많아짐
  • AI가 해결하지 못하거나 사용할 수 없는 상황에서는, 기본적인 문제 진단조차 어려운 상태에 빠질 위험이 있음
• 이해 없이 복붙하는 코딩
  • 보일러플레이트 코드를 AI가 작성하는 것은 괜찮지만, 왜 그렇게 동작하는지 이해하지 못한 채 복사하여 사용하는 경우 문제 발생
  • 특히 젊은 개발자들은 AI 덕분에 빠르게 코드를 작성하지만, 그 선택의 이유나 예외 처리 방식을 설명하지 못하는 경우가 많음
  • 다양한 대안을 고민하는 과정이 사라지면서 기초적인 사고 훈련이 결여됨
• 아키텍처 및 시스템적 사고력 약화
  • 복잡한 시스템 설계는 단일 프롬프트로 해결할 수 없음
  • 작은 문제를 AI로 해결하는 데 익숙해지면, 고차원적 설계 작업에 대한 두려움이나 회피가 생길 수 있음
  • AI는 특정 컴포넌트나 패턴을 제안할 수 있지만, 성능, 보안, 유지보수성 등 전체 맥락을 이해하는 것은 개발자 본인의 몫임
  • 시스템 수준 사고력을 사용하지 않으면 점차 약화됨
• 기억력 및 회상력 감소
  • 자주 쓰는 API 호출이나 언어 문법조차 기억이 흐려질 수 있음
  • AI 자동완성 기능에 익숙해지면서, 스스로 코드를 작성하는 능력이 약화됨
  • 이는 수학 계산기를 지나치게 의존하는 학생처럼, 기본 계산 능력 상실에 비유할 수 있음
• 시간이 흐름에 따라 일부 기술이 자연스럽게 사라지는 것은 정상적인 현상임
  • 예를 들어, 어셈블리어로 메모리를 직접 관리하거나, 손으로 긴 나눗셈을 하는 능력은 더 이상 필수적이지 않음
  • 하지만 어떤 기술은 유지해야 하고, 어떤 기술은 버려도 되는지 구분하는 것이 중요함
  • 긴급 상황에서 디버깅할 수 있는 능력은 여전히 필수 기술로 간주해야 함
  속도와 지식의 트레이드오프:
  AI는 빠른 답을 제공하지만 (높은 속도, 낮은 학습),
  전통적인 방법(Stack Overflow, 공식 문서)은 느리지만 깊은 이해를 구축해줌
• 즉각적 답변을 좇다가, 진정한 전문가로 성장하는 데 필요한 맥락 이해와 깊이를 놓칠 위험이 있음

AI 과의존의 장기적 위험

• AI 도구에 대한 과도한 의존이 통제되지 않을 경우, 경력상 비판적 사고 위기에 직면할 가능성이 있음
• AI가 대부분의 사고 과정을 대신하게 되면, 도구가 실패하거나 해결하지 못하는 문제에 대해 스스로 대응할 능력을 잃게 됨"AI를 많이 쓸수록 뇌를 덜 쓰게 됩니다. 그러면 AI가 해결할 수 없는 문제에 부딪혔을 때, 당신은 스스로 해결할 수 있는 기술이 있을까요?"
• 실제로 AI 코딩 도우미 장애로 개발자들의 워크플로우가 완전히 멈춘 사례도 발생함
• 자기 실현적 예언(Self-Fulfilling Prophecy)
  • Microsoft 연구팀은 AI에 의한 직업 상실을 걱정하면서도 "무비판적(uncritically)으로 AI를 사용"할 경우, 스스로 경쟁력을 잃게 될 수 있음을 경고함
  • 특히 신입 개발자들은 "어려운 길"을 건너뛰고 빠른 생산성에만 집중하여, 심화 학습 없이 조기에 성장 정체에 빠질 위험이 있음
  • 결과적으로, 스스로 문제를 해결하는 기쁨이나 깊은 이해를 경험해보지 못한 버튼 누르는 인력(button-pushers) 집단이 생겨날 수 있음
  • 이들은 AI에게 질문하는 방법은 능숙할지 몰라도, 정답을 진정으로 이해하지 못하는 상황에 빠질 수 있음
  • AI가 사소하게 틀렸을 때 그 오류를 발견하지 못하고, 버그나 보안 취약점이 코드에 섞여 들어가는 문제도 발생할 수 있음
• 팀 문화와 조직 역동성
  • 모든 개발자가 AI 도우미만 사용하게 되면, 멘토십과 비공식적 학습(osmosis learning) 이 약화될 수 있음
  • 주니어 개발자들이 동료 대신 AI에 의존하면, 시니어 개발자들이 지식을 전수하기 어려워짐
  • 기초가 약한 주니어들이 많아질 경우, 시니어들은 AI가 만들어낸 오류를 고치는 데 시간을 소모하게 됨
  • 결국 팀은 개별 구성원이 AI에 의존하는 집합체로 전락할 수 있으며, 비판적 리뷰나 공동 품질 유지 문화가 사라질 수 있음
  • 버스 팩터(bus factor) 에 사실상 "AI 서비스 장애"도 포함이 가능함
    • "프로젝트가 무너지려면 몇 명이 버스에 치여야 할까?"
• 아날로그 방식으로 돌아가자는 것이 아니라, AI를 신중하게 사용해야 한다는 경고임
  • AI를 활용하면서도, 작업 그 자체뿐 아니라 사고력 자체까지 아웃소싱하지 않도록 주의해야 함
  • 목표는 AI의 혜택을 최대한 누리되, 동시에 자기 자신의 기술과 사고력을 견고히 유지하는 것임

AI를 목발이 아닌 협력자로 사용하기

• AI 코딩 도우미의 생산성 향상을 누리면서도, 사고력과 기술을 유지하기 위해서는 의식적인 사용 습관이 필요함
• AI를 전능한 답변자가 아니라, 주니어 페어 프로그래머나 러버덕 디버깅 파트너처럼 대해야 함
• 다음은 고려해봐야할 구체적 실천 전략들
• "AI hygiene(위생)" 실천 – 항상 검증하고 이해하기
  • AI의 결과물이 그럴듯해 보여도 무조건 신뢰하지 않고 검증하는 습관을 들여야 함
  • AI가 생성한 함수나 코드에 대해 의도적 테스트를 수행하고, 엣지 케이스를 찾아야 함
  • "왜 이 솔루션이 작동하는가?", "한계는 무엇인가?"를 스스로 질문함
  • AI에게 코드를 줄 단위로 설명하거나 대안 접근법을 요청해 학습에 활용함
  • AI의 답변을 심문하면 수동적인 답변을 능동적인 교훈으로 바꿀 수 있음
• 기본기 훈련 – 때로는 고생도 필요함
  • 매주 일정 시간을 "AI 없는 코딩시간" 으로 설정하여 순수한 수작업으로 문제를 해결하는 시간 확보
  • 경험 많은 개발자들은 "No-AI Day" 를 지정하여 직접 코드 작성, 에러 분석, 문서 검색을 실천함
  • 초기에는 느리고 답답하지만, 시간이 지나면서 자신감과 깊이 있는 이해를 회복할 수 있음
  • AI 없이 꾸준히 코딩하면 기본 실력이 엔트로피로 떨어지는 것을 방지할 수 있음
  • 이는 개발자 두뇌를 위한 크로스 트레이닝과 같음
• AI한테 묻기전에 문제에 스스로 먼저 도전하기
  • 문제를 접했을 때 곧바로 AI에 묻지 않고, 먼저 접근 방법을 고민함
  • 최소한 의사 코드(pseudocode) 나 간단한 아이디어라도 스스로 세워본 후 AI를 활용함
  • 버그가 발생하면 최소 15~30분 정도는 스스로 디버깅해보는 시간을 갖기
  • 이러면 문제 해결 능력을 키울 수 있으며, AI 답변과 자신의 접근법을 비교하며 능동적으로 학습이 가능
• AI를 사용하여 코드 검토를 대체하는 것이 아니라 증강하기
  • AI가 생성한 코드도 인간 동료가 작성한 것처럼 철저히 리뷰함
  • 가능하다면 AI 코드에 대해 인간 코드 리뷰를 병행하여 팀 차원의 품질을 유지함
  • 이를 통해 팀 지식을 루프에 유지하고, AI를 신뢰할 때 단독 개발자가 놓칠 수 있는 문제를 포착함
  • 이는 "AI가 초안을 만들 수는 있지만, 우리가 코드를 소유한다"는 태도를 장려
  • 누가 작성했는지에 관계없이 팀이 저장소에 있는 모든 코드를 이해하고 유지관리 할 책임이 있음
• 능동적 학습 – 후속 질문과 반복 학습
  • AI가 제시한 솔루션이 잘 작동해도, 그 자리에서 학습을 강화하는 시간을 가짐
  • 복잡한 정규 표현식이나 알고리듬을 AI로 작성한 경우, 그 구조를 스스로 설명하거나, AI에 왜 이 방법을 썼는지 질문함
  • AI를 단순 답변 제공자가 아니라, 무한 인내심을 가진 튜터처럼 대화형으로 활용함
    • ChatGPT가 생성한 코드에 대해 "왜 이 방법은 안 돼?" 라고 묻기
  • 이렇게 하면 AI는 단순한 코드 배포자가 아닌 멘토가 됨
• 학습 일지 및 "AI 어시스트" 목록을 기록하기
  • AI에 반복적으로 묻는 주제를 기록하여 지식 공백을 파악함
  • 예를 들어, CSS에서 div 정렬이나 SQL 쿼리 최적화를 반복해서 묻는다면, 해당 주제를 집중 학습함
  • 플래시카드나 짧은 연습 문제를 만들어 반복 학습하여 장기 기억으로 전환함
  • 다음에 비슷한 문제에 직면하게 되면 AI 없이 문제를 풀어보고 그 방법을 기억하는지 확인해 볼 것
  • AI를 첫 번째 해결책이 아닌, 마지막 안전망으로 사용하는 태도를 유지함
• AI와 페어 프로그래밍하기
  • AI를 질문 처리 API처럼 대하는 대신, 페어 프로그래밍 파트너처럼 대화함
  • 예를 들어, 내가 함수 초안을 작성하고 AI에게 개선점을 제안받거나, 반대로 AI가 초안을 작성하면 내가 수정함
  • 대화 예시: "이 함수는 작동하는데, 더 명확하게 리팩토링할 방법이 있을까?"
  • 이렇게 하면 당신이 운전석에 앉아있게 함. 단순히 답변을 소비하는게 아니라, AI가 기여할 수 있도록 큐레이션하고 지시
  • AI를 감독이 필요한 주니어 개발자로 취급하고, 최종 책임자는 인간 개발자임을 명확히 함
• 이런 습관을 통해 AI 사용은 순수한 이득이 되며, 스스로의 능력도 잃지 않게 됨
• 실제로 AI를 활용하여 생소한 코드를 설명하거나, 복잡한 케이스로 AI를 시험하는 과정은 개인 기술 향상에도 매우 유익함
• 예를 들어, AI를 사용하여 익숙하지 않은 코드를 설명하면 지식을 심화할 수 있고, 까다로운 사례로 AI를 당황하게 만들면 테스트 사고방식을 향상시킬 수 있음
• 핵심은 수동적 소비자가 아니라 능동적 사용자로 남는 것임

결론: 날카로움을 유지하기

• 소프트웨어 산업은 AI 기반 코드 생성의 시대를 향해 가속 중이며, 이제 되돌릴 수 없는 흐름이 됨
• 이러한 도구를 받아들이는 것은 불가피할 뿐만 아니라, 대체로 이득이 되는 일임
• 그러나 AI를 워크플로우에 통합하면서, 각자 기계에게 양보할 것과 스스로 유지해야 할 것 사이에서 신중한 선택이 필요함

• 코딩을 사랑한다면, 단순히 빠르게 기능을 출시하는 것뿐 아니라, 문제를 해결하는 장인정신과 즐거움도 유지해야 함

• AI를 능력 증폭기(amplifier) 로 활용하되, 대체자(replacement) 로 만들지 말아야 함
• AI가 반복 작업을 대신할 수 있도록 하고, 그 freed-up 시간을 창의적이고 복잡한 작업에 투자함
• 그러나 기초 기술이 퇴화하지 않도록 주의해야 하며, 항상 "어떻게"와 "왜"를 탐구하는 호기심을 유지해야 함
• 디버깅 본능과 시스템 사고력을 계속 갈고닦아야 하며, AI가 제시하는 지름길만 탐색해서는 안 됨
• "간단히 말해서, AI를 당신의 목발이 아닌 협력자로 삼을 것"

• 성공하는 개발자는 인간적 직관과 경험을 AI의 초능력과 조화롭게 결합할 줄 아는 사람일 것임
  • autopilot이 있거나/없거나 상관없이 코드베이스를 탐색할 줄 아는
• 자기주도적 연습과 도전을 통해, fancy한 도구가 실패하거나 새로운 문제에 직면해도 스스로 문제를 해결할 수 있어야 함
• "AI가 당신을 대체할까봐 걱정하지 말고, 당신을 대체 불가능하게 만드는 기술을 키우지 않는 것에 대해 걱정할 것"
• "AI가 제공하는 답변을, 엔지니어의 마음으로 이해해야 한다"는 원칙을 항상 지키면, AI 열풍에 타면서도 쓸려가지 않을 것

• 보너스
  • 다음에 AI가 기능 전체를 코딩해줄 때 유혹을 느낀다면, 스스로 직접 일부를 작성해보라는 신호로 받아들여야 함
  • 놀랍게도 많은 것을 기억하고 있고, 다시 직접 손으로 코딩하는 기쁨을 느낄 수 있음
  • AI를 생산성 향상의 도구로 삼되, 능동적으로 기술을 연마하는 습관을 절대 멈추지 말아야 함

최고의 미래 개발자는, 오늘날의 AI로 인해, 스스로 생각하는 법을 잊지 않은 사람이 될 것임

오픈소스 이니셔티브(OSI)는 AI 시스템이 진정한 오픈소스 AI인지 판단하기 위한 참조 기준을 제공한다고 밝혔다.
 
OSI가 오픈소스 AI 시스템을 정확히 정의하는 표준을 만들기 위해 1년 동안 진행한 글로벌 커뮤니티 이니셔티브의 결과를 지난 28일 발표했다.

노스캐롤라이나주 롤리에서 열린 ‘올 씽스 오픈(All Things Open) 2024’ 컨퍼런스에서 OSI는 ‘오픈소스 AI 정의(OSAID) 버전 1.0’를 공개하며 “오픈소스 정의가 소프트웨어 생태계에서 해왔던 것처럼 허가가 필요 없고, 실용적이며 단순화된 협업을 재창조할 수 있는 원칙을 AI 실무자를 위해 확립하는 프로젝트의 첫 번째 안정 버전”이라고 밝혔다.

마이크로소프트(Microsoft), 구글(Google), 아마존(Amazon), 메타(Meta), 인텔(Intel), 삼성(Samsung) 등 기업의 리더와 모질라 재단(Mozilla Foundation), 리눅스 재단(Linux Foundation), 아파치 소프트웨어 재단(Apache Software Foundation), UN 국제전기통신연합을 포함한 25개 이상의 조직이 공동 설계 과정에 참여한 이 문서는 이미 전 세계 조직으로부터 지지를 받고 있다.

스탠포드대학교 파운데이션 모델 연구센터의 센터장 퍼시 리앙은 성명에서 “데이터에 대한 제약으로 인해 제대로 된 오픈소스 정의를 내리기는 어렵지만, OSI 버전 1.0 정의가 최소한 데이터 처리를 위한 전체 코드(모델 품질의 주요 동인)를 오픈소스로 요구한다는 점을 기쁘게 생각한다”라고 밝혔다. 그는 “핵심은 세부 사항에 있기 때문에, 이 정의를 자체 모델에 적용하는 구체적인 사례가 나온 후에 더 많은 의견을 제시할 수 있을 것”이라고 덧붙였다.

OSI는 자사 방법론이 초기 목적에 부합하는 표준을 만들어냈다고 자신했다.

OSI 이사회 의장인 카를로 피아나는 “오픈소스 AI 정의 1.0으로 이어진 공동 설계 과정은 잘 개발됐고 철저했으며, 포용적이고 공정했다. 이사회가 제시한 원칙을 준수했으며, OSI 리더십과 직원들이 우리 지침을 충실히 따랐다. 이사회는 이 과정을 통해 오픈소스 정의와 자유 소프트웨어 정의에 명시된 기준을 충족하는 결과를 만들어냈다고 확신하며, OSI가 이 정의를 통해 전체 산업에서 의미 있고 실용적인 오픈소스 지침을 제공할 수 있는 위치에 서게 된 것에 매우 고무적이다”라고 강조했다.

오픈소스 AI 시스템의 4가지 기준
오픈소스 AI가 되려면 시스템이 자유 소프트웨어 정의(Free Software Definition)에서 파생된 4가지 기준을 충족해야 한다고 명시됐다. OSAID는 다음과 같이 설명하고 있다.

AI 시스템은 다음과 같은 자유를 부여하는 조건과 방식으로 제공돼야 한다.

• 허가를 구할 필요 없이 어떤 목적으로든 시스템을 사용할 수 있다.

• 시스템의 작동 방식을 연구하고 구성 요소를 검사할 수 있다.

• 출력을 변경하는 것을 포함하여 어떤 목적으로든 시스템을 수정할 수 있다.

• 수정 여부와 관계없이 다른 사람이 어떤 목적으로든 시스템을 공유할 수 있다.

OSAID는 “이 자유는 완전한 기능을 갖춘 시스템과 시스템의 개별 요소 모두에 적용된다. 자유를 행사하기 위한 전제 조건은 시스템을 수정하기 위해 권장되는 양식에 액세스할 권한을 갖는 것이다”라고 언급했다.

또한 OSAID는 머신러닝 시스템을 수정할 때 권장되는 양식을 설명하며, 포함해야 할 데이터 정보, 코드, 매개변수를 명시했다.

그러나 OSAID는 “오픈소스 AI 정의는 모델 매개변수가 모든 사람에게 자유롭게 제공되도록 보장하는 특정 법적 메커니즘을 요구하지 않는다. 본질적으로 자유로울 수도 있고, 자유를 보장하기 위해 라이선스 또는 다른 법적 수단이 필요할 수도 있다. 법률 체계가 오픈소스 AI 시스템을 다룰 기회가 많아지면 더 명확해질 수 있다”라고 설명했다.

자체적인 오픈소스 AI 규정을 갖고 있는 넥스트클라우드(Nextcloud)도 OSAID를 지지하며, 이를 자사의 규정에 통합할 계획이라고 언급했다. 넥스트클라우드의 CEO이자 설립자인 프랭크 칼리체크는 “AI 솔루션 사용자는 투명성과 통제권을 누릴 자격이 있다. 우리가 2023년 초에 윤리적 AI 등급을 도입한 이유다. 이제 기술 대기업들이 오픈소스 AI라는 용어를 악용하려 하는 모습이 목격되고 있다. 사용자와 시장을 보호하기 위해 커뮤니티에서 오픈소스 AI에 대한 명확한 정의를 만드는 일을 전적으로 지지한다”라고 밝혔다.

관련 질문 및 우려 사항
한편 인포테크 리서치 그룹의 수석 연구 책임자인 브라이언 잭슨은 몇 가지 우려 사항을 언급했다.

그는 “오픈소스 AI 표준의 개요를 읽으면서 몇 가지 중요한 질문이 떠올랐다. OSI의 표준은 명확하고 이전의 오픈소스 소프트웨어 공개 표준과 일관된다. AI에는 전통적인 오픈소스 소프트웨어 라이선스가 다루지 않는 훈련 데이터, 모델 가중치, 새로운 아키텍처 등 몇 가지 주요한 차이점이 있기에 표준이 필요하다”라고 말했다.

잭슨은 의료 데이터처럼 법적으로 공개가 불가능한 데이터도 오픈소스가 될 수 있다고 언급했다. OSAID가 학습 데이터의 비공개를 허용하기 때문이다. 그는 “맥락은 이해하지만, 학습 데이터에 저작권 보호 콘텐츠가 포함되는 문제를 해결하지 못한다”라고 지적했다.

또한 그는 딥페이크나 가짜 누드 이미지를 생성하는 ‘누디파이’ 앱과 같은 오픈소스 AI로 인해 발생할 수 있는 피해도 우려했다.

잭슨은 “우리는 이미 오픈소스 AI로 인한 피해 사례를 목격했다”라고 덧붙였다. 그는 “아동 성 착취물(CSAM)은 오픈소스 AI가 악의적으로 사용되는 대표 사례다. 인터넷 감시 재단은 다크웹 포럼에서 이런 자료의 거래 활동이 증가하고 있으며, 제작자들이 더 정확한 결과를 얻기 위해 오픈소스 이미지 생성 모델 사용을 선호한다고 보고한 바 있다. 오픈소스 AI를 사용한 사기도 문제다. 이런 모델은 더 설득력 있는 딥페이크 제작, 피싱 메시지 맞춤화, 취약점이 있는 사용자 자동 검색에 활용되도록 수정될 가능성이 있다”라고 말했다.

반면 공동 설계자들의 우려는 크지 않았다. 모질라에서 AI 전략을 이끄는 아야 브데이르는 “새로운 정의는 오픈소스 모델이 ‘숙련된 사람이 동일하거나 유사한 데이터를 사용해 실질적으로 동등한 시스템을 재현할 수 있을’ 만큼의 학습 데이터 정보를 제공하도록 요구한다. 이는 현재의 독점 또는 표면적인 오픈소스 모델보다 더 진전된 조치다. 이는 AI 학습 데이터를 다루는 작업의 복잡성을 해결하려는 출발점이다. 다시 말해 전체 데이터셋 공유의 어려움을 인정하면서도 개방형 데이터셋을 AI 생태계의 더 일반적인 부분으로 만들기 위한 노력이다. 오픈소스 AI에서 학습 데이터와 관련한 이 관점이 완벽하지는 않겠지만, 실제로 어떤 모델 제작자도 충족하지 못할 이상적이고 순수한 종류의 표준을 고집하면 오히려 역효과를 낳을 수 있다”라고 설명했다.

OSI 자체는 OSAID 버전 1.0에 만족하고 있으며, 이를 향후 작업의 출발점으로 보고 있다.

OSI 총괄 책임자인 스테파노 마풀리는 성명을 통해 “OSAID 버전 1.0이 나오기까지 OSI 커뮤니티는 새로운 도전이 가득한 어려운 여정을 거쳤다. 서로 다른 의견과 미개척 기술 영역, 그리고 때로는 열띤 토론이 있었지만, 그 결과물은 2년간의 과정을 시작할 때 설정한 기대치에 부합한다. 더 넓은 오픈소스 커뮤니티와 함께 OSAID 버전 1.0을 이해하고 적용할 수 있는 지식을 개발하면서 점차 정의를 개선해 나가기 위해 지속적으로 노력하겠다는 첫걸음이다”라고 밝혔다.

https://www.cio.com/article/3593482/%ed%91%9c%ec%a4%80%ec%9d%84-%ed%96%a5%ed%95%9c-%ec%b2%ab%ea%b1%b8%ec%9d%8c-osi-%ec%98%a4%ed%94%88%ec%86%8c%ec%8a%a4-ai-%ec%a0%95%ec%9d%98-1-0-%eb%b0%9c%ed%91%9c.html

https://www.cio.com/article/3575332/%eb%b8%94%eb%a1%9c%ea%b7%b8-%ec%8b%a0%eb%a2%b0%ec%9d%98-%ec%9c%84%ea%b8%b0%ec%9d%bc%ea%b9%8c%c2%b7%c2%b7%c2%b7-it-%eb%b6%80%ec%84%9c%ec%9d%98-%eb%b6%80%eb%8b%b4%ec%9d%84-%ec%a4%84.html

메가존클라우드가 생성형 AI 기술 기반 서비스로 하나투어의 고객 상담을 고도화하는 프로젝트를 성공적으로 완수했다고 30일 밝혔다.
 
하나투어는 지난 7월 메가존클라우드의 ‘GenAI360’을 적용해 'AI 채팅 상담 서비스'의 시범 운영을 개시한 바 있다. 이번 프로젝트는 해당 서비스를 고객 맞춤형 상담이 가능하도록 고도화하는 작업이다. 

30일 정식 서비스에 들어간 이번 ‘AI 채팅 상담 서비스’는 고객들의 실제 예약 정보를 기반으로 맞춤 상담이 가능하도록 하는데 중점을 둔다. AI가 고객의 구체적 예약 정보를 바탕으로 상담을 이어갈 수 있도록 한다는 설명이다.
 
예를 들어 패키지 여행상품 예약 고객이 자신의 항공편이나 숙박, 여행일정, 출입국 정보, 여행지 날씨 등에 대해 문의할 경우 고객의 구체적 예약 정보를 통해 그에 해당하는 답변을 제공하는 방식이다. 이 서비스를 활용하면 여행중에도 언제든 다음 여행 일정, 숙소에서 제공하는 식사 메뉴 및 환승 교통 등을 AI 채팅을 통해 확인할 수 있다.
 
또, 기존에는 예약된 항공편을 취소할 때 발생하는 수수료 문의를 받을 경우 하나투어 웹사이트에 게시된 ‘예약 변경 및 취소/환불 통합 안내’ 페이지 링크를 답변으로 제공했으나 이번 고도화 작업의 결과로 고객의 예약 항공권에 대한 항공사 환불규정에 해당하는 구체적 환불 금액을 답변으로 제공할 수 있게 됐다.
 
이번 고도화 작업을 위해 메가존클라우드는 GenAI360 플랫폼을 적용해 하나투어의 방대한 데이터를 통합했다. 아울러 질문 의도 파악과 검색결과 정확도를 높이기 위해 AWS의 생성형 AI 플랫폼인 아마존 베드록(Amazon Bedrock)을 기반으로 앤스로픽의 클로드3 하이쿠(Anthropic Claude3 Haiku)와 소넷(Sonnet) 모델을 활용했다.
 
특히, 검색증강(RAG·Retrieaval-Augmented Generation) 기술을 적용해 패키지, 항공, 호텔 등 세부 예약정보와 함께 기존 채팅 상담 대화 이력을 연계 검색함으로써 답변 정확도를 크게 높였다고 메가존클라우드는 강조했다. 고

하나투어 관계자는 “지난 7월 이후 시범서비스를 이용한 3만명 이상의 질의를 바탕으로 데이터 학습을 강화하고 기능을 개선하면서 초개인화된 AI 채팅 서비스로 고도화할 수 있었다”라고 말했다.
 
메가존클라우드 AI&데이터 애널리틱스 센터 공성배 센터장은 “기존 인프라와 AI 기술을 통합함으로써 고객 맞춤형 AI 채팅 상담 서비스를 고도화할 수 있었다“라며 "고객 만족도와 서비스 효율성을 극대화하기 위해 AI 기술 기반 상담 서비스를 지속적으로 발전시켜 나갈 것”이라고 말했다. https://www.ciokorea.com/news/351530

생성형 AI 골드러시 속에서 초기 사용 사례로 각광받는 것 중 하나는 코딩 어시스턴트였다. 그러나 기대했던 생산성 향상 효과는 기대에 미치지 못하고 있다는 보고서가 등장해 눈길을 끈다.

많은 개발자가 AI 코딩 어시스턴트가 생산성을 높여준다고 말하지만, 최근의 한 연구에 따르면 생산성을 측정한 결과 큰 이득을 얻지 못했다. 코딩 및 협업 데이터에서 인사이트를 제공하는 업레벨(Uplevel)은 해당 연구 보고서에서 깃허브 코파일럿을 사용할 때 버그도 41% 더 많이 발생했다고 전했다. 

이 연구는 코드를 리포지토리에 병합하는 데 걸리는 시간인 PR(풀 리퀘스트) 주기와 병합된 풀 리퀘스트의 수인 PR 처리량을 측정해 효과를 살펴봤다. 그 결과 코파일럿 사용 개발자에게는 유의미한 개선 사항이 발견되지 않았다. 업레벨은 고객 기업들이 생성한 데이터를 사용하여 약 800명의 개발자가 3개월 동안 깃허브 코파일럿을 사용한 결과와 도입 전 3개월 동안의 결과물을 비교했다고 설명했다.
 

번아웃 측정
업레벨 연구는 생산성과 더불어 개발자의 번아웃 요인도 살펴봤다. 그 결과 깃허브 코파일럿이 번아웃에도 도움이 되지 않는다는 사실을 드러났다. 코딩 도구를 사용한 대조군과 테스트군 모두 표준 시간 외의 작업 시간이 감소했지만, 개발자가 코파일럿을 사용하지 않았을 때 오히려 더 많이 감소했다.

업레벨의 제품 관리자이자 데이터 분석가인 매트 호프만은 AI 코딩 어시스턴트가 보편화되면서 생산성이 크게 향상될 것이라는 주장에 대한 호기심에서 이 연구를 진행하게 되었다고 전했다. 지난 8월에 발표된 깃허브 설문조사에 따르면 소프트웨어 엔지니어, 개발자, 프로그래머의 97%가 AI 코딩 어시스턴트를 사용한다고 답했다.

호프만은 “생산성에 큰 도움이 된다는 주장을 담은 여러 연구들이 있었다. 어떤 사람들은 '그거 알아? 나는 앞으로 [코드] 리뷰어가 되어야 할 것 같아"라고 말하기도 했다”라고 전했다.

한편 깃허브 코파일럿 이번 업레벨의 연구에 대해 직접적으로 언급하지 않았다. 단 개발자가 코딩 어시스턴트를 사용하여 코드를 55% 더 빠르게 작성할 수 있었다는 최근의 연구를 언급했다. 

호프만에 따르면 업레벨은 당초 생산성 향상을 기대하며 연구에 착수했다. 그는 “우리 팀의 가설은 PR 주기 단축 효과에 대한 긍정이었다. 코드를 더 많이 작성할 수 있을 것이라고 생각했고, 실제로 코드를 배포하기 전에 이러한 생성형 AI 도구를 사용하여 코드를 검토하기 때문에 결함률이 낮아질 것이라고 생각했다”라고 말했다.

호프만은 PR 주기 시간과 PR 처리량 외에도 개발자의 생산성을 측정하는 방법이 더 있을 수 있다는 점을 인정한다면서도, 업레벨은 이들 메트릭이 개발자의 성과를 측정하는 확실한 척도로 보고 있다고 말했다.

앞으론 달라질 수도
업레벨은 이번 연구 결과에도 불구하고 코딩 어시스턴트가 빠르게 발전하고 있다는 점을 감안할 때 코딩 어시스턴트 사용을 중단하라고 제안하지는 않는다고 밝혔다. 호프만은 “코드 생성보다 코드 리뷰에 투입하는 시간이 늘고 있다. 코드가 제대로 작동하고 있다고 착각하기 쉽다. 무엇이 생성되는지, 예상한 대로 작동하는지를 면밀히 주시해야 한다”라고 말했다.

현장의 개발 팀들은 엇갈린 결과를 보고하고 있다. 맞춤형 소프트웨어 개발 회사인 게트소프트 USA(Gehtsoft USA)의 개발자들은 LLM(대규모 언어 모델) AI를 기반으로 한 코딩 어시스턴트를 통해 생산성이 크게 향상되지 않았다고 이 회사의 CEO인 이반 게트는 전했다. 게트소프트는 샌드박스 환경에서 코딩 어시스턴트를 테스트해 왔지만 아직 고객 프로젝트에 사용한 적은 없다.
 

“AI가 생성한 코드를 이해하고 디버깅하는 것이 점점 더 어려워지고 있다. 문제 해결에 투입되는 리소스가 크기 때문에 코드를 수정하는 것보다 처음부터 다시 작성하는 것이 더 쉬운 편이다.”
-이반 게크트, Gehtsoft CEO

게트 CEO는 “생산성 향상을 위해 LLM을 사용하려면 LLM이 실제 사람에 필적하는 능력을 갖춰야 하고, 실제 사용자도 LLM을 효율적으로 사용하는 방법을 알아야 한다. LLM은 비판적 사고, 자기 인식, 사고 능력이 없다”라고 말했다.

게트는 몇 줄의 코드를 작성하는 것과 본격적인 소프트웨어 개발에는 차이가 있다고 지적했다. 코딩은 문장을 쓰는 것과 같고, 개발은 소설을 쓰는 것과 같다고 그는 표현했다. “소프트웨어 개발은 요구 사항을 이해하고, 시스템을 설계하고, 한계와 제약을 고려하는 등 90%는 두뇌의 작동이다. 모든 지식과 이해를 실제 코드로 변환하는 것은 더 간단한 부분이다”라고 게트는 말했다.

업레벨 연구와 마찬가지로 AI 비서가 코드에 오류를 발생시키는 경우도 발견했다고 그는 전했다. AI가 생성한 코드가 반복적으로 재활용되면서 일관성 문제로 이어진다는 것이다. 개발자마다 다른 프롬프트를 사용함에 따라 나타나는 문제다. “AI가 생성한 코드를 이해하고 디버깅하는 것이 점점 더 어려워지고 있다. 문제 해결에 투입되는 리소스가 크기 때문에 코드를 수정하는 것보다 처음부터 다시 작성하는 것이 더 쉬운 편이다"라고 그는 말했다.

실효 체감
클라우드 서비스 제공업체 이노베이티브 솔루션(ovative Solutions)에서는 다르다. 이 회사의 CTO인 트래비스 렐은 클로드 데브 및 깃허브 코파일럿과 같은 코딩 어시스턴트를 사용하여 상당한 생산성 향상을 경험하고 있다고 전했다. 또한 자체 개발한 앤트로픽 통합을 사용하여 풀 리퀘스트를 모니터링하고 코드 품질을 검증하고 있다는 설명이다.

렐은 개발자 티켓의 완료 속도, 고객 결과물의 처리 시간, 코드 내 버그 수로 측정한 티켓의 품질을 기준으로 개발자 생산성이 2~3배 향상되는 것을 확인했다며, 과거 30일 정도 걸렸던 고객 프로젝트를 코딩 어시스턴트를 사용하여 24시간 만에 완료한 사례도 최근 있었다고 덧붙였다. 

하지만 코딩 어시스턴트가 전체 개발팀을 대체할 것이라는 주장 등 코딩 어시스턴트에 대한 일부 과대광고는 비현실적이라고 렐은 강조했다. 그저 코딩 어시스턴트는 코드의 일부를 재작업하여 코드를 빠르게 대체하거나 코드 경로를 최적화하는 데 사용되기에 적합하다고 그는 덧붙였다.

“코딩 어시스턴트가 처음부터 전체 코드를 올바르게 작성하지는 못한다. 코딩 어시스턴트에 대한 기대치를 낮춰야 한다. 단코딩 어시스턴트를 올바르게 사용하면 개발자의 코딩 속도를 두세 배까지 높일 수 있다”라고 그는 말했다.

https://www.ciokorea.com/news/351488