AI 시대를 살아가는 개발자의 덕목

GitHub Copilot, Claude, ChatGPT. 이제 코드는 자연어 한 줄이면 나온다. 코드 짜는 행위 자체의 가치가 빠르게 바뀌고 있다.

AI가 어떻게(How)를 점점 잘 해결해주는 시대에, 개발자한테 남는 건 무엇을(What)과 왜(Why)를 정의하는 능력이다. 요즘 그게 뭔지 나름대로 정리해봤다.

논리적 사고와 정확한 프롬프트

AI는 입력에 따라 출력이 달라진다. 모호한 질문에는 모호한 답이 나온다.

❌ "로그인 기능 만들어줘"
✅ "SvelteKit에서 GitHub OAuth를 구현해줘. 
    Cloudflare Workers 환경이라 Node.js API는 사용 불가하고,
    세션은 HMAC-SHA256 서명된 쿠키로 관리해야 해."

결국 좋은 프롬프트는 좋은 사고의 결과물이다. 요구사항을 정확히 분석하고, 제약 조건을 명시하고, 기대하는 결과를 구체적으로 기술하는 능력. 프롬프트 잘 쓰는 게 별도 기술이 아니라, 결국 엔지니어링 역량 그 자체다.

시스템 설계 능력

AI는 함수 하나는 잘 짠다. 하지만 시스템 전체를 설계하는 건 여전히 사람의 영역이다.

이 서비스의 트래픽 패턴은 어떤지
데이터는 어디에, 어떤 형태로 저장할 건지
장애가 나면 어떻게 복구할 건지
컴포넌트 간 의존성은 어떻게 관리할 건지

함수 단위의 정답은 AI에게 맡기더라도, 아키텍처 레벨의 판단은 경험과 트레이드오프에 대한 이해에서 나온다. “이 규모에서 마이크로서비스가 맞아?” 같은 질문에 AI는 교과서적인 답만 준다. 우리 팀 상황에 맞는 답을 내리는 건 결국 사람이다.

기술의 원리와 개념에 대한 이해

프레임워크 사용법은 AI가 알려준다. 하지만 왜 그렇게 동작하는지를 모르면, 문제가 생겼을 때 대응하기 어렵다.

HTTP 요청의 생명주기를 모르면 CORS 에러를 진단하고 해결하기 어렵다
이벤트 루프를 모르면 비동기 버그를 AI에게 설명조차 할 수 없다
브라우저 렌더링 파이프라인을 모르면 성능 최적화를 근거 없이 시도하는 것과 다르지 않다

AI 시대에 오히려 기초 CS 지식의 가치가 올라간다. API 사용법은 자동화되지만, 그 아래 원리를 아는 사람만 AI가 내놓은 코드가 맞는지 틀린지 판단할 수 있다.

문제 분해 능력

복잡한 문제를 AI에게 통째로 던지면 십중팔구 실패한다. 핵심은 적절한 크기로 나누는 것이다. 문제 분해(task decomposition), 소프트웨어 엔지니어링에서 늘 해오던 거다.

“결제 시스템을 만들어줘”가 아니라:

결제 요청 검증 로직
PG사 API 연동 어댑터
결제 상태 관리 상태머신
실패 시 재시도/보상 트랜잭션

각 단위가 독립적으로 동작하고 명확한 인터페이스로 연결되게 나누는 것. 객체지향에서 말하는 단일 책임 원칙과 같은 맥락이다. 모듈 하나가 하나의 역할만 하면, AI에게 맡기기도 쉽고 사람이 검증하기도 쉽다.

잘 나눴다는 건 문제를 잘 이해하고 있다는 뜻이기도 하다.

비판적 검증 능력

AI가 생성한 코드는 대부분 “그럴듯하게 동작한다.” 근데 그럴듯함과 정확함은 다르다.

SQL 인젝션에 취약한 쿼리를 자신 있게 생성하기도 하고
존재하지 않는 라이브러리를 import하기도 하고
엣지 케이스를 빠뜨린 채 깔끔한 코드를 내놓기도 한다

AI 출력을 검증하지 않고 사용하면 보안·성능·정확성 문제가 생길 수 있다. 동료 코드를 리뷰하듯, AI가 짠 코드도 같은 관점에서 확인해야 한다.

도메인 지식과 습득력

소프트웨어는 결국 현실의 문제를 풀기 위해 존재한다.

핀테크 개발자가 금융 규제를 모르면, 코드가 아무리 깔끔해도 실제 서비스에서는 못 쓴다. 헬스케어 개발자가 의료 데이터 규정을 모르면, AI가 만든 코드가 규정에 맞는지 판단할 수가 없다.

AI는 범용적이지만, 특정 도메인의 맥락과 뉘앙스는 그 분야에서 일해본 사람만 알 수 있다. 그리고 새 도메인으로 옮겼을 때 빠르게 핵심을 뽑아내는 습득력. 이게 결국 적응력이다.

맥락 전달력

프롬프트 작성에만 해당하는 얘기가 아니다. 동료에게, 비개발 직군에게, 그리고 미래의 나에게 맥락을 정확히 전달하는 능력.

왜 이 기술 스택을 선택했는지
이 설계에서 어떤 트레이드오프를 감수했는지
이 코드가 어떤 제약 조건 아래서 작성됐는지

AI가 코드를 대신 써줄수록, 개발자의 역할은 의사결정의 근거를 설명하는 쪽으로 옮겨간다. 코드는 AI가 쓰더라도, 왜 이 코드가 필요한지 설명하는 건 사람의 몫이다.

AI 에이전트를 다루는 기술: 하네스 엔지니어링

요즘은 AI를 단순히 “질문-답변” 용도로 쓰는 단계를 넘어서, 에이전트로 활용하는 흐름이 빠르게 퍼지고 있다. 코드 작성, 리서치, 배포까지 AI에게 맡기는 시대다.

문제는, 이걸 아무런 구조 없이 쓰면 꽤 빠르게 망가진다는 거다.

컨텍스트가 비대해져서 응답 품질이 떨어지고, 특정 LLM의 동작 방식에 종속적인 프롬프트를 쓰게 되고, 에이전트마다 규칙이 제각각이라 결과물의 일관성이 없어진다. 한마디로, AI를 많이 쓸수록 오히려 통제가 안 되는 상황이 생긴다.

이걸 해결하려는 접근이 하네스 엔지니어링이다. AI 에이전트에게 명확한 정체성, 도구 권한, 행동 규칙, 메모리 구조를 부여해서 예측 가능하게 만드는 것. 이 개념은 별도 글에서 더 자세히 다룬다.

비개발자와의 커뮤니케이션

개발자끼리는 코드를 보면 통한다. 문제는 개발자가 대화해야 하는 상대가 개발자만이 아니라는 거다.

기획자가 “이거 간단하죠?”라고 물을 때, “간단하지 않다”고 답하는 건 쉽다. 어려운 건 왜 간단하지 않은지를 상대가 이해할 수 있는 언어로 설명하는 거다. “캐시 무효화 로직이 복잡해서요”라고 말하면 기획자 입장에서는 그게 하루짜리인지 일주일짜리인지 감이 안 온다.

AI가 코드를 대신 짜주면서, 개발자의 시간이 구현에서 커뮤니케이션으로 옮겨가고 있다. 기술적 의사결정을 비기술 직군에게 납득시키고, 일정의 리스크를 사전에 공유하고, 트레이드오프를 비즈니스 관점에서 설명하는 일. 이건 AI가 대신해줄 수 없다.

솔직히, 코드를 잘 짜는 개발자보다 이해관계자와 소통을 잘하는 개발자가 조직에서 더 영향력이 크다. AI 시대에는 그 격차가 더 벌어질 거다.