생성형 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

일부 IT 리더들은 AI가 코드 작성에 더 능숙해지면서 소프트웨어 개발팀이 시니어 몇 명 수준으로 축소될 수 있다고 내다봤다.
 
초기 성과는 각기 다르지만, 결과는 분명해 보인다. 생성형 AI 코딩 어시스턴트가 소프트웨어 개발팀의 구성 방식을 바꾸고, QA와 주니어 개발자의 일자리는 위험에 처할 수 있다는 것이다. 

일부 IT 리더는 AI 어시스턴트가 코드 작성을 더 잘하게 되면서 CIO와 개발 리더들이 AI 전문가와 선임 개발자를 중심으로 팀을 재편해 AI 생성 코드를 감독하게 할 수 있다고 말했다.

클라이밋 테크 전략 어드바이저의 설립자이자 차량-그리드 간 애플리케이션 제공업체 페르마타 에너지의 전 개발팀장인 안나 데메오는 애플리케이션 개발팀이 더 간소화되고, 남은 시니어 개발자들이 제품 요구 사항을 소프트웨어 개발로 옮기는 일에 집중하게 될 것이라고 전망했다.

데메오는 특히 기업들이 AI 코딩 어시스턴트에 의존하면서 주니어 개발자, 인턴, 경우에 따라서는 제품 관리자의 역할을 AI로 대체할 것이라고 예상했다. 그는 “큰 팀에는 항상 A 플레이어와 B 플레이어가 있다. C 플레이어는 없길 바라지만 그들도 존재한다. AI는 어떤 면에서 C나 B 플레이어의 설 자리를 더 줄일 수 있다”라고 말했다. 

그는 남은 개발자들이 이제 비즈니스 요구사항을 이해하고 제품 전문가, 마케팅 부서, 기타 직원들과 교차 기능팀에서 활약할 수 있는 비판적 사고를 가져야 한다고 조언했다. 

‘편집자’로서의 개발자
데메오는 이미 일부 고객사가 AI를 중심으로 개발팀을 재편하고 있으며 시니어 개발자나 소프트웨어 아키텍트가 AI 생성 코드를 감독 및 수정하고 있다고 말했다. 그는 다양한 역할에 영향을 미치고 있는 이런 변화를 소설 출판 과정에 비유했다.

데메오는 “개발자는 더 이상 작가가 아니라 편집자다. 시니어 개발자는 콘텐츠와 독자가 누구인지, 다시 말해 고객이 누구이며 조직이 무엇을 달성하려고 하는지 이해해야 한다”라고 설명했다.

세일즈포스용 데브옵스 플랫폼 제공업체 코파도(Copade)의 에반젤리즘 담당 수석 부사장인 데이비드 브룩스는 미래의 개발팀이 제품 매니저 또는 비즈니스 분석가, UX 디자이너를 비롯해, AI 도구로 프로토타입을 생성한 다음 출시 준비가 될 때까지 코드를 조정하는 소프트웨어 아키텍트 등으로 구성될 것이라고 말했다. 그는 보안 및 규정 준수 검토 등의 나머지 소프트웨어 개발 역할을 AI가 담당할 가능성이 높다고 언급했다.

브룩스는 “언젠가는 현재의 소프트웨어 개발 일자리가 없어질 수 있다. 그렇다면 주니어 소프트웨어 개발자가 가장 먼저 피해를 볼 것"이라며 "소프트웨어 아키텍트는 코딩 대신 더 높은 수준의 시스템을 설계하며 AI가 생성한 솔루션을 확인하는 일을 주로 맡게 될 수 있다"라고 설명했다.

브룩스는 몇 가지 난관도 있다면서, 특히 다음 세대의 소프트웨어 아키텍트를 양성하는 일이 주요 과제라고 언급했다. 주니어 개발자 일자리가 줄어들면 더 높은 직급으로 자연스럽게 올라갈 수 있는 길인 도제식 교육도 이뤄질 수 없기 때문이다.

확산되고 있는 코딩 어시스턴트
개발팀 재편이 얼마나 빨리 이뤄질지는 불분명하지만, 깃허브가 최근 실시한 설문조사에 따르면 개발자들 사이에서 AI 코딩 어시스턴트의 사용은 이미 확산되고 있다. 4개국 개발자의 97% 이상이 직장에서 AI 코딩 어시스턴트를 사용한 적이 있다고 답했는데, 이는 코딩 어시스턴트가 오늘날 생성형 AI의 최대 인기 사용 사례 중 하나라는 업계의 관측과 일맥상통한다.

깃허브는 지난 1월 말 기준 코파일럿 코딩 어시스턴트 사용자가 130만 명으로 전 분기 대비 30% 증가했다고 밝혔다. 마이크로소프트에 따르면 지난 7월 말까지 7만 7,000개 이상의 조직에서 코파일럿을 도입했다.

한편 온라인 교육 제공업체 플루럴사이트의 최근 연구 결과에 따르면, 조사에 참여한 IT 전문가의 약 4분의 3이 AI로 인해 자신의 기술이 쓸모없게 될 것을 우려하고 있었다.

또한 일부 전문가는 많은 개발팀이 빠른 시일 내에 AI를 최대한 활용하기 위해 노력하는 상황에서 AI의 영향이 장기적으로 나타날 전망이라고 언급했다.

IT 컨설팅 및 서비스 제공업체 인텔리버스(Intelibus)의 설립자 에드 와탈은 기존 팀의 생산성을 높이고 AI 프롬프트 엔지니어링 기술을 구축하는 데 추가 코치가 필요하기 때문에 향후 1~2년 내에 개발팀 규모가 실제로 더 커질 수 있다고 말했다. 하지만 3명의 소프트웨어 엔지니어가 과거 5~6명이 하던 코딩 업무를 할 수 있기 때문에 장기적으로는 개발팀이 점점 더 축소될 것이라고 덧붙였다.

와탈은 더 많은 직원이 AI와 로우코드/노코드 도구를 사용해 애플리케이션을 작성하게 되면 기존 개발팀의 혼란이 가중될 수 있다면서, “직원들은 AI 생성 코드가 어떻게 작동하는지 깊이 이해하지 못할 수 있지만 코드를 작성할 역량은 충분하다”라고 언급했다.

많은 IT 리더들이 AI 코딩 어시스턴트가 궁극적으로 개발자 일자리를 줄일 것이라고 예측했지만, 일부 개발 리더들은 AI를 사용한 코드 작성과 디버깅이 현명한 방법인지 의문을 제기하기도 했다.

과대 평가된 장점?
코드 테스트 솔루션 기업 소스랩스의 수석 테스트 전략가인 마커스 머렐은 일부 조직이 AI 코딩 어시스턴트로 절약되는 시간을 과대 평가했을 수 있다고 말했다. 그는 개발자 생산성을 약 30% 개선한다는 것이 좋은 출발점으로 작용할 수는 있지만 근본적인 변화로 이어질 정도는 아니라고 지적했다. 

머렐은 “오늘날 현장에서는 팀들이 이런 도구를 통해 엄청난 이익을 얻을 수 있다고 생각해 도구에 과잉 투자하거나, 구조 및 프로세스 변경을 과도하게 진행하거나, AI 도구의 예상되는 장점만 갖고 이미 계획했던 직원 감축을 한층 더 심화하는 모습을 볼 수 있다”라고 지적했다. 

머렐은 생성형 AI가 개발자 일자리를 대체할 것이라고 생각하지 않으며, 그보다 로우코드/노코드 도구가 더 큰 영향을 미칠 수 있다고 내다봤다. AI 코딩 실험이 적당한 성공을 거두며 계속되더라도 결국 AI 대기업들은 막대한 투자액만큼의 수익을 거둬야 하기 때문이다.

머렐은 “앞으로 2~3년간 이 기술에서 온갖 생산성을 짜내기 위해 노력한 다음에는, 결국 허울에 불과했다는 것을 인정하는 데까지 매우 오래 걸릴 수 있다. 우려되는 점은 도구에 익숙해지고 나면 기업들이 모델을 운영하는 데 드는 비용을 청구하기 시작한다는 것이다. 그 때가 되면 시스템에는 큰 충격을 줄 수 있다”라고 진단했다.

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

생성형 AI가 지루한 작업을 처리하고 오류를 찾는 데 능숙하더라도 프로그래머의 전문성과 직관은 항상 필요할 것이다.

데이터셋(Datasette)의 설립자 사이먼 윌리슨은 “지금이 프로그래밍을 배우기에 더할 나위 없이 좋은 시기”라고 말했다. AI가 코딩을 대신 해줘서가 아니다. 사실 정반대다. 그는 “대규모 언어 모델은 학습 곡선을 평평하게 만들어 젊은 개발자가 더 쉽게 따라잡을 수 있게 해준다”라고 말했다. 코딩하는 방법을 잊어서는 안 되지만, 생성형 AI를 사용해 경력 수준에 관계없이 개발자 경험을 강화할 수 있다.

‘배움에 대한 의지’를 예찬
필자는 생성형 AI에 대한 윌리슨의 견해를 살피는 것을 즐긴다. 그는 이 주제를 사려 깊게 생각하는 개발자다. 오라일리(O'Reilly Media)의 마이크 루키데스 글도 큰 주제에서 핵심을 압축해 설명했기 때문에 읽어볼 만하다. 루키데스는 생성형 AI와 코딩에 대해 “정말 좋은 프롬프트를 작성하기란 생각보다 어렵다”라는 점을 상기시켜 준다. 그는 “프롬프트를 잘 작성하려면 프롬프트의 목적에 대한 전문 지식을 쌓아야 한다”라고 말했다. 다시 말해, 먼저 ‘좋은’ 프로그래머가 돼야 한다.

루키데스는 “AI를 '인간이 얻을 수 없는 전문 지식과 지혜의 보고’로 생각해버리면 이를 생산적으로 사용할 수 없게 된다”라고 조언했다. AWS 코드위스퍼러(CodeWhisperer)나 구글 코디(Codey)와 같은 도구를 효과적으로 사용하기 위해서는 기대하는 결과물을 코칭해야 한다. 그리고 AI에게 개발 문제를 해결하는 방법을 단계별로 알려주려면, 먼저 문제를 깊이 이해하고 AI가 응답하도록 이끌어내야 한다. 

또한 개발자는 AI가 틀렸을 때 이를 평가할 수 있어야 한다. 여기엔 일정 수준의 전문성이 필요하다. 윌리슨이 언급한 것처럼 코딩 어시스턴트가 프로젝트에서 더 활발히 일하고 도와줄 것으로 기대되는 상황이지만, 그렇다고 해서 개발자가 코드를 파악해야 할 필요성까지 없애주진 않을 것이다. 그렇게 되기를 바라는 이도 없을 것이다. 다시 윌리슨의 첫 번째 요점으로 돌아가 본다.

AI를 활용한 코딩 학습
특정 언어, 프레임워크, 데이터베이스 등을 처음 접하는 개발자라면 학습 곡선이 가파를 수 있다. 예를 들어 “세미콜론을 놓쳐서 기이한 오류 메시지가 표시되고, 그 오류를 다시 찾는 데 2시간이 걸리는 경우도 있다”라고 윌리슨은 말했다. 당연히 이러한 점 때문에 학생들은 자신이 프로그래밍을 배울 만큼 똑똑하지 않다고 생각해 배움을 포기할 수 있다.

바로 이 부분에서 AI 어시스턴트가 개입할 수 있다. 윌리슨은 “컴퓨터공학 학위가 없어도 컴퓨터가 지루한 일을 대신 해줄 수 있어야 한다”라고 전했다. 챗GPT 같은 LLM 기반 어시스턴트는 지루한 작업을 자동화할 수 있다. 깃허브(GitHub) 엔지니어 자나 도건은 “사람들은 코드 생성에만 너무 집중한 나머지 LLM이 코드 분석에 유용하다는 사실을 완전히 잊고 있다”라고 강조했다. 모든 작업을 AI가 할 필요는 없다. 윌리슨의 주장에 따르면, 애플리케이션을 만들거나 망치지는 않으나 개발자의 자신감을 떨어뜨릴 수 있는, 개별적이고 지루한 작업을 자동화하는 데 AI를 활용할 수 있다. 코딩 어시스턴트가 지루한 작업을 처리할 수 있음에도 개발자가 프로그래밍의 모든 측면을 배우고 수행할 것을 요구받는 경우에 더 그렇다.

언제나 그렇듯 생성형 AI와 함께 소프트웨어 개발을 시작하는 가장 좋은 방법은, 바로 시작하는 것이다. 이해는 했지만 반복해서 작성할 필요는 없는 간단한 작업부터 자동화해 작게 시작하라. 이렇게 절약한 시간으로 더 까다로운 코딩 문제를 해결하는 방법을 배우는 데 집중할 수 있다. 전문성이 높아지면 이러한 작업도 자동화할 수 있게 될 것이다.

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

생성형 AI를 도입한 소프트웨어 개발 작업에 인간 프로그래머와는 근본적으로 다른 실수가 포함된다는 사실은 잘 알려져 있다. 그럼에도 대부분의 기업에서 AI 코딩 실수를 수정하는 계획은 단순히 숙련된 인간 프로그래머를 루프에 투입하는 것에 의존하고 있다. 

숙련된 인간 프로그래머는 인간 프로그래머가 저지르는 실수와 지름길의 종류를 직관적으로 알고 있다. 하지만 소프트웨어가 소프트웨어를 만들 때 발생하는 실수의 종류를 찾아내는 훈련은 별도로 필요하다.

이러한 논의는 이르면 2026년부터 대부분의 개발자가 더 이상 코딩을 하지 않을 것으로 예상한다는 AWS CEO 매트 가먼의 발언으로 더욱 가속화되었다.
 
개발 도구 분야의 많은 업체는 AI 코딩 앱을 관리하기 위해 AI 앱을 사용하면 이 문제를 해결할 수 있다고 주장했다. 2번째 열차 사고의 신호탄이나 마찬가지다. 금융 대기업인 모건 스탠리조차도 AI를 사용해 AI를 관리하는 방법을 고민하고 있다.

현실적으로 안전하고 원격으로 실행 가능한 유일한 접근 방식은 생성형 AI 코딩 오류의 특성을 이해하도록 프로그래밍 관리자를 교육하는 것이다. 사실 AI 코딩 오류의 특성이 매우 다르다는 점을 고려할 때, 인간의 코딩 실수를 발견하는 데 익숙하지 않은 새로운 사람을 AI 코딩 관리자로 교육하는 것이 더 나을 수도 있다.

문제의 일부는 인간의 본성이다. 사람들은 차이를 확대하고 잘못 해석하는 경향이 있다. 관리자는 자신이 절대 하지 않을 실수를 사람이나 AI가 저지르는 것을 보면 그 실수가 코딩 문제에서 관리자보다 열등하다고 생각하는 경향이 있다.

하지만 자율 주행 차량에 비추어 가정해 보자. 통계적으로 자율주행차는 사람이 운전하는 자동차보다 훨씬 더 안전하다. 자동화된 시스템은 피로를 느끼지도 않고, 취하지도 않으며, 고의적으로 난폭해지지도 않는다.

하지만 자율주행차는 완벽하지 않다. 그리고 교통 체증으로 정차한 트럭을 전속력으로 들이받는 등의 실수를 저지르면 인간은 “나라면 저런 멍청한 짓은 절대 하지 않았을 텐데...인공지능을 믿을 수 없어”라고 반문하게 된다. (웨이모 주차 차량 참사는 꼭 봐야 할 동영상이다.)

하지만 자율주행차가 이상한 실수를 한다고 해서 인간 운전자보다 안전하지 않다는 의미는 아니다. 그러나 인간의 본성은 이러한 차이를 조정할 수 없다.

코딩 관리도 마찬가지다. 생성형 AI 코딩 모델은 매우 효율적일 수 있지만, 자칫 잘못하면 엉뚱한 방향으로 흘러갈 수 있다.
 

AI는 미친 외계인 프로그래머

SaaS 기업 쿼리팰(QueryPal) CEO인 데브 내그는 생성형 AI 코딩 작업을 해오면서 많은 기업 IT 경영진이 이 새로운 기술이 얼마나 다른지에 대해 준비가 되어 있지 않다고 느꼈다.

내그는 “마치 다른 행성에서 온 외계인처럼 이상한 실수를 많이 했다. 인간 개발자가 하지 않는 방식으로 코드가 잘못 작동한다. 마치 우리처럼 생각하지 않는 외계 지능처럼 이상한 방향으로 나아간다. AI는 병적으로 시스템을 조작할 방법을 찾아낼 것”이라고 말했다.

올해 ‘AI 보조 프로그래밍’을 포함해 여러 권의 AI 프로그래밍 책을 펴낸 톰 타울리에게 물어보자.

타울리는 “예를 들어 LLM에 코드 작성을 요청할 수 있으며, 때로는 원하는 작업을 수행하기 위해 프레임워크나 가상의 라이브러리 또는 모듈을 구성할 수도 있다”라고 말했다. (타울리는 LLM이 실제로는 새로운 프레임워크를 만드는 것이 아니라 그렇게 하는 척하는 것이라고 설명했다.)

타울리는 “(인간 프로그래머가) 미치지 않는 한, 가상의 라이브러리나 모듈을 만들어서 허공에서 만들어내지는 않을 것”이라고 지적했다.

이런 일이 발생하면 누구든 찾아보면 쉽게 발견할 수 있다. 타울리는 “직접 설치하려고 하면 아무것도 없다는 것을 알 수 있다. 이 경우 IDE와 컴파일러에서 오류가 발생한다"라고 설명했다.

실행 파일의 창의적인 제어를 포함해 애플리케이션 전체 코딩을 주기적으로 환각을 일으키는 시스템에 넘긴다는 생각은 끔찍한 접근 방식인 것 같다.

생성형 AI 코딩의 효율성을 활용하는 훨씬 더 좋은 방법은 프로그래머가 더 많은 작업을 수행할 수 있도록 돕는 도구로 사용하는 것이다. AWS의 가먼이 제안한 것처럼 인간을 배제하는 것은 자살 행위나 다름없다.

만약 생성형 AI 코딩 도구가 마음대로 돌아다니면서 백도어를 만들어 나중에 사람을 귀찮게 하지 않고도 수정할 수 있도록 한다면 공격자들도 사용할 수 있는 백도어를 만들면 어떨까?

기업은 앱, 특히 자체 개발한 앱의 기능을 테스트해 앱이 제대로 작동하는지 확인하는 데 매우 효과적인 경향이 있다. 앱 테스트가 실패하기 쉬운 부분은 앱이 수행해서는 안 되는 작업을 수행할 수 있는지 확인하는 경우이다. 이것이 바로 모의 침투 테스트 사고방식이다.

하지만 생성형 AI 코딩 현실에서는 이러한 펜 테스트 방식이 기본이 되어야 한다. 또한 생성형 AI의 실수라는 엉뚱한 세계에 대해 잘 교육받은 감독자가 이를 관리해야 한다.

기업 IT는 확실히 더 효율적인 코딩 미래를 기대하고 있다. 프로그래머는 앱이 무엇을 해야 하는지, 왜 해야 하는지에 더 집중하고 모든 줄을 힘들게 코딩하는 데 시간을 덜 할애하여 더 전략적인 역할을 맡을 것이다.

하지만 그러한 효율성과 전략적 이득은 막대한 대가를 치러야 한다. AI가 생성한 코드가 올바른 방향으로 나아가도록 하기 위해 더 뛰어나고 다르게 훈련된 인력을 고용해야 하기 때문이다.

https://www.itworld.co.kr/topnews/350221

https://www.itworld.co.kr/news/337915

우리는 모두 규칙을 위반할 때의 짜릿함을 안다. 그 위반은 시속 55마일 구역에서 56마일로 달리는 것일 수도 있고, 주차 미터기의 유효 기간이 지나도록 방치하는 것일 수도 있다.

프로그래머와 규칙은 묘한 관계를 맺고 있다. 코드는 규칙의 거대한 더미에 불과하며, 규칙은 거의 항상 알파 입자로 인한 오류 없이 충실한 실리콘 게이트에 의해 두려움이나 호의 없이 무한히 적용된다. 인간은 트랜지스터가 규칙을 완벽하게 따르기를 바란다.

하지만 그렇게 신성하지 않은 또 다른 규칙이 있다. 인간이 기계에 전달하는 지침과 달리, 인간 스스로 만드는 규칙은 쉽게 유연해진다. 어떤 규칙은 단순히 문체적인 규칙이고, 어떤 규칙은 무질서하게 쌓인 코드 더미에 일관성을 부여하기 위해 고안된 규칙이다. 이러한 일련의 규칙은 기계의 반응 방식이 아니라 인간이 하는 일에 적용된다.
 
진짜 논쟁은 인간이 스스로 만든 규칙을 깨는 것이 좋은 생각인지 아닌지다. 인간이 즉석에서 규칙을 재해석할 권리가 있지 않을까? 어쩌면 일부 규칙은 다른 시대에서 유래한 것일 수도 있다. 처음부터 반만 완성된 개념이었을 수도 있다. 당시에는 현명한 아이디어처럼 보였지만 지금은 아닌 규칙도 있고, 어떤 것은 "습관"이라고 부르는 것이 더 나을지도 모른다.

프로그래밍 기술 개선을 저해할 나쁜 프로그래밍 습관 10가지를 정리했다.
 

주석 없는 코딩

문서화되지 않은 코드는 이해와 디버깅에 있어 악몽과도 같다. 프로그래밍 수업에서는 좋은 코멘트를 작성하는 것이 필수라고 가르친다. 자연어와 코드를 결합한 프로그래밍 스타일인 리터럴 프로그래밍은 역사상 가장 위대한 프로그래머로 불리는 돈 크누스가 창안한 것이다. 누가 이의를 제기할 수 있을까?

하지만 슬픈 진실은 댓글이 상황을 악화시킬 때가 있다는 점이다. 때로는 문서가 코드와 거의 관련이 없는 것처럼 보일 때도 있다. 문서화 팀이 코딩 팀과 멀리 있거나 다른 주에 살고 있을 수도 있고, 실제로는 생각이 다를 수도 있다. 코더가 문서화 팀에 알리지 않고 중요한 패치를 적용했거나 문서화 팀에서 알고 있지만 아직 주석을 업데이트하지 않았을 수도 있다. 때로는 코더가 변경한 메서드의 맨 위에 있는 코멘트를 업데이트하지 않기도 한다. 스스로 알아서 해결해야만 한다.

다른 문제도 있다. 코멘트가 모르는 자연어로 작성되었을 수도 있다. 7단락 미만으로 요약할 수 없는 개념인데 코더가 급하게 작성했을 수도 있다. 코멘트를 쓰는 사람이 잘못했을 수도 있다.

이러한 모든 이유로 일부 개발자는 쓸모없는 코멘트에 대한 최선의 해결책은 코멘트를 적게 포함하거나 아예 없애는 것이라고 생각한다. 대신 길고 설명적인 캐멀케이스 변수 이름을 지침으로 사용하는 간단하고 짧은 함수를 작성하는 것을 선호한다. 컴파일러에 오류가 없다면 코드는 컴퓨터가 수행하는 작업을 가장 정확하게 반영해야 한다.
 

느린 코드

코드를 빠르게 만들고 싶다면 코드를 단순하게 만들어라. 정말 빠르게 만들고 싶다면 복잡하게 만들어라. 이 과제에 적합한 최적의 지점을 찾는 것은 그리 쉬운 일이 아니다.

따라서 절충점을 찾아야 한다. 일반적으로는 프로그램이 빠르기를 원한다. 그러나 아무도 이해하지 못한다면 복잡성이 오히려 방해가 된다. 속도가 중요하지 않다면, 조금 느려도 이해하기 쉬운 코드가 더 합리적이다. 때로는 아주 영리하고 빠른 것보다 단순하고 느린 것이 더 나은 선택인 이유다.
 

장황한 코드

필자의 한 동료는 줄임표와 같은 자바스크립트의 새로운 연산자를 모두 사용하는 것을 좋아한다. 그 결과 코드는 더 간결해지고 나아진다. 모든 코드 리뷰에는 새로운 구문을 사용해 코드를 다시 작성할 수 있는 부분에 대한 제안이 함께 돌아온다.

간결한 것이 더 이해하기 쉽다고 확신하지 못하는 동료도 있다. 코드를 읽으려면 새 연산자의 포장을 풀어야 하는데, 그 중 일부는 다양한 방식으로 사용될 수 있다. 연산자가 어떻게 사용되었는지 이해하려면 익숙한 빠른 훑어보기가 아니라 잠시 멈춰서 깊이 생각해야 한다. 코드를 읽는 것은 번거로운 일이 되어 버린다.

사람들이 초밀착형 코드를 싫어하는 이유에는 역사적인 논거가 있다. 사용자 정의 기호 덕분에 엄청나게 치밀하고 효율적으로 설계된 APL 같은 언어는 본질적으로 사라졌다고 봐도 무방하다. 중괄호를 사용하지 않는 파이썬 같은 다른 언어의 인기는 계속 높아지고 있다.

멋진 추상화를 좋아하는 사람은 간결한 새 기능을 계속 밀어붙이고 간결함을 강조할 것이다. 이들은 현대적이고 유행에 발 맞춘다는 점을 강조한다. 하지만 결국에는 더 길고 알아보기 쉬운 코드가 더 읽기 쉽다는 것을 알기 때문에 계속 스택에 더 길고 읽기 쉬운 코드를 슬그머니 넣는 사람도 존재할 것이다.
 

오래된 코드

프로그래밍 언어를 설계하는 사람들은 특정 유형의 문제를 쉽게 해결할 수 있는 영리한 추상화 및 구문 구조를 발명하는 것을 좋아한다. 프로그래밍 언어는 추상화로 가득 차 있기 때문에 매뉴얼만 1,000페이지가 넘는 경우도 있다.

곧 권력의 제1 규칙이 “사용하지 않으면 잃는다”라는 주장이다. 1,000페이지에 달하는 매뉴얼에 설명된 모든 구문을 다 사용하는 것이 최선이라고 생각하기 때문이다.

그러나 항상 좋은 규칙은 아니다. 기능이 너무 많으면 혼란을 야기한다. 이제 어떤 프로그래머도 모든 구문 기믹에 능통할 수 없을 정도로 영리한 구문 기믹이 많이 등장했다. 왜 그래야 할까? 예를 들어 무효를 테스트하거나 상속이 다차원에서 작동하도록 하려면 얼마나 많은 방법이 필요할까? 그 중 어느 것이 옳은 방법, 아니면 다른 방법보다 나은 방법일까? 물론 적극적으로 이러한 논쟁을 막으려는 개발자도 있을 것이다.

기능 세트의 한계를 결정 지은 언어 개발자들도 나타났다. 고(Go) 언어 개발자들은 하루라도 빨리, 어쩌면 단 1일 만에 배울 수 있는 언어를 만들고 싶다고 말했다. 팀 내 모든 코더가 모든 코드를 읽을 수 있어야 한다는 의미다. 기능이 적을수록 혼란도 줄어든다.
 

나만의 코드 롤링

효율성 전문가는 "바퀴를 재발명하지 말라"라고 조언한다. 충분한 테스트를 거쳐 바로 실행할 수 있는 스톡 라이브러리를 사용하라. 이미 검증된 레거시 코드를 사용하라.

때로는 새로운 접근 방식이 합리적일 때도 있다. 라이브러리는 제너럴리스트와 일상적인 사용례를 위해 작성되는 경우가 많다. 데이터의 일관성을 보장하고 사용자가 잘못된 매개변수를 전송하여 작업을 망치지 않도록 벨트 앤 서스펜더 테스트가 많다. 하지만 특수한 경우라면 몇 줄의 특수 코드가 훨씬 더 빠르다. 라이브러리가 할 수 있는 모든 작업을 수행하지는 못하지만 필요한 작업을 절반의 시간 안에 처리할 수 있다.

위험한 경우도 있을 것이다. 암호화 시스템처럼 너무 난해하고 복잡한 코드도 있어서 모든 수학을 알고 있더라도 함께 조합하는 것은 좋은 생각이 아니다. 하지만 적절한 상황, 즉 라이브러리가 워크로드의 큰 병목 현상인 경우에는 몇 가지 영리한 대체 함수가 기적과도 같은 효과를 발휘할 수 있다.
 

너무 이른 최적화

프로그래머가 코드를 몇 가지 조합하고 나서 ‘조기 최적화는 시간 낭비’라는 오래된 격언으로 빠른 작업을 정당화하는 경우가 많다. 전체 시스템을 가동하기 전까지는 코드의 어느 부분이 진짜 병목 현상이 될지 아무도 모른다는 생각에서다. 1년에 한 번만 호출될 기능이라면 훌륭한 기능을 만드는 데 시간을 낭비하는 것은 어리석은 일이다.

일반적으로는 잘 통용되는 좋은 경험칙이다. 지나친 계획과 과도한 최적화 때문에 출발선을 벗어나지 못하는 프로젝트도 있기 때문이다. 하지만 조금만 미리 생각하면 큰 차이를 만들 수 있는 경우도 많이 있다. 때로는 잘못된 데이터 구조와 스키마를 선택하면 사후에 최적화하기 어려운 아키텍처가 만들어지기도 한다. 때로는 구조가 코드의 너무 많은 부분에 구워져 있어서 약간의 영리한 리팩터링만으로는 해결되지 않는 경우도 있다. 이러한 경우에는 약간의 조기 최적화가 정답이 될 수 있다.
 

부주의

훌륭한 프로그래머는 일방통행로를 건너기 전에 양쪽을 모두 살펴본다는 것을 누구나 알고 있다. 데이터를 처리하기 전에 항상 데이터를 두 번, 세 번 확인하는 추가 코드를 많이 삽입해야 한다. 널 포인터가 잘못 들어갈 수도 있기 때문이다.

안타깝게도 이렇게 많은 주의를 기울이면 코드가 느려질 수 있다. 때로는 성능 때문에 본능을 무시하고 그다지 신경 쓰지 않는 코드를 작성해야 할 때도 있다. 빠르게 실행되는 코드를 원한다면 최소한의 작업만 하고 그 이상은 하지 말아야 한다.
 

불일치

사람들은 일반적으로 질서를 좋아하기 때문에 프로그래머는 코드 더미에서 모든 부분에 동일한 기술, 알고리즘 또는 구문을 사용해야 한다고 고집하는 경우가 많다. 이러한 부지런함은 나중에 코드를 이해해야 하는 사람의 삶을 더 쉽게 만들어 준다.

반면, 일관성을 유지하려면 시간이 걸리고 때로는 복잡해지기도 한다. 차이점을 수정하려면 잘못된 경로를 따르는 모든 코드를 처음부터 다시 작성해야 하고, 그것만으로도 예산에 부담을 줄 수 있다.

더 심각한 문제는 서로 다른 섹션 간의 관계다. 레거시 코드에 의존하는 프로젝트도 있고, 라이브러리에 의존하는 프로젝트도 있다. 완전히 별도의 회사에서 완전히 다른 사람들이 작성한 API 없이는 작동할 수 없는 프로젝트가 많다.

그룹 간의 차이를 부드럽게 조정하는 것은 불가능하며, 최신 비전에 맞게 전체 스택을 다시 작성할 수 있는 횟수도 제한되어 있다. 우리 뇌의 이상한 구석에서는 완벽한 질서를 갈망하지만, 어쩌면 불일치와 화해하는 것이 더 나을지도 모른다.
 

종소리와 휘파람을 따라가기

지나친 일관성의 또 다른 문제는 혁신을 방해한다는 점이다. 일관성은 기존 업무 방식을 고집하는 일종의 경직된 태도를 조장하기도 한다.

새로운 기능을 추가하거나, 새로운 라이브러리를 도입하거나, 스택을 새로운 API와 통합하려면 기존 패턴을 깨야 할 때가 있다. 물론 코드를 읽는 동안 기어를 바꿔야 하는 사람의 삶이 조금 더 어려워지겠지만, 이것은 발전의 대가다. 또한 코딩을 재미있게 만드는 요소 중 하나이기도 하다.
 

규칙 깨기

재미를 위해 구글의 제미나이에게 프로그래머가 코드를 만드는 과정에서 규칙을 어긴 적이 있는지 물어보았다. 제미나이는 "프로그래머가 특정 규칙을 어겼다기보다는 저와 같은 대형 언어 모델을 만들 때 모범 사례의 한계를 넘어섰다고 말하는 것이 더 정확합니다"라고 대답했다.

"제미나이는 "저와 같은 대형 언어 모델은 방대한 양의 데이터로 학습하며, 모델이 데이터를 통해 학습하는 방식에는 '미지의 요소'가 존재합니다. 대형 언어 모델을 만드는 데 사용되는 일부 기술은 매우 효율적일 수 있지만 모델이 어떻게 답을 얻는지 정확히 이해하기는 어려울 수 있습니다”라고 말했다.

그렇다. LLM은 기존의 규칙이 바뀌고 있다는 사실을 사람보다 더 잘 알고 있다. 방대한 훈련 세트를 상자에 넣을 수 있다면 알고리즘을 이해하는 데 많은 시간을 할애할 필요가 없을지도 모른다. 그러니 인간답게 LLM이 규칙을 준수하도록 하자.

코딩 스타일

https://ko.javascript.info/coding-style

if (condition) {
  // 코드 1
  // 코드 2
  // ...코드 n...
}

// 백틱(`)을 사용하면 문자열을 여러 줄로 쉽게 나눌 수 있습니다.
let str = `
  ECMA International's TC39 is a group of JavaScript developers,
  implementers, academics, and more, collaborating with the community
  to maintain and evolve the definition of JavaScript.
`;

if (
  id === 123 &&
  moonPhase === 'Waning Gibbous' &&
  zodiacSign === 'Libra'
) {
  letTheSorceryBegin();
}

for (let i = 0; i < 10; i++) {
  if (cond) {
    ... // <- 중첩 레벨이 하나 더 늘어났습니다.
  }
}

for (let i = 0; i < 10; i++) {
  if (!cond) continue;
  ...  // <- 추가 중첩 레벨이 추가되지 않습니다.
}

function pow(x, n) {
  if (n < 0) {
    alert("'n'은 음수가 될 수 없습니다.");
  } else {
    let result = 1;

    for (let i = 0; i < n; i++) {
      result *= x;
    }

    return result;
  }
}

function pow(x, n) {
  if (n < 0) {
    alert("'n'은 음수가 될 수 없습니다.");
    return;
  }

  let result = 1;

  for (let i = 0; i < n; i++) {
    result *= x;
  }

  return result;
}

{
  "extends": "eslint:recommended",
  "env": {
    "browser": true,
    "node": true,
    "es6": true
  },
  "rules": {
    "no-console": 0,
    "indent": ["warning", 2]
  }
}

function pow(x,n)
{
  let result=1;
  for(let i=0;i<n;i++) {result*=x;}
  return result;
}

let x=prompt("x?",''), n=prompt("n?",'')
if (n<=0)
{
  alert(`Power ${n} is not supported, please enter an integer number greater than zero`);
}
else
{
  alert(pow(x,n))
}