"AI 코딩은 혼자 쓰는 도구라던데" 써보니 달랐다

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

혼자 빠르게 치는 코드보다 팀 맥락이 먼저 보였습니다

처음 기대와 실제 사용감의 차이

처음 AI 코딩 도구를 켰을 때는 솔직히 자동완성 성능만 봤습니다. 함수 이름을 쓰면 다음 줄을 얼마나 잘 맞히는지, 테스트 코드를 얼마나 빨리 만들어 주는지, 반복 작업을 얼마나 줄여 주는지가 전부인 줄 알았습니다.

그런데 한 달 정도 실제 프로젝트에 붙여 보니 체감은 달랐습니다. 생산성을 좌우한 것은 멋진 한 줄 제안보다 우리 팀의 코드 흐름을 얼마나 잘 설명해 줄 수 있느냐였습니다. 특히 신규 기능을 붙일 때는 AI가 코드를 대신 쓰는 것보다, 기존 구조를 읽고 변경 위치를 좁혀 주는 순간이 훨씬 유용했습니다.

• 좋았던 점: 낯선 모듈에 들어갈 때 파일 역할을 빠르게 파악할 수 있었습니다.
• 아쉬웠던 점: 레거시 규칙이나 팀 내부 약속은 프롬프트로 명확히 알려 주지 않으면 자주 놓쳤습니다.
• 가장 큰 변화: 개발 속도보다 리뷰 대화의 밀도가 먼저 달라졌습니다.

페어 프로그래밍처럼 다루면 효율이 올라갔습니다

AI 코딩 도구를 개인 비서처럼만 쓰면 결과가 들쑥날쑥했습니다. 반대로 옆자리 동료에게 설명하듯이 배경, 제약, 기대 결과를 말해 주면 훨씬 안정적인 답을 얻었습니다. 예를 들어 “이 함수 고쳐줘”보다 “결제 실패 시 재시도는 하지 않고, 사용자에게만 상태를 남겨야 한다”처럼 업무 조건을 넣는 편이 낫습니다.

팁: AI에게 바로 구현을 맡기기 전에 “수정할 파일 후보와 이유만 먼저 말해줘”라고 요청하면 엉뚱한 대규모 수정이 줄어듭니다.

이 방식은 특히 코드 리뷰 전 단계에서 좋았습니다. AI가 만든 변경을 그대로 믿는 대신, 변경 범위를 작게 나누고 사람이 의도를 확인하는 흐름을 만들면 빠른 작성과 안전한 검토 사이의 균형이 잡힙니다.

제가 가장 많이 쓴 기능은 자동완성이 아니었습니다

실전에서는 설명 요청이 더 오래 살아남았습니다

사용 전에는 자동완성이 핵심이라고 생각했습니다. 하지만 실제로 매일 쓴 기능은 “이 코드가 왜 이렇게 되어 있는지 설명해 달라”는 요청이었습니다. 오래된 프로젝트에서는 함수 하나보다 호출 흐름을 이해하는 시간이 더 많이 들기 때문입니다.

특히 백엔드와 프론트엔드가 함께 엮인 작업에서는 AI에게 먼저 경로를 설명시켰습니다. API 요청이 어느 컨트롤러로 들어가고, 어떤 서비스 계층을 지나며, 마지막에 어떤 상태를 화면에 반영하는지 말하게 하면 개발자가 놓친 연결부가 보입니다.

1. 수정하려는 기능명을 먼저 말합니다.
2. 관련 파일 후보를 찾게 합니다.
3. 각 파일의 역할을 한 문장씩 요약하게 합니다.
4. 그다음에야 구현안을 요청합니다.

보안 질문을 습관처럼 붙였습니다

AI가 만들어 준 코드는 그럴듯하지만, 그럴듯함이 곧 안전함은 아니었습니다. 입력값 검증, 인증 확인, 로그에 남기면 안 되는 정보 같은 부분은 사람이 의식적으로 다시 물어야 했습니다. 코드 보안이라는 표현이 막연하다면 코드 보안의 기본 개념을 먼저 훑어보면 질문의 방향을 잡는 데 도움이 됩니다.

제가 자주 쓰는 문장은 단순합니다. “이 변경에서 인증 우회, 민감정보 노출, 예외 처리 누락 가능성을 찾아줘.” 이렇게 묻고 나면 AI가 완벽한 감사를 해 주지는 않더라도, 개발자가 다시 봐야 할 지점을 꽤 잘 짚어 줍니다.

• 입력값: 사용자가 보낸 값이 그대로 쿼리나 명령에 들어가지 않는지 봅니다.
• 권한: 화면에서 숨긴 기능이 서버에서도 막혀 있는지 확인합니다.
• 로그: 토큰, 이메일, 결제 정보가 디버그 로그에 남지 않는지 점검합니다.
• 예외: 실패 응답이 내부 구조를 과하게 드러내지 않는지 확인합니다.

이 과정을 거치면 AI 코딩은 단순한 작성 도구가 아니라, 놓치기 쉬운 질문을 반복해서 던지는 보조 리뷰어처럼 작동합니다.

팀에 붙일 때는 프롬프트보다 작업 단위가 중요했습니다

큰 요청은 거의 항상 흔들렸습니다

“관리자 페이지 전체를 개선해 줘”처럼 큰 요청을 넣으면 결과가 화려해 보일 수는 있습니다. 하지만 실제 프로젝트에서는 파일이 너무 많이 바뀌고, 기존 디자인 규칙과 API 응답 구조를 어기는 경우가 생겼습니다. 그래서 저는 큰 요청을 작은 작업 단위로 쪼개는 방식으로 바꿨습니다.

예를 들어 대시보드 개선이라면 바로 구현을 맡기지 않았습니다. 먼저 지표 카드의 계산 기준, 빈 상태 메시지, 로딩 처리, 권한별 노출 여부를 나눴습니다. 이렇게 하면 AI가 한 번에 모든 것을 상상하지 않아도 되고, 사람도 결과를 검토하기 쉬워집니다.

• 1단계: 현재 구조 설명만 요청합니다.
• 2단계: 변경 범위와 위험 지점을 목록화합니다.
• 3단계: 가장 작은 파일 묶음부터 수정합니다.
• 4단계: 테스트 또는 수동 확인 방법을 함께 받습니다.

리뷰 코멘트는 AI에게 번역시키듯 다듬었습니다

팀에서 의외로 도움이 된 부분은 코드 작성보다 커뮤니케이션이었습니다. 리뷰에서 “왜 이렇게 했나요?”라고 쓰면 공격적으로 보일 수 있지만, AI에게 “의도를 확인하는 부드러운 리뷰 코멘트로 바꿔줘”라고 요청하면 훨씬 협업에 맞는 문장이 나왔습니다.

또한 반복되는 리뷰 패턴을 모아 두면 다음 작업에서 프롬프트 품질이 올라갑니다. “우리 팀은 조기 반환을 선호한다”, “비즈니스 로직은 컴포넌트에 두지 않는다”, “외부 API 실패는 사용자 메시지와 내부 로그를 분리한다” 같은 규칙을 짧게 붙여 두는 식입니다.

현장 팁: 팀 규칙은 길게 쓰기보다 “금지 3개, 선호 3개, 확인 3개”로 압축할 때 AI가 더 잘 지킵니다.

이때 코드 보안 요약처럼 짧게 정리된 개념 자료를 팀 온보딩 문서 옆에 붙여 두면, 비개발 직군과 이야기할 때도 기준을 공유하기가 쉬웠습니다. 어려운 용어를 길게 설명하기보다 같은 기준표를 보며 “이 부분은 노출 위험이 있다”고 말할 수 있기 때문입니다.

AI 코딩 도구는 계속 바뀌니 기록 방식도 같이 바뀌어야 합니다

요금보다 더 자주 바뀐 것은 사용 범위였습니다

실제 사용하면서 느낀 점은 도구의 가격표보다 사용 범위가 더 빨리 바뀐다는 것입니다. 어떤 달에는 자동완성이 핵심처럼 보이다가, 다음 달에는 에이전트형 작업, 터미널 명령 제안, PR 요약, 테스트 생성이 더 중요해졌습니다. 그래서 특정 도구 하나를 영원한 정답처럼 고르기보다, 팀이 어떤 작업에서 시간을 잃는지 계속 기록하는 편이 낫습니다.

저는 도구를 평가할 때 기능 목록만 보지 않습니다. “실패했을 때 복구가 쉬운가”, “변경 이유를 설명하게 만들 수 있는가”, “보안 질문을 반복해도 답이 안정적인가”를 봅니다. 코드를 작성하는 속도는 첫 주에 눈에 띄지만, 팀에 남는 효과는 보통 이런 운영 기준에서 갈립니다.

1. 주간 기록: AI 도움으로 줄인 작업과 다시 손본 작업을 함께 적습니다.
2. 실패 기록: 잘못 만든 코드, 과한 수정, 놓친 보안 조건을 따로 모읍니다.
3. 프롬프트 기록: 잘 먹힌 요청문을 팀 템플릿으로 남깁니다.
4. 검토 기록: 사람이 반드시 확인해야 하는 항목을 계속 업데이트합니다.

다음 달에도 통하는 기준만 남겼습니다

AI 코딩 환경은 빠르게 변합니다. 모델 성능, 에디터 연동, 저장소 접근 방식, 기업용 보안 옵션은 시간이 지나면 달라질 수 있습니다. 그래서 저는 글을 쓰는 지금 기준의 도구 이름보다, 시간이 지나도 흔들리지 않는 사용 습관을 더 중요하게 봅니다.

특히 팀에서 오래 쓸 기준은 세 가지였습니다. 첫째, AI가 만든 변경은 작은 단위로 남길 것. 둘째, 보안과 권한 질문을 별도 단계로 둘 것. 셋째, 좋은 결과뿐 아니라 실패한 프롬프트도 기록할 것. 이 세 가지를 지키면 도구가 바뀌어도 팀의 AI 코딩 워크플로우는 쉽게 무너지지 않았습니다.

• 도구가 바뀌어도 남는 것: 작은 작업 단위, 명확한 제약, 리뷰 가능한 변경 기록
• 계속 확인할 것: 요금제, 저장소 접근 권한, 기업 데이터 처리 조건
• 주의할 것: 최신 기능이 늘어날수록 자동 적용 범위도 넓어질 수 있습니다.

코드라는 말 자체가 여러 맥락에서 쓰이듯, 개발 현장의 코드는 단순한 문자열이 아니라 팀의 약속과 운영 방식까지 품고 있습니다. 용어의 폭이 궁금하다면 로 코드 관련 설명도 참고할 만합니다. 결국 AI 코딩을 잘 쓰는 팀은 최신 도구를 가장 빨리 눌러 보는 팀이 아니라, 바뀌는 도구를 자기 작업 기록 안으로 차분히 흡수하는 팀에 가까웠습니다.