이제 개발자는 코드를 짜는 사람이 아니라 의심하는 사람입니다

이제 개발자는 코드를 짜는 사람이 아니라 의심하는 사람입니다

developer-as-code-skeptic-hero

소개

예전에는 개발자를 설명할 때 "코드를 짜는 사람"이라는 표현이 꽤 자연스러웠습니다. 요구사항을 받고, 로직을 설계하고, 파일을 열고, 키보드로 코드를 작성하는 사람이 개발자였습니다. 물론 그때도 개발자는 단순히 타자를 치는 사람이 아니었지만, 겉으로 보이는 일의 중심은 코드 작성에 가까웠습니다. 그런데 AI 도구가 일상에 들어오면서 이 설명이 조금 낡아 보이기 시작했습니다.

이제 코드는 AI도 씁니다. ChatGPT, GitHub Copilot, Cursor 같은 도구는 함수 초안을 만들고, 테스트 케이스를 제안하고, 에러 메시지를 해석하고, 리팩터링 방향까지 알려 줍니다. 그러다 보니 개발자의 역할은 "누가 더 빨리 코드를 작성하는가"에서 "누가 더 정확히 의심하고 검증하는가"로 이동하고 있습니다. 조금 과장해서 말하면, AI 시대의 개발자는 키보드를 두드리는 사람이라기보다 코드 앞에서 팔짱을 끼고 "정말?"이라고 묻는 사람입니다.

이 글에서는 왜 개발자의 핵심 역량이 코드 작성에서 의심과 검증으로 확장되고 있는지 살펴보겠습니다. AI가 만들어 준 코드를 어떻게 바라봐야 하는지, 어떤 지점을 의심해야 하는지, 그리고 주니어 개발자와 실무 개발자가 앞으로 어떤 습관을 길러야 하는지 정리해 보겠습니다. 다만 여기서 말하는 의심은 냉소가 아닙니다. 좋은 의심은 일을 멈추게 하는 태도가 아니라, 더 안전하게 앞으로 가게 만드는 기술입니다.

코드를 잘 쓰는 것만으로는 부족해졌습니다

AI 도구가 등장하기 전에도 개발자는 많은 것을 의심해야 했습니다. 요구사항이 정말 맞는지, 입력값이 항상 정상인지, 사용자가 예상대로 행동할지, 서버가 항상 빠르게 응답할지 확인해야 했습니다. 다만 코드 작성 자체에 시간이 많이 들었기 때문에, 의심과 검증은 종종 뒤로 밀렸습니다. 일단 만들어야 했고, 마감은 늘 어딘가에서 조용히 다가오고 있었습니다.

이제는 상황이 달라졌습니다. AI가 코드 초안을 빠르게 만들어 주면서 작성 속도는 빨라졌습니다. 하지만 작성 속도가 빨라진 만큼 검토해야 할 코드도 빨리 늘어납니다. 코드는 생겼는데 작성자가 충분히 이해하지 못한 코드, 정상 흐름만 처리하는 코드, 프로젝트 맥락과 어긋나는 코드가 섞일 수 있습니다. 마치 책상이 빨리 정리된 것처럼 보였는데, 서랍을 열어 보니 모든 물건이 한꺼번에 들어가 있는 상황과 비슷합니다.

따라서 AI 시대의 개발자는 코드를 많이 생산하는 사람보다, 생산된 코드의 의미를 빠르게 파악하고 위험을 찾아내는 사람이 되어야 합니다. 작성 능력은 여전히 중요하지만, 그것만으로는 충분하지 않습니다. 이제는 "이 코드가 맞는가?", "왜 이 방식인가?", "어디서 깨질 수 있는가?", "운영 환경에서는 어떤 문제가 생길 수 있는가?"를 묻는 능력이 더 중요해졌습니다.

좋은 의심은 불신이 아니라 품질 관리입니다

의심이라는 단어는 조금 차갑게 들릴 수 있습니다. 누군가를 믿지 않는 태도처럼 느껴지기도 합니다. 하지만 개발에서 의심은 상대를 공격하는 것이 아니라 시스템을 보호하는 일입니다. 코드 리뷰에서 질문을 던지는 이유도 작성자를 곤란하게 만들기 위해서가 아닙니다. 장애를 줄이고, 유지보수를 쉽게 하고, 사용자가 겪을 문제를 미리 줄이기 위해서입니다.

AI가 만든 코드도 마찬가지입니다. AI를 의심한다는 것은 AI를 쓰지 말자는 뜻이 아닙니다. 오히려 더 잘 쓰기 위한 태도입니다. AI가 만든 결과를 신뢰하려면 먼저 검증해야 합니다. 검증 없는 신뢰는 편하지만 위험합니다. 개발자는 편한 길을 좋아하지만, 운영 환경은 편한 길을 별로 존중하지 않습니다. 운영 환경은 오직 실제 동작만 봅니다.

좋은 개발자의 의심은 "틀렸을 것이다"가 아니라 "틀렸다면 어디서 틀릴 수 있을까?"에서 시작됩니다.

이 차이가 중요합니다. 무조건 부정하는 사람은 팀의 속도를 늦춥니다. 반면 좋은 의심을 하는 사람은 위험을 구체화하고, 더 나은 결정을 돕습니다. "이건 안 됩니다"에서 끝나는 것이 아니라 "이 입력값이 비어 있을 때 실패할 수 있으니 검증을 추가합시다"라고 말하는 태도가 필요합니다.

AI가 만든 코드에서 의심해야 할 지점

AI 생성 코드는 깔끔해 보일 때가 많습니다. 변수명도 그럴듯하고, 주석도 친절하고, 함수도 적당히 나뉘어 있습니다. 그래서 더 쉽게 믿게 됩니다. 하지만 보기 좋은 코드가 항상 안전한 코드는 아닙니다. 특히 다음 지점은 반드시 확인해야 합니다.

의심할 지점	확인 질문	왜 중요한가요?
요구사항 이해	이 코드가 실제 요구사항을 반영했나요?	AI는 일반적인 답을 만들 수 있지만, 우리 서비스의 맥락은 모를 수 있습니다.
예외 처리	빈 값, 실패 응답, 권한 부족을 다루나요?	정상 흐름만 처리하면 실제 사용자 환경에서 쉽게 깨질 수 있습니다.
보안	민감한 값, 인증, 권한 검사가 안전한가요?	예제 코드는 간단하지만 운영 코드는 안전해야 합니다.
일관성	기존 코드 스타일과 구조에 맞나요?	혼자 멋진 코드는 팀 프로젝트에서 유지보수 비용이 될 수 있습니다.
성능	불필요한 반복, 중복 요청, 큰 데이터 처리가 있나요?	작은 테스트에서는 괜찮아도 실제 데이터에서는 느려질 수 있습니다.
설명 가능성	내가 이 코드를 다른 사람에게 설명할 수 있나요?	설명하지 못하는 코드는 문제 발생 시 고치기 어렵습니다.

이 표의 핵심은 간단합니다. AI가 만든 코드를 리뷰할 때는 "작동하나요?"에서 멈추면 안 됩니다. "왜 작동하나요?", "언제 작동하지 않나요?", "누가 이 코드를 유지보수하나요?"까지 물어야 합니다. 개발자는 이제 코드의 생산자이면서 동시에 코드의 심문관이 되었습니다. 물론 너무 무섭게 들리니, 실제 회의에서는 부드러운 말투를 추천합니다.

의심하는 개발자는 로그를 다르게 봅니다

좋은 개발자는 로그를 단순한 에러 메시지로 보지 않습니다. 로그는 시스템이 남긴 증언입니다. "어디서 실패했는가", "어떤 값이 들어왔는가", "어떤 순서로 일이 일어났는가"를 알려 줍니다. AI 시대에는 이 로그를 해석하는 능력이 더 중요해졌습니다. AI가 만든 코드를 제대로 이해하려면 실행 흐름을 확인해야 하기 때문입니다.

예를 들어 화면이 비어 있는데 API 응답은 성공했다고 가정해 보겠습니다. 이때 좋은 의심은 "AI 코드가 이상하다"에서 끝나지 않습니다. 실제 응답 구조와 화면에서 읽는 필드가 같은지, 상태 업데이트가 일어나는지, 렌더링 조건이 잘못되어 있지 않은지 확인합니다. 의심은 막연한 감정이 아니라 확인 가능한 질문으로 바뀌어야 합니다.

• 요청은 실제로 나갔나요?
• 응답 상태와 응답 본문은 예상과 같은가요?
• 응답 데이터가 상태에 저장되었나요?
• 화면은 저장된 상태의 올바른 필드를 읽고 있나요?
• 로딩, 빈 값, 오류 상태가 서로 충돌하지 않나요?

이런 질문을 순서대로 확인하면 문제를 좁힐 수 있습니다. 로그를 보며 감으로 찍는 것보다 훨씬 안정적입니다. 물론 디버깅을 오래 하다 보면 감도 생깁니다. 다만 그 감은 대개 수많은 실패와 커피로 숙성된 결과입니다. 처음부터 감만 믿으면 로그가 서운해합니다.

AI에게도 의심을 질문으로 전달해야 합니다

AI를 잘 쓰는 개발자는 AI에게도 좋은 의심을 던집니다. 단순히 "이 코드 괜찮나요?"라고 묻기보다, 어떤 관점에서 검토할지 명확히 말합니다. AI는 질문의 방향에 따라 답변의 품질이 달라집니다.

다음과 같은 질문을 활용해 보세요.

이 코드를 보안 관점에서 검토해 주세요.
입력값이 비어 있거나 잘못된 경우 어떤 문제가 생길 수 있나요?
이 함수가 큰 데이터에서도 안전하게 동작할까요?
기존 코드 스타일과 맞추려면 어떤 부분을 수정해야 할까요?
테스트 케이스로 확인해야 할 정상 흐름과 실패 흐름을 나눠 주세요.
이 코드에서 제가 이해하지 못하고 넘어가기 쉬운 부분을 설명해 주세요.

이렇게 물으면 AI는 단순한 코드 생성기에서 검토 보조 도구로 바뀝니다. 다만 AI의 답변도 다시 의심해야 합니다. 이것이 조금 피곤하게 들릴 수 있습니다. 하지만 개발은 원래 피곤함을 구조화해서 덜 위험하게 만드는 일에 가깝습니다. 피곤함을 없애지는 못해도, 어디에 피곤해야 하는지는 선택할 수 있습니다.

주니어 개발자에게 필요한 의심의 루틴

주니어 개발자에게 의심은 특히 중요합니다. 경험이 부족할수록 AI가 준 답변이 더 그럴듯하게 보일 수 있습니다. 처음 보는 패턴도 "아, 원래 이렇게 하는구나"라고 받아들이기 쉽습니다. 하지만 바로 그 지점에서 한 번 멈춰야 합니다. 원래 그렇게 하는 것인지, 그냥 AI가 그렇게 제안한 것인지 구분해야 합니다.

다음 루틴을 코드 작성 후에 적용해 보세요.

1. 이 코드의 목적을 한 문장으로 설명합니다.
2. 입력값과 출력값을 확인합니다.
3. 정상 흐름과 실패 흐름을 각각 적습니다.
4. 민감한 데이터나 권한 처리가 있는지 확인합니다.
5. 기존 프로젝트의 비슷한 코드와 비교합니다.
6. 테스트하거나 수동으로 확인할 시나리오를 만듭니다.
7. 코드 리뷰에서 받을 만한 질문을 미리 적어 봅니다.

이 루틴은 시간이 조금 걸립니다. 하지만 나중에 원인을 알 수 없는 버그를 붙잡는 시간보다 훨씬 짧습니다. 개발자는 시간을 아끼기 위해 코드를 빨리 쓰지만, 진짜 시간을 아끼는 습관은 코드를 빨리 의심하는 것입니다.

의심과 불안은 다릅니다

여기서 한 가지 조심해야 할 점이 있습니다. 좋은 의심은 필요하지만, 모든 것을 두려워하는 태도는 좋지 않습니다. 의심과 불안은 다릅니다. 의심은 확인할 질문을 만듭니다. 불안은 아무것도 하지 못하게 만듭니다. 개발자는 불안해서 멈추는 사람이 아니라, 의심을 검증 절차로 바꾸는 사람이 되어야 합니다.

예를 들어 "이 코드가 위험할 것 같아"에서 멈추면 불안에 가깝습니다. 반면 "이 코드는 토큰 만료 상황을 처리하지 않으니 테스트를 추가하자"라고 말하면 의심이 됩니다. 좋은 의심은 다음 행동을 만듭니다. 테스트를 추가하거나, 로그를 확인하거나, 문서를 찾아보거나, 리뷰어에게 구체적인 질문을 던지게 합니다.

의심은 개발을 멈추게 하는 브레이크가 아니라, 사고 나기 전에 속도를 조절하는 계기판입니다.

AI 시대에는 이 차이가 더 중요합니다. 생성 속도가 빨라졌기 때문에 무조건 멈추면 기회를 놓칠 수 있고, 무조건 달리면 품질을 놓칠 수 있습니다. 좋은 개발자는 빠르게 만들고, 차분하게 의심하고, 필요한 만큼 검증합니다.

코드 리뷰는 의심을 공유하는 자리입니다

코드 리뷰는 누군가의 실수를 찾는 시간이 아닙니다. 팀이 함께 의심을 나누는 시간입니다. "이 부분은 왜 이렇게 구현했나요?", "이 입력값이 없으면 어떻게 되나요?", "배포 환경에서도 같은 방식으로 동작하나요?" 같은 질문은 공격이 아니라 안전장치입니다.

AI 생성 코드가 늘어나면 코드 리뷰의 중요성은 더 커집니다. 작성자가 AI의 도움을 받았다면, 리뷰어는 코드뿐 아니라 작성자의 이해도도 확인해야 합니다. 작성자는 "AI가 만들어 줬습니다"에서 끝내지 말고 "AI가 초안을 만들었고, 저는 이 부분을 프로젝트 기준에 맞게 수정했습니다"라고 설명할 수 있어야 합니다.

리뷰어도 태도를 조심해야 합니다. AI를 썼다는 이유만으로 무시하거나 비난하면 팀원들은 AI 사용을 숨기게 됩니다. 숨겨진 AI 사용은 더 위험합니다. 차라리 팀이 AI 사용 기준을 정하고, 검증 절차를 공유하는 편이 낫습니다. 투명한 의심이 비밀스러운 붙여넣기보다 훨씬 건강합니다.

의심하는 개발자가 성장하는 이유

의심하는 개발자는 단순히 버그를 많이 찾는 사람이 아닙니다. 시스템을 더 깊게 이해하는 사람입니다. 왜 이 구조가 필요한지, 어디서 실패할 수 있는지, 어떤 선택이 장기적으로 더 나은지 계속 묻기 때문입니다. 이 질문들이 쌓이면 설계 감각이 생기고, 운영 감각이 생기고, 협업 감각이 생깁니다.

AI가 코드를 대신 작성할수록 이런 감각은 더 중요해집니다. 코드 작성 속도만으로는 차별화하기 어렵습니다. 누구나 비슷한 도구를 사용할 수 있기 때문입니다. 하지만 같은 AI 답변을 보고도 어떤 사람은 그대로 붙여 넣고, 어떤 사람은 위험을 찾아 수정합니다. 앞으로의 차이는 여기에서 생깁니다.

좋은 개발자는 AI보다 코드를 더 많이 쓰는 사람이 아닐 수 있습니다. 하지만 AI가 쓴 코드를 더 잘 읽고, 더 잘 의심하고, 더 잘 고치는 사람이어야 합니다. 키보드 속도보다 중요한 것은 판단의 정확도입니다. 물론 키보드도 빠르면 좋습니다. 하지만 빠른 손가락이 잘못된 방향으로 달리면, 되돌아오는 길도 빠르게 길어집니다.

자주 묻는 질문

AI 시대에 코딩 실력은 덜 중요해지나요?

덜 중요해진다기보다 성격이 바뀝니다. 문법을 외워서 코드를 많이 작성하는 능력만으로는 부족합니다. 코드의 의도, 구조, 예외 처리, 보안, 유지보수성을 판단하는 능력이 더 중요해집니다. 기본 코딩 실력은 여전히 필요하지만, 검증 능력과 함께 자라야 합니다.

AI가 만든 코드를 얼마나 의심해야 하나요?

기능의 중요도에 따라 다릅니다. 작은 실험용 코드라면 가볍게 확인해도 되지만, 인증, 결제, 개인정보, 데이터 삭제, 운영 자동화처럼 영향이 큰 코드는 반드시 꼼꼼히 검토해야 합니다. 정상 흐름뿐 아니라 실패 흐름도 함께 확인하는 것이 좋습니다.

의심이 많으면 개발 속도가 느려지지 않나요?

처음에는 조금 느려질 수 있습니다. 하지만 장기적으로는 오히려 시간을 아낍니다. 초기에 확인하지 않은 문제는 나중에 더 큰 디버깅 비용으로 돌아오는 경우가 많습니다. 좋은 의심은 속도를 늦추는 것이 아니라, 잘못된 방향으로 빨리 달리는 일을 막아 줍니다.

주니어 개발자는 무엇부터 연습하면 좋을까요?

AI가 만든 코드든 직접 작성한 코드든 먼저 말로 설명하는 연습을 해 보세요. 이 함수의 목적, 입력값, 출력값, 실패 가능성, 테스트 방법을 설명할 수 있으면 이해도가 높아집니다. 설명이 막히는 부분이 바로 더 공부해야 할 부분입니다.

마무리

AI 시대의 개발자는 더 이상 단순히 코드를 짜는 사람으로만 설명되기 어렵습니다. 코드는 점점 더 빠르게 생성됩니다. 중요한 것은 그 코드가 맞는지, 안전한지, 유지보수 가능한지, 우리 프로젝트의 맥락에 맞는지 판단하는 일입니다. 그래서 이제 개발자는 코드를 쓰는 사람인 동시에 의심하는 사람이어야 합니다.

좋은 의심은 개발자를 예민하게 만드는 것이 아니라 더 단단하게 만듭니다. 요구사항을 의심하고, 입력값을 의심하고, AI의 답변을 의심하고, 자신의 판단도 다시 확인합니다. 이 과정에서 코드 품질이 올라가고, 장애 가능성이 줄고, 팀의 신뢰도 쌓입니다.

다음에 AI가 멋진 코드를 만들어 주면 바로 감탄해도 좋습니다. 다만 그 다음에는 조용히 물어보세요. "정말 이게 맞을까?" 그 질문이 개발자를 불편하게 만드는 것이 아니라, 더 좋은 개발자로 데려가는 시작점일 수 있습니다. AI가 코드를 쓰는 시대일수록, 사람은 더 좋은 질문과 더 좋은 의심을 가져야 합니다.