🧑🏻💻 Ep.01 | AI 시대의 엔지니어가 고민해야 할 것들.
이제는 AI가 코드를 써줍니다. 꽤 잘 써주죠.
그래서 불안하다는 엔지니어도 많습니다.
“내 일자리가 사라지나?”라는 질문도 자주 나오고요.
그런데 이 질문은 어쩌면 조금 단순한 질문일지도 모릅니다.
현업자의 시각에서 보면, 그보다 더 불편하고 더 현실적인 질문들이 남아 있습니다.
1. 뭘 시킬지 모르는 문제
예전에는 구현 능력이 곧 실력이었습니다.
Redis 캐시를 어디에 붙일지, 쿼리를 어떻게 다듬을지, 코드 한 줄 한 줄에 공을 들였죠.
하지만 지금은 그 작업의 상당 부분을 AI가 대신해 주는 시대가 되었습니다.
💡그래서 이제 더 중요해진 건 문제 정의 능력입니다.
- 이 기능이 정말 필요한가?
- 사용자가 실제로 겪는 문제는 무엇인가?
- 여러 선택지 중 왜 이 방식을 선택했는가?
“클로드한테 시키면 되지”라는 말은 쉽게 나오지만,
정작 무엇을 시킬지 정하지 못해 멈추는 사람이 훨씬 많습니다.
심지어 같은 작업을 시켜도 시키는 사람에 따라 결과는 완전히 달라집니다.
2. 더 어려워진 코드 리뷰
AI가 생성한 코드는 대부분 컴파일도 되고 테스트도 통과합니다.
문제는 ‘그럴듯하게 틀린다’ 는 점입니다.
동작은 합니다. 하지만 의도와 다를 수 있습니다. 지금은 괜찮아 보이지만,
- 3개월 뒤 장애를 만들 수도 있고
- 기존 기능을 조용히 망가뜨릴 수도 있습니다.
AI가 코드를 많이 작성할수록 리뷰어의 부담은 더 커집니다.
읽는 눈은 더 날카로워져야 합니다.
그런데 아이러니하게도 AI가 대신 작성해주기 때문에 직접 고민하며 코드를 짜는 시간은 줄어듭니다.
감각을 기를 기회가 줄어드는 구조죠. 조금은 찜찜한 상황입니다.
3. “왜”를 기록하는 습관
AI 도구를 사용하면 하루에 여러 개의 PR을 올리는 것도 가능합니다.
수만 라인의 코드도 더 이상 드문 일이 아닙니다.
하지만 그 PR에 “왜 이렇게 했는지”가 없다면 어떨까요?
동료가 읽을 때, 6개월 뒤의 내가 다시 볼 때, 맥락 없는 코드는 그 자체로 기술 부채가 됩니다.
빠르게 작성된 코드일수록 의사결정의 근거를 더 명확히 남겨야 합니다.
예를 들어
- 커밋 메시지
- PR 설명
- 아키텍처 문서
이것들은 귀찮은 부산물이 아니라, 오히려 더 신경 써야 할 핵심 영역이 되어가고 있습니다.
4. 함수 하나는 잘 짜는데
AI에게 “함수 하나 짜줘”라고 말하는 건 쉽습니다. 클래스 하나도 꽤 그럴듯하게 만들어줍니다.
하지만 서비스 전체의 흐름은 여전히 사람의 영역입니다.
예를 들어 이런 질문들입니다.
- 서비스 A가 죽으면 메시지는 유실되는가?
- DB 커넥션 풀이 고갈되면 어디서부터 문제가 터지는가?
- 장애는 어떤 경로로 전파되는가?
이 질문을 던지려면 시스템을 통째로 이해하고 있어야 합니다.
그리고 그 전체 맥락을 구조화해 AI에게 지시하는 일은 생각보다 어렵습니다.
5. 학습이 멈추는 느낌
조금 불편한 이야기를 해보겠습니다.
AI 도구에 모든 것을 맡기면 성장이 멈출 수도 있습니다.
모르는 것이 나왔을 때 바로 물어보면 답은 빨리 얻습니다. 하지만 삽질을 통해 얻는 깊은 이해는 사라질 수 있습니다.
예를 들어, TCP 핸드셰이크를 직접 패킷을 찍어보며 익힌 사람과 설명만 읽은 사람의 차이는 새벽 장애 콜에서 드러납니다.
비효율적으로 일하라는 뜻은 아닙니다. 다만, “이해는 안 되지만 돌아가니까 넘어가자” 이 태도는 경계해야 합니다.
AI가 작성한 코드를 복붙하기 전에, 왜 이렇게 작성됐는지 한 번쯤 따져보는 습관이 필요합니다.
가능하다면 새로운 기술을 배울 때만이라도..
- 먼저 직접 해보고
- 익숙해진 뒤 AI로 가속하는
이 순서를 지키는 것이 좋습니다.
6. 사람과의 소통
채용 공고에서 “커뮤니케이션 능력”이 빠진 적은 없었습니다.
하지만 솔직히 말하면 그동안은 다소 형식적인 경우도 많았습니다.
코드를 잘 짜는 개발자는 어느 정도 용서받았으니까요.
이제는 상황이 조금 달라졌습니다.
AI가 구현을 도와주면서 엔지니어에게 남는 일의 상당 부분이 사람 사이에 놓이게 되었습니다.
예를 들어
- PO에게 기술적 제약을 설명하는 일
- 디자이너와 구현 가능성을 조율하는 일
- 동료와 설계를 두고 토론하는 일
기술적 깊이가 기본이고 소통은 보너스였던 시대가 아니라, 이제는 둘 다 기본인 시대입니다.
7. 만든 것에 대한 책임
AI가 추천 알고리즘을 짜줬습니다. 잘 동작합니다. 전환율도 올랐습니다.
그런데 만약 그 알고리즘이 특정 사용자 그룹을 차별하고 있다면 어떨까요?
AI가 생성한 코드에는 학습 데이터의 편향이 녹아 있을 수 있습니다.
“AI가 짠 건데요”라는 말은 변명이 되지 않습니다.
내가 리뷰했고, 내가 머지했다면 그건 내 코드입니다.
운영에 배포되어 문제가 발생하면, 결국 책임도 내가 지게 됩니다.
8. 결국 바뀌는 건 역할의 무게
코드 한 줄을 얼마나 잘 짜는지, 얼마나 빠르게 타이핑하는지는 예전보다 덜 중요해졌습니다.
✅ 대신 이런 능력이 더 중요해졌습니다.
- 무엇을 만들지 정의하는 능력
- 왜 이렇게 만들었는지 설명하는 능력
- 그 결과에 책임지는 태도
지금까지와 같은 방식으로 일하면 안 된다는 말은 맞습니다.
하지만 도구가 바뀌면 일하는 방식이 바뀌는 건 늘 있어왔던 일입니다.
→ 그 변화에 적응하는 것, 그게 원래 엔지니어의 일이니까요.
우리는 새로운 방식에 조금 더 빠르게 적응하면 됩니다. 일자리를 잃을까 두려워하기보다는,
역할이 바뀌는 지점을 정확히 보는 것. 어쩌면 그것이 더 생산적인 태도일지도 모릅니다.
🌱 현업 고민을 하는 엔지니어들이 모인 곳, 루퍼스
혼자 성장하기 막막하다면 루퍼스에서 그 시작을 함께 해보세요🙌
AI 시대에도 결국 중요한 건 생각하는 힘과 성장하는 환경이라고 믿습니다.
루퍼스에는 성장에 진심인 550+명의 크루가 함께하고 있습니다.
현업에서 부딪히는 고민과 경험을 나누며 함께 성장하는 크루들의 이야기.
전액 기부 강의 그리고 다양한 오프라인 네트워킹까지!
루퍼스는 개발자를 위한 지속 가능한 성장을 만들어 갑니다.
📢 LOOPERS의 소식이 궁금하다면?
Share article