이번에는 다소 개인적이고 철학적인 주제로 시작합니다. AI가 코딩을 대신해주는 시대에 “나는 앞으로 어떤 엔지니어로 남을까?”라는 질문이 더 무겁게 다가왔습니다. 이 글에서는 개발자 역할의 재편을 기술적 변화로만 보지 않고, 정체성(통제·책임·창조 욕망) 까지 함께 다루며 제가 잡아본 실천적 기준과 고찰을 정리합니다.
1) 역할은 바뀌고, 핵심은 남습니다: “코더”에서 “판단자”로
AI로 생산성은 올라가지만, 개발자의 정체성은 점점 코드 작성자에서 문제 해결·의사결정·협업을 주도하는 사람으로 이동하고 있습니다. GitHub가 말하는 “변하지 않는 것”은 특히 명확합니다.
- 도메인 이해(무엇이 중요한지 아는 능력)
- 품질·책임에 대한 판단(무엇을 허용/거부할지 정하는 능력)
SemiEngineering도 비슷하게, 반복적·초급 업무는 자동화로 대체되더라도 비판적 사고, 도메인 전문성, 검증은 끝까지 남는다고 봅니다. 결국 AI가 커버하는 범위가 넓어질수록 엔지니어의 무게중심은 “만드는 손”보다 “결정하는 머리”로 이동합니다.
여기서 중요한 갈림길이 하나 있습니다. AI를 기존 흐름에 보강하는지, 아니면 업무 흐름을 전면 재설계하는지에 따라 개인의 체감 변화가 확 달라집니다. 저는 이 포인트가 실제 현장에서 가장 크게 느껴졌습니다. “도구가 하나 추가된 느낌”으로 끝낼지, “일하는 방식 자체가 바뀌는 느낌”이 될지의 차이입니다.
2) 직함은 과도기, 실체는 딜리버리: “AI Engineer”가 답이 아닌 이유
요즘 ‘AI Engineer’ 같은 직함이 늘어나는 건, 역할 재편의 속도가 빠른 과도기적 혼란을 보여주는 신호에 가깝습니다. Medium 글에서 인상적이었던 포인트는 이겁니다.
- 성공하려면 Software Production 역량(운영·품질·배포·관측)과
- 모델 이해(한계, 데이터, 평가, 위험)를
결합해야 합니다.
저도 이 부분에 동의합니다. 직함을 새로 붙이는 것보다 더 중요한 건 “내가 실제로 무엇을 책임지고, 어떤 가치(결과)를 내는가”입니다. AI 기능을 붙여봤지만 운영에서 무너지는 팀을 많이 봤고, 반대로 모델을 깊게 몰라도 제품 품질/책임 체계를 잘 세운 팀은 강했습니다.
3) “대체”가 아니라 “오케스트레이션+리뷰”가 생산성을 만듭니다
hidekazu 글이 말하듯, AI 시대에는 지식/암기 중심 경쟁의 가치는 감소하고 다음이 핵심이 됩니다.
- 문제정의
- 출력 판단(검증/리뷰)
- 실행(딜리버리)
저는 여기서 “AI가 코드를 써주니까 나는 덜 일한다”가 아니라, “AI가 낸 결과를 내가 통제 가능한 시스템 안에 넣는다”가 진짜 변화라고 느꼈습니다. 즉, AI는 대체재가 아니라 오케스트레이션 대상입니다.
예를 들어 “AI에게 시키고 끝”이 아니라, 다음처럼 워크플로에 박아 넣는 방식입니다.
### AI 코드 활용 체크리스트(예시)
1) 의도 명시: 이 변경이 해결하려는 사용자 문제/요구사항은 무엇인가?
2) 위험 표시: 성능/보안/데이터 정합성/회귀 위험은 무엇인가?
3) 검증 설계: 어떤 테스트(단위/통합/e2e)로 확인할 것인가?
4) 관측 가능성: 배포 후 어떤 지표로 이상을 감지할 것인가?
5) 롤백 기준: 어떤 신호가 나오면 되돌릴 것인가?
이 체크리스트는 기술적으로 새롭지 않지만, AI 시대에는 “내가 코드를 썼냐”보다 “내가 이 기준을 지켰냐”가 정체성과 가치의 중심이 됩니다.
4) 그런데 더 어려운 건 마음입니다: 정체성 위기와 ‘알고리즘적 자아’
기술 변화보다 무거운 건 심리적 변화입니다. Psychology Today는 AI가 직업 성취 기반의 전통적 정체성을 흔들면서 존재론적 위기를 유발할 수 있다고 말합니다. 즉 “내가 잘하던 것(코딩) 자체가 더 이상 나의 증명이 아닐 때” 공허함이 생길 수 있습니다.
그리고 Frontiers in Psychology(논문)에서 말하는 ‘알고리즘적 자아’ 개념도 흥미롭습니다. AI 피드백이 우리의 자기이해, 감정, 선호, 행동(agency)을 공동구성하는 상태입니다. 편리하지만, 동시에 자율성과 윤리 문제가 뒤따릅니다.
개발자 입장에서 이게 남의 이야기가 아닌 이유는 간단합니다. 우리는 AI를 “쓰는 사용자”이기도 하지만, 동시에 “AI가 사람을 어떻게 바꾸는지”를 설계하는 쪽에 더 가깝기 때문입니다.
5) 제 결론: 정체성의 중심을 “통제와 책임”에 두되, 불확실성을 공개합니다
대화에서 제 정체성 키워드는 결국 통제와 책임 쪽에 가까웠습니다. 그리고 책임의 기준도 “의도”가 아니라 내 말/제품이 만든 실제 결과에 더 무게를 두고 싶었습니다. 다만 소셜/복잡계에서는 결과가 통제 밖에서 증폭되기 때문에, 책임이 무한대로 커질 위험이 있습니다.
그래서 저는 “책임 있는 엔지니어”를 다음처럼 정의해보고 있습니다.
- 결과에 책임을 지되, 예측 가능성 / 기여도 / 수정 가능성으로 책임 범위를 모델링합니다.
- 무엇보다 불확실성의 표시를 1순위 규범으로 둡니다.
- 대신 불확실성만 말하고 멈추지 않고, “업데이트 규칙(어떤 조건이면 결론을 바꾸겠다)”을 함께 둡니다.
실제로 저는 “오만”과 “무능”을 동시에 피하고 싶었습니다. 불확실성을 숨기면 오만해지고, 불확실성만 말하면 무능해 보일 수 있으니까요. 그래서 제가 선택한 균형점은 이것입니다.
불확실성을 공개한다
+ 지금 할 수 있는 최선의 다음 행동을 제안한다
+ 바뀔 조건(증거/지표/실험 결과)을 명시한다
6) “군주정”에서 “제도”로: 내가 없어도 굴러가게 만드는 리더십
대화 중 가장 크게 꽂힌 문장은 “내가 없어도 굴러가게”였습니다. 저는 팀 내 막내에 가깝지만, 중요한 프로젝트에서 결정권을 나누어가는 흐름에 있습니다.
그래서 다음 단계의 리더십은 “내가 결정하는 능력”을 과시하는 게 아니라, 내 결정 방식을 규칙/프로세스/도구로 이식하는 것이라고 봅니다. 저는 이걸 “군주가 헌법을 만든다”에 가깝다고 느꼈습니다.
예를 들어 이런 것부터 제도화할 수 있습니다.
- GO/NO-GO 기준(무엇이 충족되면 진행/유보인가)
- 리스크 수용 원칙(어떤 위험은 감수하고 어떤 위험은 금지인가)
- 의사결정 로그(왜 이렇게 결정했는가를 남기는 문화)
- 롤백과 정정의 공개성(실수했을 때 신뢰를 잃지 않는 방식)
AI 시대의 통제는 “내가 다 한다”가 아니라 “누구든 같은 기준으로 움직일 수 있게 한다”에 더 가깝습니다.
마무리
AI가 코드를 더 많이 대신할수록, 개발자의 정체성은 “창조(작성)”보다 “통제(검증)와 책임(결과)” 쪽으로 이동합니다. 저는 그 이동을 직함이나 기술 스택이 아니라, 불확실성을 공개하고도 앞으로 나아가는 규칙, 그리고 내가 없어도 굴러가는 제도로 버텨보려 합니다.
참고 자료
- GitHub: The new identity of a developer: what changes and what doesn’t in the AI era
- SemiEngineering: AI’s Impact On Engineering Jobs May Be Different Than Initial Projections
- Medium: AI Engineering: The evolution of the engineer and data scientist role
- hidekazu: AI時代のソフトウェアエンジニアのパラダイムシフト
- Psychology Today: The Psychological Crisis of AI-Driven Identity Loss
- PMC: (Frontiers in Psychology) Algorithmic self 관련 논문