긍정적 사고, 음식의 절제, 규칙적인 운동

일부 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

민감하거나 논란의 여지가 있는 주제, 또는 감정이 격해질 문제를 다루기란 쉽지 않다. 이를 위해서는 감성 지능, 공감 능력, 그리고 적극적으로 경청하는 태도가 필요하다.

IT 리더는 많은 과제에 직면하지만, 신뢰할 수 없거나 업무를 소홀히 하는 직속 직원, 특히 팀장급 직원을 다루는 것만큼 어려운 일은 많지 않다. 

스킬소프트(Skillsoft)의 CIO 올라 달리는 관리자나 임원이 직속 직원과 솔직한 대화를 해야 하는 여러 이유가 있다면서도, “근본적으로 개인이 성과 기대치를 충족하고 팀과 전반적인 문화에 긍정적으로 기여하고 있는지 여부가 중요하다”라고 말했다.

대화의 성공 여부는 다양한 관점을 이해하고, 명확하게 소통하며, 메시지가 어떻게 받아들여지는지 관찰하는 능력에 달려 있다. 

어려운 대화를 덜 고통스럽고 더 효과적으로 만드는 6가지 방법을 소개한다.

1. 열린 태도 유지하기
달리는 열린 태도를 갖고 사실에 기반해 대화에 임하는 것이 중요하다고 강조했다. 대화에 들어가기 전에 여러 관점에서 상황을 종합적으로 파악해야 한다고 그는 조언했다. 또한 “행동이나 기대에 미치지 못한 사례를 준비하면 맥락을 제공하는 데 유용하기 때문에 이런 부분을 미리 생각하는 것이 중요하다”라고 말했다. 

대화의 성공은 다양한 관점을 이해하고, 명확하게 소통하며, 메시지가 어떻게 받아들여지는지 관찰할 수 있는 능력에 달려있다. 달리는 공감 능력과 감정 지능 등의 소프트스킬이 현대 리더에게 필수이며, 이를 통해 성공한 대화와 실패한 대화의 차이를 만들 수 있다고 언급했다. 이 기술은 하루아침에 개발되는 것이 아니라 지속적으로 공부하고 연습해야 한다.

달리에 따르면 최근 스킬소프트는 생성형 AI 기반 코치인 케이시(CAISY)를 개발했다. 이 시스템은 리더가 대인 관계 기술을 개발하고 안전한 환경에서 연습할 수 있도록 지원하며, 각 시뮬레이션 후 개인화된 피드백을 제공한다. 이 시나리오에서 팀장급 직원들은 성과가 저조한 팀원에게 건설적인 피드백을 제공해야 한다.

달리는 "시뮬레이션을 하는 동안 학습자는 공감, 인내심, 그리고 적극적이고 해결책 지향적인 접근 방식으로 어려운 상황을 효과적으로 관리하는 다양한 전략을 접하게 된다"라고 설명했다.

2. 서번트 리더십으로 접근하기
ISG의 파트너인 올라 차우닝은 대화에 앞서 다뤄야 할 행동이나 성과에 대한 명확한 예시를 준비해야 한다고 조언했다. 이를 위해 지표, KPI, 개인적 관찰 등 가능한 한 객관적인 정보를 확보해야 한다. 

차우닝은 “회의 전에 팀원이나 동료들과 일상적인 대화를 나누는 것도 도움이 될 수 있다”라고 말했다.

그는 행동 문제와 관련해 구성원을 섬기는 자세로 접근하는 서번트 리더십이 효과적일 수 있다고 설명했다. 그는 “직속 직원의 집중력, 주의력, 정신 건강에 영향을 미치는 외부 요인이 있는지 물어보라. 성과 문제는 일반적으로 사실에 근거하겠지만, 성과를 저해하는 내부 요인이나 제약이 있는지 물어보는 것이 적절할 수 있다. 이후의 대화는 결과, 사례, 기대되는 변화로 이어질 수 있다”라고 말했다. 

3. 상대방의 관점 고려하기
의료 소프트웨어 및 IT 자문 기업 리버액스(Riveraxe)의 CEO 데이비드 펌프리는 대화의 목표를 검토하고 개인의 관점을 이해해 대화를 준비해야 한다고 조언했다. 그는 적극적으로 경청하고 개방적으로 질문할 것을 제안했다. 

필요할 때 건설적인 지침을 제공하는 것도 중요하다. 펌프리는 “직속 팀의 한 팀장이 프로세스 간소화에 어려움을 겪고 있을 때, 먼저 약속 일정의 자동화부터 시작해 점진적으로 확장해 나가라고 제안했다. 이런 조언과 경험은 해당 직원을 다시 정상 궤도에 올리는 데 도움이 됐다”라고 회상했다.

추가 지원이 필요해 보일 경우 핌프리는 코칭이나 교육과 같은 단계를 권장했다. 그는 “한번은 직원의 의사 소통 기술을 돕기 위해 컨설턴트를 초빙한 적도 있다”라고 말했다. 

다른 모든 방법이 실패할 경우 직원의 재능과 능력에 더 잘 맞는 직책으로 재배치하는 것도 고려해야 하지만, 핌프리는 이 방법이 마지막 수단으로 사용돼야 한다고 언급했다. 그는 “지원이 있으면 많은 직원이 개선되지만, 때로는 팀과 비즈니스의 성공을 위해 변화가 필요할 수 있다. 하지만 역할 교체 전에 해당 직원을 정상 궤도에 올리는 것이 목표여야 한다”라고 설명했다. 

팀과 목표는 항상 우선시돼야 한다. 대화의 목표는 직속 직원에게 개선을 위한 기회와 리소스를 제공하는 것이지만, 필요할 때는 어려운 결정도 내려야 한다. 펌프리는 “강력한 리더십과 의사 소통이 핵심”이라고 덧붙였다. 

4. 명확한 목표 설정하기
지니어스 솔루션(Genius Solutions)의 사장 겸 CIO인 진 마그니는 공식적인 대화 일정을 잡기 전에 직속 직원과 비공식적으로 만나 회의의 구체적인 목표를 설정할 필요가 있다고 제안했다. 

마그니는 회의가 시작되면 전체적인 맥락을 파악하고 직속 직원의 관점을 이해하기 위해 경청해야 한다고 말했다. 그는 “개방적인 질문을 통해 전체적인 상황을 파악한 뒤에 지침을 제공하라. 해결해야 할 문제를 파악했다면 구체적인 예시와 개선을 위한 제안을 통해 직접적이면서도 건설적인 태도를 취하라”라고 조언했다. 

초기 논의 후 추가 조치가 필요한 경우 코칭, 교육 또는 역할 변경 등 적절한 다음 단계를 결정해야 한다. 직원의 능력에 확신이 서지 않는다면 최후의 방법으로 인사 담당자를 개입시키거나 역할을 재배치해야 한다고 마그니는 덧붙였다. 

마그니는 "열린 의사소통과 지원으로 많은 문제를 해결해 팀이 다시 잘 작동하게 할 수 있다. 하지만 어떤 경우에는 팀과 프로젝트 또는 비즈니스 목표의 성공을 위해 역할 교체가 필요할 수 있다"라고 말했다.

5. 마음가짐을 갖추기
IT 서비스 기업 어센던트 테크놀로지스(Ascendant Technologies)의 비즈니스 개발 매니저인 매튜 프란지센은 대화에 임할 마음가짐이 갖춰졌는지 점검하는 것이 중요하다고 말했다. 그는 "객관적으로 대화에 접근할 수 있는 마음가짐을 갖춰 사실에 집중하고 전문적인 태도를 유지할 수 있어야 한다"라고 설명했다.

프란지센은 "직원을 사무실로 부르기 전에 예의 바르고, 전문적이며, 협력적인 방식으로 대화에 접근할 계획을 세워야 한다. 대화의 목표에 집중해야 한다. 그들의 행동을 바꾸고 싶은 것인가, 직면한 문제에 대한 설명을 듣고 싶은 것인가, 아니면 둘 다인가?"라며 대화를 시작하기 전에 목표를 아는 것이 중요하다고 말했다.

6. 성급한 판단 피하기
디지털 컨설팅 에이전시 디비사(DIVISA)의 CEO 디터 샤오는 직속 직원의 관점을 완전히 이해하기 위해 판단 없이 경청해야 한다고 말했다. 그는 "성과 부진의 근본 원인을 파악하기 위해 심도 있는 질문을 하고 구체적이고 건설적인 피드백과 권장 사항을 제공하라"라고 조언했다.

참여와 지원에도 불구하고 어려움이 지속되다면 개인의 역할을 재평가해야 할 수 있다. 샤오는 "역할 교체는 엄청난 혼란을 초래할 수 있기 때문에, 그 단계를 밟기 전에 개선을 위한 기회와 자원을 제공하기 위해 모든 노력을 기울인다. 대부분의 문제를 해결하는 열쇠는 열린 의사 소통과 협력적인 접근 방식이지만, 팀과 비즈니스 목표의 성공이 최우선이어야 한다”라고 말했다. 

다른 이해관계자의 개입은 직속 직원이 추가적인 코칭, 교육 또는 독립적인 중재로부터 이익을 얻는 경우에만 있어야 한다. 샤오는 "성과와 역량을 다시 정상 궤도에 올리기 위해 가능한 한 투명하고 지원적으로 문제를 해결하는 데 목표를 둬야 한다"라고 덧붙였다. 

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

[python] Generate Captcha Using Python

https://www.geeksforgeeks.org/generate-captcha-using-python/

In this article, we are going to see how to generate a captcha using Python package captcha to generate our own CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart) in picture form. CAPTCHA is a form of challenge-response authentication security mechanism. CAPTCHA prevents automated systems from reading the distorted characters in the picture.

Installation:

pip install captcha

Generating image captcha: 

Here we are going to generate an image captcha:

Stepwise implementation:

Step 1: Import module and create an instance of ImageCaptcha().

image = ImageCaptcha(width = 280, height = 90)

Step 2: Create image object with image.generate(CAPTCHA_Text).

data = image.generate(captcha_text)  

Step 3: Save the image to a file image.write().

image.write(captcha_text, 'CAPTCHA.png')

Below is the full implementation:

Output:

Image CAPTCHA

Generating Audio captcha:

Here we are going to generate an audio captcha:

Stepwise implementation:

Step 1: Import module and create an instance of AudioCaptcha().

image = audioCaptcha(width = 280, height = 90)

Step 2: Create an audio object with audio.generate(CAPTCHA_Text).

data = audio.generate(captcha_text)  

Step 3: Save the image to file audio.write().

audio.write(captcha_text, audio_file)

Below is the full implementation:

Output:

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

IT 프로젝트는 점차 추진력과 지원을 잃을 수 있다. 만약 그런 징후를 감지한다면, 지금 바로 진행 방향을 바로잡거나 중단하기 위한 조치를 취해야 한다.
 
Y2K 날짜 변환은 기록상 최장 IT 프로젝트 중 하나였다. 장기간의 일정과 막대한 자원이 투입된 이 프로젝트가 끝까지 이어질 수 있었던 유일한 이유는 세기 말에 시스템이 중단되지 않도록 모든 날짜 형식을 변경해야 한다는 절대적인 필요성 때문이었다.

다시 말해 Y2K 프로젝트는 시급성 때문에 성공했다. 모두가 무엇이 위험한지, 그리고 프로젝트가 왜 그렇게 오래 걸리는지 알고 있었다.

다른 IT 프로젝트는 그렇지 않다. 프로젝트가 지연되거나 열정이 식어가기 시작하면 CIO와 프로젝트 매니저는 점검해야 한다. 죽어가는 프로젝트를 진행하고 있는 것은 아닌가?

프로젝트 실패로 인한 비용은 상당하다. 생성형 AI 이니셔티브, 소프트웨어 프로젝트 또는 대규모 디지털 트랜스포메이션 등 IT 프로젝트는 여전히 놀라울 정도로 높은 비율로 실패하고 있다. 실패한 프로젝트를 언제 복구할지 알아내는 것은 IT 리더가 개발해야 할 핵심 기술이다. 육감 같은 것이다. 때로는 프로젝트를 중단하는 것이 최선의 방법일 수 있다.

한때 열정적으로 지지받던 프로젝트가 흔들리기 시작하는 데에는 여러 가지 이유가 있다. IT 프로젝트가 위기에 처했음을 나타내는 몇 가지 주요 위험 신호를 소개한다.

벤더가 투자를 철회할 조짐을 보일 때
벤더 기반 시스템에 대한 일련의 자체 보고서를 작성하고 있으며, 이러한 보고서를 작성하기 위해 벤더 도구를 활용하는 경우가 있다. 프로젝트가 진행되고 있을 때 벤더의 수정 및 개선 사항 제공 속도가 느려지기 시작하는 것을 알게 된다. 벤더의 소프트웨어 릴리스 주기는 점점 길어진다. 심지어 벤더에서 감원이 임박했다는 소식도 들린다.

이는 프로젝트 위험 신호가 될 수 있는데, 프로젝트가 벤더의 도구와 플랫폼에 의존하고 있기 때문이다. 벤더의 활동이 서서히 중단되는 것처럼 보인다면, 프로젝트에도 비슷한 종말을 알리는 신호일 수 있다.

주요 벤더의 투자 의욕을 파악하는 것은 IT 이니셔티브가 장기적으로, 때로는 단기적으로 어떻게 진행될지 파악하는 데 필수적이다.

사용자가 프로젝트 플랫폼에 자주 접속하지 않는 경우
사내 시스템을 대폭 개선했지만, 지난 몇 달 동안 사용량이 꾸준히 감소했다는 것을 알게 된다. 사용자들이 이 시스템을 예전만큼 가치 있게 여기지 않는다는 신호일까? 사용자와 상의할 때다.

사용량 지표를 추적하고, 사용자 기반과 협력 관계를 구축해 요구 사항과 관심사를 더 잘 파악하는 것이 사용자 관심 저하를 확인하는 2가지 핵심 방법이다.

프로젝트 마감일이 계속 재협상되는 경우
프로젝트는 시작부터 순조롭게 진행되고 사용자와 IT 부서는 흥분하고 참여한다. 3개월이 지나자, 프로젝트 스폰서가 문을 두드리며 급한 일로 직원을 다른 곳으로 이동시켜야 하니 프로젝트 마감일을 미룰 수 있는지 묻는다. 스폰서는 모든 사람이 여전히 프로젝트를 지지하고 있다면서 일정을 미루게끔 한다. 그러나 프로젝트가 다시 시작될 즈음 스폰서는 또 찾아와 프로젝트 연기를 요청한다. 한때 높았던 프로젝트의 열정이 식어가고 있는 것일까?

잠재적인 비즈니스 이해관계자의 ‘무관심’ 신호를 읽는 법을 배우고, 이해관계자를 프로젝트 파트너로 변화시켜 위험에 처한 프로젝트를 바로잡거나, 다른 IT 우선순위를 방해하거나 더 많은 시간, 예산 및 자원을 소모하지 않고 프로젝트를 보류하기로 상호 결정할 수 있도록 해야 한다.

예산 지원이 축소되거나 연기될 때
지난 예산 편성 과정에서는 모든 사람이 프로젝트를 매우 기대했기 때문에 요청한 자금을 모두 지원받았다. 이제 새로운 예산 회의에서 CEO와 CFO는 초기 프로젝트 자금의 일부를 축소하거나, 적어도 회사가 프로젝트를 추진하기에 더 나은 재정 상태가 될 때까지 연기할 것을 요청한다.

모든 비즈니스 환경에서 긴축은 이해할 만한 일이지만, 프로젝트 긴축 요청이 두 분기 연속 발생하면 프로젝트의 실행 가능성에 의문을 제기할 때다.

CFO와 긴밀한 관계를 구축하면 도움이 될 수 있으며, 프로젝트 예산을 잘 관리하는 것도 중요하다.

프로젝트 지지자가 퇴사할 때
프로젝트의 슈퍼유저, 프로젝트 관리자 또는 기술 전문가 중 한 명 이상이 다른 직장을 위해 회사를 떠나기로 결정하면, 원래 프로젝트를 홍보하고 경영진에게 판매했던 리더의 부재로 타격을 입을 수 있다. 이러한 빈자리를 메울 수 있는 사람이 남아 있지 않다는 것은 프로젝트에 여전히 미래가 있는지 건강 상태를 측정해야 할 중요한 시기라는 의미다.

물론 직원 유지 노력이 도움이 될 수 있으며, 우수한 인재가 떠나는 일반적인 이유를 파악하는 것도 중요하다.

벤더 또는 회사에서 경영진이 바뀔 때
처음에 프로젝트를 지지했던 회사 또는 벤더의 주요 관리자가 떠나면 해당 프로젝트 지원이 그대로 유지될지 확인해야 한다.

벤더 영역에서는 회사가 합병되거나 인수될 때 경영진이 바뀌는 경우가 많다. 이 경우 프로젝트 기반이 되는 벤더 소프트웨어가 폐기 대상이 될 수도 있다.

조직에서 주요 비즈니스 스폰서가 떠나고 새로운 관리자가 들어올 경우, 새로운 사람은 자신이 사용하고 싶은 제품이나 소프트웨어에 대한 자신만의 아이디어를 가질 수 있으며, 여기에는 해당 프로젝트가 포함되지 않을 수 있다. 좋은 방법은 당사자에게 프로젝트를 계속 지원하는지 직접 묻는 것이다. 외부 종속성이 바뀌는 경우 벤더 관리 모범 사례를 참고하는 것도 도움이 될 수 있다.

비즈니스 방향이 변화할 때
고객이 온라인, 전화, 오프라인 매장에서 원활하게 소통할 수 있는 옴니채널 판매 플랫폼으로 전환하려는 기업은 이런 모든 판매 채널을 통합하는 IT 통합 프로젝트를 시작한다. 그러나 프로젝트가 진행됨에 따라 회사는 예상치 못한 극도의 시장 압박을 경험한다. 경영진은 통합이 불가능하더라도 방향을 바꿔 온라인 판매 채널을 즉시 운영해야 한다는 결론을 내린다. 이는 채널 통합 프로젝트에 어떤 영향을 미칠까?

변화를 항상 예측할 수는 없지만, 다른 주요 임원들과 긴밀한 관계를 구축하면 조기 경고 신호와 필요한 방향 전환을 위한 가치 있는 대화를 나누는 데 도움이 될 수 있다.

30여 년 전 하버드 비즈니스 리뷰(Harvard Business Review)는 "전략은 무엇을 할 것인가에 대한 선택만큼이나 무엇을 하지 않을 것인가에 대한 선택도 중요하게 만든다”라고 언급했다. 기술과 프로젝트 접근 방식은 상당히 변화했지만, 이 오래된 격언은 여전히 유효하다.

순조롭게 진행되던 프로젝트가 갑자기 진흙탕에 빠져 움직이지 않거나, 비즈니스 또는 환경 조건이 급변해 프로젝트의 미래가 의심스러울 때는 한 걸음 물러서서 실행 가능성을 고려할 때이자 프로젝트 이해관계자에게도 동일한 질문을 던져야 할 때다. 프로젝트를 갱신, 연기 또는 취소해야 할 수 있지만, 솔직한 대화를 통해 적어도 합의와 명확한 전략적 방향을 얻을 수 있다.

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