코드 작성은 전통적으로 소프트웨어 개발에서 항상 가장 많은 시간과 리소스가 소요되는 작업이었다. 그러나 AI가 등장하면서 변화하고 있으며, 그 변화의 속도는 대부분의 엔지니어링 조직이 충분히 준비하지 못할 만큼 빠르다. 클로드 코드, 커서 같은 툴은 이미 코드 구성의 상당 부분을 처리해서 개발자가 요구사항, 아키텍처, 설계에 더 많은 시간을 할애할 수 있게 해준다.

그러나 이 변화에는 새로운 과제가 따른다. AI가 힘든 일을 맡아 처리하면서 가장 중요한 기술은 상향 이동하고 있다. 즉, 이제는 프롬프트에 적절한 컨텍스트를 제공하는 방법, 모델이 생성한 결과물을 평가하는 방법, 그리고 자신 있게 말하지만 틀린 AI의 답변에 속지 않을 정도로 문제를 심층적으로 이해하는 방법이 가장 중요하다.

이러한 세 가지 기술, 그리고 이를 마스터한 개발자가 그렇지 못한 개발자에 비해 상당한 경쟁 우위를 점하게 될 이유를 살펴보자.

코딩을 넘어 : 프롬프트 기술 마스터하기

컴파일러, 어셈블러와 같은 소프트웨어 번역 툴은 고수준 코드 설명을 실행에 적합한 저수준 표현으로 매핑한다. 코딩 생산성의 첫 번째 비약적인 향상은 이러한 툴의 계층화에서 비롯됐다. AI 프롬프트 엔지니어링은 컴파일러와 어셈블러 위에 위치하는 차세대 계층형 번역 소프트웨어를 의미한다. AI 코드 생성이 도입되면서, 초점은 좋은 코드 작성에서 좋은 프롬프트 작성으로 이동하게 된다.

좋은 프롬프트를 구성하는 요소는 무엇일까? 바로 좋은 컨텍스트다. 그렇다면 무엇이 최선의 컨텍스트를 제공할까? 가장 중요한 점은 소프트웨어가 수행해야 할 작업을 개발자가 잘 이해해야 한다는 것이다. 일반적인 소프트웨어 모듈을 작성하는 데 필요한 사항을 고려할 때 프롬프트는 다음과 같은 요소를 포함해야 한다.

• 예상 입력과 출력(예를 들어 소프트웨어의 핵심 기능)
• 오류 및 예외 조건과 그 처리 방법
• 성능 기대치
• 소프트웨어를 둘러싼 기존 프레임워크 및 사용되는 프로그래밍 언어
• 사용자가 기대하는 인터페이스
• 필요한 스토리지, 컴퓨팅 및 네트워크 리소스

시스템 설계가 컨텍스트에 미치는 영향

새로운 이니셔티브에서 이 모듈에 대한 컨텍스트는 세부적인 시스템 설계에서 가져와야 한다. 시스템 설계는 본질적으로 소프트웨어의 청사진이며, 전체 설계를 더 작고 개별 부위, 즉 모듈로 나누는 방식으로 생성된다. 각 모듈은 소프트웨어가 제공해야 하는 특정 기능을 담당한다. 마이크로서비스 구현에서 도메인 주도 설계는 비즈니스 요구사항을 마이크로서비스로 매핑할 수 있는 개별적인 하위 도메인으로 분할한다.

좋은 시스템 설계에는 예를 들어 모듈이 어떻게 함께 작동해 기능적 요구사항을 충족하는지와 같은 운영 개념을 제공하는 일관적인 아키텍처가 있다. 최선의 시스템 설계는 잘 파악된 요구사항과 적절한 아키텍처가 결합될 때 탄생한다.

역방향으로 작업하면서 프롬프트에 컨텍스트를 구축해 넣음으로써 우리는 요구사항 분석(소프트웨어가 무엇을 해야 하는가)과 아키텍처 및 시스템 설계(그것을 어떻게 하는가)를 포함한 개발 수명 주기에서 가장 중요한 단계를 발견했다.

선형적 소프트웨어 수명 주기의 예.

Confluent

한 번의 설계 과정으로 될 수도 있지만 많은 경우 개발자들은 최선의 결과를 얻기 위해 설계를 반복해야 한다. 많은 소프트웨어 전문가들이 오랜 시간 동안 이를 강조했는데, 특히 유명한 컴퓨터 과학자 프레드 브룩스는 “버릴 계획을 세워라. 어차피 버리게 될 것이다”라는 말로 이를 잘 표현했다.

반복적 소프트웨어 수명 주기의 예.

Confluent

나선형, 진화적 프로토타이핑과 같은 반복적 수명 주기는 “버리는” 부분을 프로세스에 내장한다. 무언가를 버린다는 말은 낭비처럼 들릴 수 있지만, 각 반복은 사용자 요구사항, 아키텍처의 한계, 위험, 기회 등 문제에 대한 더 깊은 이해를 구축한다. 각 반복에서 습득하는 내용에 따라 최종 제품의 비용과 복잡성이 대폭 줄어든다.

AI 툴이 개발자 생산성에 미치는 영향

AI 번역 툴은 개발자의 생산성을 높여줄 잠재력이 있지만 개발자가 게을러지고 툴에 의존하게 될 위험도 초래한다. 최근 한 연구에 따르면 LLM의 도움을 받아서 에세이를 쓰면 LLM의 도움 없이 에세이를 쓰는 경우에 비해 작업과 관련된 인지 에너지가 줄어드는 것으로 나타났다. 이 효과를 “인지 부채(cognitive debt)”라고 한다.

필자는 지나치게 편리한 현대 생활에 대처하기 위해 근력 트레이너와 함께 운동한다. 현대 생활에서는 무거운 물건을 들거나 격렬한 활동이 불필요하므로 근력과 건강을 향상시키기 위해서는 그러한 활동을 시뮬레이션해야 한다. AI 코딩 툴은 코드 생성이라는 힘든 일을 개발자를 대신해 수행하는 로봇과 같다. 인간은 극복해야 할 과제가 없으면 점점 더 약해진다.

현대 코딩과 AI 툴

AI 툴을 사용하는 동안 뇌를 계속 열심히 사용할 방법을 찾아야 한다. 그래야 소프트웨어 설계와 개발 작업에서 직면하는 어려운 문제에 대해 생각할 수 있는 능력을 유지할 수 있다.

최적화된 어셈블리 코드를 작성하는 데 시간을 투자하는 것은 이제 낭비다. 그 부분은 컴파일러가 워낙 뛰어나기 때문이다. 그러나 최근까지도 자바, 고, 파이썬으로 컴파일러나 런타임 엔진을 위한 좋은 코드를 작성하는 것은 중요한 기술이었다. 사실 이러한 기술은 LLM이 코드 생성을 지원하더라도 여전히 중요할 것이다. 개발자는 생성된 코드를 검토하고 LLM 출력이 특정 표준을 충족하는지 확인해야 하기 때문이다. 오랜 기간 코드를 작성하며 경험을 쌓은 개발자들은 이미 이러한 기술을 보유하고 있다. 신규 개발자와 기존 개발자 모두 새로운 기법과 아이디어를 접하게 해주는 LLM 툴을 통해 배우고 지식을 확장할 수 있다.

직접 코딩이 일부 대체되더라도 LLM이 생성한 코드에 대한 이해와 판단력을 유지하기 위한, 코딩에 있어서의 근력 트레이닝에 상응하는 것을 찾아야 한다. 뇌를 어떻게 사용해야 인지 부채를 피할 수 있을까?

인지 부채의 위험 피하기

첫째, 프롬프트를 통해 생성된 코드를 학습하고 이해하라. 그런 다음 프롬프트를 재작성해서 생성된 코드를 개선하거나, 필요한 수준에 충분히 근접한 코드가 생성됐다면 코드를 직접 재작성하라. LLM은 통계적으로 작동하므로 생성된 코드가 설계 목표를 충족하지 못하는 경우는 얼마든지 발생할 수 있다. LLM의 가스라이팅은 실재한다. LLM이 생성한 코드가 실행되지 않거나 올바르지 않은 경우가 매우 흔하지만, LLM은 모든 것이 문제없다고 자신 있게 주장할 것이다. LLM의 말을 신뢰하지 말고 항상 검증하라.

LLM은 동일하거나 약간 다른 프롬프트로 대안적인 설계를 생성할 수 있다. 많은 개발자가 이미 이 기능을 활용해 설계 공간을 탐색한다. 생성된 코드를 이해하고 수정하는 데 노력을 기울여야 한다. 그러면 코딩 기술을 유지할 수 있다.

둘째, 프롬프트 엔지니어링의 초점은 LLM에 컨텍스트를 제공하는 데 있다. 따라서 이 컨텍스트를 생성하고 생성된 코드를 이해하고 판단하는 능력이 핵심이 된다. 소프트웨어 전문가는 기존의 언어 및 코딩 기술을 유지하는 것 외에, 프롬프트를 위한 고품질의 컨텍스트를 확보하기 위해 다른 수명 주기 요소, 특히 요구사항과 아키텍처, 설계에 집중해야 한다.

셋째, 새로운 언어와 데이터 모델을 배우고 각각 어디에 가장 적합한지 이해하라.

넷째, 언어 독립적인 코드 구성과 설계의 모범 사례에 대한 이해를 쌓아 다양한 언어에 걸쳐 적용되는 모범 사례를 사용해 생성된 코드를 판단할 수 있어야 한다.

경쟁력을 유지하려면 기준이 높아진다는 사실을 인식해야 한다. 한 연구에 따르면 역사적으로 가장 생산적인 개발자는 가장 생산성이 낮은 개발자보다 이미 약 10배 더 효율적이며, 최상위 팀은 최하위 팀보다 약 5배 더 뛰어나다. AI 툴은 이 차이를 2~3배 더 벌려 생산성 격차를 더욱 확대할 수 있다. 이러한 고생산성 팀의 상당수는 여러분의 경쟁사에서 일하는 팀이다.

AI는 요구사항, 아키텍처, 설계를 명확하게 구체화할 수 있는 개발자와 팀이 프로젝트에 다양한 언어와 데이터 모델을 신속하게 적용하고 평가할 수 있게 해줄 것이다. AI는 각 반복에서 병렬 개발 경로를 통해 나선형 및 진화적 프로토타이핑과 같은 반복적 수명 주기의 효율성을 대폭 높여줄 것이다. 성공의 열쇠는 코드 복잡성에 대한 통제력을 잃지 않으면서 더 높은 수준의 설계 문제에 집중할 수 있도록 AI를 활용하는 것이다. 이러한 고수준 기술을 배우지 않는다면, 이를 배우는 개발자와 팀에 비해 훨씬 더 생산성이 떨어지게 된다.

병렬 경로와 피드백 루프가 포함된 반복적 수명 주기.

Confluent

우발적 복잡성 Vs. 본질적 복잡성

일각에서는 AI가 소프트웨어 생산성을 획기적으로 향상시킬 것이라고 주장한다. 이들이 상상하는 미래에서는 소프트웨어 개발자가 프롬프트 몇 개만 작성하면 LLM이 기존 SaaS 제품을 대체할 수 있는 소프트웨어를 생산한다. 그러나 프레드 브룩스가 1986년 유명한 논문인 ‘만능 해결책은 없다’에서 주장한 바와 같이, 우발적 복잡성과 본질적 복잡성이라는 두 가지 유형의 복잡성이 남아 있기 때문에 이는 여전히 불가능하다.

우발적 복잡성(또는 ‘사고’)

사고는 문제 자체가 아니라, 소프트웨어를 구축하기 위해 사용되는 툴, 언어, 하드웨어 한계와 구현 세부 사항을 포함한 프로덕션 프로세스에 내재한다. 역사적으로 대부분의 생산성 향상은 우발적 복잡성을 줄이는 데서 이뤄졌다. AI 생산성은 우발적 복잡성을 줄일 수 있지만 개발자는 환각, 저품질 코드를 포함한 AI 자체의 과제에 대처해야 한다.

본질적 복잡성(또는 ‘본질’)

본질은 문제 자체의 내재적이고 피할 수 없는 복잡성을 의미한다. 소프트웨어가 해결해야 하는 현실 세계의 문제를 정확하게 모델링하는 “복잡한 개념적 구성물(예를 들어 추상적이고 서로 맞물린 개념, 데이터 관계, 알고리즘, 동작 등)을 형성”하는 과제다.

AI가 만능 해결책이 될 수 없는 이유는 소프트웨어의 내재적 복잡성에 있다. 모든 우발적 작업에 소요되는 시간을 0으로 줄일 수 있다 해도 본질적인 작업은 여전히 개발자의 가장 큰 과제로 남아 대부분의 노력이 투입되는 영역이 될 것이다. 그럼에도 불구하고 AI는 강력한 툴이다. 적절히 사용해서 복잡성을 관리하고 설계 공간을 탐색한다면 팀의 생산성과 개발된 소프트웨어의 품질을 크게 높일 수 있다.
dl-itworldkorea@foundryco.com