AI는 개발자의 일을 없애기보다 기준을 바꾼다
AI 코딩 도구는 코드를 더 빨리 만들 수 있게 해준다. 반복적인 보일러플레이트 작성, 테스트 초안 생성, 문서 요약, 간단한 리팩터링 제안처럼 시간이 많이 들지만 패턴이 뚜렷한 작업에서 특히 유용하다. 그러나 속도가 빨라졌다고 해서 개발자의 책임이 줄어드는 것은 아니다.
AI가 제안한 코드는 그럴듯해 보일 수 있다. 하지만 그 코드가 요구사항을 만족하는지, 기존 구조와 맞는지, 보안 문제는 없는지, 운영 환경에서 성능 문제가 생기지 않는지는 여전히 사람이 판단해야 한다. AI 시대의 개발자는 "코드를 직접 많이 쓰는 사람"에서 "문제를 정확히 정의하고, 결과를 검증하며, 팀이 이해할 수 있게 결정 과정을 남기는 사람"으로 더 강하게 요구된다.
중요한 태도는 간단하다. AI는 초안을 낸다. 개발자는 결정한다. 일부 실무 사례에서도 AI 코딩 도구를 대체자가 아니라 초안 작성자이자 보조 페어 프로그래머로 다루고, 사람이 검토·테스트·문서화하는 흐름을 강조한다1.
AI 생성 이미지
AI 코딩 도구를 현실적으로 쓰는 방법
AI를 잘 쓰려면 "코드 짜 줘"라고 묻기보다 작업을 작게 나누고 맥락을 충분히 제공해야 한다. 맥락이란 프로젝트의 목적, 기존 코드 규칙, 사용 중인 프레임워크, 데이터 모델, 보안 제약, 완료 기준을 말한다.
예를 들어 다음과 같이 요청할 수 있다.
주문 취소 API의 서비스 계층 초안을 작성해 주세요.
조건은 다음과 같습니다.
이미 배송된 주문은 취소할 수 없습니다.
결제 취소는 외부 결제 API를 호출합니다.
데이터베이스 갱신과 취소 이력 저장은 하나의 트랜잭션이어야 합니다.
예외 메시지는 사용자용 메시지와 로그용 메시지를 분리합니다.
테스트 케이스 목록도 함께 제안해 주세요.
이 요청은 단순한 명령이 아니라 설계 조건을 담고 있다. AI는 이런 조건이 있을 때 더 나은 초안을 만든다. 최근에는 단순한 프롬프트 작성보다, AI가 참고할 수 있는 아키텍처 제약, 보안 규칙, 기존 코드 패턴을 함께 제공하는 능력을 중요한 역량으로 본다2. 이를 거창하게 생각할 필요는 없다. 결국 좋은 동료에게 일을 부탁할 때처럼 배경과 기준을 명확히 주는 것이다.
다만 맥락을 많이 준다는 말이 무엇이든 그대로 넣어도 된다는 뜻은 아니다. 사내 비공개 코드, 고객 개인정보, API 키, 비밀번호, 토큰, 운영 로그처럼 민감한 정보는 회사 정책과 도구의 보안 조건을 확인한 뒤 다뤄야 한다. AI에게 일을 맡길 때도 "무엇을 알려줘야 좋은 답이 나오는가"와 "무엇은 절대 넣으면 안 되는가"를 함께 판단해야 한다.
AI 도구는 다음 작업에 현실적으로 도움이 된다.
설계 초안 만들기: API 흐름, 모듈 분리, 예외 처리 위치를 비교해 볼 수 있다.
테스트 케이스 생성: 정상 입력뿐 아니라 경계값, 권한 오류, 외부 API 실패, 동시 요청 같은 누락하기 쉬운 경우를 떠올리는 데 유용하다.
문서 요약: 긴 공식 문서나 릴리스 노트에서 변경점, 주의할 옵션, 마이그레이션 항목을 빠르게 파악할 수 있다.
리팩터링 보조: 중복 코드 제거, 함수 이름 개선, 조건문 분리, 테스트하기 쉬운 구조 제안을 받을 수 있다.
검토 관점 넓히기: 내가 놓친 예외 상황, 장애 시나리오, 테스트 누락 가능성을 질문해 볼 수 있다.
단, AI에게 한 번에 큰 기능 전체를 맡기면 검토하기 어려워진다. 작업은 작을수록 좋다. "회원 가입 기능 전체 구현"보다 "비밀번호 검증 함수와 테스트 케이스 작성", "중복 이메일 예외 처리 흐름 제안"처럼 나누는 편이 안전하다. 작은 단위로 요청하면 결과가 틀렸을 때도 원인을 찾기 쉽고, 받아들일 부분과 버릴 부분을 구분하기 쉽다.
AI가 만든 코드는 반드시 검토해야 한다
AI가 만든 코드는 빠르게 보이지만, 실제 프로젝트에서는 다음 문제가 숨어 있을 수 있다.
첫째, 요구사항 불일치다. AI는 일반적인 패턴을 잘 제안하지만 우리 서비스의 정책을 모른다. 예를 들어 관리자는 모든 주문을 볼 수 있지만 일반 사용자는 자신의 주문만 볼 수 있다는 인가 규칙이 빠질 수 있다. 코드는 실행되지만 서비스 정책을 어기는 상태가 된다.
둘째, 보안 문제다. 입력값 검증이 부족하거나, SQL Injection에 취약한 쿼리를 만들거나, 쿠키 보안 옵션을 빠뜨릴 수 있다. 외부 URL을 서버가 그대로 호출하는 SSRF 위험, 로그에 토큰이나 개인정보를 남기는 문제도 생길 수 있다. AI 기반 개발에서도 보안은 코드가 배포되기 전 개발 생명주기 안에서 확인해야 한다는 점이 강조된다3.
셋째, 성능 문제다. 작은 예제에서는 괜찮아 보여도 실제 데이터가 많아지면 N+1 쿼리, 불필요한 전체 테이블 조회, 반복문 안의 외부 API 호출 같은 병목이 생긴다. AI가 만든 코드를 볼 때는 "입력이 10개일 때"가 아니라 "10만 개일 때도 괜찮은가"를 생각해야 한다.
넷째, 라이선스와 의존성 문제다. AI가 제안한 라이브러리가 실제로 존재하지 않거나, 유지보수가 중단되었거나, 프로젝트 정책과 맞지 않는 라이선스를 가질 수 있다. 의존성을 추가하기 전에는 공식 저장소, 다운로드 추이, 최근 릴리스, 보안 이슈, 라이선스를 확인해야 한다.
다섯째, 존재하지 않는 API와 잘못된 사용법이다. AI는 실제로 없는 함수나 옵션을 마치 있는 것처럼 제안할 수 있다. 오래된 버전의 사용법과 최신 버전의 사용법을 섞어 답할 수도 있다. 그래서 코드를 복사하기 전에 공식 문서와 타입 정의, 컴파일 결과, 테스트 결과로 확인해야 한다.
검토 기준은 다음처럼 정리할 수 있다.
이 코드가 요구사항과 완료 기준을 모두 만족하는가?
실패 상황과 예외 처리가 명확한가?
인증과 인가가 서버에서 검증되는가?
사용자 입력이 안전하게 처리되는가?
데이터베이스 조회와 외부 API 호출이 과도하지 않은가?
테스트로 핵심 동작과 경계 조건을 확인했는가?
새 의존성이 꼭 필요하며, 라이선스와 보안 상태가 적절한가?
사용하는 API, 옵션, 설정값이 현재 버전의 공식 문서와 맞는가?
팀의 코드 스타일과 아키텍처 경계를 지키는가?
AI 결과를 그대로 붙여 넣는 습관은 위험하다. 받아들인 코드는 내 코드다. 장애가 나면 "AI가 이렇게 만들었다"는 설명은 도움이 되지 않는다. AI가 만든 코드는 초안으로 보고, 최소한 읽기, 실행하기, 테스트하기, 리뷰받기를 거쳐야 한다.
공식 문서를 읽는 습관이 더 중요해진다
AI는 문서를 요약해 줄 수 있지만, 최종 근거는 공식 문서에 있어야 한다. 특히 프레임워크 업그레이드, 데이터베이스 옵션 변경, 클라우드 설정, 보안 정책처럼 운영에 영향을 주는 내용은 요약만 믿으면 안 된다.
기술 문서를 읽을 때는 순서를 정해 두면 좋다.
개념 문서에서 이 기술이 해결하려는 문제를 먼저 이해한다.
공식 레퍼런스에서 함수, 옵션, 설정값의 정확한 의미를 확인한다.
릴리스 노트에서 변경 사항과 호환성 깨짐 여부를 확인한다.
마이그레이션 가이드에서 기존 코드 수정 방법을 본다.
이슈 트래커에서 알려진 버그, 제약, 우회 방법을 찾는다.
예를 들어 웹 프레임워크를 새 버전으로 올릴 때는 "AI에게 업그레이드 방법 요약"을 요청할 수 있다. 하지만 실제 적용 전에는 공식 릴리스 노트의 breaking changes, deprecated API, 설정 기본값 변경을 직접 확인해야 한다. 데이터베이스 드라이버나 인증 라이브러리처럼 보안과 연결되는 의존성은 더욱 그렇다.
문서를 읽는 능력은 느린 능력이 아니다. 오히려 장기적으로 가장 빠른 능력이다. 검색 결과와 AI 답변을 오가며 추측하는 시간을 줄이고, 정확한 근거를 기준으로 판단하게 해준다. AI가 답을 빠르게 보여 줄수록, 그 답이 어디에 근거하는지 확인하는 습관은 더 중요해진다.
질문과 설명은 개발자의 생산성을 결정한다
AI 시대에도 협업의 기본은 명확한 설명이다. 문제를 잘 설명하지 못하면 동료도, AI도, 미래의 나도 제대로 도와줄 수 없다.
좋은 질문에는 보통 다음 정보가 들어간다.
현상: 무엇이 어떻게 잘못되었는가?
기대 동작: 원래는 어떻게 동작해야 하는가?
재현 방법: 어떤 입력과 순서로 문제가 발생하는가?
환경: 브라우저, 서버 버전, 데이터베이스, 배포 환경은 무엇인가?
이미 시도한 것: 어떤 로그를 봤고 어떤 가설을 확인했는가?
영향 범위: 일부 사용자 문제인가, 전체 장애인가?
예를 들어 "로그인이 안 됩니다"보다 다음 질문이 훨씬 낫다.
운영 환경에서 Google OAuth 로그인 후
/callback에서 500 오류가 발생합니다.
스테이징에서는 정상입니다.
오늘 배포에서 인증 라이브러리를 2.4에서 2.6으로 올렸고, 로그에는redirect_uri mismatch가 있습니다.
환경 변수OAUTH_REDIRECT_URI값은 운영과 스테이징이 다릅니다.
설정 변경 문제로 보이는데, 릴리스 노트에서 관련 변경 사항을 함께 확인해 주실 수 있을까요?
이런 질문은 문제 해결 시간을 줄인다. 질문 자체가 이미 디버깅 과정이기 때문이다.
기술적 의사결정도 문서로 남겨야 한다. 긴 문서가 아니어도 된다. 다음 네 가지면 충분한 경우가 많다.
배경: 어떤 문제가 있었는가?
결정: 무엇을 선택했는가?
대안: 어떤 선택지를 비교했는가?
결과: 장점, 단점, 되돌리는 방법은 무엇인가?
예를 들어 "Redis 캐시를 도입한다"는 결정에는 캐시 대상, 만료 시간, 데이터 불일치 허용 범위, 장애 시 동작, 제거 방법이 함께 적혀야 한다. 이런 기록은 코드보다 오래 팀을 돕는다. 시간이 지난 뒤에도 왜 이런 구조가 되었는지, 어떤 조건이 바뀌면 결정을 다시 검토해야 하는지 알려 주기 때문이다.
T자형 역량으로 성장하기
AI 시대의 개발자에게 필요한 성장은 모든 것을 얕게 아는 것이 아니다. 한 분야에서는 깊이를 만들고, 주변 분야는 대화와 판단이 가능할 만큼 넓히는 것이다. 이를 흔히 T자형 역량이라고 부른다.
세로축은 자신의 주력 분야다. 백엔드 개발자라면 API 설계, 데이터베이스, 트랜잭션, 성능 진단, 장애 대응을 깊게 파고들 수 있다. 프론트엔드 개발자라면 브라우저 렌더링, 상태 관리, 접근성, 성능 최적화, 사용자 경험을 깊게 다룰 수 있다.
가로축은 함께 일하기 위해 필요한 공통 지식이다.
네트워크: 요청 지연, HTTP 상태 코드, 인증 흐름을 이해한다.
데이터: 모델링, 인덱스, 트랜잭션의 기본을 안다.
운영: 로그, 메트릭, 배포, 롤백, 장애 대응 흐름을 안다.
보안: 입력 검증, 권한 확인, 시크릿 관리, 의존성 취약점을 점검한다.
테스트: 변경을 안전하게 만드는 테스트 전략을 세운다.
커뮤니케이션: 문제, 결정, 위험을 명확히 설명한다.
성장 계획은 크게 잡기보다 작게 반복하는 편이 좋다. 예를 들어 한 분기에는 "SQL 실행 계획 읽기", 다음 분기에는 "운영 로그 기반 장애 분석", 그다음에는 "인증과 인가 설계"처럼 주제를 하나씩 정한다. 각 주제는 공식 문서 읽기, 작은 실습, 코드 리뷰 적용, 회고 기록으로 마무리한다.
AI는 이 과정에서 좋은 보조 도구가 된다. 학습 로드맵을 만들고, 어려운 문서를 요약하고, 연습 문제를 만들고, 내가 쓴 설명의 빈틈을 찾아줄 수 있다. 그러나 이해를 대신해 주지는 않는다. 성장의 기준은 "AI가 답을 줬는가"가 아니라 "내가 그 답을 검증하고 설명할 수 있는가"다.
오래 가는 개발자의 기준
기술은 계속 바뀐다. 언어, 프레임워크, 클라우드 서비스, AI 도구도 달라진다. 하지만 오래 가는 개발자의 기준은 크게 변하지 않는다.
문제를 정확히 정의한다. 기본 원리를 이해한다. 변경의 영향을 예상한다. 결과를 테스트한다. 보안과 운영을 고려한다. 모르는 것을 문서와 실험으로 확인한다. 동료가 이해할 수 있게 설명한다.
AI는 이 과정을 빠르게 도울 수 있다. 그러나 판단, 책임, 검증은 개발자의 몫이다. 앞으로 더 중요한 개발자는 AI를 쓰지 않는 사람이 아니라, AI를 활용하되 결과를 비판적으로 읽고 안전하게 제품에 반영할 수 있는 사람이다.
참고
1AI Coding Assistants in Software Development: Lessons from Our 'Trust but Verify' Approach
2Copilot Competency: Training Developers to Effectively Use AI Coding Assistants
3AI Coding Assistants: A Guide to Security-Safe Navigation for the Next Generation of Developers
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.