AI 시대의 소프트웨어 엔지니어
'소프트웨어’라는 단어를 사용할 때, 그것이 하나의 제품을 지칭한 것일지라도, 그 기반에는 제품이 의존하고 있는 거대한 소프트웨어 산업, 내지는 소프트웨어 생태계가 있다. 소프트웨어 산업이 지금처럼 성장한 이유는 다양한 문제를 하나의 소프트웨어로 해결할 수 없기 때문이다. 기능의 수와 소프트웨어의 복잡도는 비례하며 증가한다. 개인이나 조직이 감당할 수 없는 수준의 복잡도에 도달하면 더 이상 소프트웨어에 기능을 추가하거나 유지보수할 수 없게 된다. 다양한 문제에 다양한 제품이 필요하고, 원천 문제를 해결하기 위한 또 다른 제품이 필요하기 때문에 소프트웨어 산업은 단일 제품이 아니라 서로에게 의존하는 생태계로서 성장할 수 있었다.
AI가 소프트웨어 엔지니어의 존재를 위협하려면 소프트웨어 공학의 특정 분야나 단일 제품, 특정 산업 섹터가 아닌 소프트웨어 산업 전반을 위협할 수준에 도달해야 한다. 구체적으로는 다음과 같은 이유로, 지금은 AI가 소프트웨어 산업 전체를 위협할 수준이 아니다.
- AI가 출력하는 결과물은 코드 혹은 그 코드를 통해 실행되는 소프트웨어이기 때문에 다른 소프트웨어에 의존할 수밖에 없다. 생성 비용이 높기 때문에 생성한 코드의 복잡도를 장기적으로 관리해야 한다. 소프트웨어를 유지보수해야 하는 순간 소프트웨어 공학적으로 접근할 수밖에 없다.
- 소프트웨어의 구조와 기술적인 제약을 결정해 AI에게 입력해야 한다. AI에게 추상적인 요구사항을 입력하면 추상적인 결과물이 만들어진다. 결과물이 엣지 케이스를 처리하지 못하고, 잠재적인 위험을 고려하지 않아 리소스에 누수가 일어나거나 과도한 비용이 발생한다.
- AI가 출력하는 결과물의 품질이 일관되지 않고, 충분히 신뢰할 수 없다[1]. 문제가 발생하면 결국 AI가 생성한 코드를 확인하고 원인을 규명해야 하는 순간이 온다. 특히 AI가 브라운필드에서 구축한 소프트웨어에는 결함이 많다.
수년 안에는 AI가 일관되게 높은 품질의 코드를 출력할 수 있을 것처럼 보인다. AI가 생성한 코드는 대부분 문제없이 동작하기 때문에 코드는 사실상 블랙박스에 가까워진다. 인지 부채를 줄이기 위해 고안된 각종 프로그래밍 전술과 읽기 좋은 코드를 위한 관례는 AI의 효율을 높이기 위한 부차적인 요소가 된다. 이제 AI가 '좋은 코드’를 작성하기 때문에 소프트웨어 엔지니어는 더 이상 좋은 코드에 대해 고민하지 않는다. 중요한 점은 AI의 출력물이 결국 인간이 쌓아 올린 소프트웨어 생태계의 위에서 동작하는 또 다른 소프트웨어라는 것이다. 때문에 여전히 첫 번째와 두 번째 문제를 완전히 해결하지 못한다. 소프트웨어 엔지니어의 업무에서 코드를 작성하거나 읽는 데 들이는 시간이 현저히 줄어들거나 아예 사라지겠지만, 구현은 애초에 소프트웨어 엔지니어 업무의 일부에 불과했다. AI의 출력이 소프트웨어라면, 이전과 비교할 수 없을 정도로 많은 소프트웨어가 만들어질 것이다. 성장하는 소프트웨어의 복잡성을 관리하는 것은 소프트웨어 공학이 다뤄온 핵심 주제였다. 앞으로 훨씬 많은 소프트웨어가 만들어진다면 오히려 소프트웨어 공학에 대한 전문성을 갖춘 엔지니어의 역할은 더욱 중요해질 것이다.
더 나아가서, 만약 하나의 AI 모델 혹은 그 모델을 사용하는 하나의 소프트웨어가 모든 문제를 광범위하게 해결할 수 있다면 소프트웨어 산업은 지금과는 전혀 다른 모습이 될 것이다. 이때는 AI가 소프트웨어를 완전히 추상화할 수 있다. AI가 사용자의 요구사항을 입력받아 즉시 실행 가능한 소프트웨어를 출력하는 함수인 셈이다. 모든 사용자가 각자의 고유한 문제를 해결하기 위해 고유한 소프트웨어를 빠르게 만들어 사용한다면 소프트웨어를 배포할 필요가 없다. 소프트웨어를 장기적으로 유지보수할 필요도 없고, 다른 소프트웨어에 의존할 필요도 없다. SaaS는 종말을 맞고, AI 제품을 서빙하는 플랫폼이 소프트웨어의 전부일 것이다.
소프트웨어 엔지니어의 미래를 고민하는 이들은 AI의 최대 수준을 상상하곤 한다. 미래에 대해 이야기할 때는 상한을 잘 설정해야 한다. 그렇지 않으면 언젠가는 초월적인 능력을 가진 만능 기계가 등장해 모든 문제를 해결할 것이라는 결론에 이르기 십상이다. 그런 결론은 실용적이지도 않고, 증명도 불가능하다. 'AI가 소프트웨어 엔지니어를 대체할 것인가?'라는 질문에 대한 답을 구하는 이유는 흥미진진한 미래 세상을 상상하기 위한 것이 아니라, 현재를 살아가는 소프트웨어 엔지니어에게 실용적인 방향을 제시하기 위한 것이다.
추상적인 비즈니스 요구사항을 입력하면 즉시 실행 가능한, 완벽히 동작하는 소프트웨어를 만드는 AI가 나타날까? 언젠가는 등장할 수도 있겠지만, 그 AI가 지금처럼 사전 학습한 뒤 RLHF로 미세 조정된 LLM은 아닐 것[2]이라는 의견에 동의한다. LLM은 세상을 시뮬레이션하는 모델이 아니기 때문에 복잡한 현실 문제를 다루는 데 태생적인 한계를 안고 있다. 그 한계를 넘어서지 못하는 이상, 현실 문제를 소프트웨어로 해결하는 방법을 고민하는 것, 그 소프트웨어를 어떻게 구축할지 설계하는 것, 만들어진 소프트웨어를 검증하는 것, 그 소프트웨어를 안정적으로 운영하는 것은 인간의 몫일 것이다. 우리는 지금까지 그런 일을 하는 사람들을 소프트웨어 엔지니어라고 불러왔다.
AI 사용 패턴 기록
이런 시대에는 아무나 그럴듯한 예언을 할 수 있다. 예언을 하고 싶지는 않으니 나의 AI 사용 패턴을 기록해본다.
2024년 12월
GitHub Copilot으로 코드 스니펫을 자동 완성한다. 주석이나 함수 시그니처를 작성해두면 내용은 AI가 완성해준다. AI가 작성한 코드가 완전하지 않기 때문에 반드시 수정해야 한다. 대부분의 코드는 내가 작성한다.
2025년 4월
ChatGPT를 사용한다. 요구사항을 입력하면 AI가 코드를 제시한다. 이 코드를 실제로 사용하려면 내가 사용하는 에디터에 복사-붙여넣기해야 한다. 실수가 많고, 작동하지 않는 코드를 작성하기도 한다. 대부분의 코드를 AI가 작성하지만, 내가 컨텍스트를 일일이 설명해야 한다. AI의 실수를 고치는 것보다 내가 직접 구현하는 편이 빠르다.
2025년 5월
Cursor와 Zed 같은 AI 에디터를 사용한다. 개발 요구 사항을 입력하면 AI가 코드베이스 전체를 탐색해 편집한다. 대부분의 코드를 AI가 작성하지만, 모든 변경사항을 내가 검토하고 승인한다. 내가 전체적인 구조를 설계하고, 스켈레톤 코드를 작성해두지 않으면 AI는 많은 실수를 한다.
2025년 8월
Claude Code를 사용한다. 기술적인 요구 사항을 추상적으로 입력하면 AI가 모든 코드베이스를 훑고, 각종 도구를 이용해 구체적인 기능을 구현한다. 많은 코드를 AI가 작성하지만, 초기에 내가 잘못된 설계를 입력하거나 AI가 잘못 접근해 구현하는 경우 초기 가정에서 벗어나지 못한다. 도구나 기능을 구현할 수 있지만, 한 번에 완벽히 구현하지는 못한다.
2026년 2월
여전히 Claude Code를 사용한다. 요구사항을 잘 정리해서 계획서를 작성하게 하고, 여러 번 그 계획을 검토하게 한다. 계획서 작성에 구현보다 훨씬 많은 시간을 쓴다. 문제 상황을 입력하면 설계부터 구현까지 AI가 담당한다. 슬랙 링크나 리니어 이슈 번호를 입력하면 AI가 스스로 맥락을 파악한다. 거의 모든 코드를 AI가 작성한다. 코드 품질은 그리 좋지 않은데, 애초에 코드 품질이 예전만큼 중요치 않다고 느낀다.
엣지 케이스나 잠재적인 위험에는 잘 대응하지 못한다. 이를 극복하기 위해 계획 단계에 반드시 계획의 각 부분을 실증하게 하고, 인공지능 코딩을 위한 테스트 주도 개발을 한다. (다만 테스트도 AI가 작성한다.) 계획을 잘 작성하면 한 번에 구현이 끝나는 경우도 많다.
복잡한 워크플로우나 정책은 내가 많은 부분을 결정해야 하고, 나의 기술 이해가 완성도에 많은 영향을 미친다. 오래된 히스토리와 복잡한 맥락이 엮여 있으면 AI는 국소적인 해결책만 제시한다. 여러 조직에 걸친 의사 결정은 사람이 해야 한다. 예를 들어, 네이티브 모바일 앱이 웹뷰의 HTTP 요청을 가로채 헤더에 토큰을 주입하는 인증 방식으로 인해 웹뷰의 앞으로가기/뒤로가기 동작에 문제가 있는 경우, AI는 주어진 문제 해결에만 천착해 근본적인 대안을 제시하지 못한다. 사람은 기존의 토큰 인증 방식 대신 mTLS 인증 방식을 고려한다. 이 의사결정에는 앞으로가기/뒤로가기라는 현재 문제뿐만 아니라, 시스템 운영과 설계 측면에서의 장기적인 관점이 동기로 작용한다. 사람은 네이티브 앱, 웹뷰, 서버, 인프라 등 소프트웨어를 구성하는 모든 레이어에서 어떤 변경이 필요한지 계획한다.
관련문서
- AI 시대에 살아남기
- 인공지능
- 『프롬프트 엔지니어링』
- 『Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity』
- 『Towards a Science of AI Agent Reliability』
- 『Welcome to the Era of Experience』
- 『지능의 기원』