반응형
반응형

[AI] 에인전틱(AgenticAI)와 생성형 AI(Generative AI)

 

Agentic AI와 Generative AI는 최근 AI 분야에서 중요한 개념이므로, 두 기술을 비교하여 설명해 드릴 수 있습니다.

1. 생성형 AI (Generative AI)

  • 정의: 기존 데이터로부터 학습하여 텍스트, 이미지, 오디오, 비디오 등 새로운 콘텐츠를 생성하는 AI 기술입니다.
  • 특징:
    • 학습된 데이터의 패턴과 구조를 모방하여 창의적인 결과물을 생성할 수 있습니다.
    • 다양한 분야에서 활용될 수 있습니다. (예: 글쓰기, 그림 그리기, 음악 작곡, 코드 생성 등)
    • 대표적인 모델로는 GPT (텍스트 생성), DALL-E (이미지 생성), Stable Diffusion (이미지 생성) 등이 있습니다.
  • 예시:
    • 사용자의 질문에 맞춰 자연스러운 문장으로 답변하는 챗봇
    • 텍스트 설명을 기반으로 이미지를 생성하는 이미지 생성 모델
    • 사용자가 원하는 스타일의 음악을 작곡하는 음악 생성 모델

2. 에이전틱 AI (Agentic AI)

  • 정의: 스스로 계획을 세우고, 필요한 도구를 활용하여 목표를 달성하는 AI 시스템입니다. 여기서 "에이전트"는 환경을 인식하고 자율적으로 행동하는 주체를 의미합니다.
  • 특징:
    • 복잡한 작업을 여러 단계로 나누어 순차적으로 처리할 수 있습니다.
    • 외부 환경과 상호작용하며, 필요한 정보를 검색하고, API를 호출하는 등 다양한 도구를 활용합니다.
    • 장기적인 목표를 설정하고, 그 목표를 달성하기 위한 전략을 수립할 수 있습니다.
  • 예시:
    • 사용자의 요청에 따라 여행 일정을 계획하고 예약하는 여행 에이전트
    • 주식 시장의 데이터를 분석하여 투자 결정을 내리는 투자 에이전트
    • 소셜 미디어에서 사용자의 관심사를 파악하여 맞춤형 콘텐츠를 추천하는 추천 에이전트

비교 요약:

  • 생성형 AI는 새로운 콘텐츠를 생성하는 데 초점을 맞추는 반면, 에이전틱 AI는 자율적으로 목표를 달성하는 데 초점을 맞춥니다.
  • 생성형 AI는 주어진 입력에 따라 결과물을 생성하지만, 에이전틱 AI는 스스로 계획을 세우고 실행합니다.
  • 생성형 AI는 특정 작업에 특화되어 있는 경우가 많지만, 에이전틱 AI는 다양한 도구를 활용하여 복잡한 작업을 수행할 수 있습니다.

두 기술은 상호 보완적으로 사용될 수 있습니다. 예를 들어, 에이전틱 AI가 생성형 AI를 활용하여 특정 작업을 수행하는 시나리오도 가능합니다.

반응형
반응형
T자형 인재는 살고
I자형 인재는 죽는다
 
이러한 AI 네이티브 컴퍼니의 등장은 인재상에 큰 변화를 일으키고 있습니다. 현장 지식인 도메인 놀리지 뿐 아니라 AI 활용 능력과 이를 기반으로 한 빠른 판단 능력 역시 중요해 질수밖에 없는 것인데요. 많은 기업들이 베테랑 직원들이 갖고 있는 역량을 AI로 학습시켜 이를 전사에 배포할 가능성이 크기 때문입니다. 즉 직원들의 일반 능력이 평준화 되는 추세입니다.

T자형 인재가 뜰 것이다

하지만 AI한테는 문제가 있습니다. AI는 정답이 있는 문제를 푸는 데 탁월하지만, 현실의 일터에는 정답이 없는 문제가 훨씬 많다는 점입니다. 예를 들어 복잡한 의사결정, 예외 상황 대응, 이해관계 조율은 여전히 사람이 할 수밖에 없기 때문입니다.

때문에 미래 인재상은 T자형 인재(T-shaped Talent) 입니다. T자형 인재란 세로 줄에는 전문성을, 가로줄에는 융합력을 가진 인재를 가리킵니다. 예를 들어 한 분야(마케팅, 서비스 운영, 재무 등)에 깊이 있는 전문지식과 실무 경험을 보유하면서도, 다른 영역(데이터 분석, 기술 이해, 협업 커뮤니케이션 등)에 대한 폭넓은 이해력과 협업 능력을 갖춘 사람입니다.

MBA에 공학까지 섭렵

T자형 인재를 중시하는 기업으로는 JP모건이 있습니다. JP모건은 데이터 사이언스 역량과 금융 이해를 동시에 갖춘 ‘하이브리드 인재’를 핵심 인재상으로 제시했는데요. AI가 만든 분석 결과를 고객 맞춤 전략으로 바꾸는 가교 역할을 수행하는 인재를 가리킵니다. 실제로 JP모건은 작년부터 MBA와 STEM(과학·기술·공학·수학) 수학을 병행한 인력을 우선적으로 채용하고 있습니다.

또 AI한테 없는 창의성(Creativity), 감정(Emotion), 그리고 신뢰(Trust)는 더 중요해 집니다. PwC 보고서에 따르면, 고객이 제품·서비스를 선택할 때 ‘신뢰와 경험’을 중시하는 비중이 73%에 달했습니다. AI가 수치와 데이터를 기반으로 제안은 할 수 있어도, 고객과 관계를 쌓고 기대를 뛰어넘는 방식으로 문제를 해결하는 능력은 여전히 사람의 영역입니다.

I자형 인재는 사라진다

반면 단순히 패턴화된 직무는 빠르게 사라지고 있습니다. 반복적인 입력, 단순 응대, 정형화된 분석 등은 AI가 더 정확하고 빠르게 처리하기 때문입니다. 예를 들어 미국 내 500개 이상의 콜센터가 AI 챗봇을 도입했고, 이 가운데 절반 이상이 연간 20% 이상의 인건비를 감축했습니다. 한 가지 역량만 갖춘 I자형 인재는 AI에 의해 대체될 가능성이 높은데요. 이는 직무 난도나 직종을 가리지 않습니다.

로펌 업계에서는 계약서 검토, 판례 검색, 증거 정리 등 고부가가치 법률 업무의 상당 부분을 AI 도구가 대체하고 있습니다. 준법지원팀과 신입 변호사 수요가 감소하고 있는 것인데요. 가트너는 2026년까지 대형 로펌에서 신입 변호사 업무의 약 50%가 AI에 의해 처리될 것으로 예측하고 있습니다.

우리에게 진정 필요한 것

AI는 또 다른 일자리도 창출하고 있습니다. 세일즈포스에 따르면, 가장 빠르게 성장 중인 직군 중 하나는 AI 운영 관리자와 AI를 교육하는 디지털 트레이너입니다. 이들은 기술의 언어와 사람의 언어를 동시에 이해하고, AI와 인간 사이에서 조율자 역할을 수행합니다. 직장인이 고민해야할 대목이 바로 여기에 있습니다.

따라서 미래에 ‘내 일이 남아 있느냐’가 아니라, ‘내 역할을 어떻게 재정의하느냐’에 집중해야합니다. 앞으로 10년은 단순히 버티는 사람의 시대가 아닙니다. 미래는 직무가 AI에 무너지더라도 다시 쌓을 줄 아는 사람의 몫이라고 생각합니다.
 
반응형
반응형

AI(인공지능)는 광범위한
윤리적, 사회적 질문과 도전을 제기한다.
AI의 의사결정 과정의 투명성, 프라이버시 보호,
직업 시장에서의 변화, AI 시스템의 공정성과 편향 문제 등은
과거의 기술에서는 고려되지 않았던 새로운 차원의 고민을
가져온다. 과거 기술은 작동 원리와 결과가 상대적으로
예측 가능하고 이해하기 쉬웠다. 반면 AI, 특히 심층학습과
같은 고급 기술은 내부 작동 메커니즘이 복잡해 때때로
블랙박스로 여겨진다. 이는 AI 시스템의 결정과 행동을
예측하고 이해하는 것을 어렵게 만들며,
윤리적, 법적 책임의 문제를
복잡하게 한다.


- 변형균의 《통찰하는 기계 질문하는 리더》 중에서 -


* AI 기술은
빛의 속도로 진화하고 있습니다.
챗GPT를 이용해 본 사람은 무섭게 실감합니다.
어마어마한 자본, 기술, 두뇌가 요구되는 사안입니다.
그런 점에서 우리나라는 분명 한계가 있습니다. 하지만
그 한계를 넘어설 수 있는 것이 콘텐츠입니다. 특히
'AI 윤리' 부분은 세계를 선도할 수 있습니다.
'AI 윤리'가 장착된 '한국형 챗GPT'도
개발할 수 있습니다.

반응형

'아침편지' 카테고리의 다른 글

울컥하는 이름 하나  (0) 2025.05.19
  (0) 2025.05.19
아픔은 일어난 뒤에 사라진다  (0) 2025.05.16
쉬운 길만 택한다면  (0) 2025.05.14
나도 모르는 게 많다  (0) 2025.05.13
반응형

[AI Tech 2025]

AI 융합 비즈니스 개발 컨퍼런스

 

https://dubiz.co.kr/Event/374

 

[AI Tech 2025]AI 융합 비즈니스 개발 컨퍼런스

“Fine-tune is done. Now what?”GPT를 도입했다고 끝난 게 아닙니다. 이제부터 시작이죠.AI 도입 이전보다 이후를 고민하는 실무자 관점의컨퍼런스를 만들었습니다."Fine-Tuning 이후에 모델을 어떻게 굴

dubiz.co.kr

 

https://youtu.be/-e-53zvmu0k

 

 

“Fine-tune is done. Now what?”
GPT를 도입했다고 끝난 게 아닙니다. 이제부터 시작이죠. 
AI 도입 이전보다 이후를 고민하는 실무자 관점의 컨퍼런스를 만들었습니다.

'Fine-Tuning 이후에 모델을 어떻게 굴릴 것인가', 'RAG, SLM, LLMOps는 어떻게 활용할 수 있을까',
'PoC에서 프로덕션으로 넘어가기 위해 필요한 조직 구성과 전략은?'

모든 실무자의 질문에, 현장의 실전 경험으로 답하는 자리. 
그게 바로 ‘AI Tech 2025 - Your Fine-Tuning Roadmap’입니다. 



◀ 
이 행사가 특별한 이유 ▶ 

1. 실무자 관점에서 출발한 컨퍼런스
대기업도, 스타트업도 모두 고민 중인 AI 도입에 대한 현실. 
이 행사는 '도입에서 멈추는 AI가 아니라, 현장에서 돌아가는 AI'를 다룹니다. 

2. Fine-Tuning 이후를 말하는 컨퍼런스
지금까지 대부분의 AI 컨퍼런스는 '개발', '사례', '비전'만 말했죠. 
AI Tech 2025는 AI 모델 운영과 이를 통해 생산성을 확보하는 전략에 집중합니다. 
나아가 AI 운영에 걸맞은 기업 문화와 조직 구성에 대한 팁도 공유할 예정입니다. 


3. 도입과 운영의 온도차를 이해하는 컨퍼런스
AI 기술 트렌드과 최적화 전략을 소개하는 키노트
Track A : Infra & Intelligence Lab ? 개발자와 엔지니어를 위한 구조와 성능 이야기

Track B : Adopt & Scale Strategy ? 기획자와 전략가를 위한 도입과 확산 로드맵

◀ About, AI Tech 2025 ▶ 

◎ 일  시 : 2025. 5. 15(목) 10:00-16:30
◎ 장  소 : 코엑스 3층 컨퍼런스룸 317호, 318호
◎ 주  최 : ㈜첨단, 헬로티, 한국인공지능협회, 서울메쎄, 인공지능신문
◎ 후  원 : 과학기술정보통신부, 마우저
◎ 주  제 : ‘Your Fine-Tuning Roadmap'
◎ 행사 규모 : 각 산업 비즈니스 개발 관계자 200여 명 대상
◎ 관련 전시 : 국제인공지능대전 2025 / AI Tech 등록 시 동시 관람 가능

※ 등록해주신 분들께는 상품권 증정을 통해 감사의 마음을 전합니다.



◀ 궁금한 점들 ▶

Q : 발표 트랙이 총 2개인데, 자유롭게 들을 수 있나요?
A : 네, 프로그램 표를 보시고 원하시는 룸 이동하셔서 자유롭게 들으실 수 있습니다. 

Q : 행사 당일 준비해야 할 것과 등록 방법은 어떻게 되나요?
A : 별도 준비 서류는 없습니다. 행사 당일 등록대에서 성함 확인 후 명찰을 지급해 드립니다. 
     대리 참석의 경우 본래 참석자 명함을 가져오시기 바랍니다. (정보 확인 후 변경해드립니다.)

Q : 점심은 어떻게 하나요?
A : 신세계 상품권(1만원권)이 지급됩니다. 코엑스 지하 여러 음식점에서 사용 가능합니다. 

Q : 참가확인증과 영수증 발급은 가능한가요?
A : 참가확인증은 행사 후, 두비즈 [마이페이지] → [등록 이벤트] → [프린트 아이콘] 클릭으로 직접 발급하실 수 있습니다. 현장 등록의 경우, 별도로 참가확인증 발급 요청을 해주시면 메일로 전달드리겠습니다. 영수증은 신용카드 결제 시 [마이페이지] → [결제내역]에서 영수증 출력이 가능합니다. 입금 계좌 시 [결제 방식] → [무통장 입금] → [세금계산서 발행] 선택 후 사업자 정보를 기입하시면 됩니다. 

Q : 발표자료를 모바일이나 웹으로 확인할 수 있나요?
A : 행사 당일, QR코드를 통해 발표자료를 다운받으실 수 있도록 QR코드를 행사장 곳곳에 부착해둘 예정입니다. 

※ 문의 : AI Tech 2025 담당자 / 070-4345-9890 / E-mail. dubiz@hellot.net

 


 

 

 

반응형
반응형


AI 코딩의 숨겨진 비용

 

 

The Hidden Cost of AI Coding

AI coding tools boost productivity but may sacrifice the flow state and deep satisfaction developers experience when writing code by hand. What are we losing?

terriblesoftware.org

 

 

 

  • 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

“The best moments in our lives are not the passive, receptive, relaxing times… The best moments usually occur if a person’s body or mind is stretched to its limits in a voluntary effort to accomplish something difficult and worthwhile.” — Mihaly Csikszentmihalyi

I know I’ve posted some upbeat content about AI before, celebrating its potential and encouraging teams to embrace these tools. And honestly, I still believe in that future. But today I want to share something more personal, more nuanced — the one thing that currently worries me most about using AI for software development: lack of joy.

It’s easy to talk about productivity gains, competitive advantages, and how AI will reshape our industry. We’ve had those conversations. What’s harder to discuss is what might be lost along the way – something intangible but vital to many of us who chose this profession not just for the paycheck, but because we genuinely love the craft of programming.


It’s 8:47 AM, fresh coffee steams on the table, and my headphones cocoon me in the perfect playlist. I go to Asana, where I know exactly what I need to do that day. I open Neovim and code starts flowing through me. I’ve lost the sense of time; I’m completely present in the moment.

That, my friends, is what I used to describe as a happy work day. I’m sure that some of you will resonate.

Those days I’d emerge tired but fulfilled. Something about the direct connection between thought and creation — where my fingers were simply the conduit for translating ideas into working software — felt almost transcendent. The struggle to solve problems, the small victories along the way, and the satisfaction of building something from nothing… these weren’t just aspects of the job; they were the reason I fell in love with programming in the first place.

This experience I’m describing is what psychologists call “flow” — a mental state where you’re fully immersed in an activity, energized by deep focus and complete involvement. First described by Mihaly Csikszentmihalyi (the psychologist I quoted at the beginning), flow is that sweet spot where challenge meets skill, where the task at hand is neither too easy (causing boredom) nor too difficult (causing anxiety). It’s a state strongly associated with creativity, productivity, and most importantly — happiness. For software developers, it’s that magical zone where problems become puzzles rather than obstacles, where hours pass like minutes, and where the boundary between you and your code seems to dissolve.

Fast forward to today, and that joy of coding is decreasing rapidly. Well, I’m a manager these days, so there’s that… But even when I do get technical, I usually just open Cursor and prompt my way out of 90% of it. It’s way more productive, but more passive as well.

Instead of that deep immersion where I’d craft each function, I’m now more like a curator? I describe what I want, evaluate what the AI gives me, tweak the prompts, and iterate. It’s efficient, yes. Revolutionary, even. But something essential feels missing — that state of flow where time vanishes and you’re completely absorbed in creation. If this becomes the dominant workflow across teams, do we risk an industry full of highly productive yet strangely detached developers?


So that’s what I’m worried about, and honestly, I have no idea what to think of it. On one hand, it’s clear to me that people using AI tools are more productive. On the other hand, I worry about long-term happiness and joy in their craft when they’re simply hitting tab to generate code rather than writing it themselves.

When we outsource the parts of programming that used to demand our complete focus and creativity, do we also outsource the opportunity for satisfaction? Can we find the same fulfillment in prompt engineering that we once found in problem-solving through code?

Perhaps what we need is a new understanding of where happiness can exist in this AI-augmented world. Maybe the joy doesn’t have to disappear completely — it just shifts. Instead of finding delight in writing the perfect algorithm, perhaps we’ll discover satisfaction in the higher-level thinking about system design, in the creative process of describing exactly what we want to build, or in the human aspects of software development that AI can’t touch.

I don’t have all the answers. But maybe, just maybe, we need to be intentional about preserving (some) spaces in our work where flow can still happen — where we still code by hand sometimes, not because it’s efficient, but because it make us happy.

After all, if we lose the joy in our craft, what exactly are we optimizing for?

반응형
반응형

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

 

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

 

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

 

Avoiding Skill Atrophy in the Age of AI

How to use AI coding assistants without letting your hard-earned engineering skills wither away.

addyo.substack.com

  • 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로 인해, 스스로 생각하는 법을 잊지 않은 사람이 될 것임

반응형

+ Recent posts