AI 시대에 살아남는 개발자의 조건, 결국 기본이다

Claude에게 기능 하나를 맡기고, 몇 초 만에 코드가 나오는 걸 보면서 드는 생각이 있다. “이러다 내가 필요 없어지는 건 아닐까.”

이 감각은 AI를 쓰는 시간이 길어질수록 희미해지기도 하고, 오히려 선명해지기도 한다. 내가 하는 일이 진짜로 무엇인지 생각하게 만든다는 면에서, 꼭 나쁜 불안은 아니다.

그 불안이 어디서 오는지 들여다보면, 대부분은 자기 일이 코드를 치는 것이라는 전제에서 시작한다. AI가 코드를 치는 속도가 점점 빨라지고 있으니, 그 전제 위에 서 있는 사람은 불안할 수밖에 없다. 그런데 그 전제가 맞는지부터 따져봐야 한다. 코드를 치는 게 개발자의 핵심 가치였던 때가 있었다. 지금은 그 부분이 빠르게 자동화되고 있다. 남는 것은 코드를 판단하는 능력이다.

AI 코드를 판단하는 사람이 남는다

AI를 쓰기 시작하면서 개발자 사이에 선이 하나 생겼다. AI가 뱉은 코드를 그대로 붙여넣는 사람과, 한 번 읽고 판단하는 사람. 겉보기엔 둘 다 AI를 쓰고 있지만, 시간이 지나면 결과가 달라진다.

첫 번째 유형은 빨라진다. 그런데 같이 불안해진다. 코드가 왜 동작하는지 모르는 채로 쌓이고, 조금만 상황이 달라지면 대응이 안 된다. AI가 잘못된 코드를 내놓을 때 잡아내지 못한다.

두 번째 유형은 빨라지면서 안정된다. AI를 쓰는 속도는 같은데, 거기에 판단 한 겹이 붙어 있다. 이게 맞는지, 여기서 병목이 생기지는 않는지, 이 구조가 나중에 어떤 문제를 만들지. 그 판단이 어디서 나오는가 하면, 기본에서 나온다.

툴이 바뀌어도 판단하는 능력은 그 자리에 있다. 지금 코드를 짜주는 게 Claude든 Gemini든 GPT든, 그 코드를 읽고 “이게 맞아?”를 물을 수 있는 사람이 필요하다. 그게 AI 시대에도 사람이 하는 일이다.

실제로 써먹히는 기본기 세 가지

기본이라고 하면 넓다. CS 전공 4년을 싸잡아 기본이라고 부를 수도 있다. 실제로 AI 코드를 검토하는 상황에서 반복적으로 쓰이는 것들로 좁혀보면 세 가지가 나온다.

복잡도 감각

AI는 동작하는 코드를 잘 짠다. 그런데 효율적인 코드를 짜는 건 다른 문제다. 반복문 안에 반복문이 있고, 거기서 DB 조회까지 들어가는 코드를 AI가 내놓을 때가 있다. 기능은 된다. 그런데 데이터가 1만 건이 되면 무너진다.

이걸 보는 능력이 복잡도 감각이다. O(n)인지 O(n²)인지, 루프 안에서 불필요한 연산이 반복되는 건 아닌지, 캐시를 쓸 수 있는 자리인데 매번 재계산하고 있는 건 아닌지. 알고리즘 문제를 풀 때 배우는 것들이 실제로는 이 감각을 키우는 데 쓰인다.

복잡도를 정확히 계산하지 못해도 된다. “이 코드 데이터 많아지면 느려질 것 같다”는 직감이 어디서 오는가 하면, 코드를 많이 보고 복잡도를 따져본 경험에서 온다. AI가 짠 코드에 그 직감을 들이대는 것이 실용적인 복잡도 감각이다.

구체적으로 어떤 상황인지 생각해보면 이렇다. 사용자 목록을 받아서 각각의 권한을 확인하는 코드가 있다. AI가 사용자 수만큼 루프를 돌면서 매번 DB에서 권한을 조회하는 코드를 짰다. 100명이면 100번 쿼리. 1,000명이면 1,000번 쿼리. 코드는 맞다. 규모가 커지면 터진다. 권한을 미리 한 번에 가져와서 메모리에 올려두고 확인하는 방식으로 고치면 쿼리는 한 번이다. 이 차이를 보는 게 복잡도 감각이다.

자료구조 선택

AI는 요청한 대로 코드를 짜는데, 자료구조를 잘못 고를 때가 있다. 중복 제거가 필요한 곳에 배열을 쓰거나, 빠른 조회가 필요한 곳에 리스트를 순회하거나. 코드는 돌아가지만 그게 최선은 아닌 경우다.

이걸 잡으려면 자료구조마다 어떤 연산이 빠르고 어떤 연산이 느린지가 몸에 배어 있어야 한다. 해시맵은 키 기반 조회가 O(1), 배열 정렬은 O(n log n), 집합은 포함 여부 확인이 빠르다. 이 감각이 없으면 AI가 내놓은 선택이 왜 좋거나 나쁜지 말할 수가 없다.

“여기 배열 말고 Map 쓰는 게 낫지 않을까?” 이 한 마디가 자료구조 지식에서 나온다. 어떤 상황에 어떤 자료구조가 맞는지 판단하는 능력은 AI가 대신해주기 어려운 영역이다. AI는 요청한 방식으로 짜준다. 더 나은 방식이 있다고 스스로 바꾸지는 않는다.

동시성 이해

비동기 코드는 AI가 잘 틀리는 영역이다. 레이스 컨디션이 어디서 생기는지, 공유 상태를 잘못 건드리면 어떻게 되는지, 비동기 함수가 예상한 순서로 실행된다고 가정했을 때 무슨 일이 생기는지.

기능만 보면 코드가 맞아 보인다. 그런데 동시에 여러 요청이 들어왔을 때 어떻게 되는지가 빠져 있다. 이걸 잡는 건 코드를 실행해봐서는 쉽게 드러나지 않는다. 머릿속에서 “이 코드가 동시에 100개 실행되면 어떻게 되지?”를 시뮬레이션할 수 있어야 한다.

비동기, 락, 트랜잭션. 이 개념들이 실제 코드 리뷰에서 반복적으로 등장하는 이유가 여기 있다.

AI가 짠 비동기 코드를 받아서 “이 코드 동시 요청에서 안전한가?”를 물을 수 있는 사람과 그냥 넘기는 사람은 시간이 지나면 만드는 서비스의 안정성이 달라진다. 배포하고 나서 이상한 버그가 산발적으로 터지는 경우의 상당수가 이런 데서 온다.

AI 코드를 검증하는 루틴

기본기를 유지하는 가장 현실적인 방법은 AI 코드를 검증하는 습관을 만드는 것이다. 새로운 공부를 따로 할 시간을 내는 게 아니라, 매일 하는 일 안에서 기본기를 쓰는 구조를 만드는 것이다.

몇 가지를 습관으로 들이면 달라진다.

AI에게 요청을 보내기 전에, “이 기능을 어떻게 구현할지 나라면?” 30초라도 생각해보는 것이다. 코드가 나온 뒤 비교하면 내가 어떤 부분을 놓쳤는지, 반대로 AI가 뭘 놓쳤는지 보인다. 매일 반복하면 설계 감각이 무뎌지지 않는다.

코드를 받은 뒤에는 반례를 던진다. “데이터가 비어 있으면?”, “동시에 10개가 들어오면?”, “숫자가 매우 크면?” 이 질문들을 코드를 볼 때마다 습관적으로 던진다. 처음엔 귀찮지만, 이 질문이 버그를 잡는 기준이 된다.

이해하지 못한 코드는 쓰지 않는다. AI가 짜준 코드를 한 줄씩 읽었을 때 왜 이렇게 됐는지 설명할 수 없다면 그냥 쓰지 않는다. 이 기준 하나가 “AI 코드를 그대로 붙여넣는 사람”과 “판단하는 사람”을 가르는 경계다.

PR 리뷰를 선생으로 삼는다. 동료가 올린 PR, 혹은 AI가 짠 코드의 리뷰를 꼼꼼히 하는 것 자체가 기본기 훈련이다. 왜 이 방식이 나은지, 어디서 비용이 올라가는지를 언어로 표현하는 연습이 기본기를 선명하게 만든다.

가끔 맨손으로 짜본다. AI 없이, 검색 없이, 익숙한 기능을 하나 구현해보는 것이다. 자주 할 필요는 없다. 한 달에 한 번 정도면 충분하다. 빈 파일에서 로직을 쌓아가는 과정에서, 내가 뭘 알고 뭘 모르는지 선명하게 드러난다. AI를 쓰면 이 감각이 흐려지는데, 가끔 꺼내서 확인하는 것이다.

불안의 방향을 바꾸는 것

“AI한테 대체되는 건 아닐까”라는 불안은 사라지지 않는다. 툴이 빨라질수록 그 불안이 커질 수도 있다.

그런데 그 불안을 “코드를 더 빨리 쳐야 한다”는 방향으로 쓰면 소용이 없다. AI는 이미 충분히 빠르고, 앞으로 더 빨라진다. 속도에서 AI와 경쟁하는 건 이기기 어려운 싸움이다.

방향을 바꾸면 다르다. “AI가 짠 코드를 더 잘 읽을 수 있어야 한다. 더 날카롭게 판단할 수 있어야 한다.” 이 방향으로 움직이면, 툴이 아무리 좋아져도 사람이 할 일이 남아 있다. 판단하는 사람이 필요하고, 책임지는 사람이 필요하다. 그 자리는 AI가 채우지 않는다.

복잡도, 자료구조, 동시성. 유행이 아닌 것들이 기준이 된다. 10년 전에도 유효했고, 10년 뒤에도 유효할 것들이다. 그게 기본이라고 부르는 이유다.

참고 자료

• Addy Osmani: The 70% Problem: AI가 70~80%를 해결해줄 때 나머지 30%가 사람의 영역이라는 논거
• The Pragmatic Programmer, 20th Anniversary Edition: 기본기가 왜 경력 전반에 걸쳐 유효한지에 대한 고전적 논의