AI 기초 및 활용 26회: 업무와 창작의 AI — 검증되는 일이 먼저 바뀐다

오늘의 질문 — 일에서 실제로 뭐가 달라졌나

AI가 일자리를 바꾼다는 이야기는 많은데, 지금 당장 내 일에서 무엇이 달라졌는지는 잘 안 보입니다. 어떤 분야는 확 바뀌었고 어떤 분야는 거의 그대로거든요.

차이가 어디서 오는지 오늘 짚겠습니다. 그리고 만드는 일에서 AI가 실제로 어디까지 왔는지, 내 컴퓨터에서 돌리는 것과 남의 서버에 맡기는 것을 어떻게 나눌지도 함께요.

오늘의 질문은 셋입니다. 왜 코딩이 가장 먼저 바뀌었나. 창작에서 AI가 잘하는 자리는 어디인가. 그리고 무엇을 내 손 안에 두어야 하나.

지난 회차 연결 — 일과 만드는 일로

24회차가 개인의 일상, 25회차가 접근성이었다면 오늘은 일과 창작입니다.

그리고 오늘의 판단 기준도 앞에서 다 나왔습니다. 23회차의 검증 가능한 보상이 왜 코딩을 앞서게 했는지, 17회차의 디퓨전이 창작 도구의 밑바탕인지, 21회차의 검증 습관이 실무에서 어떻게 구현되는지요.

코딩 보조 — 왜 여기가 가장 성숙했나

AI가 가장 크게 바꾼 직군을 하나 꼽으라면 소프트웨어 개발입니다. 우연이 아니에요. 구조적인 이유가 넷 있습니다.

하나, 데이터가 압도적으로 많습니다. 공개 코드 저장소가 인터넷에 산더미로 쌓여 있죠. 18회차의 사전학습 재료로 이만큼 좋은 것이 드뭅니다.

둘, 정답을 기계가 확인할 수 있습니다. 19회차에서 다룬 검증 가능한 보상이요. 코드는 실행해 보면 됩니다. 사람의 취향이 개입할 여지가 적어요.

셋, 형식이 엄격합니다. 문법이 정해져 있고 규칙이 명확합니다. 18회차에서 봤듯 모델은 규칙이 있는 것을 잘 압축합니다.

넷, 틀려도 대체로 안전합니다. 실행해 보면 알고, 되돌리기도 쉽죠. 23회차의 기준으로 맡기기 좋은 조건을 전부 갖췄습니다.

자동완성에서 대화로, 그리고 에이전트로

몇 년 사이 방식이 세 번 바뀌었습니다.

처음은 자동완성이었습니다. 타이핑하면 다음 줄을 제안하는 방식이요. 편했지만 내가 무엇을 쓸지 이미 알고 있어야 했습니다.

그다음은 대화입니다. "이런 걸 만들고 싶은데"라고 말하면 코드를 내놓는 방식이요. 여기서 모르는 것을 물어볼 수 있게 됐습니다.

지금은 에이전트입니다. 23회차의 그것이요. 파일을 읽고 고치고 실행해 보고 오류를 보고 다시 고칩니다. 사람이 매 단계 지시하지 않아도 되죠.

그런데 23회차의 경고가 그대로 적용됩니다. 단계가 길어지면 실패율이 올라가고, 실패해도 멈추지 않습니다. 그래서 실무에서는 작업을 작게 쪼개고 자주 확인하는 쪽이 결과가 낫습니다.

테스트라는 자동 채점기

코딩에서 AI가 특히 강한 이유를 하나 더 짚겠습니다. 테스트입니다.

테스트는 "이 코드가 제대로 도는지"를 기계가 판정해 줍니다. 그러면 AI가 스스로 고칠 수 있어요. 고치고, 돌려 보고, 실패하면 또 고치고요.

21회차의 환각 문제가 여기서는 훨씬 덜 위험합니다. 틀린 코드는 실행하면 티가 나니까요. 그럴듯하지만 안 돌아가는 코드는 곧바로 걸립니다.

그래서 실무 요령이 나옵니다. 테스트를 먼저 요구하세요. "이 기능을 만들기 전에 어떤 경우를 확인해야 하는지 목록으로 뽑아 줘"처럼요. 그러면 AI가 스스로 채점할 기준이 생깁니다.

반대로 말하면 테스트가 없는 영역에서는 이 이점이 사라집니다. 디자인, 기획, 글쓰기가 그렇죠. 그래서 그쪽은 여전히 사람이 판정해야 합니다.

코딩에서 실제로 조심할 것

잘 된다고만 하면 정직하지 않으니 실제 함정을 짚겠습니다.

돌아가는 코드와 좋은 코드는 다릅니다. AI가 만든 코드는 대체로 돌아가지만 불필요하게 복잡하거나 나중에 고치기 어려운 경우가 많습니다. 특히 여러 번 고치다 보면 구조가 무너져요.

오래된 방식을 씁니다. 18회차의 지식 마감 때문입니다. 라이브러리는 계속 바뀌는데 모델은 학습 시점의 방식을 씁니다. 그래서 지금 쓰는 버전을 명시해야 합니다.

보안 문제를 만듭니다. 공개 코드에서 배웠으니 흔한 실수도 함께 배웠거든요. 특히 인증·권한·입력 검증 쪽은 반드시 사람이 봐야 합니다.

모르는 코드가 쌓입니다. 24회차에서 말한 그 문제요. 설명할 수 없는 코드가 늘어나면 나중에 고칠 수가 없습니다.

비개발자에게 열린 것

더 큰 변화는 개발자가 아닌 사람에게 일어났습니다.

간단한 자동화, 데이터 정리, 작은 도구 만들기가 가능해졌습니다. 반복 작업을 처리하는 스크립트, 파일 이름 정리, 자료 형식 변환 같은 것들이요.

여기서 중요한 조언 하나. 결과를 확인할 방법을 먼저 만드세요. 코드를 이해 못 해도 결과가 맞는지는 확인할 수 있습니다. 작은 표본으로 먼저 돌려 보고 눈으로 대조하는 식으로요.

그리고 원본을 반드시 복사해 두고 작업하세요. 23회차의 되돌릴 수 있게 만들기입니다. 파일을 정리하는 스크립트가 잘못 돌면 되돌릴 수 없습니다.

창작 도구 지형도

이제 만드는 쪽입니다. 도구가 아주 많은데 범주로 묶으면 정리가 됩니다.

이미지 생성. 17회차의 디퓨전 계열이요. 그림, 사진풍 이미지, 삽화를 만듭니다.

이미지 편집. 있는 이미지를 고치는 쪽입니다. 배경 지우기, 일부만 바꾸기, 확장하기요. 실무에서는 생성보다 편집이 더 많이 쓰입니다.

음성. 글을 소리로 만드는 합성, 목소리를 다른 목소리로 바꾸는 변환, 소리에서 목소리와 반주를 분리하는 것까지요.

영상. 22회차에서 봤듯 가장 어려운 영역입니다. 짧은 분량은 쓸 만해졌지만 긴 영상의 일관성은 아직입니다.

음악. 반주 생성, 곡 구조 만들기요. 완성곡을 뽑기보다 재료를 만드는 데 주로 쓰입니다.

이미지 생성 실무

17회차에서 원리를 다뤘으니 실무만 짚겠습니다.

한 번에 완성을 노리지 마세요. 여러 장을 뽑아 고르는 것이 기본입니다. 그리고 마음에 든 것의 시드를 기록해 두면 비슷한 결과를 다시 얻을 수 있어요.

글자는 포기하세요. 17회차에서 봤듯 글자를 부르는 낱말을 쓰면 철자가 깨진 글자가 나옵니다. 글자가 필요하면 이미지를 만든 뒤 따로 얹는 것이 정답입니다.

부정문을 피하세요. "이건 넣지 마"가 오히려 그것을 불러옵니다. 원하는 것만 긍정문으로 적으세요.

규격을 문서로 만드세요. 색, 구도, 크기, 금지어를 정리해 두면 여러 장을 만들어도 톤이 유지됩니다. 이 블로그가 실제로 그렇게 운영됩니다.

음성과 영상

음성은 이미 실용 단계입니다. 낭독, 안내 음성, 영상 나레이션에 충분히 쓰입니다. 25회차에서 봤듯 접근성에서도 큰 몫을 하고요.

다만 목소리 복제는 조심해야 합니다. 남의 목소리를 동의 없이 쓰는 것은 17회차에서 다룬 딥페이크와 같은 문제예요. 본인 목소리이거나 명시적 허락을 받은 경우로 제한하세요.

영상은 짧은 것만 실용적입니다. 몇 초짜리 장면은 쓸 만하고, 그것들을 이어 붙여 긴 영상을 만드는 방식이 현재의 실무예요.

그리고 이미지를 먼저 만들고 그것을 움직이게 하는 방식이 통제가 쉽습니다. 처음부터 영상을 생성하면 결과를 예측하기 어렵거든요.

창작에서 AI가 잘하는 자리

정리해 보면 패턴이 보입니다. 양이 필요한 자리에서 강합니다.

후보를 잔뜩 만드는 일. 시안 스무 개, 제목 서른 개, 배경 이미지 백 장이요. 사람이 하기엔 지치는 일입니다.

반복 작업. 같은 규격의 이미지를 여러 장, 같은 형식의 문안을 여러 벌이요.

재료 만들기. 완성품이 아니라 조합할 조각을 만드는 일. 배경, 효과음, 기본 반주요.

다른 형태로 옮기기. 글을 영상 대본으로, 대본을 나레이션으로, 긴 글을 짧은 요약으로요.

공통점이 있습니다. 사람이 최종 선택과 배치를 한다는 것. 24회차의 "순서가 결정한다"가 창작에서도 그대로예요.

창작에서 AI가 못하는 자리

반대쪽도 분명합니다.

왜 이것이어야 하는지를 정하는 일. 무엇을 만들지, 누구에게 왜 보여줄지는 AI가 정해 주지 못합니다. 물어보면 그럴듯한 답을 주지만 그건 평균적인 답이에요.

일관된 세계를 유지하는 일. 같은 인물이 여러 장면에 나오게 하는 것, 긴 이야기의 앞뒤를 맞추는 것이 여전히 약합니다.

진짜 새로운 것. 17회차에서 봤듯 생성은 배운 분포 안에서 뽑는 일입니다. 분포 밖으로 나가지 않아요. 그래서 평균적으로 좋은 것은 잘 만들지만 낯선 것은 잘 안 만듭니다.

그래서 창작에서 사람의 자리가 분명해집니다. 무엇을 만들지 정하고, 낯선 것을 알아보고, 최종 책임을 지는 것이요.

로컬 AI와 클라우드 AI

이제 실무의 중요한 선택입니다. 내 컴퓨터에서 돌릴 것인가, 남의 서버에 맡길 것인가.

클라우드는 회사가 운영하는 서버에 요청을 보내고 결과를 받는 방식입니다. 우리가 쓰는 대부분의 AI 서비스가 이것이에요.

로컬은 모델 파일을 내 컴퓨터에 내려받아 내 장비로 직접 돌리는 방식입니다. 예전에는 연구자만 했지만 지금은 개인용 그래픽카드로도 꽤 됩니다.

가능해진 이유가 둘입니다. 모델이 작아지면서도 성능이 좋아졌고, 18회차에서 말한 "같은 성능을 더 작게" 흐름이 실물로 나왔거든요. 그리고 공개 가중치 모델이 늘었습니다.

로컬을 고르는 이유 ① 개인정보

가장 큰 이유입니다. 데이터가 내 장비를 떠나지 않습니다.

24회차에서 "공개 게시판에 올려도 괜찮은 것만 넣으라"고 했죠. 그 제약이 로컬에서는 사라집니다.

그래서 이런 경우에 유용합니다. 진료 기록, 상담 내용, 계약서, 미공개 원고, 개인 사진이요. 다루는 것 자체가 민감한 자료들입니다.

25회차와도 이어집니다. 장애나 질병 관련 정보는 가장 민감한 개인정보인데, 정작 그 정보를 다루는 데 AI가 유용하거든요. 로컬은 그 딜레마를 푸는 실질적인 방법입니다.

다만 정직하게 말하면 로컬 모델이 클라우드보다 성능이 낮습니다. 그래서 민감도가 성능보다 중요한 자료에 쓰는 것이 현실적인 기준이에요.

로컬을 고르는 이유 ② 비용과 통제

두 번째는 비용 구조입니다. 클라우드는 쓸 때마다 돈이 나갑니다. 로컬은 처음에 장비값이 들고 그다음은 전기값이죠.

그래서 대량 반복 작업에서 유리합니다. 이미지 수백 장을 만들거나 긴 문서를 여러 번 처리하는 일이요.

세 번째는 통제권입니다. 클라우드 모델은 어느 날 갑자기 바뀝니다. 잘 되던 프롬프트가 안 통하게 되거나, 쓰던 모델이 없어지거나, 요금이 오르거나요.

로컬은 내가 안 바꾸면 안 바뀝니다. 오래 유지해야 하는 파이프라인에서는 이게 결정적일 수 있어요.

클라우드를 고르는 이유

공정하게 반대쪽도 봅시다.

성능이 훨씬 좋습니다. 가장 큰 모델은 개인 장비에서 못 돌립니다. 어려운 추론이 필요한 일은 클라우드가 압도적이에요.

준비가 필요 없습니다. 로컬은 설치하고 설정하고 문제가 생기면 직접 고쳐야 합니다. 그 시간도 비용이에요.

항상 최신입니다. 좋아진 모델을 자동으로 쓰게 됩니다.

어디서나 됩니다. 장비에 묶이지 않죠.

그래서 기본은 클라우드입니다. 로컬은 이유가 있을 때 고르는 선택지예요. "로컬이 좋다"가 아니라 "이 자료는 나갈 수 없다"거나 "이 작업은 너무 자주 돌린다"일 때요.

실제로는 나눠 씁니다

실무의 답은 둘 중 하나가 아니라 나누는 것입니다.

기준은 자료의 민감도와 작업의 반복성 두 축이에요.

민감하지 않고 어려운 일은 클라우드로. 공개 자료 조사, 복잡한 분석, 글 다듬기요.

민감하고 단순한 일은 로컬로. 개인 문서 요약, 사적인 기록 정리, 음성 받아쓰기요.

반복이 많은 일도 로컬이 유리합니다. 이미지 대량 생성 같은 것이요.

그리고 조합도 가능합니다. 민감한 부분을 로컬에서 가려낸 뒤 나머지만 클라우드로 보내는 식으로요. 24회차의 "가리고 넣기"를 자동화한 셈입니다.

1인 작업자의 구성 예시

구체적인 그림이 있으면 이해가 쉬우니 1인 창작·개발 환경을 예로 들겠습니다.

글 작업은 클라우드 대화형으로. 초안, 구조 검토, 다듬기요. 민감한 내용이 아니면 성능이 좋은 쪽이 낫습니다.

코드 작업도 클라우드 에이전트로. 다만 사내 코드나 비공개 프로젝트라면 정책을 확인해야 합니다.

이미지 생성은 로컬로. 양이 많고 규격이 정해져 있으니 비용과 통제 양쪽에서 유리합니다.

음성 합성과 받아쓰기도 로컬로. 목소리 자료는 민감하고, 반복이 많습니다.

개인 기록 정리는 로컬로. 일기, 건강 기록, 사적인 메모요.

중요한 것은 이 구성이 정답이 아니라 예시라는 점입니다. 자기 자료의 민감도와 작업 빈도에 따라 달라져야 해요.

저작권과 출처 — 실무 기준

17회차에서 쟁점을 다뤘으니 실무 기준만 정리하겠습니다.

상업적으로 쓸 것이라면 도구의 이용약관을 확인하세요. 생성물의 권리를 누가 갖는지, 상업 이용이 허용되는지가 도구마다 다릅니다.

실존 작가 이름을 프롬프트에 넣지 마세요. 화풍 자체는 대체로 보호 대상이 아니지만, 이름을 넣어 그 사람의 시장을 대체하는 것은 다른 문제입니다.

학습 데이터 출처가 밝혀진 모델을 고르세요. 선택지가 있다면요.

AI 생성물임을 밝히세요. 17회차에서 봤듯 유럽에서는 2026년 8월부터 법적 의무가 됐습니다. 29회차에서 규제 지형을 다루겠지만, 의무가 아닌 곳에서도 밝히는 편이 낫습니다. 나중에 문제가 되지 않고, 신뢰를 잃지 않으니까요.

팀에서 쓸 때의 규칙

혼자 쓸 때와 팀에서 쓸 때는 다릅니다. 최소한 정해야 할 것을 짚겠습니다.

무엇을 넣어도 되는지. 고객 정보, 미공개 자료, 코드요. 이걸 정하지 않으면 각자 판단하게 되고, 그러면 사고가 납니다.

어떤 도구를 쓸지. 데이터 처리 정책이 도구마다 다릅니다. 입력이 학습에 쓰이는지를 반드시 확인하세요.

결과물을 누가 검토하는지. "AI가 만들었으니 내 책임이 아니다"가 되면 안 됩니다. 내보내는 사람이 책임집니다.

어디에 표시할지. AI가 관여한 산출물을 어떻게 표시할지요.

이 규칙들은 27회차에서 더 자세히 다룹니다.

도구를 고르는 법

도구가 너무 많아 고르기 어렵습니다. 실용적인 방법을 드리겠습니다.

벤치마크 순위를 그대로 믿지 마세요. 19회차에서 봤듯 모델의 성격은 미세조정이 만듭니다. 점수가 높아도 내 용도에 안 맞을 수 있어요.

내 실제 과제를 두세 도구에 똑같이 던져 보세요. 삼십 분이면 순위표보다 정확한 답이 나옵니다.

바꾸기 쉬운 구조로 쓰세요. 특정 도구에 깊이 묶이면 나중에 갈아타기 어렵습니다. 23회차에서 다룬 공통 규격이 그래서 중요해요.

접근성을 확인하세요. 25회차에서 짚었듯 도구 자체가 쓰기 어려우면 성능이 아무 소용 없습니다.

도구는 계속 바뀝니다

마지막으로 태도 이야기를 하겠습니다. 이 회차의 구체적인 내용은 가장 빨리 낡습니다.

도구 이름, 성능 순위, 가능한 것과 불가능한 것의 경계가 몇 달 단위로 바뀝니다. 그래서 오늘 특정 제품 이름을 거의 쓰지 않았어요.

대신 변하지 않는 것에 집중했습니다. 왜 코딩이 앞섰는지(검증 가능성), 창작에서 사람의 자리가 어디인지(선택과 책임), 무엇을 손 안에 두어야 하는지(민감도와 반복성)요.

그리고 정기적으로 다시 시도하세요. 24회차에서 말한 그것이요. 반년 전에 안 되던 것이 지금은 될 수 있습니다. 안 된다고 결론 내린 것을 기록해 두었다가 다시 확인하는 습관이 실질적으로 유용합니다.

핵심 정리 — 세 줄

첫째, 코딩이 가장 먼저 바뀐 것은 검증이 자동화되기 때문입니다. 데이터가 많고 형식이 엄격하며 무엇보다 실행해 보면 정답을 기계가 확인해 줍니다. 그래서 테스트를 먼저 요구하는 것이 실무 요령이고, 반대로 테스트가 없는 영역에서는 이 이점이 사라져 사람이 판정해야 합니다.

둘째, 창작에서 AI는 양이 필요한 자리에 강하고 방향을 정하는 자리에 약합니다. 후보를 잔뜩 만들고 반복하고 재료를 뽑는 일은 잘하지만, 무엇을 왜 만들지 정하는 일과 낯선 것을 알아보는 일은 못 합니다. 생성은 배운 분포 안에서 뽑는 일이기 때문입니다.

셋째, 로컬과 클라우드는 민감도와 반복성으로 나눕니다. 기본은 클라우드이고 로컬은 이유가 있을 때 고르는 선택지입니다. 자료가 나갈 수 없거나 작업이 너무 자주 반복될 때요. 그리고 도구 이름은 빨리 낡지만 이 판단 기준은 남습니다.

용어 정리

코딩 에이전트 — 파일을 읽고 고치고 실행해 오류를 보고 다시 고치는 순환을 스스로 도는 개발 보조 도구.

테스트 — 코드가 의도대로 도는지 기계가 판정하게 하는 절차. AI가 스스로 고칠 수 있게 하는 자동 채점기 역할을 합니다.

로컬 AI — 모델을 내 장비에 내려받아 직접 돌리는 방식. 데이터가 밖으로 나가지 않습니다.

클라우드 AI — 사업자의 서버에 요청을 보내 결과를 받는 방식. 성능이 좋고 준비가 필요 없습니다.

공개 가중치 모델 — 모델 파일이 공개되어 누구나 내려받아 돌릴 수 있는 모델. 로컬 활용의 전제입니다.

시드 — 생성의 출발점을 정하는 값. 기록해 두면 같은 결과를 재현할 수 있습니다.

다음 회차 예고 — 그리고 생각해볼 질문

27회차는 「AI를 안전하게 쓰는 법」입니다. 제5부의 마지막 회예요.

오늘 여러 번 "27회차에서 다룹니다"라고 미뤄 둔 것들을 거기서 정리합니다. 개인정보의 구체적 기준, 저작권 실무, 답변 검증 습관, 그리고 AI 의존의 경계선이요.

특히 마지막이 중요합니다. 24회차에서 도구와 나의 거리를 이야기했는데, 그것을 개인의 습관이 아니라 사회적 조건의 문제로 넓혀 보려 합니다.

생각해볼 질문. 오늘 "로컬을 고르는 가장 큰 이유는 데이터가 내 장비를 떠나지 않는 것"이라고 했습니다. 그런데 이 선택지는 장비를 살 수 있고 설정할 줄 아는 사람에게만 열려 있습니다.

그러면 개인정보를 지킬 수 있는 능력도 결국 자원의 문제일까요? 민감한 자료를 다뤄야 하는데 로컬을 쓸 수 없는 사람은 어떻게 해야 할까요? 이건 개인이 조심할 문제인가요, 아니면 제도가 보장해야 할 문제인가요? 댓글로 들려주세요.

이 포스트는 SVIL 연구소 「AI 기초 및 활용」 30회 시리즈의 26회차이며, 제5부 「실전 활용」의 세 번째 회입니다. 하버드 CS50 AI, MIT 6.S191 등 공개 교육과정의 구조를 참고했으며, 모든 내용은 이미지 없이 본문만으로 이해할 수 있도록 구성되어 있습니다. 모든 이미지에는 내용을 설명하는 대체텍스트가 포함되어 있습니다.

협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://kuroicode-beep.github.io/svil-homepage/