시니어 개발자 전쟁: AI는 날개를 달아주지만 조종할 준비가 된 사람에게만
Source: Dev.to
실제로 버틸 수 있는 솔루션을 만드는 고군분투
공장 도구와 제조 용어는 제쳐두세요. 진짜 문제는 이렇습니다: AI는 생각보다 빠르게 코드를 작성할 수 있지만, 무엇을 유지해야 할지는 알려주지 못합니다. 바로 여기서 시니어 개발자가 강점을 갖게 됩니다.
현장에서 실제로 일어나는 일로 설명하면
AI는 거울과 같습니다. “내 코드가 작동하지 않아”라고 물으면 쓰레기를 돌려받게 됩니다.
좋은 프로그래머는 대신 이렇게 합니다:
- 문제 범위 좁히기: “Safari에서만 10분 후에 인증이 깨져요.”
- 맥락 제공: 사용 중인 프레임워크, 기대하는 동작, 실제 발생한 현상을 명시합니다.
- 시도한 내용 보여주기: “토큰 만료를 확인했고, localStorage도 써봤지만 여전히 실패합니다.”
- 오류 공유: 정확한 스택 트레이스를 그대로 붙여넣고, 요약하지 않습니다.
- 가정 명시: “세션 쿠키가 만료된다고 가정합니다.”
왜냐하면, 효과적인 질문을 하면 시간 절약, 디버깅 속도 향상, 협업 효율화, 그리고 AI를 진정으로 유용하게 만들 수 있기 때문입니다. Garbage in, garbage out. 질문의 질 = 답변의 질.
함정
코드가 많을수록 생산성이 높다는 생각은 역효과입니다.
현실: 코드가 많을수록 유지보수가 늘어난다.
추가하는 모든 기능·추상화·레이어는 6개월 뒤 새벽 2시에 디버깅해야 할 대상이 됩니다. 경험 많은 엔지니어는 언제 멈춰야 할지 압니다.
보통 더 나은 해결책은 다음과 같습니다:
- 복잡성을 추가하기보다 제거한다.
- 실제로 필요 없는 로직을 삭제한다.
- 이미 존재하는 도구를 활용한다.
- 움직이는 부품 수를 줄인다.
문제를 안정적으로 해결하는 가장 짧은 코드는 유지보수가 가장 쉽습니다. 우아함은 영리함이 아니라 좋은 의미에서의 지루함입니다.
초보자가 흔히 하는 실수
- 무작위 파일을 수정하며 “뭔가 되길” 기대한다.
- 하나를 고치려다 세 개의 새로운 버그를 만든다.
- 눈앞에 있는 오류 메시지를 무시한다.
- 사실을 확인하지 않고 가정에 의존한다.
숙련된 엔지니어는 감정적 절제력을 길렀습니다. 디버깅 과정은 체계적입니다:
- 관찰: 정확히 무엇이 깨졌는가?
- 재현: 로컬에서 다시 만들 수 있는가?
- 격리: 무엇이 바뀌었는가? 변화를 좁힌다.
- 가정 검증: 데이터베이스가 다운된 건가, 아니면 커넥션 풀만 문제인가?
- 확인: 문제를 고친 뒤 실제로 해결됐는지 검증한다.
스트레스는 터널 비전을 만들지만, 침착함은 근본 원인에 더 빨리 도달하게 합니다.
고전적인 컴퓨터 과학 농담이 존재하는 이유
“컴퓨터 과학에서 어려운 것은 두 가지뿐이다: 캐시 무효화, 이름 짓기, 그리고 오프‑바이‑원 오류.”
// Hard to read, raises cognitive load
let x;
let data2;
function processThing() {}좋은 이름은 혼란을 없애고, 온보딩 시간을 단축하며, 버그를 줄이고, 귀중한 정신적 노력을 절약합니다.
// Intent is immediately clear
let customerProfile;
let invoiceTotal;
function calculateMonthlyRevenue() {}코드는 작성된 것보다 10배 더 많이 읽힙니다. processThing()이 무엇을 하는지 내부를 열어보지 않고는 알 수 없다면 이미 패배한 겁니다. 명확한 이름은 영리한 알고리즘보다 더 중요합니다.
프로그래밍은 정신적으로 비용이 많이 듭니다. 8시간을 일해도 산만하고, 수면 부족이며, 5분마다 컨텍스트를 전환한다면 아무것도 이루지 못합니다. 뇌가 타버르면 시간 관리는 무의미합니다.
차이점 예시
- 개발자 A: 산만하고, 수면 부족, 끊임없이 컨텍스트 전환 → 8시간 일했지만 진행 없음.
- 개발자 B: 집중하고, 충분히 쉬며, 보호된 딥 워크 블록에서 작업 → 4시간 일했지만 고품질 기능을 배포.
엘리트 개발자는 단순히 캘린더를 관리하지 않습니다. 인지 용량을 관리합니다. 그들은 다음을 보호합니다:
- 수면과 신체 건강
- 집중과 딥 워크 시간
- 전략적 휴식(스크린에서 눈을 떼는 시점)
번아웃은 지식 부족보다 생산성을 더 빠르게 파괴합니다. AI가 이를 해결해 주지는 못합니다. 뇌가 타버리면 AI를 이용해 더 많은 쓰레기를 더 빨리 만들 뿐입니다.
AI는 날개를 달아 주지만, 이미 조종사인 경우에만
- 문제 범위 좁히기: “오류는 여기, 시도한 것은 여기, 놓친 부분은 뭐지?” 라고 물어보세요.
- 과도한 코딩 방지: “더 간단한 방법이 있을까?” 라고 물어보며 추상화를 도전하게 하세요.
- 침착함 유지: 오류를 붙여넣고 “단계별 디버깅 과정을 알려줘” 라고 요청하면 위기 상황에 차분한 목소리가 됩니다.
- 이름 짓기: “이 함수가 하는 일을 설명하는 더 좋은 이름 5개를 줘” 라고 물어보세요.
- 에너지 절약: 반복적인 보일러플레이트, 기본 테스트, 문서 작성을 AI에게 맡기고, 어려운 아키텍처 결정에 뇌력을 집중하세요.
가치 있는 솔루션을 만드는 고군분투는 코드를 더 많이 쓰는 것이 아니라
무엇을 삭제할지, 언제 멈출지, 모든 것이 엉망일 때 어떻게 명확하게 생각할지를 아는 것입니다. AI는 그 능력을 대신해 주지 못합니다. 하지만 그 스킬을 갖추고 있다면 AI는 실행 속도를 10배 빠르게 만들어 줍니다.
초보 개발자의 “이커머스 플랫폼을 만들라”는 공포
경험 많은 개발자는 바로 범위를 축소합니다:
- 사용자 인증
- 제품 모델 & 스키마
- 장바구니 기능
- 결제 게이트웨이 연동
프로그래밍은 본질적으로 분해입니다. 거대하고 복잡한 시스템도 작은, 해결된 문제들의 집합일 뿐입니다.
AI와 함께 할 때
“이커머스 플랫폼을 만들어 줘” 대신
“타입스크립트로 로컬라이즈된 장바구니 리듀서를 단위 테스트와 함께 작성해 줘” 라고 요청하세요. 작은 조각이 더 나은 AI 출력과 번개 같은 피드백 루프를 만들습니다.
소프트웨어는 사람을 위해 만들어지지만, 많은 개발자는 기계만 생각합니다. 인간 행동을 이해하면 다음을 예측할 수 있습니다:
- 흔한 사용자 실수
- 혼란스러운 UI
- 팀 커뮤니케이션 병목
- 변화하는 제품 기대치
- 고객 불만
기술 스킬만으로는 인간 이해가 부족한 시스템을 만들게 됩니다. 수학적으로는 정확하지만 실용적이지 않은 제품이 탄생합니다. 공감은 엔지니어링 스킬입니다. AI는 코드를 쓸 수 있지만, 사용자가 레이아웃을 직관적으로 느낄지는 알려주지 못합니다. 그 책임은 여러분에게 있습니다.
시간 추정의 함정
신입 개발자는 “이 기능은 한 시간 정도 걸릴 거야”