AI 시대의 컴퓨터공학
AI가 코드를 쓰기 시작하자, 많은 사람이 가장 먼저 이런 질문을 던졌다. 이제 개발자는 덜 필요해지는 걸까?
표면만 보면 그렇게 보일 수도 있다. 실제로 많은 개발자가 이미 AI 코딩 도구를 일상적으로 사용하고 있고, 코드 초안을 만드는 속도도 크게 빨라졌다.1 하지만 현장에서 벌어지는 일은 조금 다르다. 코드를 쓰는 일은 빨라졌지만, 무엇을 만들어야 하는지 정하고, 그것이 정말 맞는지 검증하고, 기존 시스템과 안전하게 연결하는 일은 오히려 더 중요해졌다.
쉽게 말해, AI는 개발자의 일을 없애기보다 위로 끌어올린다. 손으로 한 줄씩 구현하던 시간을 줄여 주는 대신, 더 높은 층위의 판단을 요구한다. 예전에는 "이 함수를 어떻게 작성하지?"가 핵심 질문이었다면, 이제는 "이 기능이 정말 필요한가?", "이 출력을 믿어도 되는가?", "이 시스템은 장애가 나면 어디서 무너지는가?"가 더 중요한 질문이 된다.
이 장에서는 바로 그 변화를 살펴본다. AI가 코딩을 어떻게 바꾸는지, 개발자의 역할이 무엇으로 재편되는지, 그리고 왜 알고리즘·운영체제·네트워크·데이터베이스·분산 시스템 같은 오래된 CS 주제가 여전히 중심에 남는지 차근차근 연결해 보자.
AI가 코딩을 바꾸는 방식
AI 코딩 도구의 가장 큰 변화는 첫 초안의 비용을 크게 낮췄다는 데 있다. 반복적인 보일러플레이트 코드, 비슷한 CRUD API, 테스트 초안, 간단한 문서화는 이제 예전보다 훨씬 빠르게 만들어진다.1 그래서 개발자는 빈 파일에서 시작하는 시간이 줄어든다.
하지만 여기서 착각하면 안 된다. 초안을 빨리 만드는 것과 제대로 동작하는 시스템을 만드는 것은 전혀 다른 문제다. AI는 로그인 화면을 금방 만들 수 있다. 하지만 그 로그인 기능이 실제 서비스에서 안전하게 작동하려면 세션 관리, 토큰 저장 위치, 비밀번호 정책, 속도 제한, 감사 로그, 개인정보 처리, 장애 대응까지 함께 설계되어야 한다. 데모는 몇 분 만에 나올 수 있지만, 서비스는 여전히 공학이다.
그래서 AI 시대에는 병목이 아래에서 위로 이동한다. 구현 속도가 올라갈수록, 오히려 다음 네 가지가 더 중요해진다.
무엇을 만들 것인가를 정의하는 일
그것이 맞는지 평가 기준을 세우는 일
기존 시스템과 충돌 없이 통합하는 일
실패했을 때 복구하고 책임지는 일
이 변화 때문에 개발자의 역할은 점점 "타이핑하는 사람"보다 "오케스트라를 지휘하는 사람"에 가까워진다. GitHub와 Thoughtworks 같은 곳에서도 개발자의 일이 순수한 작성보다 정의, 리뷰, 테스트, 조율, 시스템 이해 쪽으로 이동하고 있다고 본다.23
재미있는 점은, 이 변화가 개발자를 덜 중요하게 만들지 않는다는 것이다. 오히려 판단력이 있는 개발자와 없는 개발자의 차이를 더 크게 만든다. AI는 코드를 많이 제안한다. 그러나 어떤 코드를 받아들이고, 어떤 코드를 버리고, 무엇을 다시 묻고, 어디를 의심해야 하는지는 여전히 사람의 몫이다.
한마디로 정리하면 이렇다. AI는 구현을 더 싸고 빠르게 만들었고, 그 결과 설계와 검증은 더 비싸고 더 중요해졌다.
개발자의 역할은 어떻게 바뀌는가
AI 시대의 개발자는 단순한 구현자가 아니라, 문제를 계산 가능한 형태로 다시 정의하고 시스템 전체를 책임지는 사람으로 이동한다. 역할의 중심이 바뀌는 것이다.
먼저 중요해지는 것은 문제 정의 능력이다. AI는 마음을 읽지 못한다. 맥락이 흐리면 흐린 결과를 내놓고, 애매한 요청에는 애매한 코드를 돌려준다. 그래서 좋은 개발자는 "로그인 만들어 줘"라고 말하는 대신, 사용자 유형, 권한 구조, 실패 조건, 예외 흐름, 보안 요구사항, 기존 API 계약까지 포함한 맥락을 구조화해 전달한다. AI가 강해질수록, 오히려 더 정확한 요구사항을 만드는 사람이 강해진다.2
그다음으로 중요해지는 것은 평가 설계 능력이다. 전통적인 프로그램은 보통 컴파일이 되거나 안 되거나, 테스트를 통과하거나 실패하거나, 비교적 분명한 기준이 있었다. 하지만 AI가 포함된 시스템은 다르다. 챗봇의 답변은 "그럴듯하지만 틀릴" 수 있고, 요약기는 사실을 누락할 수 있으며, 추천 시스템은 편향된 결과를 낼 수 있다. 그래서 이제 개발자는 코드를 쓰는 사람일 뿐 아니라, 무엇을 좋은 출력으로 볼지 기준을 세우는 사람이어야 한다.
예를 들어 문서 요약 기능을 만든다고 해보자. 이 기능의 성공은 단순히 API 호출이 성공했는지로 판단할 수 없다. 핵심 정보가 남았는지, 허위 내용이 섞이지 않았는지, 금지 표현이 들어가지 않았는지, 응답 시간이 허용 범위 안인지, 비용이 감당 가능한 수준인지까지 함께 봐야 한다. AI 시대에는 "테스트 코드"만이 아니라 "평가 프레임"이 중요해진다.
세 번째는 시스템 통합 능력이다. 좋은 AI 제품은 모델 하나로 완성되지 않는다. 모델은 검색과 붙고, 데이터베이스와 붙고, 인증 시스템과 붙고, 캐시와 붙고, 큐와 붙고, 관측 도구와 붙는다. 그래서 단순 문법 암기보다 AI 보조 개발, API 및 시스템 통합, AI 출력 평가, 배포와 운영 감각이 더 중요해진다.3
네 번째는 보안 감수성이다. AI가 코드를 빨리 만들 수 있다는 말은, 보안 구멍도 빨리 만들 수 있다는 뜻이다. 인증이 빠진 관리자 API, 민감한 프롬프트를 그대로 로그에 남기는 서버, 권한 검증 없이 사내 문서를 검색하는 챗봇은 모두 "빨리 만든 결과물"로 등장하기 쉽다. 특히 AI 시스템은 사용자 질문, 내부 문서, API 키, 대화 로그처럼 민감한 자산을 많이 다루기 때문에, 보안은 마지막 점검 항목이 아니라 처음 설계 항목이어야 한다.
이 변화는 주니어 개발자에게도 그대로 적용된다. 엔트리 레벨 채용이 쉬운 시기는 아닐 수 있다. 하지만 그렇다고 주니어가 불필요해진 것은 아니다. 오히려 AI 도구를 잘 쓰는 주니어는 더 빨리 기여할 수 있고, 더 빨리 상위 수준의 사고를 훈련할 수 있다. 다만 전제 조건이 있다. 기초가 있어야 한다는 것이다. 기초 없이는 AI의 출력을 검토할 수 없다.
결국 개발자의 역할 변화는 이렇게 요약할 수 있다. 예전보다 덜 쓰고, 더 많이 묻고, 더 엄격하게 검증하고, 더 넓게 연결하는 사람. 그것이 AI 시대의 개발자다.
AI 제품을 만들수록 CS가 다시 중심에 온다
여기서 역설이 하나 나온다. AI 시대에는 AI만 잘 알면 될 것 같지만, 실제로는 전통적인 CS를 더 깊게 이해한 사람이 더 멀리 간다.
이유는 단순하다. AI 제품도 결국 소프트웨어 시스템이기 때문이다.
알고리즘과 자료구조는 여전히 중요하다. 검색 결과를 어떻게 정렬할지, 캐시를 어떤 정책으로 둘지, 벡터 검색과 키워드 검색을 어떻게 조합할지, 대량 요청을 어떤 큐 전략으로 처리할지는 모두 성능과 비용을 바꾼다. AI가 코드를 써 줘도, 시간복잡도와 메모리 사용을 읽을 줄 모르면 그 코드는 쉽게 비싸고 느린 코드가 된다.
운영체제와 컴퓨터 구조는 AI 시스템에서 더 자주 얼굴을 드러낸다. 모델 서빙에서는 메모리 부족이 바로 장애가 되고, 병렬 처리 방식이 처리량을 바꾸며, 프로세스와 스레드의 차이가 성능을 좌우한다. 학습 쪽으로 가면 더 노골적이다. 데이터 로더의 멀티프로세싱, 부동소수점 표현 때문에 생기는 수치 불안정성, GPU 메모리 병목 같은 문제는 라이브러리 사용법만 알아서는 해결하기 어렵다.
네트워크도 핵심이다. 외부 모델 API를 호출할 때는 지연 시간과 재시도 정책이 중요하고, 스트리밍 응답에서는 백프레셔를 고려해야 하며, 분산 학습이나 다수의 추론 서버를 운영할 때는 처리량과 네트워크 병목이 현실 문제가 된다. 화면에서는 챗봇이 "생각 중..."이라고 보이지만, 그 뒤에서는 타임아웃, 연결 풀, 패킷 손실, 혼잡 제어 같은 고전적인 네트워크 문제가 그대로 움직인다.
데이터베이스는 더 말할 것도 없다. 사용자 대화 기록, 임베딩, 메타데이터, 피드백 로그, 평가 결과, 비용 추적 데이터까지 모두 저장해야 한다. 어떤 데이터는 관계형 구조가 적합하고, 어떤 데이터는 문서형이나 벡터 인덱스가 더 잘 맞는다. 그리고 벡터 검색이 유행해도, 정확한 필터링과 메타데이터 조회를 떠받치는 기본 저장 구조와 인덱싱 감각은 사라지지 않는다.
분산 시스템은 AI 제품이 커질수록 피할 수 없다. 트래픽이 몰리면 모델 서버를 여러 대로 늘려야 하고, 요청은 큐에 쌓이며, 캐시가 없으면 비용이 폭발한다. 일부 요청은 결국 늦게 끝나거나 실패한다. 그러면 재시도 정책을 둘지, 부분 실패를 허용할지, 최종적 일관성을 받아들일지 같은 판단이 필요해진다. AI 기능이 들어갔다고 해서 분산 시스템의 어려움이 사라지는 것이 아니라, 오히려 더 자주 나타난다.
즉, AI 제품 개발은 새로운 세상이 아니라, 이 책 앞부분에서 다뤘던 세계들이 다시 한자리에 모이는 장면이다. 알고리즘은 응답 비용을 줄이고, 운영체제는 실행 자원을 관리하며, 네트워크는 모델과 서비스를 연결하고, 데이터베이스는 기억을 저장하며, 분산 시스템은 규모를 감당한다. AI는 그 위에 올라간 새로운 층일 뿐이다.
앞으로 무엇을 배워야 하는가
그렇다면 이제 현실적인 질문이 남는다. 앞으로는 무엇을 배워야 할까?
답은 "무조건 AI만 배워라"도 아니고, "예전 방식만 고수하라"도 아니다. 더 현실적인 답은 이렇다. 기초를 단단히 하고, AI를 그 위에 얹어라.
학습 순서는 대체로 다음과 같이 잡는 편이 좋다.
먼저 한 가지 언어와 런타임을 제대로 이해한다. 문법을 넘어서 함수, 타입, 에러 처리, 비동기 실행, 테스트, 디버깅까지 다룰 수 있어야 한다.
그다음 자료구조와 알고리즘으로 코드의 성능과 구조를 읽는 눈을 만든다. AI가 제안한 코드가 왜 느린지, 왜 위험한지 판단하려면 이 단계가 필요하다.
운영체제, 네트워크, 데이터베이스를 통해 프로그램이 실제로 어떻게 실행되고 저장되고 연결되는지 배운다. 이 지점부터 코드가 아니라 시스템이 보이기 시작한다.
그 위에 클라우드, 배포, 관측 가능성, 보안을 얹는다. 실제 서비스는 로컬에서 돌아가는 데모가 아니라 운영되는 시스템이기 때문이다.
마지막으로 프롬프트 설계, 평가, RAG, 에이전트, 모델 선택, 비용 관리 같은 AI 응용 역량을 붙인다. 이때는 단순 사용자가 아니라, AI를 제품으로 다루는 엔지니어가 된다.
이 순서가 중요한 이유는 분명하다. AI는 학습 속도를 올려 주지만, 이해를 건너뛰게 해 주지는 않기 때문이다. 오히려 이해가 부족한 상태에서 AI를 쓰면, 그럴듯한 오류를 더 빨리 쌓게 된다. 반대로 기초가 있는 사람은 AI를 발판으로 더 빨리 높은 수준의 일을 할 수 있다.
또 하나 기억할 것이 있다. 앞으로 강한 사람은 한 분야만 깊고 나머지는 전혀 모르는 사람이기보다, 하나의 깊이와 여러 개의 연결 감각을 가진 사람일 가능성이 크다.3 예를 들어 백엔드 개발자라면 데이터베이스와 네트워크를 깊게 이해하되, AI 평가와 프롬프트 구조도 읽을 수 있어야 한다. 프런트엔드 개발자라면 UI를 잘 만들되, 스트리밍 응답과 인증, 캐시, API 한계도 알아야 한다. AI 엔지니어라면 모델만이 아니라 서빙, 로깅, 비용, 보안까지 봐야 한다.
결국 "무엇을 배워야 하는가"라는 질문의 답은 도구 목록이 아니다. 더 근본적인 능력 세 가지가 남는다.
첫째는 추상화다. 복잡한 시스템을 적절한 계층으로 나누고, 어디까지는 감추고 어디부터는 드러낼지 판단하는 힘이다.
둘째는 트레이드오프 판단이다. 속도와 비용, 정확도와 지연 시간, 보안과 편의성, 유연성과 예측 가능성 사이에서 무엇을 선택할지 결정하는 힘이다.
셋째는 디버깅 능력이다. 겉으로 보이는 증상 뒤에 있는 원인을 구조적으로 추적하는 힘이다. AI가 코드를 많이 써 줄수록, 이상한 버그도 많이 가져온다. 그래서 마지막에 빛나는 사람은 늘 원인을 추적할 줄 아는 사람이다.
AI 시대에 더 강해지는 개발자
AI는 개발자의 일을 더 쉽게 만들었다. 하지만 동시에 더 얕게 일할 수 없게 만들었다.
초안은 기계가 빨리 만든다. 대신 사람은 더 많이 판단해야 한다. 기능은 더 빨리 붙는다. 대신 시스템 전체의 복잡성은 더 빨리 올라간다. 프로토타입은 더 쉽게 나온다. 대신 품질, 안정성, 보안, 유지보수성의 차이는 더 크게 벌어진다.
그래서 AI 시대의 경쟁력은 "코드를 얼마나 빨리 치는가"에 있지 않다. 문제를 얼마나 정확히 정의하는가, 결과를 얼마나 엄격히 검증하는가, 시스템을 얼마나 넓게 이해하는가에 있다.
바로 이 지점에서 컴퓨터공학의 큰 지도가 다시 힘을 발휘한다. 알고리즘, 운영체제, 네트워크, 데이터베이스, 분산 시스템, 보안은 옛날 지식이 아니라, AI 시대에도 여전히 모든 것을 떠받치는 바닥이다.
코드는 시작일 뿐이다. AI가 그 시작을 더 쉽게 만들어 준 시대일수록, 그 뒤를 지탱하는 구조를 이해하는 사람이 결국 오래 강하다.
참고
1GitHub Docs, Copilot 및 AI-assisted development 관련 문서. https://docs.github.com/en/copilot
2GitHub Blog, "The developer role is evolving. Here's how to stay ahead." https://github.blog/ai-and-ml/the-developer-role-is-evolving-heres-how-to-stay-ahead/
3Thoughtworks, "Software engineering skills, jobs and careers in the AI era". https://www.thoughtworks.com/en-us/insights/articles/software-engineering-skills-jobs-careers-ai-era
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.