선배 엔지니어가 신입 엔지니어에게 AI 이용을 금지하고 있는 장면이 있었습니다.

"스스로 조사하는 능력을 키웠으면 좋겠다"

"문제 해결 능력 (Problem Solving Ability)을 갖추었으면 좋겠다"

라는 의도가 있었다고 합니다.

그 생각 자체는 매우 잘 이해할 수 있습니다.

엔지니어에게 스스로 조사하는 능력은 매우 중요합니다.

에러를 읽고, 공식 문서 (Official Documentation)를 확인하며, 가설을 세우고 검증하는 능력도 필수적입니다.

눈앞의 문제를 그대로 누군가에게 던지기만 해서는 엔지니어로서 성장하기 어렵다는 생각에도 납득이 갑니다.

다만, 한편으로는 저는 약간의 위화감을 느꼈습니다.

그것은,

"조사하는 능력이나 문제 해결 능력을 갖추길 바라는 것"과 "AI 활용을 금지하는 것"은 별개의 문제가 아닌가

라는 점입니다.

앞으로의 엔지니어에게 필요한 것은 AI를 사용하지 않는 능력만이 아니라고 생각합니다.

오히려 AI를 사용한 상태에서, 출력을 의심하고 근거를 확인하며 스스로 판단하는 능력이 요구되는 것이 아닐까요?

• AI에 대한 우려는 결코 틀리지 않았다
• "AI를 사용하는 것"과 "사고를 포기하는 것"은 다르다
• AI를 사용하면 정말 실력이 늘지 않는 것일까
• 신입 엔지니어에게 필요한 것은 AI를 활용한 문제 해결 능력이다
• 선배 엔지니어가 봐야 할 것은 "AI를 사용했는가"가 아니다
• 금지가 아니라 가드레일 (Guardrail)을 만들어야 한다
• AI는 "답을 내는 도구"가 아니라 "생각하는 과정을 보조하는 도구"다
• AI를 금지하면 AI에 강한 엔지니어는 자라기 어렵다

AI 이용에 신중한 분들의 의견으로는 다음과 같은 것들이 자주 나옵니다.

• AI는 잘못된 정보를 출력할 때가 있어 완전히 신뢰할 수 없다
• 기밀 정보나 개인 정보를 입력해 버릴 리스크가 있다
• 학습 목적으로 사용하면 스스로 생각하는 능력이 붙기 어려워진다

이러한 우려들은 결코 틀리지 않았다고 생각합니다.

생성형 AI (Generative AI)는 그럴듯한 오정보를 내놓을 때가 있습니다.

기술적으로 존재하지 않는 API를 마치 존재하는 것처럼 설명하기도 합니다.

오래된 사양을 전제로 답변하기도 하고, 라이브러리 (Library)의 버전 차이를 충분히 고려하지 않은 답변을 하기도 합니다.

또한, 사내 코드, 고객 정보, 미공개 사양, 개인 정보 등을 부주의하게 입력해 버릴 리스크도 있습니다.

이는 엔지니어로서 경시해서는 안 될 점입니다.

나아가 AI의 답변을 그대로 복사해서 끝내는 것뿐이라면, 학습 효과가 낮아질 가능성도 있습니다.

"돌아가니까 OK"로 끝내 버리면, 왜 돌아가는지를 이해하지 못한 채로 남게 됩니다.

하지만 여기서 중요한 것은, 이러한 문제들이

"AI를 금지해야 할 이유"가 아니라,
"AI를 다루는 법을 가르쳐야 할 이유"

가 아닌가 하는 점입니다.

식칼은 위험하니까 요리를 가르치지 않는다, 라고 하지는 않을 것입니다.

인터넷에는 잘못된 정보가 있으니까 검색을 금지한다, 라는 이야기도 되기 어렵다고 생각합니다.

공식 문서에도 잘못 읽을 가능성이 있으니까 문서를 읽게 하지 않는다, 라는 식으로 가지도 않을 것입니다.

위험이 있다면 위험한 사용법을 피하는 방법을 가르칩니다.

오류가 있다면 검증 방법을 가르칩니다.

의존할 가능성이 있다면 의존하지 않는 사용법을 가르칩니다.

AI에 대해서도 이와 똑같이 생각할 필요가 있는 것이 아닐까요?

AI에 관한 논의에서는 자주 혼동되는 부분이 있다고 느낍니다.

그것은,

AI를 사용하는 것 과

스스로 생각하지 않는 것

을 동일한 것으로 취급해 버리는 것입니다.

물론 다음과 같은 사용법은 그다지 바람직하지 않습니다.

이 에러를 고쳐주세요.

AI가 내놓은 코드를 그대로 붙여넣는다.

돌아가면 종료한다.

왜 고쳐졌는지는 확인하지 않는다.

부작용 (Side Effect)도 생각하지 않는다.

테스트 (Test)도 작성하지 않는다.

공식 문서도 확인하지 않는다.

이러한 사용법으로는 확실히 실력이 붙기 어렵다고 생각합니다.

하지만 AI의 사용법은 그뿐만이 아닙니다.

예를 들어, 동일한 에러에 대해서도 다음과 같이 사용할 수 있습니다.

이 에러의 원인 후보를 3가지 들어주세요.
각각을 확인하기 위해 어떤 로그나 설정을 봐야 하는지 알려주세요.

이 수정안이 유효한 이유를 설명해 주세요.
또한, 이 수정으로 인해 발생할 수 있는 부작용도 들어주세요.

공식 문서의 어떤 관점을 확인해야 하나요?
확인해야 할 키워드도 알려주세요.

이 문제에 대해 잠정 대응과 영구 대응을 나누어 생각해 주세요.
각각의 장점과 단점도 비교해 주세요.

이렇게 사용한다면, AI는 단순한 "정답을 내놓는 기계"가 아니게 됩니다.

• 원인을 분해하기 위한 브레인스토밍 (Wall-hitting) 상대
• 조사 관점을 넓히기 위한 보조
• 자신의 가설을 검증하기 위한 리뷰어 역할
• 공식 문서 (Official Documentation)를 읽기 전의 지도
• 여러 해결책을 비교하기 위한 상담 상대

로서 활용할 수 있습니다.

즉, 문제는 AI를 사용하느냐 아니냐만이 아닙니다.

AI에게 무엇을 시킬 것인가, AI의 답변을 어떻게 다룰 것인가가 중요하다고 생각합니다.

"AI를 쓰면 실력이 늘지 않는다"라는 의견은 자주 듣습니다.

다만, 이 주장은 조금 입도가 거칠다(단순하다)고 느껴집니다.

정확하게는, 다음과 같이 나누어 생각할 필요가 있지 않을까요?

실제로 AI를 학습에 사용하는 연구에서도, AI의 효과는 "사용하느냐 사용하지 않느냐"만으로 결정되지 않는다는 것이 나타나 있습니다.

예를 들어, AI 튜터 (AI Tutor)를 사용한 학습에 관한 연구에서는, 적절하게 설계된 AI 튜터가 학생의 학습 성과나 동기 부여를 높일 가능성이 보고되고 있습니다.

한편, 프로그래밍 초보자에 관한 연구에서는, 생성형 AI (Generative AI)가 학습을 돕는 경우도 있지만, 이해가 얕은 채로 "할 수 있다는 착각"에 빠질 위험도 지적되고 있습니다.

여기서 말할 수 있는 것은, AI가 항상 좋다는 뜻이 아닙니다.

반대로, AI가 항상 나쁘다는 뜻도 아니라고 생각합니다.

중요한 것은,

AI의 유무가 아니라, AI와의 관계 맺는 방식

입니다.

AI를 써도 생각하지 않는 사람은 생각하지 않을 수 있습니다.

AI를 쓰지 않아도 통째로 암기해 버리는 사람은 있다고 생각합니다.

반대로, AI를 사용하면서도 계속해서 질문을 던지는 사람은 성장해 나갈 수 있을 것입니다.

앞으로의 신입 엔지니어에게 필요한 것은,

"AI를 사용하지 않고 버티는 힘"만은 아니라고 생각합니다.

물론, 기초 역량은 필요합니다.

에러 메시지를 읽는 능력도 필요합니다.

로그를 보는 능력도 필요합니다.

공식 문서 (Official Documentation)를 읽는 능력도 필요합니다.

디버깅 (Debugging)하는 능력도 필요합니다.

다만, 거기에 더해 앞으로는 다음과 같은 능력도 필요해지지 않을까요?

• AI의 답변을 맹신하지 않는 능력
• AI의 출력에 대해 "왜 그렇게 되는가"라고 다시 질문하는 능력
• 공식 문서나 구현을 통해 사실 관계를 확인 (Cross-check)하는 능력
• 여러 해결책을 비교하는 능력
• 장점과 단점을 정리하는 능력
• 보안 및 기밀 정보의 경계를 판단하는 능력
• AI에 전달해도 좋은 정보와 전달해서는 안 되는 정보를 구별하는 능력
• AI의 답변을 자신의 언어로 설명하는 능력

이는 기존의 문제 해결 능력과 모순되는 것이 아닙니다.

오히려, 기존의 문제 해결 능력을 AI 시대에 맞춰 확장한 것이라고 생각합니다.

예를 들어, AI에게 질문할 때도 문제를 올바르게 분해하지 못하면 좋은 답변을 얻기 어려워집니다.

작동하지 않습니다. 고쳐주세요.

라는 질문과,

Next.js에서 API Routes를 사용하고 있습니다.
POST 요청 시 500 에러가 발생하고 있습니다.
확인한 사항:
...

라는 질문은 얻을 수 있는 답변의 질이 크게 달라집니다.

좋은 질문을 하기 위해서는 상황을 정리하는 능력이 필요합니다.

전제 조건을 분리하는 능력도 필요합니다.

무엇을 알고 있고, 무엇을 모르고 있는지를 언어화하는 능력도 필요합니다.

즉, AI를 사용하는 것 자체가 문제 정리의 훈련이 될 수도 있지 않을까요?

신입 엔지니어가 AI를 사용했을 때, 선배 엔지니어가 보아야 할 것은,

"AI를 사용했는지 여부"만이 아니라고 생각합니다.

보아야 할 것은 다음과 같은 점이 아닐까요?

• 그 답변을 왜 옳다고 판단했는가
• 어떤 정보를 근거로 했는가
• 공식 문서를 확인했는가
• 테스트로 검증했는가
• 다른 선택지와 비교했는가
• 부작용 (Side effect)을 고려했는가
• 자신의 언어로 설명할 수 있는가

예를 들어, 코드 리뷰 (Code Review)에서는 다음과 같이 확인할 수 있습니다.

이 구현을 선택한 이유는 무엇인가요?

AI의 답변을 참고했을 경우, 어느 부분을 채택하고 어느 부분을 채택하지 않았나요?

이 수정이 옳다는 것을 어떻게 확인했나요?

다른 구현 방법은 검토해 보았나요?

이 변경으로 인한 부작용이 있나요?

이러한 질문이 있다면, 신입 엔지니어는 AI를 사용하고 있더라도 생각하게 됩니다.

오히려 AI를 사용한 것을 숨기게 만들기보다,

AI를 어떻게 사용했고 어떻게 판단했는지를 언어화하도록 만드는 것이 교육으로서 더 건전하지 않을까요?

AI의 이용을 완전히 금지하는 것이 아니라, 현장에서 사용한다면 규칙을 만드는 것이 중요하다고 생각합니다.

예를 들어, 신입 엔지니어를 위해서는 다음과 같은 규칙을 고려할 수 있습니다.

AI의 답변은 어디까지나 후보로서 취급합니다.

최종적으로 채택할지 여부는 스스로 판단합니다.

AI가 내놓은 코드라 할지라도, 리뷰 시에 설명할 수 없다면 채택하지 않도록 합니다.

"AI가 그렇게 말했으니까"는 이유로서 불충분합니다.

AI의 답변만을 근거로 삼지 않도록 합니다.

필요에 따라 공식 문서 (Official Documentation), 실제 로그, 테스트, 기존 구현을 확인합니다.

사내 코드, 고객 정보, 인증 정보, 개인 정보, 미공개 사양 등은 입력하지 않도록 합니다.

입력해도 좋은 정보와 입력해서는 안 되는 정보의 경계를 명확히 해두는 것이 중요합니다.

필요에 따라 PR (Pull Request)이나 설계 메모에 다음과 같은 내용을 남깁니다.

AI에게 상담한 내용:
- 에러 원인의 후보
- 구현 방침의 비교
...

AI의 첫 번째 답변만으로 끝내지 않도록 합니다.

최소한 한 번은 이유를 확인하는 습관을 들이는 것이 좋다고 생각합니다.

왜 그 수정으로 해결할 수 있나요?

이 코드가 작동하는 원리를 초보자도 알 수 있게 설명해 주세요.

이 구현으로 실패할 수 있는 케이스가 있나요?

AI에게는 하나의 정답뿐만 아니라, 여러 가지 선택지를 내놓게 할 수도 있습니다.

이 문제에 대해 3가지 해결책을 제시해 주세요.
각각의 장점과 단점 (Merit/Demerit), 구현 비용, 유지보수성 관점에서 비교해 주세요.

이를 통해 단순히 답을 얻는 것뿐만 아니라, 설계 판단 연습으로도 이어질 수 있습니다.

AI를 학습이나 개발에 사용할 때, 가장 주의해야 할 점은 AI를 "답을 내는 도구"로만 취급해 버리는 것이라고 생각합니다.

물론, AI는 답 같은 것을 내놓아 줍니다.

코드도 작성해 줍니다.

에러 원인도 추측해 줍니다.

설계안도 제시해 줍니다.

하지만 그것을 그대로 받아들이기만 해서는 학습으로서 충분하지 않습니다.

중요한 것은 AI를 사용하여 사고의 과정을 넓히는 것이라고 생각합니다.

• 내가 놓치고 있는 관점은 없는가
• 달리 어떤 원인이 생각될 수 있는가
• 이 구현에는 어떤 부작용 (Side Effect)이 있는가
• 더 심플한 방법은 없는가
• 장래의 유지보수성은 어떠한가
• 테스트해야 할 관점은 무엇인가
• 공식 문서에서는 어디를 확인해야 하는가

이러한 질문을 AI에게 던짐으로써, 혼자서는 깨닫지 못했던 관점을 얻을 수 있는 경우가 있습니다.

그리고 그 관점을 바탕으로 스스로 조사하고, 스스로 판단합니다.

이 프로세스야말로 AI 시대의 문제 해결 능력 (Problem Solving Ability)이 아닐까요.

AI를 금지하면 신입 엔지니어는 AI를 사용하지 않게 될지도 모릅니다.

하지만 그렇다고 해서 AI를 올바르게 다룰 수 있게 되는 것은 아닙니다.

오히려 AI를 사용하는 상황이 왔을 때,

• 어디까지 신용해도 되는지
• 어떻게 검증하면 좋을지
• 무엇을 입력해서는 안 되는지
• 어떻게 질문하면 좋을지
• 출력을 어떻게 리뷰하면 좋을지

를 모르는 상태가 되어버릴 가능성이 있습니다.

이것은 앞으로의 엔지니어에게 큰 손실이 아닐까요.

AI를 사용하는 세대에게 필요한 것은 AI를 피하는 경험만이 아닙니다.

AI와 마주하고, 오류를 찾아내며, 사용 시점을 판단하는 경험도 필요하다고 생각합니다.

신입 엔지니어에게 AI를 금지하는 것은 언뜻 보면 "기초력을 기르기 위한 교육"처럼 보일지도 모릅니다.

하지만 그것만으로는 불충분하다고 느끼고 있습니다.

앞으로의 엔지니어에게 필요한 것은 AI를 사용하지 않는 전제의 문제 해결 능력만이 아닙니다.

AI를 사용하면서 출력을 의심하고, 근거를 조사하며, 자신의 판단으로 채택 또는 기각할 수 있는 능력도 필요합니다.

AI를 사용한다고 해서 반드시 성장할 수 있는 것은 아닙니다.

AI를 사용한다고 해서 반드시 생각하는 힘이 떨어지는 것도 아닙니다.

중요한 것은 AI를 어떻게 다루느냐입니다.

AI의 답변을 그대로 붙여넣기만 한다면 확실히 실력이 붙기 어렵다고 생각합니다.

하지만 AI에게 이유를 묻고, 근거를 확인하며, 별안을 비교하고, 공식 문서로 교차 검증하며, 자신의 언어로 설명한다면 그것은 충분히 학습으로 이어질 것입니다.

AI를 금지한다고 해서 AI에 의존하지 않는 인재가 육성되는 것은 아니라고 생각합니다.

오히려 AI를 올바르게 다루는 훈련을 받지 못한 인재가 육성될 가능성이 있습니다.

선배 엔지니어가 신입 엔지니어에게 가르쳐야 할 것은,

"AI를 사용하지 않는 것"이 아니라,

"AI를 사용하더라도, 생각하는 것을 멈추지 않는 것"입니다.

아닐까요?

Scientific Reports: AI 튜터링 (AI tutoring) 및 학습 결과 (learning outcomes)

https://www.nature.com/articles/s41598-025-97652-6 -
The Widening Gap: 초보 프로그래머를 위한 생성형 AI (Generative AI)의 이점과 해악

https://juholeinonen.com/assets/pdf/prather2024widening.pdf -
프로그래밍 교육에서의 AI 코딩 어시스턴트 (AI-coding assistants) 도입

https://link.springer.com/article/10.1007/s40692-025-00375-w -
The Guardian: 학생의 92%가 AI를 사용함에 따라 평가 방식의 스트레스 테스트 (stress-test)를 강조하라는 영국 대학들에 대한 경고