구글 스티치 사용법을 제대로 이해하면 웹서비스를 만드는 과정이 훨씬 가벼워집니다. 예전에는 아이디어를 정하고, 디자이너에게 화면을 맡기고, 개발자가 코드를 작성하고, 다시 수정하는 과정이 필요했습니다. 하지만 이제는 구글 스티치, MCP, 안티그래비티를 연결해 디자인부터 코드 생성, 상세 페이지 확장까지 하나의 흐름으로 이어갈 수 있습니다.

특히 AI 1인 기업을 준비하는 사람에게 중요한 것은 완벽한 서비스 하나를 오래 붙잡는 것이 아니라, 여러 아이디어를 빠르게 만들고 시장 반응을 확인하는 것입니다. 해외에서는 작은 웹서비스를 여러 개 만들고, 그중 반응이 좋은 서비스를 키우는 방식이 점점 늘어나고 있습니다.

구글 스티치는 웹서비스의 첫 화면을 빠르게 구체화하는 디자인 도구입니다

구글 스티치는 텍스트로 원하는 앱이나 웹사이트를 설명하면 그에 맞는 화면 디자인을 생성해 주는 도구입니다. 예를 들어 “운동 습관을 게임처럼 관리하는 글로벌 웹서비스를 만들어줘”라고 입력하면, 캐릭터와 미션, 진행률, 버튼 구조가 포함된 화면 시안을 빠르게 만들어낼 수 있습니다.

중요한 점은 스티치가 단순 이미지 생성 도구처럼 보일 수 있지만, 실제로는 서비스 기획의 첫 단계를 시각화해 주는 역할을 한다는 것입니다. 머릿속에만 있던 아이디어를 화면으로 보면 사용 흐름과 기능 구조가 훨씬 명확해집니다.

구글 스티치의 핵심은 아이디어를 말로 설명하는 단계에서 바로 화면 구조로 바꿔준다는 점입니다.

다만 스티치만 단독으로 사용하면 한계가 있습니다. 생성된 화면은 보기에는 좋지만 기능이 작동하는 실제 웹서비스는 아닙니다. 그래서 안티그래비티와 MCP 연결이 필요합니다.

스티치와 안티그래비티를 MCP로 연결하면 디자인이 개발로 이어집니다

MCP는 서로 다른 AI 도구를 연결하는 다리 역할을 합니다. 스티치가 디자인을 만들고, 안티그래비티가 그 디자인을 바탕으로 실제 웹사이트나 앱을 개발하는 식으로 역할을 나눌 수 있습니다.

이 구조를 만들면 사용자는 일일이 스티치에 접속해 디자인을 만들고, 다시 코드를 옮기고, 다시 개발 도구에서 구현하는 과정을 반복하지 않아도 됩니다. 안티그래비티 안에서 스티치 MCP를 호출하고, 프로젝트 목록을 확인하고, 새 디자인을 만들고, 코드로 확장하는 작업을 이어갈 수 있습니다.

MCP 연결의 장점은 디자인 도구와 개발 도구를 따로 쓰는 것이 아니라 하나의 자동화 흐름으로 묶을 수 있다는 것입니다.

디자인 MD를 만들면 여러 페이지를 만들어도 화면 톤이 흔들리지 않습니다

바이브 코딩으로 웹사이트를 만들다 보면 가장 자주 생기는 문제가 디자인 일관성입니다. 첫 화면은 초록색 계열인데 다음 페이지는 노란색이 되고, 버튼 모양이나 폰트가 달라지는 일이 생깁니다. 서비스가 커질수록 이런 문제는 더 눈에 띕니다.

이때 필요한 것이 디자인 MD입니다. 디자인 MD는 색상, 폰트, 버튼 스타일, 카드 형태, 여백, 캐릭터 톤 같은 디자인 규칙을 문서화한 기준입니다. 이후 새로운 페이지를 만들 때 이 문서를 먼저 참고하게 하면 전체 서비스의 분위기를 유지할 수 있습니다.

디자인 MD는 AI가 만든 화면을 일회성 시안으로 끝내지 않고, 계속 확장 가능한 서비스 디자인 기준으로 바꾸는 장치입니다.

예를 들어 운동 습관 게임 웹서비스라면 귀여운 캐릭터, 둥근 버튼, 밝은 색상, 경험치 표시, 연속 운동일 수 같은 규칙을 디자인 MD에 정리할 수 있습니다. 이렇게 기준을 잡아두면 메인 화면, 미션 화면, 상점 화면, 결제 화면을 추가해도 디자인이 크게 흔들리지 않습니다.

핵심 정리

구글 스티치는 화면을 만들고, 디자인 MD는 그 화면의 규칙을 저장하며, 안티그래비티는 이를 바탕으로 실제 웹서비스 개발을 이어갈 수 있게 합니다.

운동 습관 게임처럼 작은 서비스부터 만들면 수익화 검증이 쉬워집니다

AI 1인 기업이 처음부터 거대한 플랫폼을 만들 필요는 없습니다. 오히려 작은 문제를 해결하는 웹서비스를 빠르게 만들고 검증하는 방식이 현실적입니다. 예를 들어 운동 습관을 만들기 어려워하는 사람을 위해 게임처럼 매일 운동을 체크하고 캐릭터를 성장시키는 서비스를 만들 수 있습니다.

이런 서비스는 구조가 단순하면서도 수익화 포인트를 만들기 좋습니다. 무료로 기본 기능을 제공하고, 캐릭터 꾸미기, 추가 미션, 통계 기능, 프리미엄 습관 관리 기능을 유료화할 수 있습니다.

1인 기업 웹서비스는 거창한 아이디어보다 작고 명확한 문제를 빠르게 해결하는 방향에서 시작하는 것이 좋습니다.

이미지 생성까지 연결하면 서비스의 캐릭터와 세계관도 빠르게 만들 수 있습니다

웹서비스를 만들 때 화면만 중요한 것이 아닙니다. 사용자가 계속 들어오게 만들려면 기억에 남는 캐릭터, 아이콘, 시각적 분위기가 필요합니다. 안티그래비티 안에서 이미지 생성 기능을 함께 활용하면 캐릭터, 알, 몬스터, 성장 단계 같은 시각 요소도 빠르게 만들 수 있습니다.

운동 습관 서비스라면 처음에는 알 형태의 캐릭터가 등장하고, 운동을 기록할수록 아기 몬스터, 공룡, 드래곤처럼 성장하는 방식으로 게임성을 줄 수 있습니다. 이런 구조는 단순 체크리스트보다 사용자의 반복 방문을 유도하기 좋습니다.

작은 웹서비스라도 캐릭터와 성장 구조를 넣으면 사용자가 다시 방문할 이유를 만들 수 있습니다.

다만 생성된 이미지는 저작권, 상표권, 기존 캐릭터와의 유사성을 반드시 확인해야 합니다. 유명 캐릭터를 직접 연상시키는 형태는 서비스에 사용하기 어렵습니다.

상업용 웹서비스에 이미지 생성물을 사용할 때는 기존 캐릭터와 비슷하지 않은지 반드시 확인해야 합니다.

Firebase와 결제 MCP까지 붙이면 실제 서비스 운영 흐름으로 확장할 수 있습니다

디자인과 프론트엔드 화면만 있어서는 수익화가 어렵습니다. 실제 서비스가 되려면 데이터 저장, 로그인, 결제, 배포가 필요합니다. 여기서 Firebase 같은 백엔드 서비스와 PayPal 또는 Stripe 같은 결제 시스템을 연결하면 운영 가능한 구조로 확장할 수 있습니다.

예를 들어 사용자의 운동 기록은 데이터베이스에 저장하고, 프리미엄 기능은 결제 후 열리게 만들 수 있습니다. 배포까지 자동화하면 아이디어를 만든 뒤 실제 사용자에게 보여주는 속도가 훨씬 빨라집니다.

AI 1인 기업의 핵심은 화면을 만드는 데서 끝나는 것이 아니라 배포, 결제, 운영까지 이어지는 작은 시스템을 만드는 것입니다.

• Firebase로 사용자 기록과 서비스 데이터를 저장합니다.

• PayPal 또는 Stripe로 해외 결제를 연결합니다.

• 랜딩 페이지와 상세 페이지를 함께 구성합니다.

• 무료 기능과 유료 기능을 나눠 수익화 구조를 만듭니다.

• 서비스 반응을 보고 빠르게 수정합니다.

여러 서비스를 빠르게 만들되 검증 없는 양산은 피해야 합니다

해외 1인 기업 사례를 보면 작은 웹서비스를 30개, 40개씩 만들고 그중 잘되는 것을 키우는 전략이 자주 등장합니다. 이 방식은 AI 도구가 발전하면서 더 현실적인 전략이 되고 있습니다. 하지만 무작정 많이 만든다고 성공하는 것은 아닙니다.

각 서비스는 명확한 문제, 검색 수요, 결제 가능성, 유지관리 가능성을 갖춰야 합니다. 단순히 화면만 예쁜 서비스는 오래가기 어렵습니다. 사용자가 실제로 반복해서 쓰고 돈을 낼 이유가 있어야 합니다.

AI로 빠르게 만들 수 있다는 이유만으로 검증 없는 웹서비스를 계속 양산하면 시간과 비용이 낭비될 수 있습니다.

AI 시대의 1인 기업은 실행 속도와 연결 능력에서 갈립니다

이제 웹서비스를 만들기 위해 모든 기술을 처음부터 배워야 하는 시대는 지나가고 있습니다. 물론 기본적인 이해와 검토 능력은 필요하지만, 디자인과 개발의 많은 부분은 AI 도구가 도와줄 수 있습니다. 중요한 것은 어떤 도구를 어떤 순서로 연결해 결과물을 만들 것인지 판단하는 능력입니다.

구글 스티치는 디자인을 빠르게 만들고, MCP는 도구를 연결하며, 안티그래비티는 실제 개발 흐름을 실행하게 만듭니다. 여기에 데이터베이스, 결제, 배포 시스템이 붙으면 혼자서도 작게 시작할 수 있는 웹서비스 구조가 만들어집니다.

앞으로의 1인 기업은 혼자 모든 일을 직접 하는 사람이 아니라, AI 도구들을 연결해 작은 팀처럼 운영하는 사람이 유리해집니다.

처음에는 오류가 나고 낯설 수 있습니다. 하지만 작은 서비스 하나를 끝까지 만들어 보면 디자인, 코드, 배포, 수익화 흐름이 눈에 들어오기 시작합니다. 완벽한 아이디어를 기다리기보다 작게 만들고, 빠르게 보여주고, 반응을 확인하는 방식이 더 현실적입니다.

함께 보면 좋은 원본 영상

자세한 내용은 아래 원본 영상에서 확인할 수 있습니다.

원본 영상 보기

구글 NotebookLM 사용법을 단순히 “자료를 넣고 요약하는 도구” 정도로만 이해하면 활용 범위가 매우 좁아집니다. NotebookLM은 자료를 모으는 공간이면서 동시에 AI 에이전트 자동화의 중심 노드가 될 수 있습니다. 여기에 MCP와 안티그래비티 같은 실행 도구를 연결하면 리서치, 소스 수집, 인포그래픽 제작, 슬라이드 생성, 마인드맵 정리까지 하나의 흐름으로 묶을 수 있습니다.

특히 1인 기업이나 소규모 팀에서는 시간이 가장 큰 자원입니다. 하루 종일 자료를 찾고, 정리하고, 발표자료를 만들다 보면 정작 중요한 기획과 실행에는 시간을 쓰기 어렵습니다. 이때 AI 에이전트 자동화는 단순 편의 기능이 아니라 업무 구조 자체를 바꾸는 방식이 됩니다.

NotebookLM은 자료를 저장하는 곳이 아니라 지식을 작업물로 바꾸는 공간입니다

NotebookLM의 기본 역할은 여러 자료를 한곳에 모아 이해하기 쉽게 정리하는 것입니다. 유튜브 링크, 웹페이지, 텍스트, 문서 자료 등을 넣으면 AI가 이를 기반으로 요약하고 질문에 답하며 핵심 내용을 정리해 줍니다.

하지만 여기서 한 단계 더 나아가면 NotebookLM은 단순한 요약 도구가 아니라 지식 생산 도구가 됩니다. 예를 들어 유튜브 채널 아이디어를 찾고 싶다면 관련 자료를 수집한 뒤, 그 자료를 바탕으로 수익화 전략, 콘텐츠 방향, 타깃 독자, 실행 순서를 정리할 수 있습니다.

NotebookLM의 핵심은 자료를 모으는 것이 아니라, 흩어진 자료를 내가 바로 활용할 수 있는 지식 형태로 바꾸는 데 있습니다.

이 기능은 블로그 작성, 강의 기획, 사업 아이디어 검토, 보고서 작성, 발표자료 제작처럼 반복적으로 자료를 읽고 정리해야 하는 업무에 특히 효과적입니다.

MCP와 안티그래비티를 연결하면 여러 프로젝트를 동시에 움직일 수 있습니다

NotebookLM을 하나씩 직접 클릭해서 사용하는 것도 충분히 유용하지만, MCP와 안티그래비티를 연결하면 자동화의 범위가 훨씬 넓어집니다. 사용자는 “유튜브 수익화 아이디어를 찾아줘”, “AI 1인 기업 모델을 조사해줘”, “ChatGPT와 Gemini 비교 슬라이드를 만들어줘”처럼 여러 작업을 한 번에 지시할 수 있습니다.

이 구조에서는 AI 에이전트가 각각의 프로젝트를 만들고, 관련 소스를 찾고, NotebookLM에 자료를 넣고, 결과물을 생성하는 흐름으로 작동합니다. 즉 사람이 반복적으로 클릭하던 과정을 에이전트가 대신 수행하는 방식입니다.

AI 에이전트 자동화의 장점은 하나의 명령으로 여러 개의 리서치 프로젝트를 동시에 진행할 수 있다는 점입니다.

인포그래픽과 마인드맵은 복잡한 정보를 빠르게 이해하게 만듭니다

리서치를 많이 해도 정보를 머릿속에 넣지 못하면 실제 업무에는 도움이 되지 않습니다. NotebookLM의 강점은 수집한 자료를 인포그래픽이나 마인드맵처럼 시각적으로 이해하기 쉬운 형태로 바꿀 수 있다는 점입니다.

예를 들어 유튜브 수익화 전략을 조사했다면, 단순 요약문보다 인포그래픽이 더 빠르게 구조를 보여줄 수 있습니다. 어떤 채널 아이디어가 있고, 어떤 수익 모델이 있으며, 어떤 실행 순서가 필요한지 한눈에 파악할 수 있기 때문입니다.

복잡한 리서치 결과는 글로만 정리하기보다 인포그래픽, 마인드맵, 표 형태로 바꿔야 실제 실행 속도가 빨라집니다.

마인드맵은 1인 기업 아이디어를 정리할 때도 유용합니다. 콘텐츠 제작, 디지털 상품, 교육 자료, 자동화 서비스, 마이크로 SaaS처럼 여러 방향으로 뻗는 사업 모델을 구조적으로 비교할 수 있습니다.

핵심 정리

NotebookLM은 자료를 요약하는 데서 끝나는 도구가 아닙니다. MCP와 안티그래비티를 연결하면 리서치, 정리, 시각화, 발표자료 제작까지 하나의 자동화 흐름으로 확장할 수 있습니다.

슬라이드 자동 생성은 보고서와 발표자료 작업 시간을 크게 줄입니다

회사 업무에서 많은 시간을 차지하는 작업 중 하나가 발표자료 제작입니다. 특히 비교 분석 자료는 자료 조사, 항목 분류, 장단점 정리, 슬라이드 구성까지 이어지기 때문에 시간이 오래 걸립니다.

AI 에이전트 자동화를 활용하면 ChatGPT와 Gemini 같은 도구를 비교하는 자료도 자동으로 수집하고, 이를 기반으로 슬라이드 구조를 만들 수 있습니다. 더 나아가 “게임 대결 스타일”, “캐릭터 배틀 스타일”, “보고용 문서 스타일”처럼 표현 방식까지 지정할 수 있습니다.

슬라이드 자동 생성의 핵심은 단순히 예쁜 디자인이 아니라, 자료 조사부터 발표 구조까지 한 번에 줄이는 데 있습니다.

물론 최종 발표자료는 사람이 검토해야 합니다. AI가 만든 슬라이드는 초안으로 활용하고, 실제 업무 목적에 맞게 표현, 근거, 문장 톤, 시각 자료를 수정하는 과정이 필요합니다.

자동화가 강력할수록 권한 승인과 보안 확인은 더 중요해집니다

AI 에이전트가 파일에 접근하거나 터미널 명령을 실행하거나 외부 서비스와 연결될 때는 반드시 권한 승인을 확인해야 합니다. 자동화 도구가 편리하다고 해서 모든 접근을 무조건 허용하면 보안 문제가 생길 수 있습니다.

특히 MCP, 로컬 실행 도구, 브라우저 자동화, 파일 접근 기능은 업무 효율을 크게 높이지만 동시에 민감한 정보에 접근할 가능성도 있습니다. 따라서 어떤 파일에 접근하는지, 어떤 명령을 실행하는지, 어떤 계정으로 로그인되어 있는지를 확인해야 합니다.

AI 에이전트에게 모든 권한을 무심코 허용하면 개인 정보, 업무 자료, 계정 정보가 노출될 수 있습니다.

• 권한 요청이 나오면 어떤 파일과 경로에 접근하는지 확인합니다.

• 모르는 명령어나 코드 실행은 바로 승인하지 말고 내용을 먼저 검토합니다.

• 중요 계정은 자동화 테스트용 계정과 분리하는 것이 안전합니다.

• 업무 자료와 개인 자료가 섞인 폴더에는 무제한 접근 권한을 주지 않는 것이 좋습니다.

1인 기업은 모든 일을 직접 하는 구조에서 에이전트를 운영하는 구조로 바뀝니다

AI 자동화가 중요한 이유는 단순히 일을 빠르게 끝내기 위해서만은 아닙니다. 1인 기업의 운영 방식 자체를 바꿀 수 있기 때문입니다. 예전에는 리서치 담당자, 기획자, 디자이너, 발표자료 제작자, 콘텐츠 작성자가 각각 필요했던 일을 이제는 한 사람이 AI 에이전트를 조합해 처리할 수 있습니다.

물론 이것이 사람의 역할이 사라진다는 뜻은 아닙니다. 오히려 사람은 무엇을 시킬지 정하고, 결과물을 판단하고, 방향을 수정하는 역할에 집중하게 됩니다. 반복 실행은 에이전트가 맡고, 전략과 의사결정은 사람이 맡는 구조입니다.

앞으로의 1인 기업 경쟁력은 AI 도구를 얼마나 많이 아느냐보다, 여러 도구를 연결해 하나의 업무 시스템으로 만들 수 있느냐에 달려 있습니다.

AI 에이전트를 잘 쓰려면 도구 사용법보다 작업 지시법이 먼저입니다

자동화 도구가 아무리 좋아도 명령이 모호하면 결과물도 흐려집니다. “자료 찾아줘”라고만 말하는 것보다 “최근 인터넷 자료를 기반으로 유튜브 수익화 아이디어 5개를 찾고, 각각의 장단점과 실행 난이도를 비교해줘”라고 지시해야 결과가 좋아집니다.

또한 결과물의 형태를 미리 정하는 것도 중요합니다. 인포그래픽으로 만들지, 표로 정리할지, 슬라이드로 만들지, 마인드맵으로 만들지를 정해 주면 에이전트가 더 정확하게 작업할 수 있습니다.

AI 에이전트 자동화의 품질은 도구 자체보다 사용자가 내리는 지시의 구체성에 크게 좌우됩니다.

• 작업 목표를 먼저 말합니다.

• 참고할 자료 범위와 기준을 정합니다.

• 결과물 형식을 지정합니다.

• 원하는 스타일이나 톤을 설명합니다.

• 중간 진행 상황을 보고하도록 요청합니다.

AI가 만든 결과물을 그대로 믿기보다, 출처와 논리, 최신성은 반드시 사람이 다시 확인해야 합니다.

지금 필요한 것은 AI 도구를 구경하는 것이 아니라 내 업무에 연결하는 것입니다

NotebookLM, MCP, 안티그래비티 같은 도구는 처음에는 복잡하게 느껴질 수 있습니다. 오류도 생기고, 권한 승인도 낯설고, 원하는 결과가 한 번에 나오지 않을 수도 있습니다. 하지만 중요한 것은 도구를 완벽하게 익힌 뒤 시작하는 것이 아니라, 내 업무 중 반복되는 부분 하나를 골라 자동화해 보는 것입니다.

예를 들어 매주 작성하는 보고서, 블로그 초안, 시장 조사, 강의 자료 정리, 유튜브 콘텐츠 기획처럼 반복되는 작업이 있다면 그것부터 NotebookLM과 AI 에이전트 구조에 연결해 볼 수 있습니다.

AI 시대의 생산성은 더 오래 일하는 사람이 아니라, 반복 업무를 시스템으로 바꾸는 사람이 가져갑니다.

1인 기업을 준비한다면 더욱 그렇습니다. 혼자 모든 일을 처리하려고 하면 한계가 빨리 옵니다. 하지만 리서치 에이전트, 정리 에이전트, 슬라이드 에이전트, 콘텐츠 에이전트를 만들어 두면 혼자서도 작은 팀처럼 움직일 수 있습니다.

함께 보면 좋은 원본 영상

자세한 내용은 아래 원본 영상에서 확인할 수 있습니다.

원본 영상 보기

AI 에이전트 업무 자동화는 이제 단순히 “편리한 도구를 쓰는 것”을 넘어, 일하는 방식 자체를 바꾸는 단계로 들어가고 있습니다. 예전에는 사람이 직접 검색하고, 정리하고, 문서를 만들고, 일정을 등록했다면 이제는 AI 에이전트가 정해진 규칙에 따라 업무를 수행하고 결과물을 만들어냅니다. 중요한 변화는 AI가 질문에 답하는 수준을 넘어, 실제 업무 흐름 안에서 반복적으로 실행되고 개선된다는 점입니다.

특히 1인 기업, 프리랜서, 강사, 콘텐츠 제작자, 사무직 직장인에게 AI 에이전트는 단순한 보조 도구가 아니라 작은 팀처럼 작동할 수 있습니다. 업무를 잘게 나누고, 각 업무에 맞는 규칙과 자료를 제공하면 리서치, 콘텐츠 제작, 이메일 정리, 일정 관리, 보고서 작성까지 상당 부분을 자동화할 수 있습니다.

AI 에이전트는 도구보다 업무 구조를 먼저 바꿔야 제대로 작동한다

AI 에이전트를 사용할 때 많은 사람이 먼저 어떤 서비스를 써야 하는지부터 고민합니다. 클로드 코드, 오픈클로, 챗GPT, 코덱스, 자동화 툴처럼 다양한 선택지가 있기 때문입니다. 하지만 실제로 중요한 것은 도구 이름이 아니라, 내가 맡기려는 업무가 어떤 순서와 기준으로 처리되어야 하는지를 정리하는 일입니다.

AI 에이전트 업무 자동화의 핵심은 좋은 도구를 찾는 것이 아니라, 반복 가능한 업무 흐름을 설계하는 것입니다.

예를 들어 블로그 작성, 강의 슬라이드 제작, 고객 문의 분류, 일정 등록 같은 일은 겉으로는 서로 달라 보이지만 내부 구조는 비슷합니다. 입력 자료를 받고, 필요한 정보를 판단하고, 정해진 양식에 맞게 결과물을 만들고, 사람이 최종 검토하는 흐름입니다. 이 흐름을 명확히 정의할수록 AI 에이전트는 더 안정적으로 일합니다.

반대로 업무 기준이 모호하면 아무리 성능이 좋은 AI 모델을 사용해도 결과물은 흔들립니다. AI가 똑똑해졌다고 해도 아직은 “내가 원하는 방식”을 스스로 완벽히 이해하지 못합니다. 그래서 업무별 폴더, 규칙 문서, 참고 자료, 예시 파일, 결과물 양식 등을 미리 구성하는 과정이 필요합니다.

하네스 엔지니어링은 AI를 내 방식대로 일하게 만드는 설계법이다

최근 AI 에이전트를 설명할 때 자주 등장하는 개념이 하네스 엔지니어링입니다. 쉽게 말하면 뛰어난 AI 모델이 엉뚱한 방향으로 가지 않도록 업무 규칙과 실행 환경을 단단히 잡아주는 방식입니다. 예전의 GPTs가 주로 프롬프트로 AI를 규율했다면, 요즘의 에이전트는 프롬프트뿐 아니라 코드, 문서, 스크립트, 데이터 파일, 양식 파일까지 활용해 훨씬 촘촘하게 통제합니다.

하네스 엔지니어링이 잘된 AI 에이전트는 단순한 대화형 AI보다 복잡한 업무를 더 일관되게 처리할 수 있습니다.

예를 들어 강의 슬라이드를 자동으로 만들고 싶다면 “PPT 만들어줘”라고 말하는 것만으로는 부족합니다. 어떤 색상 체계를 사용할지, 한 장의 슬라이드에 들어갈 문장 길이는 어느 정도인지, 표지와 본문과 정리 페이지의 구조는 어떻게 다른지, 어떤 형식의 파일로 저장할지까지 정해두어야 합니다. 이 기준이 쌓이면 AI는 단순히 문장을 생성하는 것이 아니라, 하나의 제작 시스템처럼 움직이게 됩니다.

업무 기준을 만들지 않은 상태에서 AI에게 많은 권한을 주면 결과물은 빨라질 수 있지만, 품질과 방향성이 흔들릴 수 있습니다.

업무용 AI 에이전트는 폴더와 역할을 나누면 팀처럼 움직인다

AI 에이전트를 실무에 적용할 때 효과적인 방법은 업무를 하나의 거대한 덩어리로 맡기지 않고, 목적별로 나누는 것입니다. 예를 들어 교육 설계 에이전트, 강의 슬라이드 제작 에이전트, 블로그 작성 에이전트, 유튜브 아이디어 에이전트, 이메일 분류 에이전트처럼 역할을 분리하면 각 에이전트가 더 명확한 기준으로 움직일 수 있습니다.

업무를 쪼개고 각 에이전트의 역할을 명확히 할수록 AI는 주니어 직원처럼 실무를 처리할 수 있습니다.

중앙에 라우터 역할을 하는 비서형 에이전트를 두는 방식도 유용합니다. 사용자는 하나의 창구에만 요청하고, 중앙 에이전트가 요청 내용을 판단해 적절한 업무 에이전트에게 넘기는 구조입니다. 이렇게 하면 여러 프로젝트 폴더를 직접 오가며 실행하지 않아도 되고, 텔레그램 같은 메신저를 통해서도 업무 지시가 가능해집니다.

• 교육 설계 에이전트: 고객사, 직무 수준, 교육 목표를 바탕으로 실습 시나리오 생성

• 평가 에이전트: 수강생 결과물을 기준표에 맞춰 평가하고 피드백 작성

• PPT 제작 에이전트: HTML 기반 초안을 만들고 슬라이드 파일로 변환

• 블로그 에이전트: 자막, 자료, 키워드를 바탕으로 SEO 글 초안 작성

• 영업 관리 에이전트: 이메일을 분류하고 고객사별 진행 상황을 요약

• 리서치 에이전트: 링크드인, 유튜브, 블로그 등에서 참고 자료를 수집

이 구조가 자리 잡으면 혼자 일하는 사람도 작은 운영팀을 가진 것처럼 일할 수 있습니다. 다만 AI가 모든 판단을 대신하는 것은 아니므로 최종 검토와 방향 설정은 사람이 맡아야 합니다.

클로드 코드는 정밀한 업무 자동화에, 오픈클로는 유연한 개인 비서에 가깝다

업무용 AI 에이전트를 만들 때는 정밀하게 설계할 업무와 가볍게 시도할 업무를 나눠보는 것이 좋습니다. 클로드 코드처럼 프로젝트 폴더와 규칙을 세밀하게 잡을 수 있는 도구는 업무 품질을 안정적으로 유지해야 하는 경우에 적합합니다. 반면 오픈클로처럼 컴퓨터 화면을 직접 조작하는 방식에 강한 도구는 일정 관리, 카카오톡 아카이빙, 열차 좌석 조회처럼 일상적인 반복 작업에 잘 맞습니다.

정밀한 결과물이 필요한 업무는 강한 하네스가 필요하고, 생활형 자동화는 유연한 컴퓨터 조작 능력이 더 중요합니다.

예를 들어 캘린더에 일정을 등록할 때 매번 구글 캘린더를 열고 클릭할 필요 없이, 메신저에 “다음 주 화요일 오후 2시에 미팅 등록”이라고 입력하면 AI가 직접 캘린더를 생성할 수 있습니다. 카카오톡 나에게 보내기 메시지를 긁어와 구글 시트에 정리하고, 링크 내용을 보강해 나만의 학습 데이터베이스로 만드는 것도 가능합니다.

다만 금융, 결제, 세금계산서, 예약 구매처럼 실제 권한과 책임이 발생하는 작업은 반드시 사람이 최종 확인하는 구조가 필요합니다.

콘텐츠 제작과 리서치는 AI 에이전트가 가장 빠르게 성과를 내는 영역이다

AI 에이전트가 특히 빠르게 성과를 내는 영역은 콘텐츠 제작과 리서치입니다. 블로그 글 작성, 유튜브 주제 발굴, 썸네일 아이디어 정리, 링크드인 글 모니터링, 경쟁 채널 분석처럼 자료를 모으고 재구성하는 일은 AI가 매우 잘 처리합니다.

콘텐츠 자동화의 목적은 글을 대충 많이 만드는 것이 아니라, 자료 수집과 초안 작성 시간을 줄여 사람이 더 중요한 판단에 집중하게 만드는 것입니다.

예를 들어 매일 특정 전문가들의 글을 모니터링하고, 전날 올라온 글을 요약해 아침마다 받아볼 수 있습니다. 유튜브 채널을 주기적으로 확인해 새로 제작할 만한 주제나 썸네일 방향을 추천받을 수도 있습니다. 좋은 글이나 링크를 카카오톡에 저장해두면 AI가 이를 정리해 학습용 웹사이트나 데이터베이스로 변환하는 방식도 가능합니다.

핵심 정리

AI 에이전트는 콘텐츠를 대신 만들어주는 도구이기 전에, 흩어진 자료를 모으고 분류하고 재활용 가능한 구조로 바꾸는 생산성 시스템입니다. 좋은 자료를 꾸준히 모으고, 그 자료를 글·영상·강의·보고서로 전환하는 흐름을 만들면 1인 기업도 콘텐츠 생산량을 크게 늘릴 수 있습니다.

이 방식의 장점은 단순히 시간을 아끼는 데서 끝나지 않습니다. 사람이 놓치기 쉬운 자료를 계속 모아주기 때문에 아이디어 고갈을 줄이고, 반복적인 정리 업무를 줄이며, 콘텐츠 제작의 출발점을 빠르게 만들어줍니다.

AI 에이전트는 한 번 만들고 끝나는 도구가 아니라 계속 훈련해야 하는 시스템이다

AI 에이전트를 만들었다고 해서 바로 완성되는 것은 아닙니다. 오히려 중요한 과정은 그다음부터 시작됩니다. 결과물을 보고 피드백을 주고, 잘못된 부분을 수정하고, 기준을 보강하면서 계속 개선해야 합니다. 신입 직원에게 일을 가르치듯이 AI 에이전트도 반복적인 피드백을 통해 더 안정적으로 바뀝니다.

AI 에이전트의 품질은 처음 만든 설정값보다, 이후 얼마나 검증하고 개선했는지에 따라 결정됩니다.

특히 평가 기준을 정해두고 AI가 스스로 결과물을 비교하게 하는 방식은 매우 효과적입니다. 예를 들어 PPT 제작 에이전트라면 디자인 일관성, 문장 길이, 정보 구조, 시각적 균형, 브랜드 톤 같은 기준을 만들고, AI가 그 기준에 맞을 때까지 실험하게 할 수 있습니다. 이런 반복 개선 과정을 통해 첫 번째 결과물보다 열 번째 결과물이 훨씬 좋아지는 일이 가능합니다.

• 결과물이 마음에 들지 않으면 단순히 다시 만들라고 하지 말고, 무엇이 부족한지 기준을 알려준다.

• AI에게 “현재 시스템을 비판적으로 검토하고 개선점을 제안하라”고 요청한다.

• 다른 AI 모델의 의견도 함께 비교해 구조적 허점을 찾는다.

• 좋은 결과물이 나오면 그 기준과 예시를 에이전트 규칙에 반영한다.

에이전트가 많아질수록 관리할 자료와 판단할 결과물도 늘어나므로, 자동화 자체가 새로운 관리 업무가 될 수 있다는 점을 고려해야 합니다.

깃허브와 벤치마킹은 비개발자에게도 강력한 출발점이 된다

AI 에이전트를 더 잘 만들고 싶다면 이미 누군가 만들어둔 사례를 적극적으로 참고하는 것이 좋습니다. 깃허브는 개발자만 쓰는 공간처럼 보이지만, AI 에이전트 시대에는 비개발자에게도 매우 유용한 참고 자료가 됩니다. 코드를 직접 이해하지 못해도 AI에게 깃허브 링크를 주고 “이것처럼 내 업무에 적용하려면 어떻게 해야 하느냐”고 물어보면 시작할 수 있습니다.

이제 중요한 것은 모든 기술을 직접 아는 것이 아니라, 참고할 만한 사례를 찾아 AI가 구현할 수 있게 연결하는 능력입니다.

예를 들어 PPT 자동 생성, 영상 편집 자동화, 웹 크롤링, 데이터 정리, 문서 변환 같은 기능은 이미 다양한 프로젝트와 사례가 공개되어 있습니다. AI에게 관련 깃허브 프로젝트를 찾아보게 하고, 그중 적합한 방식을 자신의 업무에 맞게 변형해달라고 요청하면 비개발자도 충분히 자동화 시스템을 만들 수 있습니다.

유튜브 인터뷰, 논문, 블로그 글, 기술 문서도 좋은 벤치마킹 자료가 됩니다. 핵심 아이디어만 추출해 AI에게 전달하면, AI는 이를 바탕으로 구체적인 실행 구조를 제안할 수 있습니다. 이 과정에서 사람의 역할은 모든 코드를 직접 작성하는 것이 아니라, 어떤 방향이 필요한지 판단하고 좋은 기준을 제시하는 것입니다.

AI 에이전트 시대에는 실행자가 아니라 설계자가 더 중요해진다

AI 에이전트가 확산되면 사무직의 역할은 크게 달라질 가능성이 큽니다. 문서를 직접 작성하고, 자료를 직접 찾고, 반복 업무를 직접 처리하는 능력보다 어떤 일을 자동화할지 정하고, 그 업무의 기준을 설계하고, 결과물을 검증하는 능력이 더 중요해집니다.

앞으로의 생산성 차이는 AI를 쓰느냐 안 쓰느냐가 아니라, AI 에이전트를 얼마나 내 업무에 맞게 설계하고 운영하느냐에서 갈릴 가능성이 큽니다.

특히 대표, 팀장, 1인 기업 운영자라면 AI 에이전트를 직접 체험해볼 필요가 있습니다. 단순히 직원에게 맡기거나 외부 서비스만 도입해서는 체감하기 어렵습니다. 실제로 자신의 메일, 일정, 자료 정리, 콘텐츠 제작, 영업 관리 중 하나라도 에이전트로 바꿔보면 업무의 병목이 어디에 있는지 훨씬 명확하게 보입니다.

전통적인 산업에서도 가능성은 큽니다. 건설, 제조, 공공 분야처럼 디지털 전환이 느리다고 여겨졌던 분야에서도 도면 기반 수량 산출, 문서 정리, 공고 수집, 보고서 작성, 일정 관리 같은 업무는 AI 에이전트와 결합될 수 있습니다. 중요한 것은 거창한 시스템을 처음부터 만드는 것이 아니라, 매일 반복되는 작은 업무 하나를 AI에게 맡겨보는 것입니다.

AI 에이전트가 모든 일을 완전히 대체한다고 생각하기보다, 사람이 기준을 만들고 AI가 실행을 담당하는 구조로 접근해야 실패 가능성을 줄일 수 있습니다.

지금 시작할 수 있는 가장 현실적인 AI 에이전트 적용 순서

AI 에이전트를 처음 도입한다면 복잡한 시스템부터 만들 필요는 없습니다. 가장 먼저 해야 할 일은 내 업무 중 반복되는 일을 찾는 것입니다. 매일 확인하는 메일, 매주 작성하는 보고서, 자주 만드는 블로그 초안, 반복적으로 정리하는 회의록, 계속 모니터링하는 웹사이트가 좋은 출발점입니다.

AI 에이전트 도입은 거대한 자동화 프로젝트가 아니라, 반복 업무 하나를 줄이는 실험에서 시작하는 것이 가장 현실적입니다.

처음부터 회사 전체 업무를 자동화하려고 하면 실패하기 쉽습니다. 대신 “아침마다 메일 요약 받기”, “자막으로 블로그 초안 만들기”, “회의록을 보고서 형식으로 정리하기”처럼 작고 명확한 업무부터 시작하는 편이 좋습니다. 이 작은 성공이 쌓이면 자연스럽게 업무용 에이전트 구조를 확장할 수 있습니다.

AI 에이전트는 이미 현실이 되었고, 이제는 직접 다뤄봐야 한다

AI 에이전트는 먼 미래의 이야기가 아니라 이미 업무 현장에서 적용 가능한 현실적인 도구가 되고 있습니다. 단순한 자동 응답이나 문장 생성 수준을 넘어, 일정 관리, 콘텐츠 제작, 리서치, 이메일 분류, 웹사이트 제작, 데이터 수집, 문서 작성까지 다양한 업무에 들어오고 있습니다.

AI 에이전트 시대의 핵심 역량은 내가 원하는 결과를 정의하고, AI가 그 기준에 맞게 일하도록 시스템을 설계하는 능력입니다.

물론 모든 업무가 즉시 자동화되는 것은 아닙니다. 유지보수도 필요하고, 오류도 발생하며, 사람이 최종 판단해야 하는 영역도 분명히 남아 있습니다. 그러나 반복적인 사무 업무와 디지털 기반 지식 노동의 상당 부분은 이미 에이전트 전환이 가능한 단계에 가까워지고 있습니다.

지금 필요한 것은 완벽한 도구를 기다리는 것이 아니라, 내 업무 중 하나를 골라 직접 실험해보는 것입니다. 작은 자동화 하나를 성공시키면 AI가 단순한 도구가 아니라 함께 일하는 시스템이 될 수 있다는 감각을 빠르게 얻을 수 있습니다.

함께 보면 좋은 원본 영상

자세한 내용은 아래 원본 영상에서 확인할 수 있습니다.

원본 영상 보기

자하 하디드의 건물은 복잡하고 놀랍고 완전히 독보적이지만, 더 혁명적인 것은 건물 자체가 아니라 그것을 만드는 과정입니다. 그녀의 전환점은 AA(런던) 4학년 논문에서 말레비치의 절대주의(Suprematism)를 건축으로 옮긴 작업 “말레비치의 테크토닉”이었습니다. 말레비치가 현실 재현을 버리고 단순한 기하와 제한된 색으로 순수한 감정을 밀어붙였듯, 자하는 전통적 건축 드로잉의 한계(평면·입면·투시의 빈곤)를 넘어 추상을 ‘표현 수단’이 아니라 ‘설계 방법’으로 사용하기 시작합니다. 2D와 3D, 실루엣과 입체, 여러 시점을 한 화면에 섞어 움직임을 만들고, 말레비치의 형상이 ‘아키텍톤(3D 오브제)’이 되고, 그 아키텍톤이 다시 실제 건물로 번역되는 연쇄를 보여줍니다.

이 흐름은 홍콩 더 피크(미실현)에서 더 선명해집니다. 자하는 콜라주처럼 도시·산·프로젝트를 한 장면에 겹쳐 그 건물이 “산에서 자라난다”는 맥락적 생성을 드로잉으로 증명합니다. 여기서 등장하는 것이 그녀 특유의 캘리그래피(서예적) 스케치입니다. 반쯤 평면이고 반쯤 회화인 선들은 곧 공간의 동선·흐름·응집을 예고하며, 시간이 지나 건물로 진화합니다. 그리고 이때부터 말레비치의 ‘떠 있는 형상’은 엘 리시츠키(El Lissitzky)·구성주의(Constructivism)의 언어와 접속합니다. 구성주의는 예술을 감정의 표출에 머물지 않고 사회적·기능적 설계로 연결하려 했고, 리시츠키는 다중 소실점, 중첩된 평면, 역동적 시점으로 ‘보이지 않는 차원’을 암시했는데, 이것이 자하에게 결정적으로 꽂힌 개념이 바로 4차원=시간입니다.

자하가 시간(4차원)을 건축으로 구현하는 방식은 “건물을 한 컷으로 보게 하지 않는 것”입니다. 로마의 MAXXI를 보면, 상부에서 읽히는 선들은 여전히 문자처럼 흐르는 형태를 갖고 있고, 내부에서는 여러 갈래의 동선 선택을 통해 관람자가 서로 다른 경험을 하게 만듭니다. 즉, 공간은 고정된 장면이 아니라 이동·선택·체류를 통해 완성되는 사건이 됩니다. 그녀는 천장 핀과 보행교, 계단을 대비시키며 구성주의적 화면을 내부에 ‘실제로’ 세팅하고, 시야가 한 번에 끝나지 않게 만들어 시간의 감각을 공간 속에 심습니다. 그래서 MAXXI는 “어디서 시작해 어디서 끝나는지”가 흐릿하게 느껴지고, 그 흐릿함이 곧 건축적 시간으로 작동합니다.

또 하나의 핵심은 ‘표현(드로잉)은 본질적으로 환영(illusion)이다’라는 태도입니다. 원근법(1점·2점 투시), 액소노메트릭, 아이소메트릭은 모두 2D 위에 3D를 믿게 만드는 장치인데, 자하는 이 환영을 그냥 ‘그림’으로 두지 않고 평면 자체에 주입해 버립니다. 독일 BMW 센터 평면에서 보이는 마름모·왜곡된 방 형태는 사실 아이소메트릭 큐브의 착시에서 온 기하이고, 그녀는 그 착시 도형을 실제 방의 형태로 채택합니다. 결과적으로 도면에서 “왜곡되어 보이던 것”이 현실에서 “왜곡된 공간감”으로 체험됩니다. 즉, 그녀는 ‘그리는 방식’이 ‘만들어지는 공간’까지 바꾸도록 설계를 재구성한 것입니다.

비트라 소방서에서는 이 사고가 “동작이 얼어붙은 형태(frozen action)”로 번역됩니다. 화재 출동의 폭발적 긴장감을 건물 자체가 품고 있어야 한다는 생각 아래, 벽·캐노피·모서리는 직각을 피하고 비스듬히 꺾이며, 한 시점에서는 날카로운 사선의 덩어리로, 다른 시점에서는 전혀 다른 실루엣으로 읽힙니다. 같은 캐노피가 각도에 따라 완전히 다른 형태로 보이는 장면은, 자하가 시점·왜곡·중첩을 통해 공간을 ‘정지된 조형’이 아니라 ‘인지가 변하는 사건’으로 다루었다는 증거입니다. 그녀의 혁명은 결국 “형태가 특이해서”가 아니라, 회화적 추상→드로잉의 환영→공간 경험의 시간성을 한 줄로 연결해 건축의 설계 언어를 바꿔버린 데 있습니다.

구글 애드센스 수익을 정산받기 위해 꼭 필요한 과정이 바로 세금 정보(Tax Info) 등록입니다. 특히 미국 외 국가 사용자도 미국 세금법에 따라 W-8BEN 제출이 필수가 되었기 때문에, 등록하지 않으면 수익의 최대 24%까지 원천징수될 수 있습니다. 이번 글에서는 한국 애드센스 사용자 기준으로 세금 정보를 등록하는 방법을 단계별로 설명드릴게요.

1. 세금 정보 등록이 필요한 이유?

• 구글은 미국 기업이며, 미국 세법에 따라 콘텐츠 수익에 세금 처리를 해야 함

• W-8BEN 양식은 미국 외 국가 사용자(예: 한국)가 미국에서 발생한 수익에 대한 면세 또는 감세를 요구하는 공식 문서

• 등록하지 않으면 최대 24%의 세금이 전체 수익에 부과됨

2. 세금 정보 등록 절차

• 구글 애드센스 접속 후, 로그인

  • https://adsense.google.com/intl/ko_kr/start/

Google 애드센스 - 웹사이트에서 수익 창출하기

웹사이트에서 광고 및 콘텐츠를 통해 수익을 창출하세요. 웹사이트에서 애드센스를 사용하는 방법을 알아보세요.

adsense.google.com

• [지급] → [지급 정보] → [설정관리] 이동

• [결제 프로필] → [미국 세금 정보] → [세금 정보 관리] 이동

• "세금정보 추가" 클릭 후, "양식 시작" 선택

• 미국 세금 정보 등록

  • 계좌 유형은 무엇인가요? → "개인" 선택

  • 미국 시민 또는 거주자인가요? → "아니요" 선택

  • W-8 세금 양식 유형을 선택하세요 . → "W-8BEN" 선택

  • "W-8BEN 양식으로 이동" 클릭

• W-8BEN 세금 양식 작성 (세금 ID)

  • 수익권자에 해당하는 개인의 이름 → 영문 이름(여권과 동일한 이름) 작성

  • 시민권을 보유한 국가/지역 → "대한민국" 선택

  • "다음" 클릭

• W-8BEN 세금 양식 작성 (주소)

  • 거주 국가/지역 → "대한민국" 선택

  • 도/시 → 해당 도/시 선택

  • 시/군/구 → 해당 시/군/구 선택

  • 상세 주소 → 상세 주소를 영문으로 작성

  • 동, 호 등(선택사항) → 해당 동/호 작성

  • 우편번호 → 우편번호 작성

  • "우편 주소가 영구 거주지 주소와 동일합니다." 선택

  • "다음" 클릭

• W-8BEN 세금 양식 작성 (조세조약)

  • "조세 조약에 따라 인하된 원천징수세율을 신청하시나요?" → "아니요. 원천징수세율 인하 요건을 충족하지 않습니다." 선택

  • "다음" 클릭

• W-8BEN 세금 양식 작성 (미국에서 수행한 활동 및 서비스)

  • "미국 내에서 Google에 대한 활동 및 서비스를 수행했거나 앞으로 수행할 예정인가요?" → "아니요" 선택

  • "Google 또는 Google 제휴사에 제공하는 서비스가 미국 밖에서만 행해지며 해당 서비스의 제공에 사용되는 노동력 또는 자본(시설 또는 기타 도구 포함)이 실제로 미국 외부에 위치함을 보증합니다." 선택

  • "다음" 클릭

• W-8BEN 세금 양식 작성 (세금 신고)

  • "미국 세금 문서 발송 방법(1099K, 1099-MISC 등의 양식)" → "우편 수신 중지(권장)" 선택

  • "우편 수신 중지에 동의합니다." 선택

  • "다음" 클릭

• W-8BEN 세금 양식 작성 (문서 미리보기)

  • "W-8BEN양식: 기본값.pdf" 선택하여 세금양식을 다운로드 받아서 확인

  • "생성된 세무 서류를 본인이 알고 있는 한도 내에서 검토했으며 서류가 진실되고 정확하며 완전함을 확인합니다." 선택

  • "다음" 클릭

• W-8BEN 세금 양식 작성 (인증 및 서명)

  • "세금 양식 인증" →  "위증 시 처벌을 받는다는 조건하에 다음을 보증합니다." 선택

  • "상태 불변 진술서"  

    • 구글로부터 대금을 지급 받은 적이 없다 → 생략

    • 구글로부터 대금을 지급 받은 적이 있다 → "위증 시 처벌을 받는다는 조건하에, 이 세금 양식의 정보 및 진술이 변경되지 않았으며, 아래에 명시된 경우를 제외하고 정보를 입력한 연도부터 현재까지 해당 정보가 진실되고 정확하며 완전하다는 것을 확인합니다." 선택

  • "내 서명" → "예. 세금 ID 섹션에 기재된 수익권자입니다." 선택

  • "제출" 클릭

• 문서 누락

  • 이름 증빙 서류(운전면허증, 여권, 압세자 증명서, 기타 정부 발급 신분증, 합당한 서면 설명)를 업로드

  • "문서 제출" 클릭

• 최종 승인까지는 대략 1~2일이 소요 된다고 합니다.

3. 마무리

• 애드센스 수익을 온전히 받기 위해서는 세금 정보 등록은 필수 절차입니다.

• 이 글을 보고 따라하신다면 누구나 10분 안에 등록할 수 있어요.

• 수익을 지키는 첫걸음, 꼭 등록하세요!

🤖 AI 영상 모델 비교: OpenAI Sora 2 vs. Google Veo 3.1

구글이 OpenAI의 Sora 2를 의식하여 Veo 3.1을 불과 5개월 만에 출시했습니다. 현존하는 가장 최신 플래그십 모델인 Sora 2와 Veo 3.1을 공정한 프롬프트를 사용하여 영상 품질, 물리 현상 구현, 사운드, 컨트롤 기능, 일관성, 그리고 가격 측면에서 상세하게 비교 정리했습니다.

1. 🎬 영상 구현 및 품질 비교

2. 🎤 사운드 구현 및 복합 기능 비교

3. 🎯 영상 컨트롤 및 프롬프트 이해도

4. 👤 일관성 및 인물 처리

5. 💰 가격 비교 (자체 플랫폼 기준)

🌟 최종 요약 및 용도 제안

1) 5년 전망: “절반이 사라진다”보다 중요한 것

• 초급·반복적 지식노동의 자동화는 현실화된다. 채팅·요약·초안 작성·리서치·QA 같은 업무가 먼저 바뀐다.

• 동시에, 극소수 인원(심지어 1인)으로도 예전 ‘수백 명 팀’이 하던 제품을 만들 수 있는 환경이 형성된다.

• 22세 신입보다 재교육을 회피하는 50~60대가 더 타격을 받을 가능성이 크다. 젊은 층일수록 전환 속도가 강점.

핵심 시나리오

• 팀 구조: 대규모 주니어 채용 → 소수 핵심 인력 + AI 워크플로.

• 커리어 경로: ‘부서별 말단’ → 작게 만들고 크게 배포하는 빌더/창업자.

2) 왜 지금이 “1인 빌더”의 황금기인가

• 최신 모델·툴 체인은 텍스트/이미지/음성/코드 전 영역을 커버한다.

• 인프라·오토메이션 덕분에 기획→디자인→개발→마케팅이 짧은 주기로 수렴한다.

• 결과적으로 소수 인원으로 Billion-scale 임팩트가 가능한 드문 시기.

3) AI를 가르는 네 축(Compute · Data · Algorithm · Product)

3-1. Compute(컴퓨트): 가장 큰 병목은 에너지

• 칩·메모리·네트워킹·랙·데이터센터 건설·허가·전력 수급까지 전 주기 대공사.

• 수요 급증 시 접속 제한/대기열 같은 서비스 병목이 반복될 수 있다.

• 중장기 해법: 더 많은 칩과 기가와트급 전력을 안정 조달, 생산·설치의 자동화.

3-2. Data(데이터): 합성·과제 생성·발견형 학습으로 이동

• 교과서 추가 학습의 한계가 보인다. 이제 모델은 데이터에 없는 것을 배우는 방향(가설→실험→업데이트).

• 사용자와 함께 더 어려운 태스크·환경을 생성해 모델을 단련하는 흐름이 중요해진다.

3-3. Algorithm(알고리즘): 추론 강화로 “작은 모델의 기적”

• 추론 능력 강화를 통해, 로컬·경량 모델도 고성능을 낼 수 있는 돌파구가 나타났다.

• 같은 컴퓨트로 더 똑똑하게, 더 싸게 돌리는 길이 열리며 보급 속도를 끌어올린다.

3-4. Product(제품화): 과학만으론 부족하다

• 사람 손에 쥐여 실제 문제를 푸는 제품으로 이어질 때 사회와 함께 진화한다.

• 모델보다 **경험 설계(온보딩·피드백·신뢰·과금)**가 성공/실패를 좌우한다.

4) 2030 신입을 위한 역량 지도

What > How

• 특정 툴 숙련도보다 문제정의·기획·평가지표 설계가 더 큰 레버리지.

• “이걸 어떻게 만들지”보다 “무엇을 만들어 누구의 어떤 문제를 어떻게 바꿀 것인지”.

추론·시스템 사고

• 프롬프트 한 번보다 체인·루프·도구 호출이 엮인 시스템 프롬프팅이 성과를 만든다.

• 데이터 수집→합성→평가→수정의 폐쇄 루프를 설계하는 감각이 필요.

제품 감각·윤리/거버넌스

• 과장·허상 대신 신뢰 가능한 동작 범위를 명확히 보여 주는 것.

• 프라이버시, 안전장치(정렬), 책임소통을 처음부터 제품요건으로 포함.

5) 6개월 액션 플랜(대학생·입문자 기준)

1주차 — 세팅

• 업무/학습 흐름을 적고, 가장 귀찮은 1단계를 AI로 치환.

• 매일 15분 실험 슬롯 확보(요약/코드/이미지/오디오 중 하루 하나).

2~4주차 — 시스템화

• 자주 쓰는 프롬프트를 모듈화하고, 나만의 미니 에이전트로 고정.

• 결과물은 반드시 내 말투·사례로 재작성(그대로 복붙 금지).

5~8주차 — 공개 프로젝트 2개

• 실제 사용자를 상정한 작은 제품 2개(예: 회의 도우미, 마이크로 자동화).

• 깃허브/노션/블로그에 문제–접근–평가–한계까지 정리.

9~12주차 — 성능 관리

• TOT(생각의 나무)나 체인 기반으로 3가지 접근 생성→A/B 테스트.

• “정확도·속도·비용” 3축 지표판 만들기.

13~24주차 — 확장·협업

• 동료 2~3명과 역할을 나누어 엔드투엔드 제품 한 번.

• 실사용자 20명 인터뷰/피드백 반영→버전 2 배포.

6) 채용·이직 관점: 포트폴리오는 이렇게 보인다

• “무엇을 바꿨나”에 초점: 이전/이후(비용, 시간, 품질) 수치화.

• 리스크 관리: 실패 사례·버그·한계와 그 조치(안전·프라이버시·거부 처리).

• 재현 가능성: 실행 스크립트/프롬프트·데이터 파이프라인 공개(가능한 범위에서).

7) 마음가짐: 도망치지 말고 작게 부딪히기

• 거대한 미래를 예측하는 대신, 작은 실험을 빠르게 반복하자.

• 완벽보다 일주일마다 눈에 보이는 개선을 내는 사람이 결국 앞선다.

끝으로

“절반이 대체된다”는 구호는 공포를 자극하지만, 커리어 전략은 공포가 아니라 설계와 실행이 만든다.

당신이 정의한 문제를, 당신만의 방식으로, 지금 당장 작은 규모로 풀어보자.

그 루프를 6개월만 돌리면—입직 경쟁력은 이미 다른 세계가 된다.

“모든 직업이 대체될까?”

예측은 계속 빗나가고, 결국 남는 건 ‘행동’입니다

한때는 판사·변호사 같은 전문직은 AI가 대체하기 어렵고, 단순 노동부터 치환될 거라 말했습니다. 하지만 지난 20년을 돌아보면 “대체된다/안 된다”는 목록은 몇 년 간격으로 뒤집혔고, 최근 것조차 금세 낡은 예측이 되곤 합니다. 결론은 단순합니다. 직업의 종류가 아니라 ‘일의 방식’이 바뀐다는 사실, 그리고 먼저 행동하는 사람이 기회를 선점한다는 사실입니다.

1) 예측은 틀리고 변화는 빨라진다

• 20년 전, 5년 전, 심지어 1년 전의 “대체 불가” 목록이 오늘 보면 뒤집혀 있습니다.

• 기술의 궤적을 정확히 그리는 건 점점 어려워졌고, 유일하게 확실한 건 변화의 속도뿐입니다.

2) 왜 ‘쓰는 사람’이 이긴다

대부분의 사람은 AI를 “한번 써보고 말아요.” 체감 이익이 즉시 오지 않으면 배움을 미룹니다. 그래서 활용자와 비활용자의 격차는 생각보다 빠르게 벌어집니다.

제가 대학 강의에서 “AI를 반드시 쓰라”고 해도 실제로는 끝까지 안 쓰는 학생이 많습니다. 이유는 단순합니다. 지금도 과제·시험을 ‘어떻게든’ 할 수 있으니까. 그러나 “어떻게든”의 생산성으로는, AI를 파고든 동료의 속도를 따라잡기 어렵습니다.

3) 하우(How)의 시대에서 왓(What)의 시대로

예전엔 포토샵을 “배워야” 디자인을 했습니다. 이제는 무엇(What)을 만들지 명확히 말하면 도구가 구현을 ‘대행’합니다.

이미지·음악·영상·카피라이팅까지, 도구의 숙련도보다 목표 정의와 방향 설정이 더 큰 가치가 되는 흐름입니다.

4) 예술과 ‘피지컬 AI’까지 진입한다

AI는 그림과 음악도 만듭니다. 여기에 로봇·인공근육 등 물리적 영역(피지컬 AI)이 결합되면, 무용·공연·서비스업 같은 ‘몸의 노동’까지 영향을 받습니다.

“그래도 인간의 고유 영역”이라는 믿음은 점점 도전받고 있습니다. 대체의 속도와 범위를 과소평가하지 않는 편이 안전합니다.

5) 정렬(Alignment)과 거부 문제

AI는 사회 규범을 어기는 요청(폭력·불법 등)을 차단하도록 설계됩니다. 이런 규범적 거부는 당연하고 필요합니다.

문제는 규범 외의 영역에서 발생하는 “모델의 자의적 거부”인데, 시장의 선택은 냉정합니다. 사용자가 성능 저하로 느끼는 거부는 도태를 부릅니다. 결국 품질·안전·책임의 균형을 맞춘 모델이 살아남게 됩니다.

6) AI는 인프라가 된다

전기·인터넷처럼 끊기면 사회가 멈추는 인프라가 됩니다. 공공 행정부터 교육·산업 전반으로 스며들 것입니다.

그때 가서 배우기엔 늦습니다. 지금의 시행착오가 자산입니다.

7) 도구는 이미 일상 속으로

• 회의 보조: 실시간 요약·질문 추천·액션 아이템 정리까지 자동화하는 회의 도구들이 폭넓게 쓰입니다.

• 콘텐츠 제작: 이미지·영상 생성·편집, 음성/나레이션, 배경 제거, 스타일 변환 등은 제작의 장벽을 낮춥니다.

• 개인화 음악/미디어: 기분·상황에 맞춘 음악·사운드를 즉석 생성해 쓰는 것도 흔해졌습니다.

핵심은 특정 서비스 이름이 아니라, **“업무 흐름에 어디를 AI로 치환할지”**를 설계하는 시각입니다.

8) 잘 쓰는 법: 질문을 ‘AI에게’ 설계시키라

“좋은 질문이 중요하다”는 말은 맞지만, 초보자에게는 어렵습니다. 방법은 간단합니다.

1. 막연한 목표를 먼저 적기: “이 주제로 3분 스피치를 하고 싶다.”

2. 질문 설계도 요청: “내 목표를 이루려면 무엇을 물어야 하나? 단계별로 프롬프트 목록을 만들어 줘.”

3. 그 프롬프트로 다시 질의: 각 단계 결과를 이어 붙여 작업 완성.

그리고 결과는 반드시 내 언어로 재작성하세요. 원문 그대로 붙이면 “AI 특유의 문체”가 남습니다. 내 용어·사례·감각으로 덮어씌우는 과정이 품질을 가릅니다.

9) 개인 워크플로를 ‘봇’으로 고정

반복 업무가 있다면 나만의 챗봇/에이전트를 만들어 프로세스를 고정하세요.

예: 유튜브 제작 → [주제 입력] → [제목 후보] → [썸네일 카피] → [대본 구조] → [스크립트] → [타임라인·CTA].

매번 새로 묻지 말고 템플릿화하면 속도와 일관성이 올라갑니다.

10) Tree of Thoughts(TOT): 생각의 가지를 늘리기

프롬프트 끝에 “여러 방법으로 생각해 줘”를 명시하면, AI가 해결 경로를 분기해 제시합니다.

정답이 하나인 문제도 접근법은 여러 개일 수 있습니다. 이때 TOT는 내가 못 본 조합을 보여주는 데 강합니다.

11) 창의성은 ‘연결’에서 온다

창의성은 서로 무관해 보이는 것들의 새로운 연결입니다.

매일 아무 두 단어를 뽑아 억지로 연결하는 훈련만으로도 발상이 열립니다. AI는 이 연결 놀이에 탁월합니다. 내 아이디어의 출발점을 AI에 위탁해 보세요. 이후의 선택과 편집은 사람의 몫입니다.

12) 기업가정신(Entrepreneurship), 지금 더 필요하다

앞으로의 세계는 더 복잡하고, 예측 불가능합니다. 막다른 길에서 돌아가는 사람과 뚫고 나가는 사람이 갈립니다.

기업가정신은 회피가 아니라 돌파의 기술입니다. 작게라도 실행하고, 짧게 검증하고, 빨리 전환하는 습관이 결국 자산이 됩니다.

13) “인간이 퇴화한다”는 걱정에 대하여

계산기가 생겨도 인간의 사고가 사라지지 않았듯, 기억의 외주는 생각의 파괴가 아닙니다.

전화번호를 외우지 않아도 우리는 더 많은 것을 배웁니다. AI는 사고의 여유 공간을 만들어 줄 뿐, 우리의 판단과 책임을 대신하지는 않습니다.

지금 시작할 수 있는 7가지 액션

1. 현재 업무 흐름을 적고, 가장 귀찮은 1단계를 AI로 치환해 본다.

2. 자주 쓰는 프롬프트를 문서로 모아 ‘나만의 봇’에 고정한다.

3. 매일 15분 실험 슬롯을 만든다(요약, 회의록, 이미지, 코드 중 하루 하나).

4. 결과물은 반드시 내 말투로 재편집한다.

5. TOT로 3가지 대안을 받아 비교 후 택1 한다.

6. 한 달에 한 번, 업무 전 과정의 자동화 비율을 점검한다.

7. 팀·학생·지인과 베스트 프랙티스를 공유해 집단 학습 속도를 올린다.

맺음말

“직업이 대체되느냐”는 질문은 점점 덜 중요해집니다. 중요한 건 내 일의 어떤 부분이 바뀌고 있는지, 그리고 내가 지금 무엇을 바꾸고 있는지입니다.

AI 시대는 하우가 아니라 왓을 선명히 말하고 실행하는 사람에게 유리합니다. 완벽한 계획보다 작은 실행이, 느린 학습보다 짧은 실험의 반복이 더 멀리 데려다 줍니다.

지금도 선택지는 두 개뿐입니다. 바뀌는 세계를 구경하느냐, 만드는 쪽에 서느냐.

정답은 늘 행동하는 쪽에 있습니다.

소규모 오피스 서버(Server) 구축 - Lenovo Thinkcentre M720q

리눅스(Linux): 운영체제의 “핵심(커널)” 이름. 윈도우/맥과 다른 계열.

우분투(Ubuntu): 리눅스를 바탕으로 만든 “배포판(Distribution)” 브랜드. (리눅스의 한 종류)

우분투 서버(Ubuntu Server): 우분투의 서버용 에디션(기본적으로 GUI 없이, 서버에 필요한 구성만).

그래서 정확히 쓰면:

“리눅스(계열) 중 하나인 우분투의 서버용 에디션(= Ubuntu Server 24.04 LTS)”

을 설치하자는 뜻이라서 “리눅스 우분투 서버”라고 줄여 부르는 거예요.

Desktop vs Server 차이는?

• 커널/명령어는 동일하고, 기본 제공 패키지와 기본 설정이 다를 뿐.

• Server: GUI 없음(가벼움), SSH/네트워크/서비스 운영에 최적. 24/7 서버에 딱.

• Desktop: GUI 있음(편리하지만 무거움), 개발/일상용에 편함.

당신 목적(Flask 24시간 운용, 저전력, 가성비)이면 Ubuntu Server 24.04 LTS가 정답.

정확한 이름/파일

• ISO 이름 예: ubuntu-24.04.1-live-server-amd64.iso

  (M720q 같은 x86-64 PC는 이걸 쓰면 됩니다)

0) M720q에 Ubuntu Server 24.04 LTS 설치를 처음부터 끝까지

준비물

• USB 메모리 8GB 이상 1개

• 모니터/키보드(설치 때만 필요)

• 유선 LAN 케이블(설치 중 네트워크 자동 설정에 유리)

1) 설치 USB 만들기 (Windows에서)

1. Ubuntu Server 24.04 LTS ISO 받기

   파일 이름 예: ubuntu-24.04.1-live-server-amd64.iso

2. Rufus 실행 → USB 선택 → ISO 선택 → 옵션은 기본값(UEFI) 그대로 → Start

   (BalenaEtcher를 써도 괜찮음: Etcher 실행 → ISO 선택 → USB 선택 → Flash)

팁: M720q는 UEFI 잘 지원합니다. 파티션 스킴 GPT, Target UEFI로 두면 OK.

2) M720q 부팅 설정

1. USB 꽂고 M720q 전원 ON

2. F12 연타 → Boot Menu에서 USB 선택 (부팅목록이 안보이면 BIOS에서 USB Boot 허용 필요)

   • BIOS 진입: F1 연타

   • 필요한 설정(있으면):

     • Startup → CSM/Legacy: 기본 UEFI 유지

     • Security → Secure Boot: 기본 그대로 사용해도 보통 설치 가능 (안되면 Off)

     • Virtualization: 나중에 Docker에 유리하니 Enabled 추천

     • Auto power on after power loss: 정전 후 자동 켜짐 원하면 Enabled

저장 후 재부팅 → F12 → USB로 부팅.

3) Ubuntu Server 설치 마법사

화면 지시에 따라 순서대로:

1. Language: Korean(또는 English)

2. Keyboard: Korean(101/104 자동 인식)

3. Network: 유선 LAN 꽂혀 있으면 DHCP로 자동 연결됨 (Wi-Fi는 나중에 해도 됨)

4. Proxy / Mirror: 비워두고 넘어가도 OK

5. Storage:

   • Use an entire disk 선택(단일 디스크 전체 사용)

   • 파일시스템: 기본 ext4 권장 (ZFS 필요 없으면 선택 X)

   • NVMe 250GB 하나면 그대로 진행

6. Profile setup: 서버 사용자 만들기

   • 이름, 서버명(hostname), 사용자ID, 비밀번호 설정 (기억해두기)

7. SSH: Install OpenSSH server 체크 (필수)

8. Featured Server Snaps: 아무것도 선택하지 말고 넘어가기

9. 설치 진행 → 완료 후 Reboot.

재부팅 직전에 설치 USB를 뽑아 주세요(계속 USB로 부팅되지 않도록).

SSH(Secure Shell) 는

“다른 컴퓨터(서버)에 안전하게 접속해서, 그 컴퓨터에서 직접 명령을 내려 쓸 수 있게 해 주는 통로”예요.

암호화돼서 도중에 엿보여도 내용이 안 풀립니다.

뭘 할 때 쓰나?

• 원격 서버에 로그인해서 폴더 만들고, 파일 복사하고, 프로그램 설치/실행

• Flask 서버 재시작, 로그 보기, 업데이트 등 전부 터미널로 처리

• 파일 전송(SCP/SFTP)도 SSH 위에서 안전하게 가능

어떻게 동작해?

• 서버 쪽: SSH 서버(sshd) 가 22번 포트에서 대기

• 내 PC: SSH 클라이언트로 접속

• 인증 방식: 비밀번호 또는 키(공개키/개인키) — 키 방식이 훨씬 안전

지금 바로 쓰는 방법 (당신 상황 기준)

1) 서버(우분투) 준비 확인

Ubuntu Server 설치할 때 OpenSSH server를 체크했다면 이미 켜져 있어요.

확인:

sudo systemctl status ssh

IP 주소 확인:

ip a   # 또는 서버 화면에 표시된 IP 확인

2) 접속(내 PC → 서버)

• Windows 10/11: PowerShell 열고

ssh <서버사용자>@<서버IP>
# 예: ssh ubuntu@192.168.0.50

• macOS/Linux: 터미널에서 위와 동일

처음 접속 시 “fingerprint 신뢰하겠냐” 묻는 건 정상 → yes.

비밀번호 대신 “키”로 접속(추천)

내 PC에서 키 만들기

ssh-keygen -t ed25519 -C "my-laptop"
# Enter, Enter, Enter로 넘어가면 ~/.ssh/id_ed25519 (개인키) / .pub(공개키) 생성

공개키를 서버에 등록

ssh-copy-id <서버사용자>@<서버IP>
# ssh-copy-id가 없으면:
# cat ~/.ssh/id_ed25519.pub 출력해서
# 서버의 ~/.ssh/authorized_keys 파일에 붙여넣기

이제부터는 비밀번호 없이:

ssh <서버사용자>@<서버IP>

안전하게 쓰는 습관

• 개인키(id_ed25519)는 절대 공유 금지 (백업만 안전하게)

• 서버 방화벽에서 SSH 허용:

sudo ufw allow OpenSSH
sudo ufw enable

• 나중에 외부에 열 때는 포트포워딩 최소화 또는 VPN/Cloudflare Tunnel 사용 권장

• 가능해지면 /etc/ssh/sshd_config에서 비밀번호 로그인 끄고(키만 허용) 보안 강화

초간단 치트시트

# 접속
ssh user@SERVER_IP

# 파일 보내기(로컬 -> 서버)
scp local.txt user@SERVER_IP:/home/user/

# 파일 가져오기(서버 -> 로컬)
scp user@SERVER_IP:/home/user/log.txt .

# 키 생성
ssh-keygen -t ed25519 -C "my-laptop"

# 키 등록(가능하면)
ssh-copy-id user@SERVER_IP

Flask 배포 순서

“기본 보안 + Flask 서비스”

1) 기본 업데이트 & 유틸

sudo apt update && sudo apt upgrade -y
sudo apt install -y git curl htop unzip ca-certificates
sudo timedatectl set-timezone Asia/Seoul

2) 방화벽(UFW) 설정

sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp      # Nginx(HTTP)
# HTTPS 쓸 거면 다음도:
# sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

3) SSH 보안(키 로그인 권장)

• 로컬PC에서 키가 없다면 생성:

  ssh-keygen -t ed25519 -C "my-laptop"
  
  

• 서버에 공개키 등록(가능하면):

  ssh-copy-id <서버사용자>@<서버IP>
  
  

• (선택, 보안강화) 비밀번호 로그인 끄기:

  sudo nano /etc/ssh/sshd_config
  # 아래처럼 변경/추가
  PasswordAuthentication no
  PermitRootLogin no
  
  

  sudo systemctl reload ssh
  
  

4) 고정 IP(선택) — 서버 안정운영에 좋음

ip a          # 유선 인터페이스명 확인(ex: enp0s31f6)
sudo nano /etc/netplan/*.yaml

예시:

network:
  version: 2
  ethernets:
    enp0s31f6:
      addresses: [192.168.0.50/24]
      routes:
        - to: default
          via: 192.168.0.1
      nameservers:
        addresses: [1.1.1.1,8.8.8.8]

적용:

sudo netplan apply

Flask 배포 (도커 없이 깔끔 루트)

5) Nginx + Python 가상환경

sudo apt install -y nginx python3-venv python3-pip

6) 코드 가져오기

GitHub에 올린 저장소를 클론(예: firstcontainer1):

cd ~
git clone https://github.com/<아이디>/firstcontainer1.git
cd firstcontainer1
python3 -m venv .venv
source .venv/bin/activate
# requirements.txt가 있으면:
pip install -r requirements.txt
# 없으면 최소:
pip install flask gunicorn

7) 앱 로컬 구동 테스트

gunicorn -w 2 -b 127.0.0.1:5000 app:app

• 다른 터미널/PC에서 http://<서버IP>:5000 접속해 확인(임시 테스트).

8) Nginx 리버스 프록시(80 → 5000)

sudo tee /etc/nginx/sites-available/flask <<'EOF'
server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}
EOF
sudo ln -s /etc/nginx/sites-available/flask /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

→ 이제 http://<서버IP>로 접속.

9) 부팅 자동 실행(systemd)

sudo tee /etc/systemd/system/flask.service <<'EOF'
[Unit]
Description=Flask via Gunicorn
After=network.target

[Service]
User=<서버사용자>
WorkingDirectory=/home/<서버사용자>/firstcontainer1
Environment="PATH=/home/<서버사용자>/firstcontainer1/.venv/bin"
ExecStart=/home/<서버사용자>/firstcontainer1/.venv/bin/gunicorn -w 2 -b 127.0.0.1:5000 app:app
Restart=always

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now flask
sudo systemctl status flask --no-pager

<서버사용자>를 실제 사용자명으로 바꿔 넣어줘(예: ubuntu).

(선택) HTTPS, 자동업데이트, 모니터링

10) HTTPS (도메인 있을 때)

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your.domain.com

11) 보안 업데이트 자동화

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

12) 모니터링/로그 보기

sudo apt install -y glances
glances   # 실시간 상태
journalctl -u flask -f   # Flask 서비스 로그 실시간

BIOS 전원 옵션(유용)

정전 후 자동 켜짐:

• 부팅 시 F1 → BIOS → Power 또는 After power loss → On

A) Git으로 옮기기 (인증 해결됐을 때 제일 깔끔)

구름IDE 터미널에서

cd /workspace/firstcontainer1     # 네 프로젝트 폴더
git add .
git commit -m "deploy"
git branch -M main
git push -u origin main           # (비번 대신 PAT 또는 SSH)

서버(우분투)에서

cd ~
git clone https://github.com/<너아이디>/firstcontainer1.git
cd firstcontainer1
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt   # 없으면: pip install flask gunicorn

퍼블릭 저장소면 바로 되고, 프라이빗이면 PAT/SSH 필요(앞서 안내한 대로).

B) SSH로 직접 복사(가장 빨리 됨) — 추천

방법 B-1. scp 한 방에 복사 (구름IDE → 서버)

구름IDE 터미널에서

# 폴더 통째로 복사
scp -r /workspace/firstcontainer1  <서버사용자>@<서버IP>:/home/<서버사용자>/
# 예: scp -r /workspace/firstcontainer1 ubuntu@192.168.0.50:/home/ubuntu/

포트가 22가 아니면 -P 2222처럼 추가.

방법 B-2. rsync로 빠르고 반복 배포

rsync -avz --delete /workspace/firstcontainer1/  <서버사용자>@<서버IP>:/home/<서버사용자>/firstcontainer1/
# 마지막 슬래시( / ) 중요: 내용물만 동기화

방법 B-3. ZIP으로 묶어서 전송

cd /workspace/firstcontainer1
zip -r app.zip .
scp app.zip <서버사용자>@<서버IP>:~/
ssh <서버사용자>@<서버IP> 'mkdir -p ~/firstcontainer1 && unzip -o ~/app.zip -d ~/firstcontainer1 && rm ~/app.zip'

C) SFTP(그래픽 툴)로 드래그&드롭

윈도우면 WinSCP / 맥이면 Cyberduck:

• 호스트: <서버IP>

• 프로토콜: SFTP

• 포트: 22

• 사용자/비밀번호: 서버 계정

• 접속 후 /home/<서버사용자>/firstcontainer1에 로컬 폴더 통째로 업로드

옮긴 뒤 “바로 실행” 체크리스트 (서버에서)

cd ~/firstcontainer1
python3 -m venv .venv
source .venv/bin/activate
# requirements.txt 있으면:
pip install -r requirements.txt
# 없으면 최소:
pip install flask gunicorn

# 임시 실행 테스트
gunicorn -w 2 -b 127.0.0.1:5000 app:app

브라우저에서 http://서버IP:5000 열어보고 보이면 OK.

Nginx 리버스 프록시(80 → 5000) — 아직 안 했다면

sudo apt install -y nginx
sudo tee /etc/nginx/sites-available/flask <<'EOF'
server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}
EOF
sudo ln -sf /etc/nginx/sites-available/flask /etc/nginx/sites-enabled/flask
sudo nginx -t && sudo systemctl reload nginx

→ 이제 http://서버IP 접속.

부팅 자동실행(systemd) — 아직 안 했다면

sudo tee /etc/systemd/system/flask.service <<'EOF'
[Unit]
Description=Flask via Gunicorn
After=network.target

[Service]
User=<서버사용자>
WorkingDirectory=/home/<서버사용자>/firstcontainer1
Environment="PATH=/home/<서버사용자>/firstcontainer1/.venv/bin"
ExecStart=/home/<서버사용자>/firstcontainer1/.venv/bin/gunicorn -w 2 -b 127.0.0.1:5000 app:app
Restart=always

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now flask
sudo systemctl status flask --no-pager

<서버사용자>를 실제 계정명으로 바꿔줘.

.env/비밀키 주의

• 퍼블릭 Git엔 .env, 비밀키 올리지 마!

• 이런 파일은 B 방식(scp/rsync/SFTP) 으로만 서버에 배포해서 ~/firstcontainer1/.env에 두고,

  Flask에서 python-dotenv로 읽거나 시스템d Environment=에 넣어.

0) 가상환경 들어가기 (공통)

cd ~/firstcontainer1
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt  # 없으면: pip install flask gunicorn

1) 파일이 APPLICATION.py이고, 안에 app = Flask(__name__) 가 있다면

(개발용, 바로 확인)

FLASK_APP=APPLICATION.py flask run --host=0.0.0.0 --port=5000

(운영용, Gunicorn)

gunicorn -w 2 -b 127.0.0.1:5000 APPLICATION:app

리눅스에서는 대소문자 구분합니다. 파일이 APPLICATION.py면 모듈 이름도 APPLICATION입니다.

(소문자로 application:app 쓰면 import 에러 납니다)

2) “앱 팩토리” 구조(예: def create_app(): return app)라면

(개발용)

FLASK_APP=APPLICATION.py FLASK_RUN_PORT=5000 flask run --host=0.0.0.0

(운영용)

gunicorn -w 2 -b 127.0.0.1:5000 "APPLICATION:create_app()"

3) wsgi.py가 따로 있고 그 안에 app이 있다면

gunicorn -w 2 -b 127.0.0.1:5000 wsgi:app

Nginx를 이미 붙여놨다면

위에서 하나를 띄운 뒤 브라우저에서:

• 개발용(직접): http://서버IP:5000

• 운영용(Nginx 프록시 통과): http://서버IP

  (프록시 설정을 내가 준 그대로 썼다면 80→5000으로 전달됩니다)

부팅 자동 실행(systemd)도 ExecStart만 맞추면 끝

(예: APPLICATION.py + app 전역일 때)

sudo tee /etc/systemd/system/flask.service <<'EOF'
[Unit]
Description=Flask via Gunicorn
After=network.target

[Service]
User=<서버사용자>
WorkingDirectory=/home/<서버사용자>/firstcontainer1
Environment="PATH=/home/<서버사용자>/firstcontainer1/.venv/bin"
ExecStart=/home/<서버사용자>/firstcontainer1/.venv/bin/gunicorn -w 2 -b 127.0.0.1:5000 APPLICATION:app
Restart=always

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now flask
sudo systemctl status flask --no-pager

앱 팩토리면 ExecStart= ... gunicorn ... "APPLICATION:create_app()" 로 바꿔주세요.

자주 나는 오류 체크

• ModuleNotFoundError: 대소문자/경로 틀림 → APPLICATION:app 철자 확인

• AttributeError: module ... has no attribute app: 팩토리 구조인지 확인 → create_app() 사용

• Address already in use: 이미 떠 있는 프로세스가 5000 사용 중 → pkill -f gunicorn 후 재실행

• 빈 페이지/502: journalctl -u flask -f 로 서비스 로그 확인

처음엔 집 와이파이/공유기 설정이 제일 헷갈립니다.

핵심은 “내 서버(우분투)까지 안정적 IP를 주고, 밖에서 안전하게 접속” 두 가지예요.

아래 3가지 루트 중 하나만 고르면 됩니다. (난 #2 또는 #3을 강력 추천)

0) 공통: 내부 IP를 고정(또는 예약)해두기

• 공유기 관리자 페이지 → DHCP 예약(고정 할당)에서 서버 MAC 주소에 예: 192.168.0.50 부여

  (또는 우분투에서 고정 IP 설정)

# 인터페이스명 확인 (enp0s31f6 등)
ip a
# netplan 편집
sudo nano /etc/netplan/*.yaml
# 예시
network:
  version: 2
  ethernets:
    enp0s31f6:
      addresses: [192.168.0.50/24]
      routes: [{ to: default, via: 192.168.0.1 }]
      nameservers: { addresses: [1.1.1.1,8.8.8.8] }
sudo netplan apply

• 우분투 방화벽:

sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
# HTTPS 쓸거면: sudo ufw allow 443/tcp
sudo ufw enable

1) (가장 단순) 내부에서만 쓰기 — 포트포워딩 불필요

• 집 안에서만 http://192.168.0.50 로 접속

• 외부 접속 필요 없으면 여기서 끝!

2) (안전·편리) Cloudflare Tunnel — 포트포워딩 없이 외부 접속

공유기·통신사 설정 복잡함을 회피하는 최적의 방법. CGNAT/이중 NAT도 통과됨.

1. 도메인이 Cloudflare에 있다면:

# 설치
curl -fsSL https://pkg.cloudflare.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloudflare.gpg
echo "deb [signed-by=/usr/share/keyrings/cloudflare.gpg] https://pkg.cloudflare.com/cloudflared $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install -y cloudflared

# 터널 생성/로그인
cloudflared tunnel login
cloudflared tunnel create myflask
cloudflared tunnel route dns myflask flask.my-domain.com

# 프록시(80→127.0.0.1:5000) 설정파일
sudo mkdir -p /etc/cloudflared
sudo tee /etc/cloudflared/config.yml <<'EOF'
tunnel: myflask
credentials-file: /home/ubuntu/.cloudflared/<생성된-credentials.json>
ingress:
  - hostname: flask.my-domain.com
    service: http://127.0.0.1:5000
  - service: http_status:404
EOF

# 서비스로 등록
sudo cloudflared service install
sudo systemctl enable --now cloudflared

• 이러면 포트포워딩 없이 https://flask.내도메인 으로 바로 접속됩니다.

• 22(SSH), 80/443 공유기 포트 여는 작업이 전혀 필요 없음.

3) (정석) 공유기 포트포워딩 — 80/443 외부로 열기

도메인+Let’s Encrypt 직접 쓰고 싶을 때.

1. 공유기에서 포트포워딩:

• 외부 80 → 내부 192.168.0.50:80

• 외부 443 → 내부 192.168.0.50:443

  (SSH 22는 외부 개방 금지 권장. 원격관리 필요하면 WireGuard VPN 사용)

2. 우분투에서 Nginx + 인증서:

sudo apt install -y nginx certbot python3-certbot-nginx
# Nginx 리버스프록시(80→5000) 이미 했다면 그대로 두고
sudo certbot --nginx -d flask.my-domain.com

3. 테스트는 LTE/5G(모바일 데이터)로 접속해보기(집 와이파이=내부라 착시 생김).

⚠️ ISP가 80/443 차단/CGNAT이면 포워딩이 안 될 수 있어요. 그땐 #2 Cloudflare Tunnel 선택이 편합니다.

보너스: WireGuard VPN(원격에서 내부망처럼)

외부에서 관리/SSH만 필요하면 VPN이 제일 안전.

sudo apt install -y wireguard
# docker로 linuxserver/wireguard 써도 편함

• 공유기에서 51820/UDP만 포워딩 → 외부에서 폰/노트북으로 VPN 접속 → 192.168.0.50 바로 접근.

자주 막히는 지점 체크리스트

• DHCP와 고정IP 충돌: 공유기에서 IP 예약으로 해결(가장 쉬움).

• 더블 NAT/CGNAT: #2 Cloudflare Tunnel로 우회.

• NAT Loopback 미지원: 집 와이파이에선 도메인이 안 열릴 수 있음 → LTE로 테스트.

• 방화벽: UFW/보안 솔루션에서 80/443, 51820(UDP) 허용 확인.

• 도메인 DNS 전파: A/AAAA 레코드 수정 후 수 분~수십 분 지연 가능.

추천 선택 요약

• 가장 쉬움/빠름: #2 Cloudflare Tunnel

• 전통적 직접 서비스: #3 포트포워딩 + Certbot

• 관리 전용(보안↑): WireGuard VPN + 내부만 공개

 [방수의 원칙]

가. 방수는 기본적으로 구조체 표면에 하는 것이 원칙이다. 

이 것은 내외부 방수를 가리지 않는 대원칙이다.

다만 온도의 영향으로 부터 비교적 자유로운 실내는 구조체를 대신 할 수 있는 강도를 가지는 구성재에 할 수도 있다. 예를 들어 바닥 난방을 위한 방통몰탈 위에는 방수를 할 수 있는데, 이 부분은 본문에서 좀 더 자세히 다룬다.

나. 방수 물매가 최소 1/100 이상 또는 증발 가능한 상태 형성

방수 제품 중에는 '담수가능 제품(물이 표면에 고이거나 담겨도 그 성능을 지속하게 유지하는 제품)'이 따로 있을 정도로, 물이 고여 있다면 방수에는 치명적일 수 있다.

예를 들어 수영장 방수에 우레탄계열의 제품이 사용되지 않는 이유는 높은 압력이 걸리는 수영장의 물이 우레탄이 지속적으로 접속해 있다면, 가수분해 현상 (이른바 표면이 녹는 현상)이 생기면서 종래는 방수가 훼손되기 때문이다.

우레탄의 형성

R-NCO                 +  R’-OH → R-NH-CO-O-R’

폴리이소시아네이트 + 폴리올 → 폴리우레탄 

폴리우레탄의 가수분해

R-NH-CO-O-R’ + H2O → R-NH2 + R’-OH + CO2

폴리우레탄      + 물    → 아민    + 알콜   + 이산화탄소

이 때, 고온수 또는 산성, 알칼리성의 물은 가수분해를 촉진 시킨다.

이런 이유로 상시 물에 잠겨 있는 수영장, 수조 등에는 우레탄방수 또는 수지계방수가 아닌 별도의 전용 제품을 사용해야 한다.

<출처 : Sika Korea 홈페이지>

옥상이나 화장실 등에 사용되는 방수제품에서 이런 현상이 목격되지 않는 이유는.. 수영장 처럼 거의 영구적으로 물에 잠겨 있는 것이 아니라, 잠시만 고여 있다가 그 물이 쉽게 증발할 수 있기 때문이다.

또한 물이 고여 있다면 언젠가는 그 물에 의한 오염이나 곰팡이 생성이 쉽기 때문에 모든 방수에는 많은 물이 고이지 않도록 표면의 물매가 잡혀야 한다.

혹은 일시적으로 고여 있더라도 증발할 수 있는 환경을 만들어 주는 것이 좋다.

우리나라 표준시방서에도 

비노출방수 : 1~2% 물매

노출방수    : 2~5% 물매를 요구하고 있다.

다. 모서리 보강

모든 방수 부위에서 가장 취약한 부분은 모서리에 있다.

모서리는 수평/수직의 벽이 각각 자기 길이 방향으로 수축/팽창을 하면서 모서리의 움직임이 상대적으로 더 크기 때문에, 이 인장응력으로 부터 방수층이 견디기 위한 보강이라고 보면 된다.

화장실 방수를 할 때 아래와 같이.. 바닥은 액체방수, 바닥모서리와 배관의 접속부는 고무계아스팔트방수를 하는 광경을 흔히 목격하게 되는데...

이 것도 일종의 모서리 보강의 원리를 따른 것이다. 물론 이대로 하면 안되지만...

이렇게 하는 근본적인 이유는..

고무계아스팔트 방수 표면에는 타일 본드의 접착이 어렵기 때문에 (일부 모래를 뿌려서 접착력을 높이려고 노력을 하는 분들도 있긴 하나...) 타일 본드가 붙지 않아도 된다고 생각하는 모서리 부분에만 이런 제품을 바르려는 경향으로 출발을 한 것이다.

(아래 사진에서 가장 치명적 실수는 배관 표면의 시멘트몰탈을 완전히 제거하지 않고 방수액을 발랐다는 것이다. 이 몰탈을 통해 물을 흡수하고, 그 물은 종래에 도막방수층을 훼손시키고, 결국 배관 주변의 누수를 유발한다.)

실내 방수는 아래와 같은 '방수부직포'라는 것을 이용해서 보강이 가능하다.

혹은 아래와 같이 탄성을 가진 제품도 있다.

<출처 : https://jabjaje.com/goods/goods_view.php?goodsNo=1000000643>

모서리에 부직포 보강을 하는 요령은 아래와 같다.

이 것만 보더라도 골조 품질이 작업 결과에 큰 영향을 미칠 수 있다는 것을 알 수 있다.

이 원칙만 지키면 큰 무리가 없는 것이 실내 방수이다.

화장실도 다르지 않다.

[우리나라의 문제점] 

가. 골조 품질

우리나라의 골조 품질은 거의 유사한 경제 수준을 가지고 있는 국가들과 비교하여 거의 절망적 수준이다.

이는 실내도 마찬가지로 봐야 한다.

심지어 최근에는 아파트도 수직/수평이 맞지 않는다는 하자 사례가 빈번히 보고되고 있다.

화장실은 신축도 문제지만, 리모델링 시 기존 타일을 거칠게 철거를 하고 드러난 구조체 표면에 아무런 조치를 하지 않고 바로 방수 작업에 들어 가는데, 이는 머지 않아 다시 철거를 유도하고 있는 셈이다.

그러므로 이 골조 품질은 아무리 강조를 해도 지나침이 없다. 방수 역시 골조품질이 되어야 그 위에 바로 설 수 있다.

나. 너무 급함

이는 자본주의 사회에서 당연한 수순이기는 하나, 공동체 생활을 하는 아파트가 주거의 대부분을 차지하고 있고, 이사갈 집과 이사한 집 들끼리 서로 서로 날짜가 맞물리면서.. 1,2주 안에 거의 모든 것을 마무리 해야 한다는 강박관념과, 싸게 싸게 해야 살아남는 다는 시장 분위기, 무조건 최저가를 선택하려는 소비 심리, 표면만 이쁘면 된다라는 사회 분위기가 절묘한 조화를 이루면서... 

공사 후 눈에 보이지 않는 방수 작업은.. 그저 지나가는 절차일 뿐이며, 최대한 빨리 끝내야 다음 공정에 들어가기 때문에...

빨리 말라야 하고, 마르지 않더라도 마른 것 처럼 하고 마감을 하려는 행위가 반복되고, 그렇게 해야 일 잘한다는 소문이 나고, 어차피 2년 지나면 쌩까도 되는 분위기이고.... 

화장실 방수 공사를 타일까지 이틀 안에 끝내려는 분들이 있고, 그렇게 하는 회사 만을 찾는 소비자가 있다. 심지어 하루에 방수, 타일, 위생기구 시공까지 모두 끝내고 철수를 하는 분들도 있다.

그러나 화장실 공사는, 신축 또는 전면 철거 후 재시공일 경우 아무리 빨라도 5일이 걸린다. 이게 정상이다.

다. 액체방수에 대한 지나친 믿음

액체 방수란, 시멘트에 방수액을 섞어서 몰탈을 만들고, 그 몰탈로 방수층을 형성하는 방법이다.

이 방식은 방수제품에 탄성이라는 개념이 없던, 70년에 만들어진 방수 방법이고, 지금은 유효하지 않다. 방수는 기본적으로 최소한의 탄성이 있어야 한다.

물론 '콘크리트 바닥은 움직일 수가 없다. 그러므로 액체방수가 탄성이 없더라도 충분한 방수의 역할을 할 수 있다'라는 주장이 틀린 말은 아니다.

일견 움직이지 않아 보이기 때문이다.

그러나 이 '움직임'에는 구조체가 흔들리는 지진 같은 것이 아니더라도, 외부에 무거운 산업용 차량이 지나간다던가, 바람이 매우 세차게 분다던가 하면서 생기는 '진동'도 포함된다. 탄성이 전혀 없는 액체방수는 아주 미세한 진동에도 균열이 생기게 되고, 물은 이 미세한 균열을 통해서 충분히 누수가 될 수 있다.

'내가 액체방수만 했는데 누수가 된 적이 없다'라는 분도 계신다. 그 분은 운이 좋았던 것이고, 액체방수는 이미 균열이 있지만 누수가 되지 않은 이유는, 콘크리트에 균열이 없기 때문일 뿐이다.

80~90년대초까지의 구조체는 꽤 정성스럽게 타설을 했기 때문에 균열이 거의 생기지 않을 수 있었다.

또한 바닥에서 돌출된 배관은 콘크리트가 아닌 PVC 이기 때문에, 이질재가 접하고 있는 모서리는 배수 등으로 인한 움직임이 상시 있다고 봐야 하기 때문에.. 액체방수는 소용이 없다. 그러므로 이제는 건축분야와 액체방수는 헤어질 때가 지나도 한참 지났다.

그리고 자재비가 싼 것도 선택의 한 이유이기도 한데, 이제는 인건비를 고려할 때 액체방수를 선택해서 몇 푼 아껴봐야 부끄러운 수준일 뿐이다. 

라. 줄눈이 방수가 된다라는 오해

화장실에 누수가 생기면, 타일 줄눈에 실리콘을 바르고 방수가 될 거라는 희망을 가진 분들이 의외로 많다. 물론 수년 째 작업하시는 분들은 그게 안된다는 것을 스스로 너무나 잘 알고 있다. 계속 연락이 오고 있기 때문이다.

그러나 그 분들이 스스로 '된다'라고 세뇌를 하는 이유는.. 그 것 보다 더 싸면서, 일시적으로 소비자를 안심(?) 시킬 방법이 없기 때문이다.

우리는 모두 하루만 살면 되기에 그렇다...

심지어 줄눈에 침투성방수제를 넣는 분들도 있다. 물론 돈도 받는다.

건물의 외장재가 방수층이 아니듯이 타일면은 방수층이 아니다. 그러므로 화장실 바닥을 통해서 누수가 생기면 줄눈이 깨진 탓이 아니라, 타일 하부의 방수층이 깨졌다는 의미이기에 타일을 들어 내고 방수 작업부터 다시 해야 한다.

물론 큰 돈이 들어간다. 이 돈은 위에서 언급한... 처음 할 때 제대로 하지 않은 탓에, 후세대가 계속 그 비용을 지불해야 하는 그 돈이다.

그러므로 화장실 당 공사비가 300만원 이하여야 한다라고 알고 있는 분들과, 5일 이상의 공사 기간을 참을 수 없는 분들은 아래 내용을 더 볼 필요는 없다.

[화장실 바닥 누수의 원인 접근]

화장실에서 누수가 생겼다면 크게 네 가지에 기인한다.

가. 바닥 배수관과 콘크리트 사이에서의 누수

맨 위의 그림에서 처럼 배수관의 표면에 바닥 방수를 끌어 올려서 발라주는 것이 일반적인 상황인데..

배수관은 물이 내려가면서 사소한 진동이 계속 있기 때문에, 이 도막방수의 두께가 너무 얇거나 모서리 보강이 없거나, 시멘트가 묻어 있는 표면에 그대로 발랐거나 한다면, 배수관과의 틈새를 통해 누수가 된다.

이 경우 아파트라면 아랫집의 화장실 천장을 볼 때, 아래 사진처럼 배수관과 콘크리트 사이에서 물이 떨어지는 것을 볼 수 있다.

그러므로 배수관과 바닥이 만나는 모서리는 우레탄실리콘을 살짝 (너비 10mm) 바른 후에 도막방수를 발라 주는 것이 원칙이다. 배수관의 모서리는 방수부직포 등을 이용해서 보강을 해 줄 수 없기 때문이다.

그러므로 아랫집의 배관 주변으로의 누수는 일단 바닥 전체를 다 철거하지 말고, 드레인을 들어 내고, 배수관 주변의 타일과 몰탈만 제거를 한 후에, 부분적 공사를 하는 것 만으로도 (최소한 줄눈 방수를 하는 것 보다) 훨씬 건전한 보수가 가능해 질 수 있다. 

나. 수도배관 이음매에서의 누수

수도꼭지를 설치하기 위한 밸브 등의 이음 부속을 통한 누수가 있다.

이런 누수는 타일의 뒷면으로 흐르기 때문에, 화장실과 인접한 방 벽면에 누수의 흔적이 있을 수도 있다. 

이런 누수는 수도관에 대한 가스압력시 누수검사로 대개의 경우 다 찾을 수 있다.

혹은 수도계량기의 별침이 미세하게 돌아가는 것으로도 확인은 가능하나, 수도꼭지 중에서 어느 수도꼬지인지를 알 수는 없기에 누수 검사를 하긴 해야 한다.

다. 바닥과 벽이 만나는 모서리에서의 누수

건식구조에서는 이 부분의 하자가 매우 많으며, 콘크리트 구조에서는 흔하진 않지만, 위에 언급한 바닥과 벽이 만나는 모서리에 보강을 하지 않는 것이 우리나라 화장실 방수의 고질적 문제이기 때문에 이 부분을 통한 누수가 있을 수 있다.

이 부분은 화장실 바닥을 다 드러내야 보수가 가능하다. 

이 누수는 콘크리트 보다는 건식 구조 (목구조, 스틸)에서 주로 발생을 한다.  혹은 ALC와 같은 조적식 구조에서는 흔한 편이다.

이 것의 연장선에서...

새로 집을 사고 나서 기존 화장실을 리모델링을 할 때, 돈문제가 가장 크겠지만 기타 여러가지 이유로, 타일을 철거하고 방수 부터 다시 하는 경우는 매우 드물다. 대부분 이른바 덧방이라는 것을 선택하게 되는데...

문제는 기존 화장실의 상태가 아무 문제가 없다면 괜찮으나, 살다가 누수가 생기면 방수를 다시 해야 하는데.. 그 원인 파악을 하기는 지난한 과정이 필요하니.. 대부분 바닥타일만 걷어 내고, 방수를 다시 한다는 것이다.

이러면 벽면 하단에 방수턱 높이가 나오지 않고, 벽면 타일 뒤로 넘어간 물은 방수층의 뒷면으로 흐르기 때문에 결국 다시 누수로 이어질 수 밖에 없다.

그러므로 이런 경우에는 최소한 벽에서 맨 하단의 타일까지는 제거를 하고 바닥과 벽면까지 다 방수를 하고 다시 타일을 붙여야 한다. 정말 최소한 이정도는 해야 한다.

라. 드물게 바닥 타일 하부로 차오른 물이 방수턱을 넘어서 누수 (아래 이중배수와 관련)

위에 언급한 바와 같이.. 타일 표면은 방수층이 아니다. 아무리 줄눈을 정성스럽게 넣는다거나 에폭시 줄눈을 한다거나 그 할아버지 급의 줄눈 시공을 해도 역시 마찬가지다.

그러므로 줄눈 하부로는 언제든 물이 들어간다는 것을 전제로 두어야 한다.

타일면 하부는 이른바 사모래층이 있다.

이 층은 타일의 물매를 잡는 용도로 시공되는 것인데, 타일 하부로 들어간 물은 이 사모래 층에 고일 수 밖에 없는 것이 우리나라의 방수 방법이다.

이 물은 물을 사용하지 않을 때는 줄눈을 통해서 서서히 건조가 된다. 그러므로 이 속에서 물이 꽤 높게 차오를 때까지는 꽤 긴 시간이 필요한데, 십수년이 걸릴 수도 있다.

이 물의 높이가 방수턱을 넘어서 누수가 되기 전에... 

전조 증상으로는 난방 배관 주변의 틈새를 통한 수분의 증발로 인해 아래 처럼 문 하부 줄눈에서 미세하게 물이 새어 나오거나

방/거실 쪽의 화장실 앞 마루가 변색이 시작되고, 

화장실에서 아무리 청소를 열심히 해도 무언가 계속 꿉꿉한 냄새가 나는 것으로 간접확인을 할 수 있다. 

타일 하부로 내려간 물이 수년 동안 고여 있으면서 나는 냄새이기 때문이다.

특히 아래 사진처럼..

드레인 하부에 두껑과 배구관이 제대로 물려 있지 않으면서, 백시멘트가 깨져 있다면, 물을 사용할 때 마다 상당히 많은 물이 타일 하부로 들어갈 수 있는 조건을 만들어 준다.

이런 경우는 일단 백시멘트로 구멍을 충실히 메워 주는 조치를 해야 한다.

이 문제를 근본적으로 해결하기 위해서는 이중배수를 해야 한다.

그에 안되면, 젖어 있는 사모래를 다 들어내고, 새로 다 설치를 해야 하는데, 그 역시 물이 고이는 원인을 제거한 것은 아니기에, 역시 수년 후에 다시 동일한 문제가 재발 할 수 있다.

[방수 자재의 선정]

실내 방수재로 안정적 실력을 인정 받고 있는 제품군은 수지계도막방수(주로 아크릴계 도막방수)가 있다. 다른 좋은 방수 제품도 많으나, 수지계가 가지고 있는 가장 큰 장점 중에 하나는 건조 속도가 빠르다는 점이다.

방수를 하고, 날이 좋으면 4시간, 좋지 않아도 8시간 후에는 타일 작업에 들어갈 수 있을 정도의 건조가 가능하다.

수지계 방수는 지금까지 (가나다 순)

마페이 아쿠아디펜스

아덱스 WPM003

시카 씨카라스틱 220W

등이 있었으나, 2024년에 국내 쌍곰에서 동류인 제품이 출시되어 있다.

쌍곰 워터쉴드

즉 더 나은 제품도 있을 수 있으나, 후속 공정을 고려하면 딱히 다른 선택의 여지는 없다.

만약, 굳이 다른 것을 선택하고 싶다면 유일한 대안은 폴리머계 무기질탄성방수가 있다.

무기질방수의 가장 큰 단점은 탄성이 유기질에 비해 적다는 것 (약 절반 수준)이지만, 가장 큰 장점은 내부의 습기가 배출될 수 있다는 점이다.

그러므로 신축 건물에서 구조체 수분이 평형 함수율에 도달하지 못했거나, 누수가 있었던 화장실을 철거하고 다시 방수를 할 때, 습한 표면에도 방수를 할 수 있다.

또한 무기질이라서 타일 본드의 접착력도 매우 안정적이다. 

대표적인 폴리머계 무기질 탄성도막방수는 (가나다 순)

마페이 마페라스틱 70KS

시카 씨카라스틱 1K

등이 있다. 국내 쌍곰 제품도 있으나 신율 정보를 찾을 수 없어서 배제를 하였다.

정리하자면...

바탕 콘크리트 표면이 충분히 건조(함수율 5% 미만)가 되었다면 수지계 도막방수를 사용하고, 그렇지 않다면 콘크리트 함수율 8% 정도가 될 때까지만 건조를 시키고 폴리머계 무기질 방수를 선택할 수 있다.

[바탕면의 정리]

우리나라 시장에서 가장 어려운 것 중에 하나인데..

절망적인 골조품질을 보완하려는 그 어떤 시도도 없다는 점이다.

그로 인해 항상 타일은 떠발이로 시공이 되고, 탈락이 되어도 보수를 하려 오신 분들은 항상 전 시공자 탓만 한다. 잘못 붙였다고...

(참고로 떠발이 붙임을 할 때, 접착몰탈은 타일 면적의 80% 이상이어야 한다. 그러므로 위 사진에서 탈락의 여러 원인이 있겠지만, 일차적으로는 접착면적 부족이 원인이다.)

이 떠붙임 공법으로부터 벗어나는 것이 여러모로 좋기에, 그러기 위해서라도 바탕면의 수직/수평을 잡기 위한 작업이 되어야 한다.

그러나 이 것이 말처럼 쉬운 것은 아니다.

일단 몰탈 미장이 들어가는 순간 몰탈이 마를 때까지 방수작업을 할 수 없기에 48시간을 허송세월로 보내야 한기 때문이다.

그러므로 협회에서도 바탕면의 미장 작업을 강요하지는 않는다. 다만 그럼에도 불구하고, 울퉁불퉁하거나 곰보가 있거나 자갈이 드러나 있거나, 리모델링 시 철거한 표면의 이루말할 수 없이 지저분한 표면 정도는 갈아내거나, 깨내거나, 급결 몰탈로 발라 주거나 하는 정도의 작업은 꼭 해야 한다.

즉 아래와 같은 표면에 방수를 하는 것은.. 결국 누수가 재발되며, 지금의 돈을 나중에 들어오는 다음 집주인이 계속 나눠 내는 셈이며, 그 돈을 합하면 처음 잘하는데 들어간 비용의 몇배가 들어간다.

그 돈을 왜 내가 다 내야 해.... 라고 생각하는 분은, 역시 이 다음의 내용을 볼 필요는 없다. 

다만, 급결몰탈이라고 할지라도 48시간은 지나야 방수 작업이 가능하다. 

즉 철거+몰탈미장 후 최소 이틀은 그냥 말리는 시간이 필요하다. 그러므로 하루에 화장실 타일까지 끝내는 것이 얼마나 무모한 일인가를 이해해야 한다. 

[방수층의 위치 결정]

우선 방수층을 어디에 둘 것인가를 먼저 결정해야 한다.

위에 언급한 바와 같이 방수층은 구조체 표면에 하는 것이 원칙이고, 그 다음은 난방을 위한 난방 파이프를 매립하고 타설하는 방통몰탈 상부에 할 수 있다.

즉, 두가지 중에 어디에 할 것인가를 정해 두고 시공에 들어가야 한다.

위/아래 두번의 방수를 하는 경우도 있는데, 큰 의미는 없으며, 협회의 추천은 구조체 표면에 하는 것이다.

[화장실 바닥 높이 결정]

화장실 바닥의 높이를 거실과 맞추고 건식으로 사용할 것인가, 다운 시켜서 실리퍼가 걸리지 않게 할 것인가를 결정해야 한다. 그래야 화장실 바닥에 들어갈 수 있는 재료의 구성과 두께를 결정할 수 있다.

최근에는 거실과 높이를 맞추는 집들도 많아 지고는 있으나, 아직까지는 거실 보다 내려서 슬리퍼가 걸리지 않기를 원하는 분들이 많다.

그러나 맞추려는 비율이 해마다 높아지고 있는 것도 사실이다.

이 부분은 누가 맞다라기 보다는 사용자의 취향이고, 점점 고단열,고밀화되어 가고 있는 형편이기에, 예전 처럼 맨발로 타일 바닥에 들어간다고 하더라도 큰 불쾌감이 없기에, 건식 사용도 한번 쯤 깊이 고민해도 될 만 하다. 거실과 높이를 맞추면 나이가 많이 들어도 큰 불편함이 없다는 장점이 있기 때문이다.

높이를 거실과 같게 할 경우 샤워실을 제외한 화장실 바닥은 당연하게 물걸레 정도로만 청소를 해야 한다. 물론 물을 부어서 청소를 해도 되지만, 자칫 거실로 물이 넘어갈 수도 있다. 

즉 건식 화장실도 하부에 방수를 하는 것은 같다. 서양에서는 화장실 바닥 방수 자체를 하지 않는 경우도 있으나, 우리나라 생활 습관상 그건 쉽지 않다. 

[이중 배수 고려]

이 글의 핵심이기도 한데...

화장실은 이중배수가 필수적으로 요구된다.

화장실은 타일의 시공을 위해서 사모래라는 것으로 바탕면을 잡게 된다.

몰탈 미장으로 할 경우 바탕면의 강도를 낼 수는 있지만, 물매를 잡기가 매우 어렵게 되기에, 모래가 많이 섞인 푸석 푸석한 건몰탈을 만들어서, 쇠흙손으로 쉽게 걷어낼 수 있도록 만들어서, 한 쪽부터 쭉 붙이고 덜어내면서 원하는 물매를 만들어 내기 용이하기 때문이다.

이 사모래는 푸석 푸석하기에 이 표면에 도막방수를 할 수 없다. 그래서 방수를 먼저 하고, 사모래를 깐 다음 타일을 붙이게 되는데, 문제는 사모래는 흡수율이 매우 높고, 공극이 커서 그 사이에 많은 물을 담을 수 있다는 점이다.

줄눈은 방수재가 아니기에, 줄눈 사이로 미세한 물이 들어가게 되고, 타일 하부로 내려간 물이 방수층에 갇혀 고여 있게 되며, 영원히 어디로 갈 곳이 전혀 없다.

다행히 들어간 물의 양이 증발되는 물의 양에 비해 작다면 하자로 이어지지는 않게 된다. 그러나 세월이 흘러서 줄눈의 상태가 점 점 좋지 않게 되면 들어가는 물이 양이 증발되는 물의 양보다 많이 질 수 밖에 없게 되면서, 타일 하부는 점차 물이 차오르게 된다.

이 차오른 물은, 냄새를 유발하고, 줄눈 사이에 물이 나오기도 하고, 화장실 앞의 마루를 변색시키기도 하는데, 방수턱을 넘으면 누수로 이어지는 결과를 초래한다.

해외 정보를 보면, 이 사모래 층 위에 방수를 하는 것을 볼 수 있고, 이를 근거로 우리나라도 그렇게 하려는 분들이 가끔 있는데 우리나라에서는 불가능하다.

영어권에서 이 사모래를 Screed 라고 하고, 사모래 작업을 Screeding 또는 Bedding 이라고도 한다.

해외의 사모래 작업과 우리나라 사모래 작업이 가지는 근본적인 차이는... 우리나라 사모래 작업이 너무 오래된 방식을 고수하고 있다는 점이다.

즉, 기술 기준이 없던 시절의 방식을 50년이 넘는 시간 동안 별다른 변화없이 유지하고 있는데 반해, 해외는 시대 흐름에 따른 기술 기준의 변화를 지속적으로 반영해 왔다는 점에 차이가 있다.

일단 해외 사모래 작업은 대략 아래와 같이 진행된다. <출처: 아덱스 교육용 영상>

맨 처음 시멘트물을 뿌려서 접착력을 높여 주고, 처음 부터 적절한 배합비를 맞춘 몰탈을 만드는데, 우리나라보다 물의 비율이 더 높다. 즉 더 단단한 몰탈을 만들 수 있다.

이 영상은 면적이 작아서 한번 배합한 것으로 계속 작업을 하지만, 몰탈층이 두껍거나 넓으면 중간 중간 물을 뿌리고 수평자로 두드리면서 표면을 단단히 만들어 가며 작업을 하는 것이 특징이다.

이 정도의 표면이 나온다면 이 위에 도막방수를 하는 것이 가능해지며, 바로 타일이 붙기 때문에 별도의 이중배수는 고려하지 않아도 된다. 

반면 우리나라는 (드물지만 처음의 시멘트 물을 바르지 않는 분도 있고), 모래 위에 시멘트 푸대를 바로 해체하고 대강 배합을 하고 작업을 하는 분도 있고, 심지어 물이 거의 없는 마른 배합으로 물매를 대략 잡은 후에, 표면에 물을 뿌려서 표면만 굳게 하는 분도 꽤 많다.

이 분들이 다 잘못되었다는 의미는 아니다. 그저 오래 전에 사라졌어야할 과거의 방법일 뿐이다.

우리나라 식의 작업은 표면의 강도는 대강 나올 수 있겠지만, 내부까지 동일한 강도는 나오지 않는다. 또한 내부 공극도 많아질 수 밖에 없다. 그래서 사모래층 위에 방수를 직접하는 것은 불가능하다.

여기에 대한 논의는 아래 글에 있었다.

https://www.phiko.kr/bbs/board.php?bo_table=z4_01&wr_id=62616

그러므로 이중배수는 필요하다.

[이중 배수 방법]

- 신축시 

- 콘크리트 구조에서 2층 이상의 일반 층

콘크리트 구조에서 2층 이상의 이중배수는 아래와 같은 제품을 사용하면 바로 적용이 가능하다.

원래 아파트 시장에서 이중배수를 목적으로 개발된 제품이어서 개별 구매가 불가능하였으나, 잡자재를 통해서 낱개로 구입이 가능해 졌다.

https://jabjaje.com/goods/goods_view.php?goodsNo=1000000343 

슬라브 콘크리트 타설시 이 제품을 매립하면 쉽게 이중배수를 구현할 수 있다.

다만 기초와 같이 그 두께가 200mm 를 넘어가면, 이 제품의 고정이 어렵기 때문에 아래의 '배수구를 2개 이용하는 방법'으로 해야 한다.

- 신축의 기초슬라브에서의 이중배수와 건식구조, 그리고 리모델링 시의 이중배수

리모델링을 할 경우는 위와 같은 제품을 사용할 수 없다.

그러므로 다음과 같은 방법으로 해야 한다.

대개의 화장실 구성이 아래와 같다고 보면.. 바닥 배수구는 표시된 것과 같이 두개가 있다.

이 중에서 세면대 하부에 있는 배수구를 사용하지 않는 것이다. 즉 바닥 배수구는 샤워공간에 있는 배수구만 사용을 하는 셈이다.

이 사용하지 않게 되는 배수구의 배관을 방수층에 잘라서 그 배관을 통해 하부 물이 빠지도록 하는 것이다.

이를 그림으로 그리면 아래와 같은 개념이 된다.

이 때, 작업 중 몰탈 등의 이물질이 배수구로 들어가지 않도록, 배수구 위에는 스텐망과 부직포를 깔아 주어야 한다.

관련된 질문/답변 사례

https://www.phiko.kr/bbs/board.php?bo_table=z4_01&wr_id=70057 

번외의 이야기이지만, 이 처럼 방수층 높이에서 배수관을 잘라서 방수를 할 경우, 맨 위에 설명한 것 처럼, 배수관을 방수가 감아 올리는 식이 아닌, 배관 내부를 감싸는 식으로 방수가 되어야 한다.

치켜 올리는 것도 그렇지만, 내려 감는 것도 콘크리트와 PVC 배관 사이가 이질재의 접합부이기 때문에, 가장 취약한 부위일 수 밖에 없다.

그러므로 이 부분은 과하다 싶을 정도로 신경써서 방수를 해야 한다.

해외 시장은 이런 이질재의 접합부 처리를 위한 전용 드레인이 개발된지 오래 되었다.

그 것도 각 방수제품에 맞는 여러 제품이 존재를 한다.

이런 기초적인 제품 조차 없는 것이 우리나라 방수 시장이다.

그리고 불행히도 이런 제품을 직구해서 구매를 하는 것도 어렵다. 우리나라 PVC 배관과 규격이 맞지 않기 때문이다. 

- 리모델링시 배수구가 하나 밖에 없거나, 샤워가 아닌 욕조가 있을 경우

이 때는 하나의 배수구로 이중배수를 만드는 차선의 방법을 선택 해야 한다.

만약 바닥 배수구의 구경이 75A 라면 그 속에 65A 를 넣고, 만약 50A 라면 그 속에 40A 배관을 넣는 방식이다.

그래서 하수관의 지름 차이를 이용해서, 이중 배수를 하게 된다.

안쪽에 끼어 지는 배관은 작업 중 하부로 떨어지지 않도록, 아래를 사선으로 절단하여 맨 아래까지 밀어 내리고, 상단을 필요 높이에 맞게 절단을 하면 무리가 없다.  

여기에 대한 논의는 아래에 있었다.

https://www.phiko.kr/bbs/board.php?bo_table=z4_01&wr_id=66868 

[기타 화장실 방수 시공 관련 몇가지 사항]

가. 타일의 접착

- 접착의 원리

타일이 장기간 탈락하지 않고 붙어 있는 것은 이론적으로 바탕면 - 본드 - 타일로 이어지는 접합면에 접착을 방해하는 이물질이 없이 접착되는 것이 중요하다. 그래서 가장 우선되는 것이 바탕면의 청소라고 봐야 한다.

이 것이 현장의 상황에서 쉽지 않기에, 건축 기술은 크게 두가지 방향으로 발전을 해왔다.

하나는 프라이머의 개량, 또 다른 하나는 타일면과 바탕면 모두 접착몰탈을 바르는 방식이다.

그러나 프라이머도 돈이고, 타일면과 바탕면 모두 접착몰탈을 바르는 것도 돈인데.. 문제는 인건비가 계속 올라가면서 이 양쪽 모두 접착몰탈을 바르는 것을 생략하는 현장이 늘어나게 되면서 탈락의 문제가 발생을 하게 되었다.

이 문제를 프라이머로 해결될 수 있다고 보았는데, 결국 그게 해법이 아니라는 것이 과학적으로 규명이 된다.

즉, 바탕면 또는 타일면 어느 한쪽에만 접착몰탈을 바르면 탈락이 되는 이유는...

아래와 같이 압착을 할 때, 접착몰탈 속의 수분이 모세관현상으로 접착몰탈 표면으로 올라오는 현상과 내부의 공기가 빠져 나오면서 표면에 공기구멍 (에어포켓)이 생기기 때문이다. 즉 접착몰탈이 붙어야 하는데, 표면에 얇은 수막과 공기층이 형성되면서 접착력을 상실하게 된 결과이다.

이 부분은 타일 뒤면에만 바르든, 바탕면에만 바르든 같은 결과라고 봐야 한다.

즉 문제의 시작은... 타일면과 바탕면 모두 접착몰탈을 발라야 한다는 규정이 잘 지켜지지 않으면서 생긴 것이라고 볼 수 있다.

- 요철쇠흙손의 필요성

그래서 개발이 된 것이 요철쇠흙손(Notched Trowel) 이다.

이 것이 접착력을 높히는 원리는.. 표면에 요철이 있어서 타일을 압착할 때, 표면으로 올라오는 수분과 공기가 (요철 부위가 뭉게지면서) 다시 접착몰탈 속으로 스며들 수 있도록 고안된 것이다.

- 시방서

그래서 시방서에도 그냥 직각으로 눌러서 접착하지 말고, 좌우로 비틀면서 압착을 하라고 나와 있는 이유이기도 하다. 그래야 표면의 수막과 공기구멍이 제대로 뭉게질 수 있기 때문이다.

물론 이 요철을 타일 뒷면에서 낼 수 있다면 이론적으로 결과는 같다.

다만 그게

가. 속도가 느리고

나. 숙련도에 따라 타일의 전면에도 접착몰탈이 붙을 수 있고,

다. 깊은 골을 내기도 어렵고

라. 작은 타일은 작업 자체가 어렵다는 점도 있지만,

마. 결정적으로 접착몰탈의 손실이 커지게 된다.

이 모든 것이 비용이고 공사비와 연관이 있기에... 그래서 바탕면에 요철을 내는 것이 표준으로 굳어지게 되었다.

- 관련 규정

바탕면에 접착몰탈을 바르고, 여기에 요철쇠흙손으로 골을 내는 것이 올바른 방법이라고 정의된 규정은 대략 아래와 같다.

규정 마다 "표준"으로 정한 것이 있고, "권장"으로 표현된 것의 차이는 있음.

ANSI A108 (American National Standards Institute) - 권장

TCNA Handbook (Tile Council of North America) - 표준

ISO 13007 Ceramic tiles - Grouts and adhesives - 권장

CTEF (Ceramic Tile Education Foundation) - 표준

EN 12004-1 Adhesives for tiles - 표준

BS 5385 (British Standard for Wall and Floor Tiling) - 권장

- 뒷면바름

그럼에도 불구하고, 지금도 대형타일은 타일면에도 얇게 접착몰탈을 바르도록 권고하고 있다.

이를 영어권에서는 Back-Buttering 이라고 표현한다.

특히 난방을 하는 바닥 타일인 경우, 대형타일과 더불어 이 뒷면바름을 "매우 강하게" 권고 하고 있다.

또한 난방을 하는 바닥의 타일에는 탄성줄눈을 사용해야 한다.

- 요철쇠흙손 크기

참고로 타일 크기에 따른 요철쇠흙손의 골 크기 권장 사항은 아래와 같다.

작은 타일 (100 x 100mm 이하)

  홈 크기: 6mm x 6mm

  타입: V형 또는 U형

중형 타일 (200 x 200mm 이하)

  홈 크기: 6mm x 10mm 또는 6mm x 12mm

  타입: U형 또는 사각형

대형 타일 (200 x 200mm 이상) 또는 모든 외부타일

  홈 크기: 12mm x 12mm 또는 19mm x 19mm

  타입: 사각형 또는 U형

특대형 타일 (300 x 300mm 이상)

  홈 크기: 19mm x 19mm 또는 25mm x 25mm

  타입: 사각형 

- 절망적 골조 품질에서의 타일 접착

우리나라는 골조품질이 거의 절망적이기에....

위에 언급한 것과 같이 바탕면에 접착몰탈을 바르는 것이 더 좋지 않은 결과로 이어질 수 있다.

오차 범위의 허용치를 넘어가고 있는 현장이 전국의 거의 모든 현장이라고 봐도 무방한 우리나라의 현실에서 바탕면에 요철쇠흙손으로 면을 만들 경우 마감면의 평활도를 도저히 만들어 낼 수 없기에, 자칫 하다가는 일부분만 붙어 있고 뒤가 떠있는 타일이 될 수 있기 때문이다.

그래서 타일 뒷면에 몰탈을 두껍게 발라서 눌러 붙이는 방식이 유효할 수 있기도 하고, 어찌 보면 이런 밑도 끝도 없는 현실에서 타일작업하시는 분들이 그나마 건전한 방식을 고민한 결과라고 볼 수도 있다.

그래야 타일 뒷면에 최대한 몰탈의 두께를 확보해야 눌러 붙일 수도 있고, 평활도도 맞추면서 그나마 탈락으로 부터 안심할 수 있기 때문이다.

또한 거기에 더해서 계절별 온도/풍속 등에 따른 오픈타임의 조절을 현장에 계신 분들이 숙지를 하고 일을 할 수 있는 사회적 기반도 거의 없는 것이 현실인지라...

그러므로 이는 꼭 타일만의 문제도 아니다. 우리나라 현장은 근본적 해결은 도외시 하고 그 뒤의 모든 문제를 마감 공사하시는 분들께 전가를 하고 있는 시장이기에 그렇다.

그러므로 바탕면에 접착몰탈을 바르는 것이 올바른 방법이고, 정의된 규정이기