나만의 AI 용어 찾아보기

들어가며

최근 개발자 채용 공고를 보면 “AI 네이티브”라는 용어가 자주 보인다. AI 네이티브한 개발자는 어떤 개발자를 뜻하는 거지? 라는 궁금증이 생긴다.
단순히 AI에 관심이 많은 개발자인걸까? 아니면 AI를 기똥차게 잘 활용해서 성과를 내는 사람을 뜻하는 걸까?

그러다가 갑자기 걱정이 찾아온다. 나는 AI 네이티브한 개발자가 아니면 어쩌지? 도태되고 있는 건 아닐까? AI 네이티브의 기준이 무엇인지도 모르면서 스스로가 거기에 맞는 사람인지 막연히 불안해 한다.

AI를 적극적으로 사용한 지 1년이 조금 넘었을까? 이제는 나만의 AI 용어에 정의가 필요한 시점이라고 느껴졌다.

나만의 AI 용어 정의

AI 네이티브라는 용어뿐만 아니라, AI 리터러시, AI 네이티브 엔지니어링. 비슷하면서도 다른 이 용어들이 왜 생겼는지, 무엇을 중요하게 여기는지를 찾아보고 고민해보았다.

AI 리터러시

AI 리터러시 용어는 학술적으로 이미 정의되어 있다. 가장 많이 인용되는 것은 Long과 Magerko가 2020년에 낸 정의다.

AI 기술을 비판적으로 평가하고, AI와 효과적으로 소통하고 협업하며, 온라인과 가정과 직장에서 AI를 도구로 사용할 수 있게 하는 역량의 집합

많은 걸 내포하고 있지만 나에게는 피부로 와닿지 않는 정의였다. 그래서 이 용어를 내 경험 위에서 다시 해석해보기로 했다.

최근 AI를 쓰면서 내 강점은 강화되고, 단점은 보완이 되었다. 즉, 원래 쭉 하던 일을 더 빨리 끝낼 수 있게 되었고, 개발 외에 기획이나 디자인 영역에 대한 허들이 낮아졌다. 요즘 흔히 이야기하는 직무에 대한 경계가 낮아졌다는 걸 많이 느낀다.

다만 장점을 극대화하는 일도, 약점을 보완하는 일도 전부 검증이 필요해진다. 잘하는 영역은 일의 양 자체가 늘어나 검증할 것도 그만큼 많아지고, 모르는 부분은 정확한 정보인지 확인하는 비용이 더 발생했다. AI는 100% 정확하지 않다. 잘못된 방향으로 시작한 일들은 수정비용이 눈덩이처럼 불어나버린다.

최근 내가 만드는 앱 서비스와 하드웨어를 연동하는 기능을 개발할 때 이런 부분을 많이 느꼈다. 제조사가 준 SDK 가이드를 믿고 AI로 기능을 만들었는데, 제대로 동작하지 않았다. 알고 보니 기기의 실제 동작과 가이드가 일치하지 않았다. 그동안 개발했던 기능을 엎고 새로 만들었다.

가이드의 문제도 있었지만, AI가 그럴싸한 계획을 세워주고 얼핏 동작하는 기능을 빠르게 만들어주었기 때문에 덜 의심한 부분도 있었다.

그럼 AI를 어디까지 믿어야 할까. 요즘은 AI에게 일을 시키든, 정보를 조사하든, 모르는 것을 물어보든 어느 정도 검증이 꼭 필요하다는 생각을 많이 한다. 답변에 대한 외부 근거를 함께 요청하거나, 작업한 결과물에 대해 테스트 코드와 스크린샷을 남기게 한다.

그래서 나는 AI 리터러시를 이렇게 정의해봤다.

나를 강화해주는 도구이지만, 정확하지 않을 수 있기 때문에 답을 어디까지 믿을지 판단할 줄 아는 능력

학술 정의에서 내가 붙잡은 건 “비판적으로 평가한다”는 부분이다. “소통과 협업”은 이렇게 바라봤다. AI와 잘 협업하려면 결국 그 답을 어디까지 믿을지 판단할 줄 알아야 한다고.

반면 “어디서든 도구로 사용한다”는 나에게는 이미 당연한 일이라 넣지 않았다. 그건 빠른 시일 내에 너무나 당연해지지 않을까 싶다.

AI 네이티브니스

검증은 중요하다. 앞에서 답을 어디까지 믿을지 판단할 줄 알아야 한다고 했는데, 그 판단의 근거가 결국 검증이기 때문이다. 이제는 AI가 아니라 AI가 만든 것이 내가 예측한 바와 같은지, 정말 제대로 만들었는지 확인하는 것이 병목이 되어버렸다. 더 빠르고, 믿을 수 있는 검증 구조가 필요해졌다.

앞선 하드웨어 연동 과정을 다시 떠올려보면, 블루투스 연동 기능을 만들어줘 라는 요청에 대한 AI 코드를 어떻게 믿을 수 있을까?

구현을 시킨 AI한테 “잘 만들었어?”라고 물어보면, 요구사항에 맞게 잘 구현했다고 대답할 것이다. “이거 이상한데?”라고 지적하면 너무나도 쉽게 “미안 잘못 이해했어”라고 답한다.

그래서 나는 말 대신 증거를 믿기로 했다. 블루투스 연동을 할 때는 모든 로그를 쌓고, 로그의 흐름을 믿었다. 물론 이 로그들을 하나씩 살펴보기는 힘드니, AI를 활용해 빠르게 로컬 대시보드 툴을 만들어 흩어져 있는 원본 로그를 쉽게 볼 수 있게 했다.

다만 같은 검증을 매번 다시 하는 것은 비용이다. 결정적인 테스트 코드나 스크립트를 만들어서 빠르게 검증을 해야 한다.

피드백을 매번 하는 것도 비용이다. 그래서 두 번 이상 반복한 피드백은 룰로 올려두었다. git add -A로 몰아넣지 말고 커밋할 파일을 하나씩 지정하라는 피드백이 그렇게 룰이 됐다.

그러나 이런 검증은 결국 내 역량에 의존한다. 내가 누락하거나 생각하지 못한 것은 검증의 대상에 포함되지 않는다. 그래서 다른 AI에게 제삼자의 시각으로 한번 더 검증에 누락이나 보강할 부분이 없는지 도움을 요청한다.

AI 네이티브라는 용어도 찾아보았는데, 산업에서 쓰는 정의가 있었다. 에릭슨 백서는 이렇게 정의한다.

신뢰할 수 있는 AI 역량을 내재하여, 설계와 배포와 운영과 유지보수에서 AI가 기능의 자연스러운 일부가 되는 것

설계와 배포, 운영과 유지보수에 AI를 활용한다는 건 이해가 갔는데, 신뢰할 수 있는 AI 역량을 내재한다는 표현이 잘 와닿지 않았다. AI 역량은 무엇이고, 그것을 신뢰할 수 있다는 건 무슨 근거로 확인할 수 있을까? 백서를 더 살펴보았지만 신뢰성과 공정성, 설명 가능성을 보장해야 한다고만 적혀 있었다. 무엇으로 확인해야 하는지는 여전히 막연했다.

내가 “AI 네이티브가 뭔데?”라고 막연했던 게 바로 이거 아니었을까.

그리고 채용공고는 AI 네이티브한 사람을 찾는다고 쓴다. 백서의 정의를 사람에게 적용해보면, 신뢰할 수 있는 AI 역량을 가지고 설계와 배포, 운영과 유지보수를 자연스럽게 하는 사람인 건가 싶었다.

중요한 건 신뢰할 수 있는 AI 역량은 뭘까. 나는 “신뢰할 수 있는”이라는 말에 집중하여 나만의 AI 네이티브니스를 이렇게 정의해보았다.

AI를 믿을 수 있는 구조를 만드는 능력

돌아보면 로그를 쌓고, 테스트를 만들고, 피드백을 룰로 승격시키고, 다른 AI에게 검증을 요청한 것 전부가 이 구조를 만드는 일이었다.

AI 네이티브 엔지니어링

두 개를 정의하고 나니 질문이 하나 남았다. 나는 AI를 어디에 쓰고 있나.

되돌아보니 AI 활용 범위가 좁았다. 버그 수정이나 새 기능을 만들때 계획과 구현, 검증하는 프로세스에 갇혀있었다.
내 한정적인 시간을 가장 많이 쏟은 일부터 AI 도움을 적극 받으려고 했다.

AI에게 반복 업무를 맡길수록 영역을 확장하거나 한층 깊게 고민해볼 수 있는 시간이 생겼다.
남은 시간에 눈에 들어온 건 구현의 앞뒤였다. 엔지니어는 원래 어디까지 하는 사람이지?
문제를 정의, 적절한 방법을 선택, 결과를 확인하는 데까지가 엔지니어링이라면,

내가 놓친 문제 정의를 같이 찾고
남들은 이 문제를 어떻게 풀었는지 조사하고
지금 상황에 맞는 방법을 여러 개 빠르게 펼쳐보고
고른 방법을 팀에 전달하고
계획대로 됐는지 검증하고
문제가 실제로 해결됐는지 확인하는 데까지

앞의 두 용어와 달리 외부 정의 대신 나만의 정의를 만들어보았다.

AI를 코드 쓰는 구간에만 두지 않고, 문제를 정의하는 데서 결과를 확인하는 데까지 모든 구간에 활용하는 능력

정의를 만들고 나서 적용을 해봤다.

지표를 자동으로 받는 워크플로우를 만들어서 확인해보니 건강검진 외부 기관 연동의 완료율이 낮은 게 보였다. 실패 사유를 뜯어보니 인증 단계에서 끊긴 세션이 대부분이었다. 카카오톡 인증을 안 하고, 인증 완료 버튼을 누르는 것으로 보였다.

그래서 인증에 실패해도 다시 시도할 수 있게 했고, 응답이 없는 세션은 60초에 정리하도록 바꿨다.

개선하고 나서 완료율이 55.6%에서 73.8%로 올랐다.

그러고 나니 앞의 두 용어의 차이가 느껴졌다.
AI가 준 답을 어디까지 믿을지 판단해야 했고, 그 판단이 다음에도 같게 나오려면 구조가 필요했다.
그리고 판단과 구조는 코드 구간에만 있는 게 아니었다.

끝으로

이번에 내린 정의를 모아보면 이렇다.

용어	내가 내린 정의
AI 리터러시	나를 강화해주는 도구이지만, 정확하지 않을 수 있기 때문에 답을 어디까지 믿을지 판단할 줄 아는 능력
AI 네이티브니스	AI를 믿을 수 있는 구조를 만드는 능력
AI 네이티브 엔지니어링	AI를 코드 쓰는 구간에만 두지 않고, 문제를 정의하는 데서 결과를 확인하는 데까지 모든 구간에 활용하는 능력

AI에서 파생되는 용어 자체가 엄청나게 중요한 것은 아니라고 생각한다. 용어를 몰라도 잘 쓰는 사람은 잘 쓰고, 들여다보면 결국 같은 것을 말한다. 다만 알고 쓰는 것과 쓰다 보니 그런 것 같은 것 사이에는 깊이 차이가 있다고 느꼈다. 이번에 시간을 내서 AI 용어에 대해 나만의 정의를 만들어보았다. 나는 AI를 어떻게 대하고 있고, 무엇을 중요하게 생각하는지를 엿볼 수 있었다. 채용공고에서 말하는 AI 네이티브한 사람은 이런 사람을 원하겠구나도 어림짐작해볼 수 있게 되었다.

또 좋았던 점은 남이 만든 정의를 따라가는 대신, 내가 만든 정의로 어떻게 AI를 쓰고 있는지 말할 수 있게 된 것이다. 같은 기준으로 지금 어느 부분이 부족한지, 방향이 언제 달라졌는지도 보인다. “당신은 AI를 어떻게 정의하시나요”라고 물어보고, 내 정의는 이런데 어떻게 생각하는지 되물을 이야깃거리도 생겼다.

AI로 인해 대혼돈의 시대지만, 그 속에서 나의 정의를 찾아보았다. 고심 끝에 만든 정의는 하루아침에 버려질지도 모른다. 그래도 그 정의가 어떻게 변해가는지 지켜보는 것은 지금이 아니면 해볼 수 없는 일이라고 생각한다.

참고

• Long, D. & Magerko, B. (2020). What is AI Literacy? Competencies and Design Considerations. CHI ‘20
• Ericsson. A detailed study of the AI Native concept
• UNESCO. AI competency framework for students (2024)