인공지능 때문에 곧 해고될 것이라는 말은 농담처럼 들릴 수도 있지만, 많은 개발자가 겪고 있는 불안한 현실입니다. 미래를 향해 나아가는 지금, AI는 더 이상 코드를 작성하는 것이 아니라 코더를 대체하고 있습니다.
마이크로소프트의 사티아 나델라는 최근 마이크로소프트 코드의 거의 Microsoft 코드의 30% 의 약 30%가 Copilot과 같은 AI 도구로 작성된다고 밝혔습니다. 이 통계가 공개된 지 며칠 후, Microsoft는 충격적인 소식을 전했습니다. 2,000명의 직원을 해고. 이것이 우연의 일치일까요, 아니면 코드의 30%가 AI라는 점과 직원 해고 사이에 연관성이 있을까요?
이러한 우연의 일치 현상은 비단 Microsoft에만 국한된 것이 아닙니다. CloudStrike, IBM 등에서도 비슷한 현상을 볼 수 있습니다. 심지어 골드만삭스의 예측에 따르면 몇 년 전만 해도 200만 명에 가까운 엔지니어가 부족했던 산업에서 최대 3억 개의 일자리가 AI로 대체될 것이라고 예측했습니다.
기술 업계가 일자리 소멸에 대해 공포에 휩싸인 것은 이번이 처음이 아닙니다.
Java 바이트코드든 클라우드로의 마이그레이션이든, 개발자들은 새로운 기술이 등장하면 항상 회의와 두려움, 저항에 직면해 왔습니다. 하지만 이번에는 다릅니다. 그 이유는 무엇일까요?
이번에는 단순한 자동화가 아니라 예측할 수 없는 결과를 만들어내는 도구를 다루고 있기 때문입니다. 이러한 도구는 환각을 불러일으킵니다. 빠를 수는 있지만 신뢰할 수 있는 것은 아닙니다. 그럼에도 불구하고 프로덕션 수준의 코드를 생성하는 데 신뢰받고 있습니다.
이 글에서는 이러한 긴장감을 살펴보고 인텐트 무결성 체인이라는 것이 통제력을 잃지 않고 AI를 이겨낼 수 있는 최선의 선택이 될 수 있는 이유를 살펴봅니다. 시작해 보겠습니다!
패닉과 진전 - 계속되는 사이클
소프트웨어 개발에서 AI를 둘러싼 공포는 새로운 것처럼 보일 수 있지만 그렇지 않습니다. 사실 Java, SaaS 도구 사용, 클라우드로의 전환 등 기술의 모든 추상화에는 항상 의심이 뒤따릅니다.
엔지니어들이 Java 바이트코드를 신뢰할 수 있는지 의문을 제기하던 시절이 있었습니다. 클라우드 컴퓨팅이 민감한 데이터에 너무 위험하다고 생각하는 사람들도 있었습니다. 이러한 저항은 항상 존재했지만, 그럼에도 불구하고 지금까지의 모든 변화는 개발자들이 이전보다 더 나은 개발을 하는 데 도움이 되었습니다.
시간이 지남에 따라 추상화는 확장성의 근간이 되어 더 빠르고 복잡하며 탄력적인 시스템 개발로 이어집니다. 하지만 현재와 다른 점은 AI의 특성입니다. 기존의 추상화는 반복 가능한 일관된 동작을 유지하면서 복잡성을 단순화하는 데 중점을 두었습니다. 그러나 대규모 언어 모델(LLM)과 같은 발전은 무작위성을 위한 여지를 제공합니다.
LLM은 확률 기반으로 설계되었기 때문에 동일한 입력이 주어지더라도 모델에 따라 결과가 달라질 수 있습니다. 이러한 예측 불가능성은 과거의 추상화와는 다른 점입니다.
과거의 도구는 두려움과 저항을 불러일으키기도 했지만, 결정할 수 있는 프레임워크가 있었습니다. 이제 개발자는 LLM을 통해 매번 다르게 작동하는 시스템으로 작업하고 있으며, 이는 개발자가 이러한 모델이 생성하는 소프트웨어의 정확성과 신뢰성과 관련된 새로운 과제에 직면해야 한다는 것을 의미합니다.
LLM은 GPU를 장착한 원숭이일 뿐인가요?
이러한 인기에도 불구하고 소프트웨어 개발과 관련하여 LLM은 여전히 신뢰할 수 없는 존재입니다. 그들의 코드 생성 기능은 엔지니어가 직접 개발하는 것보다 시행착오를 거치는 것처럼 보입니다.
LLM은 정밀하고 지능적인 도구라기보다는 작동할 때까지 여러 가지를 시도하는 원숭이처럼 생각할 수 있습니다.
이러한 현실은 실제 개발에서 어떻게 구현될까요? 이러한 모델은 단순히 함수를 발명하고 패키지 이름을 조작하며 심지어 위험할 정도로 결함이 있는 로직을 생성하는 수많은 예가 있습니다.
예를 들어, LLM이 존재하지 않는 npm 라이브러리를 참조하고 악의적인 공격자가 이러한 가짜 이름을 사용하여 패키지를 등록함으로써 공급망 공격의 새로운 벡터를 도입했습니다.
많은 사람들이 이러한 위험을 이론적으로만 존재한다고 생각할 수 있지만 그렇지 않습니다. GitHub Copilot, Amazon CodeWhisperer, ChatGPT와 같은 주요 도구의 코드 품질 결과를 비교한 연구에 따르면 다음과 같습니다. 올바른 코드 생성 31%에서 65%에 불과하여 코드에 결함이 있는 경우가 거의 절반에 달합니다.
더 심각한 문제는 AI 코드의 40%가 취약했습니다.악용 가능한 결함이 포함되어 있고 기본적인 보안 관행을 따르지 않았기 때문입니다.
지금 생각해보면 이 문제는 부정확성만의 문제가 아니라는 것이 분명해집니다. 여기에는 잘못된 자신감도 포함됩니다. 이러한 도구는 결과가 잘못된 경우에도 높은 수준의 확실성을 가지고 코드를 제시합니다.
개발자가 속도를 위해 AI에 코드 최적화를 요청하는 경우가 있었습니다. 그 결과는? 이 모델은 성능을 위해 유효성 검사를 제거하거나 테스트 커버리지를 완전히 중단합니다.
이러한 점을 고려할 때 아직은 LLM이 인간을 대체할 수 없다고 말할 수 있습니다. 하지만 사용하는 사람의 의도와 능력을 증폭시킬 수 있는 도구입니다. 즉, 이러한 모델은 시스템과 맥락에 대한 이해가 부족하기 때문에 맹목적으로 신뢰할 수 없으며 인간의 판단이 그 어느 때보다 중요해졌습니다.
인텐트 무결성 체인
지금까지 살펴본 모든 내용을 고려할 때, 인공지능이 생성한 코드에 의존하는 것은 일련의 진화하는 위험을 수반한다는 것이 분명합니다. 인텐트 무결성 체인은 이러한 위험을 방지하고 개발자의 독창적인 아이디어가 기능적이고 신뢰할 수 있는 소프트웨어로 전환될 수 있도록 설계된 프레임워크입니다.
이 프레임워크의 기본 개념은 개발자의 아이디어와 최종 결과물 사이에 무언가가 손실된다는 것인데, 이를 번역 갭이라고 합니다. 이러한 갭은 프롬프트와 LLM 모델이 생성하는 최종 결과물 사이에 존재합니다. 이는 모델의 동작이 예측할 수 없고 즉흥성에 기반하기 때문에 발생하는 것으로, 입력된 내용이 출력물에 반영된다는 보장이 없습니다.
인텐트 무결성 체인은 네 가지 아티팩트를 중심으로 하는 다단계 프로세스를 통해 이 문제를 해결하는 데 도움을 줄 수 있습니다:
- 프롬프트 - 사람이 작성한 것으로, 원시적인 의도 또는 원하는 기능을 나타냅니다.
- 사양 - 구조화되고 표준화된 버전의 프롬프트로, 여전히 자연어로 되어 있지만 명확성과 일관성을 위해 형식이 지정되어 있습니다.
- 테스트 - 사양에서 자동으로 생성되는 테스트는 올바른 동작이 어떤 것인지 정의합니다.
- 코드 - 사양에 기반한 테스트를 통과하기 위해 LLM에서 생성한 코드입니다.
이 작업을 진행하기 전에 각 아티팩트가 체인에서 연결 고리 역할을 하지만 맹목적으로 신뢰할 수 없다는 점을 알아야 합니다.
프롬프트는 시작점일 뿐이므로 유효성 검사가 필요하지 않지만, 사람이 사양을 검토하여 프롬프트의 의도를 제대로 파악했는지 확인해야 합니다. 마찬가지로 테스트는 잠겨 있고 검증 가능해야 하며, LLM에서 생성된 코드는 잠긴 테스트를 통과한 경우에만 유효성을 검사해야 합니다.
이 구조는 기본적으로 모든 단계에 체크포인트를 도입하여 보안 결함 및 환각 기능의 위험을 줄이고 결과물이 사람의 의도와 일치하도록 보장합니다.
신뢰, 확인, 프롬프트
AI로 생성된 코드는 시간이 지날수록 점점 더 보편화되고 있습니다. 이러한 상황에서 가드레일을 구축하는 것은 모범 사례를 따르는 것이 아니라 생존을 위한 것입니다.
사양 및 테스트와 같이 명확하게 정의된 제약 조건이 없으면 LLM은 안전하지 않거나 완전히 깨진 소프트웨어를 생성할 수 있습니다. 또한 테스트 중심 개발(TDD) 및 동작 중심 개발(BDD)과 같은 기술은 초기 단계의 구조를 제공하지만 개발자가 테스트 작성보다 코드 작성에 편향되어 있어 채택에 어려움을 겪어왔습니다.
이제 개발과 AI가 트렌드를 넘어 하나의 문화로 자리 잡으면서 개발자가 습득할 수 있는 가장 중요한 기술은 인텐트 명료화입니다.
즉, 개발자는 이제 요구 사항을 정확하게 표현하고, 테스트 가능한 사양을 설계하고, LLM 결과물에 결함이 있는지 감사할 수 있는 즉각적인 엔지니어로 변모해야 합니다. 이러한 점을 고려할 때 오늘날의 기술 리더십은 구조화된 프롬프트와 제약 조건 검증을 통해 모델을 안내할 수 있는 능력을 갖추는 것이 더 중요해졌습니다.
공유된 이해와 미래 지향적인 기술 세트
Gherkin과 같은 구조화된 사양을 사용하면 인간과 기계 간의 오해를 줄일 수 있습니다. 이러한 사양은 코드는 아니지만 인간과 기계가 이해할 수 있을 만큼 형식적입니다.
사양을 테스트한 후 코딩하는 작업은 최종 결과물의 AI 오류를 줄이는 데 도움이 될 수 있지만, 그렇게 하려면 개발자의 사고 방식이 바뀌어야 합니다.
LLM을 전문가로 보는 시각을 버리고 의도를 증폭시키기 위한 도구로 생각해야 합니다. 그러나 초기 의도가 좋지 않으면 코드의 결과물도 좋지 않을 것입니다.
이를 염두에 두고 개발자가 미래를 대비하기 위해 역량을 강화하는 데 집중해야 하는 세 가지 핵심 기술에는 더 나은 프롬프트 작성, 결과물 검증, 명확한 사양 설계가 포함됩니다. 이 세 가지 핵심 기술을 개발하는 개발자는 커리어에서 더 효과적으로 일할 수 있는 기회를 얻을 수 있습니다. 그렇지 않은 사람은 결국 인공지능에 의해 대체될 수 있습니다.
최종 생각
AI는 이전에는 볼 수 없었던 방식으로 소프트웨어 개발을 변화시켜 왔고 앞으로도 계속 변화시킬 것입니다. 더 빠르고 효율적인 방식으로 코딩할 수 있지만, 그 결과물이 항상 의도한 대로 나오지 않거나 논리적 결함, 악용 가능한 취약점이 포함될 수 있습니다, 잘못 구성된 보안 정책 등이 포함되어 있습니다.
그러나 개발자는 인텐트 무결성 체인을 사용하여 구조와 검증을 통해 사람의 의도를 기계의 출력과 일치시켜 AI 코드가 의도한 대로 생성되도록 제어하고 보장할 수 있습니다.

