AI 시대를 살아가는 개발자의 덕목
코드를 작성하는 행위 자체의 가치가 빠르게 변하고 있다. GitHub Copilot, Claude, ChatGPT — 이제 코드는 자연어 한 줄로 생성된다. 그렇다면 개발자는 무엇으로 차별화되는가?
AI가 어떻게(How)를 점점 잘 해결해주는 시대에, 개발자의 가치는 무엇을(What)과 왜(Why)를 정의하는 데 있다. 이 글에서는 AI 시대에 개발자가 갖춰야 할 핵심 덕목을 정리해본다.
1. 논리적 사고와 정확한 프롬프트
AI는 마법이 아니다. 모호한 질문에는 모호한 답이 돌아온다.
❌ "로그인 기능 만들어줘"
✅ "SvelteKit에서 GitHub OAuth를 구현해줘.
Cloudflare Workers 환경이라 Node.js API는 사용 불가하고,
세션은 HMAC-SHA256 서명된 쿠키로 관리해야 해." 결국 좋은 프롬프트는 좋은 사고의 결과물이다. 요구사항을 정확히 분석하고, 제약 조건을 명시하고, 기대하는 결과를 구체적으로 기술하는 능력. 이건 프롬프트 엔지니어링이 아니라 소프트웨어 엔지니어링의 본질이다.
2. 시스템 설계 능력
AI는 함수 하나는 잘 짠다. 하지만 시스템 전체를 설계하는 건 여전히 사람의 영역이다.
- 이 서비스의 트래픽 패턴은 어떤가?
- 데이터는 어디에, 어떤 형태로 저장할 것인가?
- 장애가 발생하면 어떻게 복구할 것인가?
- 컴포넌트 간의 의존성은 어떻게 관리할 것인가?
함수 단위의 정답은 AI에게 맡기더라도, 아키텍처 레벨의 판단은 경험과 트레이드오프에 대한 이해에서 나온다. “이 정도 규모에서 마이크로서비스가 맞는가?” 같은 질문에 AI는 일반론을 말해줄 뿐, 우리 팀의 상황에 맞는 답을 내리는 건 개발자의 몫이다.
3. 기술의 원리와 개념에 대한 이해
프레임워크의 사용법은 AI가 알려준다. 하지만 왜 그렇게 동작하는지를 이해하지 못하면, 문제가 생겼을 때 속수무책이 된다.
- HTTP 요청의 생명주기를 모르면 CORS 에러 앞에서 무력하다
- 이벤트 루프를 모르면 비동기 버그를 AI에게 설명조차 할 수 없다
- 브라우저 렌더링 파이프라인을 모르면 성능 최적화는 감에 의존하게 된다
AI 시대에 오히려 기초 CS 지식의 가치가 올라간다. 표면적인 API 사용법은 자동화되지만, 그 아래의 원리를 아는 사람만이 AI의 출력을 올바르게 평가하고 수정할 수 있다.
4. 문제 분해 능력
복잡한 문제를 AI에게 통째로 던지면 대부분 실패한다. 핵심은 적절한 크기로 나누는 것이다. 이건 결국 Divide and Conquer — 컴퓨터 과학의 가장 오래된 원칙 중 하나다.
“결제 시스템을 만들어줘”가 아니라:
- 결제 요청 검증 로직
- PG사 API 연동 어댑터
- 결제 상태 관리 상태머신
- 실패 시 재시도/보상 트랜잭션
각 단위가 독립적으로 동작하고, 명확한 인터페이스로 연결되도록 나누는 것. 객체지향에서 단일 책임 원칙이라 부르는 것과 같은 맥락이다. 모듈 하나가 하나의 역할만 담당하면, AI에게 맡기기도 쉽고, 사람이 검증하기도 쉽다.
문제를 잘 나누는 능력은 곧 문제를 잘 이해하고 있다는 증거이기도 하다.
5. 비판적 검증 능력
AI가 생성한 코드는 대부분 “그럴듯하게 동작한다.” 하지만 그럴듯함과 정확함은 다르다.
- SQL 인젝션에 취약한 쿼리를 자신 있게 생성하기도 하고
- 존재하지 않는 라이브러리를 import하기도 하고
- 엣지 케이스를 빠뜨린 채 깔끔한 코드를 내놓기도 한다
AI의 출력을 무조건 신뢰하지 않는 습관이 중요하다. 코드 리뷰를 할 때 동료의 코드를 검토하듯, AI가 작성한 코드도 보안·성능·정확성 관점에서 검증해야 한다. AI를 잘 쓰는 개발자는 AI를 의심할 줄 아는 개발자다.
6. 도메인 지식과 습득력
결국 소프트웨어는 현실의 문제를 해결하기 위해 존재한다.
핀테크 개발자가 금융 규제를 모르면, 아무리 깔끔한 코드를 작성해도 실제 서비스에서는 쓸 수 없다. 헬스케어 개발자가 의료 데이터 규정을 이해하지 못하면, AI가 생성한 코드의 컴플라이언스를 판단할 수 없다.
AI는 범용적이다. 하지만 특정 도메인의 맥락과 뉘앙스를 이해하는 것은 그 분야에서 일해본 사람만이 할 수 있다. 그리고 새로운 도메인으로 이동했을 때 빠르게 핵심을 파악하는 습득력 — 이것이 AI 시대에 개발자의 적응력을 결정한다.
7. 맥락 전달력
이건 프롬프트 작성에만 해당하는 게 아니다. 동료에게, 비개발 직군에게, 그리고 미래의 자신에게 맥락을 정확히 전달하는 능력.
- 왜 이 기술 스택을 선택했는지
- 이 설계에서 어떤 트레이드오프를 감수했는지
- 이 코드가 어떤 제약 조건 아래서 작성됐는지
AI가 코드 생성을 대신해줄수록, 개발자의 역할은 의사결정의 근거를 설명하는 것으로 이동한다. 코드는 AI가 쓰더라도, 그 코드가 존재하는 이유를 설명하는 건 사람의 일이다.
8. AI 에이전트를 다루는 기술 — 하네스 엔지니어링
요즘은 AI를 단순히 “질문-답변” 용도로 쓰는 단계를 넘어서, 에이전트로 활용하는 흐름이 빠르게 퍼지고 있다. 코드 작성, 리서치, 배포까지 AI에게 맡기는 시대다.
문제는, 이걸 아무런 구조 없이 쓰면 꽤 빠르게 망가진다는 거다.
컨텍스트가 비대해져서 응답 품질이 떨어지고, 특정 LLM의 동작 방식에 종속적인 프롬프트를 쓰게 되고, 에이전트마다 규칙이 제각각이라 결과물의 일관성이 없어진다. 한마디로, AI를 많이 쓸수록 오히려 통제가 안 되는 상황이 생긴다.
이걸 해결하려는 접근이 하네스 엔지니어링이다. 말(馬)에 고삐를 채우듯, AI 에이전트에게 명확한 정체성, 도구 권한, 행동 규칙, 메모리 구조를 부여해서 예측 가능하게 만드는 것. 이 개념에 대해서는 별도 글에서 더 자세히 다룬다.
9. 비개발자와의 커뮤니케이션
개발자끼리는 코드를 보면 통한다. 문제는 개발자가 대화해야 하는 상대가 개발자만이 아니라는 거다.
기획자가 “이거 간단하죠?”라고 물을 때, “간단하지 않다”고 답하는 건 쉽다. 어려운 건 왜 간단하지 않은지를 상대가 이해할 수 있는 언어로 설명하는 거다. “캐시 무효화 로직이 복잡해서요”라고 말하면 기획자 입장에서는 그게 하루짜리인지 일주일짜리인지 감이 안 온다.
AI가 코드를 대신 짜주면서, 개발자의 시간이 구현에서 커뮤니케이션으로 옮겨가고 있다. 기술적 의사결정을 비기술 직군에게 납득시키고, 일정의 리스크를 사전에 공유하고, 트레이드오프를 비즈니스 언어로 번역하는 일. 이건 AI가 대신해줄 수 없다.
솔직히, 코드를 잘 짜는 개발자보다 이해관계자와 소통을 잘하는 개발자가 조직에서 더 영향력이 크다. AI 시대에는 그 격차가 더 벌어질 거다.
마무리
AI는 개발자를 대체하지 않는다. 다만 어떤 개발자를 대체할 것인가는 명확하다 — 코드만 치는 개발자.
반대로, 문제를 정의하고, 시스템을 설계하고, 원리를 이해하고, 결과를 검증하고, 도메인을 학습하고, 맥락을 전달할 수 있는 개발자는 AI를 통해 오히려 더 강해진다.
도구가 강력해질수록, 도구를 다루는 사람의 판단력이 더 중요해진다. AI 시대의 개발자에게 필요한 건 새로운 기술이 아니라, 더 깊은 사고다.