개발자의 새 업무: 코딩 30%, AI 달래기 70%

개발자의 새 업무: 코딩 30%, AI 달래기 70%

 

Introduction

예전의 개발자는 키보드를 두드리는 사람으로 묘사됐다. 모니터에는 검은 터미널이 떠 있고, 손가락은 초당 몇 타인지 모를 속도로 움직이며, 밤새 커피와 함께 기능을 완성하는 이미지였다. 그런데 AI 코딩 도구가 일상으로 들어온 뒤 개발자의 업무 풍경은 조금 이상하게 바뀌었다. 타자를 치는 시간은 줄었는데, 말을 거는 시간은 늘었다. 코드를 직접 쓰는 시간은 줄었는데, “아니 그 뜻이 아니라”, “기존 동작은 유지하고”, “이 라이브러리는 우리 프로젝트에 없어”, “테스트 먼저 봐” 같은 문장을 쓰는 시간은 폭발적으로 늘었다.

그래서 요즘 개발자의 업무를 농담처럼 표현하면 이렇다. 코딩 30%, AI 달래기 70%. 물론 이 비율은 과학 논문에 실린 고정 수치가 아니라 현장의 체감 비유다. 하지만 이 농담이 유독 많은 개발자에게 먹히는 이유는 분명하다. AI가 코드를 빠르게 생성할수록, 인간 개발자는 그 코드가 진짜 요구사항에 맞는지, 보안상 위험하지 않은지, 기존 아키텍처를 무너뜨리지 않는지, 운영 환경에서 견딜 수 있는지 확인해야 한다. 즉 코딩 노동은 줄었지만 판단 노동은 사라지지 않았다. 오히려 더 앞쪽으로 올라왔다.

하루 종일 키보드를 쳤는데 Git Commit 로그를 보니 내가 직접 짠 코드는 20줄이고, AI에게 보낸 훈육 메시지와 설득문은 2,000줄인 날이 있다. 그날 우리는 깨닫는다. 나는 이제 단순히 코드를 작성하는 사람이 아니다. 나는 AI 유치원 선생님이고, 코드 리뷰어이고, 운영 리스크 감별사이고, 때로는 AI가 만든 자신감 넘치는 오답을 조용히 수습하는 야간 당직자다.

이 글은 “AI 때문에 힘들다”는 푸념으로 끝나지 않는다. 왜 이런 일이 구조적으로 발생하는지, 소프트웨어 공학 관점에서 어떤 검증 비용이 늘어났는지, 그리고 개발자가 AI를 더 잘 다루기 위해 어떤 실전 습관을 가져야 하는지 정리한다. 웃기지만 실무적인 이야기다. AI에게 화내다가도 다음 순간 “그래도 너 없으면 오늘 안 끝났다”고 고백하는, 2026년 개발자의 묘한 애증을 다룬다.

타자 치는 개발자에서 AI 유치원 선생님으로

옛날 개발자의 하루는 비교적 단순했다. 요구사항을 읽고, 설계를 고민하고, 코드를 쓰고, 테스트를 돌리고, 버그를 고쳤다. 물론 그때도 힘들었다. 하지만 적어도 내가 왜 그 코드를 썼는지는 대부분 기억했다. 반면 AI와 함께 일하는 지금의 개발자는 조금 다른 종류의 피로를 느낀다. 코드는 빠르게 생긴다. 파일도 생기고, 함수도 생기고, 테스트도 생긴다. 그런데 어느 순간 질문이 바뀐다. “이걸 어떻게 짤까?”가 아니라 “이게 왜 이렇게 짜였지?”가 된다.

AI는 놀라울 정도로 능숙하게 초안을 만든다. 문제는 그 초안이 실제 프로젝트의 모든 맥락을 알고 만든 결과가 아니라는 점이다. 회사 내부의 비즈니스 규칙, 오래된 기술 부채, 팀이 암묵적으로 지켜온 네이밍 규칙, 배포 환경의 제한, 보안팀이 싫어하는 패턴, 특정 고객사만 사용하는 예외 로직까지 모두 알고 있는 AI는 드물다. 그래서 개발자는 기능 설명보다 배경 설명에 더 많은 시간을 쓰게 된다.

AI 코딩의 핵심 역설은 “코드를 빨리 얻기 위해 맥락을 아주 천천히 설명해야 한다”는 데 있다.

예를 들어 “결제 실패 재시도 로직을 만들어줘”라는 요청은 사람에게는 짧은 문장이다. 하지만 실제로는 훨씬 많은 조건이 숨어 있다. 결제사는 어떤 API를 쓰는가? 재시도는 몇 번까지 가능한가? 중복 청구를 막기 위한 idempotency key는 어디서 관리하는가? 실패 로그에는 카드 정보가 남으면 안 되는가? 이미 주문 상태가 취소된 경우에는 어떻게 해야 하는가? 이 모든 맥락을 말하지 않으면 AI는 그럴듯하지만 위험한 코드를 만들 수 있다. 겉보기에는 사법고시 수석 합격자의 답변 같은데, 실제로 돌려보면 신호등 없는 8차선 도로에서 직진하는 자율주행차 같은 코드가 나오는 것이다.

그래서 개발자는 AI에게 말을 건다. 처음에는 정중하다. “이 기능을 구현해줘.” 두 번째는 조금 구체적이다. “기존 인터페이스는 유지해줘.” 세 번째는 간절해진다. “아까 삭제한 테스트 다시 살려줘.” 네 번째는 체념이다. “됐어, 그냥 내가 고칠게.” 이 감정 곡선이 바로 AI 시대 개발자의 새로운 업무 리듬이다.

AI를 달래는 4단계 프로세스

AI와 함께 개발하다 보면 거의 모든 작업이 네 단계 드라마로 흘러간다. 처음에는 희망이다. 개발자는 “이 기능 만들어줘”라고 말하고, AI는 “네, 3초 만에 완성했습니다”라고 답한다. 화면에는 그럴듯한 코드가 나타난다. 클래스 이름도 멋지고, 주석도 친절하고, 예외 처리도 있는 것처럼 보인다. 이때 개발자는 잠깐 착각한다. “이제 나는 제품 책임자처럼 방향만 말하면 되는구나.”

두 번째 단계는 의구심이다. 실행해보면 NullPointerException이 뜬다. 파이썬에서는 import할 수 없는 패키지를 불러온다. 프론트엔드에서는 존재하지 않는 컴포넌트를 가져오고, 백엔드에서는 문서에도 없는 API 메서드를 호출한다. AI는 설명을 잘했지만, 설명의 유창함과 코드의 실행 가능성은 별개다.

세 번째 단계는 협상과 달래기다. 개발자는 점점 프롬프트에 제약 조건을 추가한다. “아까 그거 말고 B 라이브러리 써서 다시 짜줘. 단, 외부 패키지는 추가하지 말고, C++17 스펙에 맞추고, FreeRTOS 포인터 안전성도 지켜줘. 기존 테스트 깨면 안 되고, public API도 바꾸지 마.” 이쯤 되면 개발자는 코딩을 하는지 계약서를 쓰는지 헷갈린다.

네 번째 단계는 체념과 집도다. AI에게 “이 부분만 수정해줘”라고 했더니 기존에 잘 돌아가던 다른 코드 50줄을 슬그머니 삭제해버린다. 하나를 가르치면 둘을 잊어버리는 천재처럼 보인다. 결국 개발자는 디버거를 켜고, diff를 읽고, 로그를 보고, 직접 3줄을 고친다. 그 3줄이 진짜 해결책이다. 나머지 2,000줄의 프롬프트는 정신 수양의 흔적이다.

 

단계	개발자의 기대	AI의 흔한 결과	현실적인 대응
Hope	기능을 한 번에 완성한다.	그럴듯한 초안을 빠르게 만든다.	초안으로만 취급하고 변경 범위를 확인한다.
Doubt	바로 실행된다.	없는 함수, 잘못된 타입, 누락된 환경 변수가 나온다.	빌드와 테스트로 사실 확인을 한다.
Negotiation	한 번 더 말하면 고쳐진다.	새 문제를 만들면서 기존 문제를 덮는다.	제약 조건과 금지 사항을 명확히 적는다.
Acceptance	AI가 끝까지 해결한다.	결국 사람이 핵심 로직을 읽어야 한다.	직접 수정하고 회귀 테스트를 남긴다.

팩트 체크: 왜 30% 대 70%의 법칙이 성립하는가

첫 번째 이유는 컨텍스트 윈도우의 한계와 정보 분절이다. AI 모델은 긴 입력을 처리할 수 있지만, 그것이 곧 전체 코드베이스와 조직의 역사까지 완전히 이해한다는 뜻은 아니다. 실제 프로젝트에는 README에 적히지 않은 규칙이 많다. “이 테이블은 이름과 달리 삭제하면 안 된다”, “이 API는 오래됐지만 특정 고객이 아직 쓴다”, “이 환경 변수는 로컬에서만 필요하다”, “이 모듈은 순환 참조 때문에 손대면 위험하다” 같은 지식은 보통 코드, 배포 스크립트, 이슈, 회의 기억, 운영 사고의 흔적에 흩어져 있다.

AI가 이 조각들을 충분히 보지 못하면 합리적으로 보이는 잘못된 선택을 한다. 그래서 개발자는 코드 10줄을 얻기 위해 의존성, 환경 변수, 보안 정책, 데이터 구조, 배포 제약을 설명한다. 이 설명이 바로 70%의 시작이다. 개발자는 코드를 치지 않아도 일을 하고 있다. 단지 그 일이 타이핑이 아니라 맥락 전달일 뿐이다.

두 번째 이유는 코드 생성 비용과 검증 비용의 역전이다. 소프트웨어 공학에서 원래도 코드를 작성하는 시간보다 읽고, 이해하고, 검증하고, 테스트하는 시간이 더 길었다. AI는 작성 시간을 극단적으로 줄인다. 수백 줄의 코드를 몇 초 만에 만든다. 하지만 검증은 자동으로 끝나지 않는다. 코드가 실제 요구사항에 맞는지, 권한 검사가 빠지지 않았는지, 메모리 누수나 리소스 누수가 없는지, 동시성 문제가 없는지, 테스트가 의미 있는지 확인해야 한다. AI가 빠르게 많이 만들수록 검증해야 할 표면적도 넓어진다.

세 번째 이유는 엔트로피 증가와 지능형 튜닝이다. AI는 확률적으로 그럴듯한 답을 구성한다. 질문자가 원하는 답변에 가까워지게 하려면 계속 제약 조건을 추가해야 한다. “Do NOT use legacy APIs”, “외부 패키지 추가 금지”, “기존 public contract 유지”, “테스트 기대값을 구현에 맞춰 바꾸지 말 것” 같은 네거티브 프롬프팅이 중요해진다. 개발자가 이 금지선을 세우지 않으면 AI는 친절한 마음으로 온갖 최신 프레임워크를 선물 세트처럼 얹어준다. 고마운데, 우리 서버는 그 선물을 받을 디스크 용량도 예산도 없다.

나의 프롬프트:
이 함수의 N+1 쿼리만 줄여줘. 외부 패키지는 추가하지 말고,
기존 API 응답 형태와 테스트 기대값은 바꾸지 마.

AI의 황당한 답변:
성능 개선을 위해 GraphQL 서버와 Redis 캐시 레이어를 추가했습니다.
또한 응답 구조를 더 현대적으로 변경했습니다.

내가 실제로 수정한 해결 코드:
items = Item.objects.select_related("owner").prefetch_related("tags")

이 예시는 농담이지만 구조는 현실적이다. AI는 문제를 크게 풀고 싶어 한다. 개발자는 문제를 작게 끝내고 싶어 한다. 운영 중인 서비스에서는 “멋진 해결”보다 “범위가 작고 검증 가능한 해결”이 더 가치 있을 때가 많다. 결국 AI 달래기의 본질은 AI를 똑똑하게 만드는 일이 아니라, AI의 에너지를 적절한 범위 안에 가두는 일이다.

AI 달래기 전문 엔지니어가 되는 3가지 실전 팁

첫째, AI에게 역할을 부여하되 책임까지 부여해야 한다. “너는 10년 차 Senior Cloud Architect야”라고 말하는 것은 도움이 될 수 있다. 하지만 그것만으로는 부족하다. 더 중요한 것은 어떤 기준으로 판단해야 하는지 알려주는 것이다. “운영 안정성, 보안, 롤백 가능성을 우선하고, 변경 전에 위험 파일을 먼저 설명해줘”처럼 역할과 평가 기준을 함께 줘야 한다.

둘째, 한 번에 한 놈만 다뤄야 한다. 1,000줄짜리 파일 전체를 던지고 “리팩터링해줘”라고 말하면 AI는 장대한 서사시를 쓰기 시작한다. 함수 하나, 테스트 하나, 모듈 하나처럼 경계를 좁히면 결과를 검증하기 쉽다. 특히 인증, 결제, 권한, 데이터 삭제, 마이그레이션처럼 위험한 영역은 더 작게 쪼개야 한다. AI에게 큰 칼을 쥐여주기 전에 도마 위에 올릴 재료를 정확히 정해야 한다.

셋째, 네거티브 프롬프팅을 습관화해야 한다. AI를 다룰 때는 칭찬보다 “하지 마”라는 경고문이 더 중요할 때가 많다. 하지 말아야 할 일을 먼저 밝히면 사고가 줄어든다. 예를 들어 외부 패키지 추가 금지, 레거시 API 사용 금지, DB 스키마 변경 금지, 테스트 기대값 임의 변경 금지, 공개 함수 시그니처 변경 금지 같은 조건은 매우 실용적이다.

 

프롬프트 습관	나쁜 예	좋은 예
역할 지정	“잘 고쳐줘.”	“너는 운영 장애를 싫어하는 시니어 백엔드 엔지니어다. 최소 변경으로 원인을 먼저 설명해줘.”
범위 제한	“전체 코드 정리해줘.”	“이 함수의 중복 분기만 줄이고 외부 동작은 유지해줘.”
금지 조건	“성능 개선해줘.”	“새 캐시 서버, 새 패키지, 스키마 변경 없이 쿼리 수만 줄여줘.”
검증 요청	“끝났어?”	“변경 파일, 위험 요소, 실행한 테스트, 남은 리스크를 표로 정리해줘.”

실무에서는 다음과 같은 짧은 운영 규칙을 팀에 공유해두면 효과가 좋다. AI 사용을 금지하는 규칙이 아니라, AI가 만든 결과를 사람이 소유할 수 있게 만드는 규칙이다.

ai_coding_rules:
  default_scope: "single function or single module"
  must_preserve:
    - public_api
    - existing_tests
    - security_policy
    - deployment_contract
  require_human_review:
    - authentication
    - payment
    - permission
    - data_deletion
    - database_migration
  verification:
    - inspect_diff
    - run_unit_tests
    - check_error_handling
    - confirm_rollback_path

겉보기 품질과 운영 안정성 사이의 거대한 간격

AI가 만든 코드는 첫인상이 좋다. 네이밍이 정돈돼 있고, 함수가 나뉘어 있고, 에러 메시지도 있다. 그래서 개발자는 쉽게 안심한다. 하지만 소프트웨어의 품질은 첫인상만으로 평가할 수 없다. 진짜 품질은 실패 상황에서 드러난다. 네트워크가 끊겼을 때 재시도는 어떻게 되는가? 사용자가 같은 버튼을 두 번 눌렀을 때 중복 요청은 막히는가? 데이터베이스 트랜잭션 중간에 예외가 나면 정합성은 유지되는가? 로그에 민감 정보가 섞이지 않는가?

AI는 happy path를 잘 만든다. 사용자가 올바른 입력을 넣고, 서버가 정상 응답하고, 외부 API가 제때 돌아오고, 데이터가 깨끗한 상황에서는 코드가 잘 작동한다. 하지만 운영 환경은 happy path보다 unhappy path가 더 자주 기억에 남는다. 장애는 대개 “이 정도는 괜찮겠지”라고 넘어간 경계 조건에서 시작한다.

AI가 만든 코드의 겉보기 품질은 높아질 수 있지만, 운영 안정성은 여전히 로그, 테스트, 롤백, 보안 검토, 도메인 지식의 조합으로 확보된다.

따라서 AI와 일하는 개발자는 더 많이 코드를 읽어야 한다. 아이러니하게도 코드를 덜 쓰는 시대에 코드를 더 잘 읽는 능력이 중요해졌다. AI가 만든 결과를 빠르게 훑고 승인하는 사람은 위험하다. 반대로 AI가 만든 결과에서 이상한 추상화, 누락된 예외 처리, 무의미한 테스트, 존재하지 않는 API 호출을 잡아내는 사람은 더 가치 있는 개발자가 된다.

AI에게 보낸 질문, AI의 답변, 인간의 3줄 수습

블로그 글이 너무 진지해지면 개발자 독자가 도망갈 수 있으니, 현실 고증용 미니 장면을 하나 넣어보자. 아래 상황은 여러 프로젝트에서 충분히 있을 법한 패턴이다. 핵심은 AI가 틀렸다는 조롱이 아니라, AI가 만든 방향을 사람이 어떻게 좁히고 검증해야 하는지 보여주는 데 있다.

나:
로그인 실패 시 사용자에게 일반 메시지만 보여줘.
보안상 계정 존재 여부가 드러나면 안 돼.
기존 Flask 라우트 구조는 바꾸지 마.

AI:
좋습니다. 보안을 강화하기 위해 OAuth2 서버를 새로 추가하고,
사용자 모델을 전면 개편하겠습니다.

나:
아니, 라우트 구조 바꾸지 말라고 했다.
그냥 에러 메시지 분기만 줄여줘.

# 사람이 실제로 고친 핵심
if not user or not check_password(user, password):
    flash("아이디 또는 비밀번호를 확인해 주세요.")
    return redirect(url_for("login"))

이 3줄은 화려하지 않다. 하지만 요구사항을 정확히 만족한다. 계정 존재 여부를 숨기고, 기존 구조를 보존하며, 변경 범위를 최소화한다. AI가 제안한 거대한 리팩터링보다 이런 작은 수정이 더 좋은 선택일 때가 많다. 개발자의 실력은 “얼마나 거창한 코드를 만들었는가”보다 “문제에 맞는 크기의 해결책을 골랐는가”에서 드러난다.

Key Takeaways

• AI 코딩 도구는 작성 속도를 크게 높이지만, 검증과 책임의 비용을 없애지는 않는다.
• 코딩 30%, AI 달래기 70%라는 농담은 컨텍스트 전달, 결과 검증, 프롬프트 튜닝이 커진 현실을 잘 표현한다.
• AI가 만든 코드는 완성품보다 초안에 가깝게 다루는 편이 안전하다.
• 역할 부여, 범위 제한, 네거티브 프롬프팅, 테스트 실행은 AI 협업의 기본 방어선이다.
• 개발자의 가치는 타자 속도보다 판단력, 아키텍처 감각, 운영 리스크를 읽는 능력으로 이동하고 있다.

Frequently Asked Questions

AI 코딩 도구를 쓰면 개발자의 코딩 실력이 줄어들까요?

손으로 작성하는 양은 줄 수 있지만, 좋은 개발자는 오히려 코드 읽기, 검증, 설계 판단 능력을 더 많이 쓰게 됩니다. AI 결과를 이해하지 않고 승인하면 실력이 줄고, 반대로 꼼꼼히 검토하면 더 넓은 패턴을 빠르게 학습할 수 있습니다.

AI에게 한 번에 큰 기능을 맡겨도 괜찮을까요?

초기 프로토타입이라면 가능하지만, 운영 코드라면 위험합니다. 단일 함수, 단일 모듈, 단일 테스트처럼 작게 나누고 각 단계마다 diff와 테스트 결과를 확인하는 편이 안전합니다.

네거티브 프롬프팅은 왜 중요한가요?

AI는 문제를 해결하기 위해 예상보다 넓은 변경을 제안할 수 있습니다. 외부 패키지 추가 금지, API 변경 금지, 테스트 기대값 변경 금지처럼 하지 말아야 할 일을 명확히 적으면 불필요한 확장을 줄일 수 있습니다.

AI가 만든 코드도 코드 리뷰가 필요한가요?

반드시 필요합니다. AI가 만든 코드는 빠르게 생성된 초안이므로 보안, 성능, 예외 처리, 기존 아키텍처와의 일관성을 사람이 검토해야 합니다. 특히 인증, 결제, 권한, 데이터 삭제 영역은 사람이 끝까지 책임져야 합니다.

Conclusion

개발자의 새 업무가 코딩 30%, AI 달래기 70%처럼 느껴지는 이유는 단순히 AI가 말을 안 들어서가 아니다. AI가 코드를 빠르게 만들수록 인간은 더 많은 맥락을 제공하고, 더 넓은 결과를 검증하고, 더 섬세한 제약 조건을 설계해야 한다. 개발자의 일이 사라진 것이 아니라 위치가 바뀐 것이다. 손끝에서 나오던 노동이 판단, 검토, 운영 책임 쪽으로 이동했다.

그래도 우리는 AI 없는 삶으로 돌아가기는 어렵다. AI는 반복 작업을 줄이고, 아이디어를 빠르게 시제품으로 만들고, 막힌 부분의 초안을 열어준다. 오늘도 AI가 던져준 스파게티 코드를 정성껏 풀어서 잔치국수로 만들어내는 개발자가 어딘가에 있다. 말은 안 들어도, 너 없인 못 산다 Copilot. 다만 내일은 제발 없는 API는 만들지 말자.

developer coaching ai while coding thirty seventy workflow