왜 '아임웹 커스터마이징 = 외주'가 공식처럼 굳었나

아임웹은 2014년 출시된 국내 대표 노코드 웹사이트 빌더로, 2025년 기준 누적 사이트 100만 개, 고객사 거래액 7조 원, 등록된 아임웹 전문가만 4,000명이 넘습니다. 그만큼 널리 쓰이지만 실무자들이 꼽는 단점 1순위가 커스터마이징 한계입니다. CSS·JS를 자유롭게 건드리기 어려워 고급 디자인이나 복잡한 인터랙션 구현이 까다롭고, 워드프레스의 6만 개 넘는 플러그인 생태계와 비교하면 확장성이 떨어진다는 지적입니다. 그래서 대부분의 가이드가 "필요하면 전문가에게 별도 의뢰하라"로 끝맺습니다. 틀린 말은 아니지만, 이 결론은 '코드는 사람이 짜야 한다'는 2023년까지의 전제 위에 서 있습니다. 2026년에는 그 전제가 바뀌었습니다.

사실은 열려 있는 문 — 아임웹 코드위젯과 공통 코드 삽입

아임웹에는 원래부터 코드위젯이 있습니다. 페이지 안에 HTML을 직접 넣는 상자라고 생각하시면 됩니다. 그리고 사이트 전체에 공통으로 적용할 CSS·JavaScript는 관리자의 SEO·헤더설정 > 공통 코드 삽입에 넣습니다. 아임웹 공식 FAQ도 이 구조를 안내합니다.

정리하면 아임웹의 커스터마이징 문법은 이렇습니다. 눈에 보이는 구조(HTML)는 코드위젯에, 디자인(CSS)과 동작(JavaScript)은 공통 코드 삽입에. 이 구조만 이해하면 버튼 모양 바꾸기, 섹션 호버 효과, 플로팅 배너, 입력폼 디자인 조정 정도는 대행사 없이도 가능합니다. 남은 문제는 딱 하나였습니다 — 그 코드를 누가 짜느냐.

AI를 '코드 대필가'로 쓰는 실무 흐름

여기서 Claude 같은 생성형 AI가 들어옵니다. 코드를 못 짜도, 원하는 걸 한국어로 설명하면 AI가 코드위젯에 붙일 코드를 대신 써 줍니다. 실제로 쓰는 순서는 이렇습니다.

1. 원하는 걸 구체적으로 말합니다. "아임웹 코드위젯에 넣을 건데, 가로 3개 카드를 만들어줘. 모바일에선 세로로 쌓이게. 회색 테두리에 흰 배경, 마우스 올리면 살짝 떠오르게."

2. 아임웹 규칙을 알려줍니다. "HTML은 코드위젯에, CSS는 공통 코드 삽입에 나눠서 줘." 이 한마디로 아임웹 구조에 맞는 형태로 나옵니다.

3. 받은 코드를 두 군데에 나눠 붙입니다. HTML은 코드위젯에, CSS는 공통 코드 삽입에. 저장하고 미리보기로 확인합니다.

4. 마음에 안 들면 말로 고칩니다. "카드 간격 더 넓게", "테두리 연하게" — 화면 캡처를 같이 주면 AI가 어디를 고칠지 더 정확히 잡습니다. 핵심은 무작정 "커스터마이징 해줘"가 아니라, 코드위젯과 공통 코드라는 정해진 자리에 맞춰 코드를 나눠 달라고 지시하는 것입니다.

어디까지 직접 하고, 어디부터 전문가가 필요한가

과장하지 않기 위해 경계를 분명히 나눕니다.

AI + 코드위젯으로 직접 할 수 있는 것 — 버튼·카드·배지 같은 디자인 요소 커스텀, 마우스 호버나 스크롤 등장 같은 가벼운 인터랙션, 플로팅 배너·인트로 화면·공지 바, 입력폼 디자인 조정처럼 눈에 보이는 연출 영역.

여전히 전문가가 필요하거나 신중해야 하는 것 — 아임웹 결제·주문·회원 등 핵심 시스템 로직을 건드리는 작업, 외부 서버 연동, 사이트 전체 성능·SEO에 영향을 주는 무거운 스크립트, "미리보기에선 되는데 실제 결제·모바일에서 깨지는" 케이스의 원인 진단. 정리하면 보이는 부분은 AI로 직접, 돈과 데이터가 걸린 부분은 전문가와가 현실적인 경계선입니다. 이 경계를 아는 것만으로도 외주 견적을 낭비 없이 쓸 수 있습니다.

아임웹이 커스터마이징에 제한이 있는 건 사실이지만, 코드위젯과 공통 코드 삽입이라는 문은 원래 열려 있었습니다. 2026년에는 코드를 못 짜도 AI에게 한국어로 설명해 코드위젯용 코드를 받는 방식으로 비개발자가 직접 상당 부분을 처리할 수 있습니다. 단, 디자인·연출은 직접, 결제·데이터·핵심 로직은 전문가와 나누는 경계는 지켜야 안전합니다.

누끼토끼는 노코드 빌더와 생성형 AI를 함께 쓰는 1인 웹 제작 실무를 칼럼과 강의로 나누고 있습니다. 오늘 정리한 코드위젯 + AI 흐름도 실제 클라이언트 작업에서 매일 쓰는 방식입니다.