서론

생성형 AI (Generative AI)가 당연해진 지금, 「AI를 사용할 줄 안다는 것」은 더 이상 이점이 아니게 되어가고 있습니다.

이미지, 영상, 음성, 문장, 리서치, 프로그래밍—— 「무엇이든 할 수 있다」는 말은 과장이 될지 몰라도, 자신의 능력만으로는 할 수 없었던 일을 AI 덕분에 할 수 있게 된 장면은 확실히 늘어났습니다. 약간의 지시만 내리면 무언가 형태가 갖춰지고, 거친 지시를 내려도 「오, 대단한데」라고 생각될 만한 출력이 돌아오기도 합니다.

반면,

「기대한 대로의 결과물을 짧은 시간 안에 만들어내고 있다」라고 당당하게 말할 수 있는 사람은 얼마나 될까요?

이미지대로 흘러가지 않아서 결국 프롬프트 (Prompt)를 수십 번씩 다시 쓴다. 출력을 수작업으로 수정하다 보면 「직접 하는 게 더 빨랐던 거 아닌가」라는 생각이 들기 시작한다.

이런 경험, 짐작 가는 곳이 없으신가요?

같은 AI인데도 낼 수 있는 성과가 다르다

이 「잘 활용하고 있다는 느낌이 들지 않는 현상」은 특히 젊은 엔지니어들에게 현저하게 나타난다고 느끼고 있습니다.

그 이유는, 베테랑과 젊은 층은 같은 AI를 사용하고 있더라도 보고 있는 세계가 완전히 다르기 때문입니다.

베테랑은 오랜 경험과 지식을 바탕으로 AI에게 구체적인 지시를 내릴 수 있습니다. 「이 API의 인증은 OAuth2로 하고, 리프레시 토큰 (Refresh Token)의 유효 기간도 고려해줘」—— 이러한 지시가 자연스럽게 나오는 이유는, 수없이 시스템을 만들어 온 경험의 데이터베이스가 있기 때문입니다. 기대치를 조절하는 능력이 뛰어나며, AI의 출력을 정확하게 궤도 수정할 수 있습니다.

반면, 젊은 층은 어떨까요?

• AI에게 개발을 맡기고 싶지만, 접근 방식이나 고려 사항을 구체적으로 전달하지 못해 쓸모없는 결과물이 나온다
• 지시를 내리고 싶지만, 자신 내부의 기대치가 모호해서 「적당히 잘 해줘」라고밖에 말할 수 없다
• 표현이 적절하지 않아서 의도한 것과 전혀 다른 아웃풋 (Output)이 돌아온다

기존에는 이러한 지식이나 경험은 상사나 선배로부터 단계적으로 전수되어 왔습니다. 하지만 AI의 등장으로 「우선 스스로 AI에게 물어봐」라는 상황이 늘어나면서, 그 육성 프로세스에 들이는 시간은 급격히 단축되고 있습니다. 뒤집어 말하면, 지식의 토대가 없는 채로 고도의 도구만을 건네받은 상태라고도 할 수 있습니다.

이 기사에 대하여

그렇다면, 젊은 엔지니어가 진정한 의미로 AI를 능숙하게 다루고 성과를 내기 위해서는 무엇을 의식해야 할까요?

AI 과도기에 신입으로 IT 업계에 들어온 필자가, AI와 격투하는 나날 속에서 깨달은 여러 가지를 정리했습니다.

1. AI의 「잘하는 것」과 「못하는 것」을 알기

AI를 잘 사용하기 위해 가장 먼저 필요한 것은, AI가 무엇을 할 수 있고 무엇을 할 수 없는지를 정확히 파악하는 것입니다.

이제는 너무 당연해서 새삼스럽다고 생각할 수도 있겠지만, 이 부분을 오해한 채 계속 사용하면 생각지도 못한 곳에서 시간을 허비하게 됩니다.

엔지니어에게 있어서의 「잘하는 것」과 「못하는 것」

「못하는 것」의 대부분은 사용법으로 극복할 수 있다

여기서 한 가지 중요한 점을 보충해 두겠습니다.

위에서 언급한 「못하는 것」은 AI의 절대적인 한계가 아니라, 있는 그대로 사용했을 때의 한계입니다. 사실 사용법을 궁리하면 상당 부분 극복할 수 있습니다.

최신 사양 파악 → 공식 문서 (Official Documentation)를 컨텍스트 (Context)로 전달한다, 웹 검색 기능이 있는 AI를 사용한다, MCP를 통해 문서를 참조하게 한다 -
프로젝트 전체의 설계 판단 → 관련 파일이나 아키텍처 (Architecture) 도표를 읽히게 한다, 코딩 에이전트 (Coding Agent, Claude Code 등)에게 여러 파일을 횡단적으로 보여준다 -
작동하는 코드 vs 올바른 코드 → 테스트 코드 (Test Code)를 함께 작성하게 한다, 리뷰 관점을 지시에 포함한다, 「에지 케이스 (Edge Case)도 고려해줘」라고 명시한다 -
할루시네이션 (Hallucination) 대책 → 「모르는 경우에는 모른다고 답해줘」라고 전달한다, 1차 소스 (Primary Source)와 대조하도록 지시한다

즉, 「AI가 못하는 것」이라고 불리는 것들의 대부분은 AI 단체의 한계라기보다, 사용자의 궁리 부족인 경우가 많습니다.

자주 빠지는 함정

그럼에도 불구하고 젊은 엔지니어가 저지르기 쉬운 실수를 하나 소개하겠습니다.

최신 라이브러리의 사용법을 AI에게 물어보고, 돌아온 코드를 그대로 실행했더니 AttributeError: module 'xxx' has no attribute 'yyy'가 나온다——. 사실 그 메서드 (Method)는 버전 업데이트로 이름이 바뀌었거나, 애초에 존재하지 않는 패턴입니다.

이것은 AI가 잘못했다기보다, 가공되지 않은 상태의 AI에게 최신 사양을 물어본 것, 그리고 그 출력을 검증하지 않고 사용해 버린 것이 원인입니다. 같은 질문이라도 공식 문서를 함께 전달하거나 웹 검색을 활성화하면 결과는 완전히 달라집니다.

「한계」와 「개선 여지」를 파악하기

잘하는 것과 못하는 것의 리스트는 실제로 사용하면서 더욱 세밀하게 업데이트되어 갑니다.

중요한 것은, 못하는 것처럼 보이는 상황에 직면했을 때 "AI로는 무리겠지"라며 포기하는 것이 아니라, "이것은 사용법에 따라 해결할 수 있는 미숙함인가, 아니면 정말로 맡겨서는 안 되는 업무인가"를 파악하는 것입니다.

도구의 한계를 알고, 그 한계를 넓힐 수 있는 방안을 고민할 수 있는 사람만이 도구를 최대한으로 활용할 수 있습니다.

2. 「만들고 싶은 것」을 언어화하는 능력

당연한 이야기지만, AI는 당신의 머릿속을 읽을 수 없습니다.

AI를 사용하여 무언가를 생성하고 싶을 경우, "이런 것이 필요하다"를 말로 표현할 수 없다면 AI에 대한 지시(Prompt)를 작성할 수 없습니다.

갑작스럽지만, 이 이미지와 똑같은 이미지를 단 한 번의 지시로 만들 수 있습니까? 실제로 한번 만들어 보세요.

제대로 생성되었나요?

참고를 위해 프롬프트(Prompt) 예시를 제시해 두겠습니다.

프롬프트 예시

빨간 사과의 수채화 일러스트.

오른쪽 뒤편에 통사과를 한 개 배치.

왼쪽 앞부분에 반으로 자른 사과를 크게 배치하여, 단면과 씨가 보이도록 함.

여기에 앞쪽 중앙에 얇게 슬라이스 된 사과 한 조각을 놓음.

전체가 삼각형 구도가 되도록, 서로 약간씩 겹치게 자연스럽고 균형 있게 배치.

여백을 넉넉히 두어, 부드럽고 여유 있는 구도.

투명감 있는 수채화의 번짐 효과,

부드러운 붓 터치,

따뜻한 느낌의 빨강·주황·노란색 색조.

배경은 흰색 베이스로 하고,

연한 노란색과 주황색의 수채화 번짐을 옅게 넣음.

동화책 같은 부드러운 분위기.

손그림 느낌이 나는 내추럴한 터치.

너무 사실적이지 않고 약간 귀여운 데포르메(Déformer).

고품질 수채화, paper texture, soft lighting

예를 들어, 명확한 이미지가 정해져 있지 않고 분위기로 결과물을 만들어낸 뒤 나중에 평가하는 방식인 바이브 코딩(Vibe Coding)의 경우에는 "느낌 있는 ○○○ 만들어줘"와 같은 프롬프트로 완성된 결과물에도 만족할 수 있을지도 모릅니다.

하지만 업무에서 AI를 활용하게 되면 대부분 제한된 조건 하에서 아웃풋(Output)의 기대치가 결정되어 있습니다. 분위기에 의존해 만들다 보면 쓸모가 없게 되거나 수정에 시간이 너무 많이 걸려 AI 활용의 혜택을 누릴 수 없으므로, 사전에 기대하는 결과물을 말로 표현할 수 있는지가 매우 중요합니다.

언어화 능력을 높이기 위한 3단계

① 목표를 명확히 하기

"무엇을 위해", "누구를 대상으로", "어떤 결과를 원하는가"를 먼저 스스로 정리한다.

② 조건과 제약 사항을 나열하기

사용할 언어·프레워크(Framework), 성능 요구사항, 기존 코드와의 정합성, 피하고 싶은 패턴 등 경계선을 명확하게 전달한다.

③ 구체적인 예시 덧붙이기

"이런 느낌"이라는 샘플 코드나 기존 구현의 일부를 보여주는 것만으로도 아웃풋의 정밀도는 격하게 올라간다.

언어화하는 능력은 AI뿐만 아니라 엔지니어의 업무 모든 장면에서 무기가 됩니다. 설계 리뷰, PR(Pull Request) 설명, 장애 보고, 팀 내 기술 공유 등 모든 것의 토대는 "전달하는 능력"입니다.

3. 인접 영역까지 「넓고 얕게」 알아두기

AI 등장 이전에는 "자신의 전문 영역을 깊게 파는 것"이 높게 평가받았습니다. 좁고 깊은 T자형의 세로 막대를 어떻게 하면 길게 늘릴 것인가 하는 세계였습니다.

하지만 AI에게 작업을 맡길 수 있는 지금, 깊이의 일부는 AI가 대신해 줍니다. 대신 가치를 갖기 시작한 것이 바로 **"자신의 전문 분야 옆에 있는 영역을 넓고 얕게 알고 있는 것"**입니다.

이것은 "같은 영역의 깊이"가 아니라, 가로 방향으로 직종을 넘나드는 확장성에 관한 이야기입니다.

엔지니어에게 있어 「인접 영역」이란

예를 들어 백엔드(Backend) 엔지니어에게 인접 영역은 다음과 같습니다.

프론트엔드(Frontend): 컴포넌트 설계, 상태 관리, UX의 기본 원칙 -
인프라/SRE: CI/CD, 컨테이너, 모니터링, 비용 구조 -
디자인: 정보 설계, 디자인 시스템, 접근성(Accessibility) -
프로덕트: 유저 스토리, KPI, 로드맵 우선순위 -
보안(Security): 인증/인가의 기초, 흔히 발생하는 취약점

이것들을 대략적으로 파악하고 있는 것만으로도 AI에게 부탁할 수 있는 내용의 폭이 단번에 넓어집니다.

왜 「넓고 얕게」로 충분한가

깊은 지식은 AI가 보완해 주기 때문입니다. 당신에게 필요한 것은 "이 영역에는 무엇이 있고, AI에게 무엇을 부탁할 수 있는가"를 판단할 수 있는 지도뿐입니다.

예를 들어 「로그인 기능을 만들고 싶다」고 생각했을 때, 인증 방식에 무엇이 있는지(세션 인증, JWT, OAuth, 패스키……)를 들어본 적이 있다면, AI에게 「OAuth의 Google 연동으로, 인가 코드 플로우(Authorization Code Flow)로 구현해줘」라고 구체적으로 지시할 수 있습니다. 반면, 인증을 「로그인하는 것」이라고만 인식하고 있다면, 「적당히 로그인 기능 만들어줘」라고밖에 말할 수 없습니다.

즉, 지도의 넓이가 곧 AI에게 맡길 수 있는 업무의 넓이가 됩니다.

지도를 넓히는 방법

특별한 공부법은 필요하지 않습니다. 일상 속에서 의식을 조금 바꾸는 것만으로도 지도는 자연스럽게 넓어집니다.

• 자신의 업무 전공정·후공정을 의식하기 (누구로부터 사양을 받고, 누구에게 전달하고 있는가)
• 옆 직종의 입문서를 딱 한 권만 읽기 (깊게 파고들지 말고, 목차 수준으로 머릿속에 넣어두기)
• 디자이너나 PM과 잡담할 기회 갖기 (용어를 접하는 것만으로도 지도를 그릴 수 있음)
• 모르는 단어를 뒤로 미루지 않기 (그 자리에서 30초만 구글링하는 습관을 들임)

지도 없이 여행을 떠나면 길을 돌아가거나, 미아가 되거나, 최악의 경우 목적지에 도달하지 못합니다. AI에게 지시를 내릴 수 있는 범위는 당신이 가진 지도의 넓이에 비례합니다.

4. 사물을 「추상적으로」 파악하는 능력

섹션 3이 「가로 방향의 확장(인접 영역을 아는 것)」이라면, 이것은 「세로 방향의 추상도(같은 영역 안에서 구체와 추상을 오가는 것)」에 관한 이야기입니다.

AI 시대에 요구되는 것은 기술의 세세한 구문을 암기하는 것이 아닙니다.

「무엇을 할 수 있는지」를 대략적으로 알고 있어서, 필요할 때 그 정보를 끌어낼 수 있는 것——즉, 사물을 추상적으로 파악하는 능력입니다.

프로그래밍으로 생각해 보기

예를 들어 어떤 언어를 배우든 처음에 for 문 작성법이나 if 문 같은 세세한 구문을 외우게 됩니다. 물론 알고 있으면 손해 볼 것은 없지만, AI 시대에 정말 중요한 것은 그것이 아닙니다.

중요한 것은 다음과 같은 추상적인 이해입니다.

• **「조건부로 반복 처리」**를 할 수 있다
• **「조건에 따라 처리를 분기」**할 수 있다
• 데이터를 「일시적으로 저장해 두는」 메커니즘이 있다 (변수, 캐시, 세션……)
• 외부 서비스와 「데이터를 주고받는」 방법이 있다 (HTTP, gRPC, 메시지 큐……)
• 처리를 「나중에 실행하는」 메커니즘이 있다 (비동기, 잡 큐(Job Queue), cron……)

이 정도의 입도로 이해하고 있다면, AI에게 「사용자 목록을 가져와서, 연령이 20세 이상인 사람만 추출하여, CSV로 내보내는 배치(Batch) 처리를 만들어줘」라고 지시할 수 있습니다. for 문이나 if 문을 구체적으로 어떻게 쓰는지 모르더라도, AI가 구체적인 코드로 구현해 주기 때문입니다.

「끌어낼 수 있는 지식의 양」이 무기가 된다

추상적인 이해의 장점은 하나의 지식을 여러 상황에서 재사용할 수 있다는 것입니다.

「반복 처리를 할 수 있다」는 지식은 Python에서도, JavaScript에서도, Go에서도, SQL의 루프에서도, 쉘 스크립트(Shell Script)에서도 활용됩니다. 구체적인 구문에 얽매인 지식은 그 언어에서만 사용할 수 있습니다.

「비동기 처리」라는 개념을 추상적으로 이해하고 있다면, JavaScript의 async/await에서도, Python의 asyncio에서도, Go의 goroutine에서도 「하고 싶은 것」을 AI에게 전달할 수 있습니다.

즉, 추상도를 높여 사물을 파악할수록 당신의 「끌어낼 수 있는 지식(引き出し, Drawer)」은 늘어납니다. 지식이 많은 사람일수록 눈앞의 과제에 대해 「저 메커니즘을 쓸 수 있겠어」, 「이 방법과 조합하면 가능할지도 몰라」라고 발상할 수 있습니다. AI에 대한 지시의 폭과 정밀도는 이 지식의 개수로 결정된다고 해도 과언이 아닙니다.

AI를 사용하여 「추상에서 구체로 내려가기」

추상적으로 파악하는 능력은 AI와 결합하면 더욱 강력해집니다. 추상적인 키워드만 알고 있다면, AI에게 물어보면서 탑다운(Top-down) 방식으로 구체적인 단계까지 내려갈 수 있기 때문입니다.

예를 들어, 「비동기 처라는 말을 어디선가 들어본 것 같다」는 수준의 이해밖에 없더라도 다음과 같이 깊이 파고들 수 있습니다.

• 「비동기 처리가 뭐야? 동기 처리와 무엇이 달라?」 (개념의 이해)
• 「JavaScript에서 비동기 처리를 작성하려면 어떤 방법이 있어?」 (선택지의 파악)
• 「async/await와 Promise.then은 어떻게 구분해서 써?」 (비교의 이해)
• 「실제로 API 3개를 병렬로 호출하는 코드를 작성해줘」 (구체적인 구현으로의 전환)

핵심은, 처음에 「비동기 처리 (Asynchronous Processing)」라는 키워드를 끌어낼 수 있는 것입니다. 이 키워드만 있다면 나머지는 AI가 지도를 채워줄 것입니다. 반대로, 키워드를 모른다면 「비동기 처리에 대해 묻고 싶다」라고 질문하는 것 자체를 할 수 없습니다.

이는 인접 영역을 배울 때도 마찬가지입니다. 「Kubernetes라는 말을 들어본 적이 있네」 → 「Kubernetes는 무엇을 해결하는 것이지?」 → 「Pod란 무엇인가?」 → 「우리 프로젝트에 도입했을 때의 장점은?」과 같이, 추상적인 것에서 구체적인 것으로 계단을 내려가듯 깊게 파고들 수 있습니다.

서적을 읽는 것보다 빠르고, 검색보다 문맥에 맞는 답을 얻을 수 있습니다. 「키워드만 알고 있으면 AI가 가르쳐 준다」라는 전제에 서면, 배우는 방식 그 자체가 바뀝니다.

가로의 확장과 세로의 추상도는 세트

섹션 3의 「인접 영역」과 이 섹션의 「추상도」는 두 가지가 모두 갖춰져야 비로소 힘을 발휘합니다.

• 가로(인접 영역)만 있다면, 지식이 얕고 넓게 퍼질 뿐 AI에게 구체적인 지시를 내릴 수 없다
• 세로(추상도)만 있다면, 자신의 전문 영역은 깊게 이해할 수 있어도 AI에게 맡길 수 있는 업무의 폭이 좁다

두 가지를 모두 의식하며 단련해 나가는 것이 AI 시대 엔지니어의 실력이 됩니다.

5. 생성물에 대해 「책임」을 질 수 있을 것

책임을 진다는 것은 구체적으로 무엇을 의미하는가

① 내용을 이해할 수 있는 수준에서 사용하기

AI가 출력한 코드의 의미를 모르는 채로 운영 환경(Production)에 배포하는 것은, 읽을 수 없는 계약서에 서명하는 것과 같습니다. 「왜 이런 구현이 되었는지」, 「다른 선택지가 아닌 이것을 선택한 이유는 무엇인지」를 설명할 수 있는 범위 내에서 사용합시다.

② 사실 확인을 게을리하지 않기

AI는 자신만만하게 거짓말을 합니다 (환각 (Hallucination)). 존재하지 않는 함수, 잘못된 API 인자, 오래된 버전의 구문 —— 반드시 공식 문서나 실제 동작을 통해 확인하는 습관을 들입시다.

③ 「최종 체크는 인간」을 원칙으로 하기

AI는 우수한 초안 작성가이지만, 최종본의 품질을 보증하는 것은 당신입니다. 커밋 (Commit), 머지 (Merge), 배포 (Deploy)를 하기 전에 반드시 자신의 눈으로 코드를 읽고, 테스트를 통과시키는 프로세스를 구축합시다.

책임을 질 수 있다는 것은, AI의 출력을 "블랙박스 (Black Box)"로 만들지 않는다는 것입니다. 내용을 알 수 있기에 수정할 수 있고, 리뷰에서 설명할 수 있으며, 장애가 발생했을 때 원인을 추적할 수 있습니다. 그것이 진정한 의미에서 「AI를 능숙하게 다루고 있는」 상태라고 생각합니다.

요약: AI는 우수한 어시스턴트에 불과하다

AI는 틀림없이 강력한 도구입니다. 하지만, 도구의 가치를 결정하는 것은 사용하는 인간 쪽입니다.

「AI가 할 수 있는 것을 전부 맡기고, 인간은 아무것도 하지 않아도 된다」 —— 그런 미래는 오지 않을 것이라고 생각합니다. 오히려 AI가 똑똑해지면 될수록, 「무엇을 만들고 싶은가」, 「왜 그것을 만드는가」, 「그것이 옳은가」를 생각할 수 있는 엔지니어의 가치가 높아져 갑니다.

내일부터 시작할 수 있는 일은 아마 이런 것들일 것입니다.

• AI에게 무언가를 부탁하기 전에, 3초만 「목표와 제약 조건」을 머릿속으로 언어화해 보기
• AI가 반환한 코드를 한 줄씩 「왜 이렇게 되어 있는지」 설명해 보기
• 평소 접하지 않던 영역의 문서를 목차만이라도 훑어보기

서두르지 말고, 자신의 페이스대로

마지막으로 하나 더.

매일 계속해서 진화하는 생성형 AI 업계의 정보를 쫓는 것도 보통 일이 아닐 것입니다. 새로운 모델, 새로운 도구, 새로운 사용법 —— SNS를 열면 매일같이 흘러나옵니다.

안 그래도 주니어는 일상 업무에서 수많은 지식을 흡수하고 있는 중입니다. 거기에 또 다른 새로운 정보를 계속해서 받아들이는 것은 솔직히 힘든 일이라고 생각합니다.

한편으로, 실제로 사용하거나 현장에 몸담지 않으면 능숙하게 다룰 수 없는 것도 사실입니다. 책을 읽거나 기사를 훑어보는 것만으로는 AI를 다루는 감각을 익힐 수 없습니다.

그렇기에 스트레스가 없는 범위 내에서, 일상에 조금씩 받아들여 보려는 의식은 가졌으면 합니다. 유행하는 도구를 전부 쫓아가지 않아도 되고, 매일 프롬프트 (Prompt)를 고민하지 않아도 됩니다. 자신이 할 수 있는 범위 내에서 무리 없이 계속하는 것이 훨씬 더 중요합니다.

그리고, 무턱대고 AI를 사용하여 효율화하는 것에만 집착하지 말고, AI를 사용할 수 있는 기초를 쌓는 것에도 눈을 돌렸으면 합니다.

기초가 없는 곳에는 높은 빌딩을 세울 수 없습니다. AI라는 편리한 도구를 정말로 활용할 수 있을지는 결국 당신이 얼마나 「자신의 토대」를 키울 수 있느냐에 달려 있습니다.

AI를 우수한 어시스턴트로 만들 수 있을지는 당신에게 달려 있습니다.