
생성 AI를 능숙하게 다루는 엔지니어와 그렇지 못한 엔지니어의 차이 ―― AI는 지능의 대체가 아니라 사고와 설계의 증폭기이다
요약
생성 AI는 인간의 지능을 대체하는 것이 아니라 문제 설정, 설계, 검증 능력을 증폭하는 도구입니다. LLM의 확률적 성질과 환각 현상을 이해하고, 이를 효과적으로 제어할 수 있는 엔지니어의 새로운 리터러시가 생산성을 결정합니다.
핵심 포인트
- AI는 지능의 대체재가 아닌 사고와 설계의 증폭기임
- LLM의 확률적 토큰 예측 및 Softmax Crowding 특성 이해 필요
- 환각(Hallucination)과 의미론적 표류(Semantic Drift) 리스크 관리 중요
- 사용자의 문제 설정 및 검증 능력이 AI 활용 성패를 결정
1. 서론
최근 소프트웨어 개발 현장에서 생성 AI (Generative AI)의 활용도에 따른 엔지니어 간의 생산성 차이가 현저해지고 있다. ChatGPT, Claude, Gemini, Copilot 등의 도구를 활용하여 설계, 구현, 리뷰, 조사, 문서 작성의 각 공정을 대폭 가속화하는 기술자가 있는 반면, 동일한 도구를 사용하고 있음에도 불구하고 "기대하는 코드가 생성되지 않는다", "출력 결과의 신뢰성이 낮다", "수정 지시를 반복할수록 코드가 파괴된다"와 같은 과제에 직면하여 결과적으로 AI 이용을 포기하는 기술자도 적지 않다.
일반적으로 이러한 차이는 이용자의 지적 능력 차이로 치부되기 쉽다. 하지만 이 견해는 정확하지 않다. 왜냐하면 생성 AI는 인간의 지능을 그대로 대체하는 것이 아니라, 이용자의 문제 설정 능력, 설계 능력, 검증 능력, 언어화 능력, 그리고 사고의 특성을 증폭하는 장치로서 기능하기 때문이다.
본고에서는 생성 AI를 비유적으로 사고를 비추는 거울이자 증폭기로 파악하여, 기술자가 AI를 효과적으로 활용하기 위한 요건과 새로운 리터러시(Literacy)에 대해 고찰한다.
2. 생성 AI의 기술적 배경과 확률적 성질
생성 AI를 적절하게 활용하기 위해서는 우선 그것을 만능 도구로 간주하는 인식을 고쳐야 한다. 현재의 대규모 언어 모델 (LLM) 대부분은 Transformer라고 불리는 아키텍처를 기반으로 하고 있으며, 입력된 문맥의 어떤 정보에 주의를 기울일지를 계산하는 어텐션 (Attention) 메커니즘을 중심으로 구성되어 있다 [6].
구체적으로는, 쿼리 (Query) [
여기서, 과도한 집중이 의미 생성의 편향이나 문맥 이용의 불안정성으로 이어지는 현상을 Softmax Crowding이라고 논하였다. 본고에서도 이 주의 가중치의 과도한 집중을 편의상 "Softmax Crowding"이라고 부른다. 이 스케일링을 통해 Attention은 문맥 중의 관련도를 더욱 안정적으로 계산할 수 있다.
나아가 이러한 LLM은 극히 단순화하면 주어진 문맥으로부터 다음에 출현할 토큰 (Token)을 예측하도록 훈련되어 있다. 즉, 과거의 토큰 열 [
을 최대화하는 확률 모델이다.
문장 전체의 생성 확률은 연쇄 법칙 (Chain Rule)을 사용하여 다음과 같이 나타낼 수 있다.
여기서 중요한 점은, AI가 "인간처럼 대상의 의미를 완전히 이해한 상태에서 응답을 생성하고 있다"고 생각하기보다, 문맥에 기반하여 그럴듯한 응답을 확률적으로 생성하고 있다고 파악하는 것이 실무상으로는 더 안전하다는 점이다.
생성 AI는 방대한 텍스트, 코드, 설계 패턴, 대화 예시로부터 학습한 확률적인 구조에 기반하여 문맥상 가장 자연스러운 응답을 생성한다. 따라서 생성 AI는 실무상 확률적 의미 생성 장치로 취급하는 것이 적절하다.
과거의 방대한 지식을 압축된 형태로 보유하고 있기 때문에, 적절히 이용하면 인간의 작업을 크게 가속화하는 것이 가능하다. 하지만 동시에 그럴듯한 오류 (Hallucination, 환각)를 출력하는 리스크도 내포하고 있다. 전제 조건이 모호한 경우에는 독자적인 전제를 보완하고, 사양에 결락이 있다면 학습된 분포에 기반하여 그럴듯한 전제를 보완한다. 또한 대화가 길어지면 초기의 의도에서 문맥이 괴리 (Semantic Drift, 의미론적 표류)되는 경우도 있다.
이용자가 적절한 검증을 수행하지 않으면 이러한 오류는 그대로 성과물에 혼입된다. 이 확률적인 성질을 이해하고 있는지 여부가 AI 활용의 성패를 가르는 첫 번째 분기점이 된다.
3. 선행 연구에서 보는 AI의 생산성 향상 효과와 한계
최근의 연구 성과를 참조하면 생성 AI의 생산성 향상 효과의 복잡성이 드러난다.
GitHub Copilot을 이용한 초기 실험에서는 JavaScript를 이용한 HTTP 서버 구현 과제에서, AI 이용 그룹은 비이용 그룹보다 평균 55.8% 빠르게 태스크를 완료했다고 보고되었다 [1]. 또한, 고객 지원 업무의 실증 연구에서도 생성 AI의 지원을 통해 생산성이 평균 15% 향상되었으며, 특히 경험이나 숙련도가 낮은 노동자일수록 현저한 효과를 얻었다고 한다 [2].
이것들은 생성 AI가 생산성을 일률적으로 향상시킨다는 것을 시사하는 것처럼 보이지만, 사태는 더 복잡하다. BCG에 의한 컨설턴트 대상 연구에서는 생성 AI의 효과는 AI의 능력 범위 안에 있는 과제에서는 크게 나타난 반면, 능력 범위 밖에 있는 과제에서는 AI 이용자의 성적이 비이용자를 밑도는 결과가 나타났다 [3]. 해당 연구는 이 현상을 "Jagged Technological Frontier"라고 호칭하고 있다.
나아가, 2025년에 경험이 풍부한 오픈소스 소프트웨어 (OSS) 개발자를 대상으로 수행된 연구에서는, 참가자들이 AI를 통한 작업 시간 단축을 예상했음에도 불구하고 실제로는 작업 시간이 19% 증가했다고 보고되었다 [4]. 이 과제는 단순한 신규 구현이 아니라, 기존의 코드베이스, 암묵지 (Implicit Knowledge), 품질 기준, 프로젝트의 문맥을 이해한 상태에서의 변경이었다.
이러한 연구들로부터 얻을 수 있는 중요한 시사점은, 생성 AI가 단순한 구현이나 정형화된 작업에는 강점을 가지는 반면, 복잡한 기존 문맥에 대한 올바른 개입에 있어서는 오히려 작업 효율을 저하시킬 가능성이 있다는 것이다. 따라서 AI 활용의 숙련도는 단순히 "프롬프트 엔지니어링 (Prompt Engineering) 기술"만으로 귀결되는 것이 아니라, "과제가 AI 적용에 적합한지를 판단하는 능력", "AI로의 위임 범위를 결정하는 능력", "인간에 의한 검증의 경계를 설정하는 능력" 등을 정확하게 수행할 수 있는지에 달려 있다.
4. AI 활용에 있어서 인간 측의 과제와 상호작용
4.1 모호성의 증폭
AI를 효과적으로 활용하지 못하는 기술자의 특징으로, AI에 '정답'을 과도하게 요구하는 경향을 꼽을 수 있다.
"이 기능을 만들어줘"
"좋은 느낌으로 설계해줘"
"버그를 수정해줘"
이러한 모호한 지시에도 AI는 응답을 생성한다. 하지만 그 출력이 요구사항, 설계의 타당성, 기존 코드와의 정합성, 보안, 테스트 용이성 (Testability)을 충족하는지는 별도로 검증되어야 할 문제이다.
AI는 의지나 목적을 가지지 않으며, 결과물에 대한 책임을 지지도 않는다. 인간이 목적, 전제, 제약, 평가 기준을 제공하지 않으면, AI는 확률적으로 그럴듯한 것을 출력할 뿐이다. 여기서 발생하는 심각한 문제가 바로 모호성의 증폭이다.
사양, 책임 분리 (Separation of Concerns), 입력 조건, 에러 처리가 모호한 상태로 AI에 입력되면, 그 모호함은 그대로 취약한 설계나 버그를 동반한 코드로 출력된다. 결과적으로 이용자는 자신의 사고의 거칠음을 AI를 통해 고속으로 증폭시키고 있는 상태에 빠지게 된다.
4.2 사고의 외부화와 적절한 제약 부여
대조적으로, AI를 효과적으로 활용하는 기술자는 AI에 태스크를 통째로 맡기지 않고, 사고를 외부화하는 장치로서 이용한다. 이들은 AI에 지시를 내리기 전에 목적, 전제 조건, 입출력, 제약, 변경 범위의 경계, 평가 기준 등을 명확하게 분해한다.
예를 들어, 다음과 같은 의뢰는 모호하다.
경비 신청 기능을 만들어줘
이 의뢰에서는 대상 엔티티 (Entity), 책임 분리, 입력 조건, 제약, 테스트 관점이 명시되어 있지 않다. 따라서 AI는 누락된 전제를 그럴듯하게 보완하며 출력을 생성한다.
반면, 다음과 같이 제약을 주면 AI가 탐색해야 할 문제 공간이 좁아진다.
Spring Boot + MyBatis + MySQL 구성으로,
Expense 엔티티를 대상으로 한 경비 신청 기능을 작성한다.
Controller / Service / Mapper / SQL / Test의 각 계층에 책임을 분리하고,
...
이러한 지시에서는 목적, 기술 스택 (Tech Stack), 대상, 책임 분리, 제약, 출력 입도 (Granularity)가 명확해진다. 이를 통해 AI가 탐색해야 할 문제 공간을 한정하고 폭주를 방지할 수 있다. 뛰어난 기술자는 AI에게 과도한 자유를 주지 않고, 적절한 제약을 통해 출력을 제어한다.
5. 생성 AI 시대의 소프트웨어 엔지니어에게 요구되는 리터러시
이상의 논의를 통해, 생성 AI 시대의 소프트웨어 엔지니어에게 요구되는 능력은 단순한 프롬프트 작성 능력으로 환원되지 않음을 알 수 있다. 오히려 중요한 것은 생성 AI의 확률적 성질을 이해한 바탕 위에서, 그 출력을 소프트웨어 공학상의 결과물로 연결하는 능력이다.
첫째, 생성 AI의 출력을 확률·통계적 모델로 파악하는 수학적 소양이 필요하다. 제2장에서 나타냈듯이, AI의 응답은 결정론적인 프로그램이 아니라 확률 분포에 기반한 예측에 불과하다.
여기서 말하는 수학적 소양은 고도의 수식 처리 능력을 의미하지 않는다. 중요한 것은 AI의 출력을 결정론적인 답이 아니라, 확률적으로 생성된 후보로서 다루는 태도이다.
토큰 (Token), 어텐션 (Attention), 온도 (Temperature), 환각 (Hallucination)과 같은 개념을 단순한 "도구의 사양"이 아니라 확률적인 거동으로서 이해함으로써, AI의 비결정적인 출력 편차에 대한 적절한 엔지니어링이 가능해진다. 예를 들어 예외 처리, 재시도 제어, 파라미터 조정, 복수 후보 비교, 테스트를 통한 검증 등이 이에 해당한다.
둘째, 소프트웨어 설계에 관한 기초 능력이 필수적이다. AI는 코드를 고속으로 생성할 수 있지만, 책임 분리 (Separation of Concerns), 경계 설계 (Boundary Design), 타입 설계 (Type Design), API 설계, 테스트 설계, 에러 핸들링 (Error Handling), 보안 설계의 타당성을 최종적으로 판단하는 것은 인간이다. 설계의 축을 갖지 못한 이용자가 AI를 사용하면, 표면적으로는 동작하지만 유지보수성이나 확장성이 부족한 코드가 대량으로 생성될 가능성이 있다.
셋째, 사양을 구조화하는 능력이 중요하다. 생성 AI에 대한 입력은 자연문에 의한 의뢰뿐만 아니라, JSON, YAML, OpenAPI, Gherkin, 테스트 케이스, ADR 등 기계 처리가 가능하고 인간이 검증 가능한 산출물로 변환될 필요가 있다. 대화로서 흘러가는 문맥을 고정된 사양이나 설계 산출물로 변환함으로써, AI의 출력을 지속적으로 검증 가능한 개발 프로세스에 편입시킬 수 있다.
넷째, AI 출력에 대한 비판적 사고가 필요하다. 생성 AI는 유창한 응답을 생성하기 때문에, 이용자는 그 그럴듯함(plausibility)을 정답으로 오인하기 쉽다. 하지만 생성 AI의 출력은 항상 검증 대상이며, 최종적인 판단 책임을 지는 주체가 아니다. 따라서 AI 활용에 있어서는 출력을 수용하는 것이 아니라, 검증, 비교, 반증, 수정이라는 비판적 프로세스를 유지하는 것이 요구된다.
Lee 등은 319명의 지식 노동자에 의한 936건의 생성 AI 이용 사례를 분석하여, 생성 AI에 대한 신뢰가 높을 경우에는 비판적 사고의 발현이 저하되기 쉬운 반면, 이용자 자신의 태스크 수행에 대한 자기 효능감이 높을 경우에는 비판적 사고가 유지되기 쉽다는 것을 보여주었다 [5].
이상을 정리하면, 생성 AI를 효과적으로 활용하는 소프트웨어 엔지니어에게 필요한 리터러시(Literacy)는 다음과 같은 4개의 층으로 구성된다.
표 1: 생성 AI 시대의 소프트웨어 엔지니어에게 요구되는 리터러시
| 층 | 내용 | 역할 |
|---|---|---|
| AI 리터러시 (통계적 사고) | 토큰 (Token), Attention, 확률 분포 (Probability Distribution), Temperature, Hallucination 등 | AI 출력의 확률적 성질과 한계를 이해한다 |
| 설계 리터러시 | 책임 분리, 경계 설계, 타입 설계, API 설계, 테스트 설계 | AI 출력을 타당한 소프트웨어 구조로 연결한다 |
| 사양화 리터러시 | JSON, YAML, OpenAPI, Gherkin, ADR, 테스트 케이스 | 모호한 자연문을 검증 가능한 산출물로 변환한다 |
| 비판적 사고 | 검증, 비교, 반증, 리뷰, 의사결정 | AI의 그럴듯함에 휩쓸리지 않고, 최종 판단을 인간이 담당한다 |
6. 결언
본고에서는 생성 AI를 이용하는 소프트웨어 엔지니어 사이에서 발생하는 생산성 차이에 대해, 생성 AI의 기술적 성질, 선행 연구에서의 생산성 향상 효과와 한계, 인간 측의 문제 설정 능력 및 검증 능력의 관점에서 고찰하였다.
선행 연구가 보여주듯이, 생성 AI는 단순한 구현 과제나 정형화된 지식 작업에서 생산성을 향상시킬 가능성을 가진다. 반면, AI의 능력 범위를 벗어난 과제나 기존 코드베이스, 암묵지, 품질 기준을 동반하는 복잡한 문맥에서는 오히려 작업 효율을 저하시키는 경우가 있다. 이는 생성 AI의 효과가 일률적이지 않으며, 과제의 성질과 이용자의 판단 능력에 강하게 의존함을 보여준다.
따라서 생성 AI 활용의 성패는 단순한 프롬프트 작성 기술에 의해 결정되는 것이 아니다. 중요한 것은 과제가 AI에 적합한지 파악하고, AI에 위임할 범위를 정하며, 출력을 검증하고, 사양·설계·테스트·산출물로 연결하는 능력이다.
생성 AI 시대의 생산성 차이는 단순한 프롬프트 기술의 차이가 아니라, AI의 확률적 출력을 사양·설계·검증 가능한 산출물로 연결할 수 있는가 하는 상호작용 설계 능력의 차이로 나타난다.
생성 AI는 지능의 대체물이 아니라, 이용자의 지식, 사고, 설계력, 검증력, 가치 판단을 증폭하는 장치이다. 비유하자면, 생성 AI는 이용자 자신의 사고를 비추는 거울이기도 하다. 사고가 구조화되어 있다면 AI는 그 구조를 증폭한다. 반대로 사양이나 판단이 모호하다면 그 모호함 또한 증폭된다.
그러므로 생성 AI 시대의 소프트웨어 엔지니어에게 요구되는 것은 AI에게 사고를 대행하게 하는 태도가 아니라, AI를 사용하여 자신의 사고를 외부화하고, 구조화하며, 검증 가능한 산출물로 변환하는 태도이다.
생성 AI를 배우는 것은 단순히 새로운 도구의 사용법을 배우는 것이 아니다. 그것은 자신의 사고, 설계, 검증 능력을 다시금 단련하는 것이기도 하다.
7. 보기: 생성 AI 평가의 어려움에 대하여
지금까지 서술한 내용은 필자가 이전에도 반복해서 말해온 내용이다. 그럼에도 불구하고 여전히 생성 AI를 제대로 활용하지 못하는 엔지니어나 조직은 적지 않다.
기업에서의 생성 AI (Generative AI) 도입에서도, "우선 사용해 본다", "몇 가지 업무에서 시도해 본다"와 같은 시행착오(Trial and Error)형 PoC (Proof of Concept)가 많다. 물론, 시도해 보는 것 자체가 나쁜 것은 아니다. 문제는 사양, 입력 조건, 평가 기준, 검증 방법이 고정되지 않은 채로 "사용할 수 있는지 여부"를 판단하려고 한다는 점에 있다.
이것은 조금 거칠게 말하자면, 두 개의 주사위를 동시에 던져 1이 나오기를 기대하는(기원하는) 상태에 가깝다.
AI가 우연히 좋은 출력을 내놓고, 평가자가 우연히 그것을 "좋다"라고 판단했을 때, PoC는 성공한 것처럼 보인다. 하지만 그 성공은 재현성(Reproducibility)을 갖지 못한다.
생성 AI의 평가에서 중요한 것은 시행 횟수를 늘리는 것이 아니라, 우연성을 줄이는 것이다. 입력, 제약, 기대 출력, 평가 기준, 검증 방법을 고정해야 비로소 생성 AI의 유효성을 재현성을 가지고 논의할 수 있다.
결국 생성 AI 활용이란, AI에게 무언가를 시켜보는 것이 아니라, AI의 변동성(Fluctuation)을 전제로 인간 측에서 평가 가능한 구조를 마련하는 것이라고 생각한다.
참고 문헌
[1] Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590.
[2] Brynjolfsson, E., Li, D., & Raymond, L. R. (2025). Generative AI at Work. The Quarterly Journal of Economics, 140(2), 889–942.
[3] Dell'Acqua, F., McFowland III, E., Mollick, E. R., Lifshitz-Assaf, H., Kellogg, K. C., Rajendran, S., Krayer, L., Candelon, F., & Lakhani, K. R. (2026). Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of Artificial Intelligence on Knowledge Worker Productivity and Quality. Organization Science. Published online March 11, 2026.
[4] Becker, J., Rush, N., Barnes, E., & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089.
[5] Lee, H.-P. (Hank), Sarkar, A., Tankelevitch, L., Drosos, I., Rintel, S., Banks, R., & Wilson, N. (2025). The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers. Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems, Article 1121, 1–22.
[6] Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł., & Polosukhin, I. (2017). Attention Is All You Need. Advances in Neural Information Processing Systems.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기