개발자 패러다임 - Agentic Coding 시대에 개발 역량 다시 보기

개요

2~3년 전까지 개발자의 역량은 주로 도메인 지식으로 평가했습니다. 코딩 실력과 특정 플랫폼에 대한 이해도입니다. 회사가 맡기는 일도 “어느 플랫폼의 어느 기능 개발”처럼 나뉘어 있었습니다. 그래서 채용 공고도 “서버 개발자”, “Apple SDK 개발자”, “최신 Kotlin을 잘 아는 Android 개발자”처럼 플랫폼 단위로 쓰였습니다.

Casebook을 만들면서 이 기준에 무언가가 더해지고 있다고 느꼈습니다. 이 글에서는 그 경험을 정리합니다.

여러 플랫폼을 코딩 에이전트와 연결하기

Casebook은 iPhone · iPad · Mac · Apple Vision Pro 앱, 서버, 문서 사이트, 운영 알림까지 여러 환경으로 이루어져 있습니다. 이번에는 대부분을 코딩 에이전트(Claude Code)와 대화하며 직접 해냈습니다. 서버 함수와 데이터베이스, 웹 배포, Slack 웹훅 같은 환경 설정도 마찬가지였습니다.

그렇다고 플랫폼 지식이 필요 없어진 것은 아닙니다. 오히려 반대였습니다. 플랫폼을 깊이 이해해야 그 플랫폼의 개발, 운영, 디자인을 위한 전문적인 프롬프트를 쓸 수 있습니다. 에이전트가 무엇을 잘못하고 있는지 알아채는 것도 그 이해에서 나옵니다. 달라진 것은 플랫폼 지식이 쓰이는 방식입니다. 직접 코드를 쓰는 데서 나아가, 에이전트에게 정확히 일을 맡기는 데 쓰입니다.

매번 다시 써야 했던 “서비스의 결”

정작 번거로웠던 일은 코드가 아니었습니다. 새 대화나 세션을 열 때마다, 서비스의 결을 맞추는 프롬프트를 처음부터 다시 쓰는 일이었습니다. 한 번 잘 나온 결과도 다음 대화에서는 분위기와 형식이 조금씩 어긋났습니다.

매번 다시 써야 했던 것	대화마다 지켜야 했던 결
의뢰인 음성 파일	사건마다 같은 시대감과 말투
사건 이미지 에셋	사건의 분위기와 앱의 그림체
사건 스토리 → .casedoc	이야기를 구상하고 앱 규칙에 맞게 바꾸는 과정
개발 블로그	정해진 형식과 말투
작업 인수인계	지금까지의 맥락을 이해하고 새 팀원이 이어서 일하기

그래서 이 결을 한 번 잘 정의해 두고 어느 대화에서든 다시 쓸 수 있는 프롬프트가 필요했습니다. 특히 마지막 항목은 팀이 커지면서 바로 필요해졌습니다. 혼자 쌓은 맥락을 다른 사람과 그 사람의 에이전트가 이어받을 수 있어야 일을 나눌 수 있습니다.

좋은 협업 프롬프트에는 도메인 지식이 필요하다

개발에 쓰는 공통 프롬프트를 예로 들어 보겠습니다. TCA(The Composable Architecture)는 오픈소스라서, 여러 사람이 각자의 AI 에이전트로 작업해도 에이전트가 같은 구조를 참고해 비슷한 결의 코드를 씁니다. 서로 코드 컨벤션을 하나하나 맞추지 않아도 됩니다.

하지만 Swift와 Apple 플랫폼 개발 역량, 그리고 아키텍처 설계에 대한 이해가 없다면 이 점을 알아챌 수 없습니다. 그러면 서로 다른 AI 에이전트를 쓰고 합류 이전의 맥락을 모르는 사람들이 함께 따를 수 있는 프롬프트도 만들 수 없습니다.

그래서 저는 좋은 프롬프트를 만드는 사람이라면 실력을 믿고 서비스 개발에 참여하는 범위를 넓혀 줄 수 있겠다고 느꼈습니다. 프롬프트에는 그 사람이 도메인을 얼마나 이해하는지, 협업을 얼마나 생각하는지가 그대로 드러나기 때문입니다.

정리

여전히 중요한 것	새로 중요해진 것
도메인 전문 지식 (기술 면접으로 확인하는 역량)	협업과 업무를 간소화하는 프롬프트를 설계하는 능력
플랫폼과 아키텍처에 대한 깊은 이해	서비스의 결을 어느 대화에서든 같은 품질로 재현하게 하는 능력
코드의 정확성	내 맥락을 다른 사람과 에이전트에게 넘겨주는 능력

참고: 프롬프트 설계 능력은 도메인 지식을 대신하지 않습니다. 도메인 지식이 깊을수록 더 좋은 프롬프트가 나옵니다.