요즘 화제가 된 「독자 AI 파운데이션 모델 프로젝트 1차 발표회」라는 표현을 보면서, 개인적으로는 한 가지 생각이 계속 들었다.

사실 여기서 ‘독자’라는 단어만 빠져도 불필요한 논란은 상당 부분 줄어들지 않았을까 하는 점이다.

‘독자’라는 말은 사전적으로 보면 홀로 독(獨), 스스로 자(自)를 써서, 말 그대로 혼자서, 자체적으로라는 뉘앙스를 강하게 담고 있다. 그래서인지 ‘국내 독자 AI 파운데이션 모델’이라는 표현을 접하면, 많은 사람들이 자연스럽게 이런 질문을 하게 된다.

“그렇다면 오픈소스를 사용하지 않고, 완전히 자체 기술로 개발한 모델이라는 의미일까?”

물론 현실적으로 오늘날의 AI 개발에서 오픈소스를 전혀 활용하지 않는 것은 거의 불가능에 가깝다.

다만 그럼에도 불구하고 ‘독자’라는 단어가 들어가는 순간, 기대치와 해석의 기준은 훨씬 엄격해진다.

기술적 자립, 원천 기술의 비중, 외부 의존도 등에 대해 더 날카로운 시선이 따라붙을 수밖에 없다.

그래서 개인적으로는, 이번 발표에서 굳이 ‘독자’라는 표현을 전면에 내세우지 않았어도 충분히 의미와 성과를 설명할 수 있지 않았을까 하는 아쉬움이 남는다.

단어 하나가 만들어내는 기대와 오해의 간극이 생각보다 크다는 점을 다시 한번 느끼게 되는 지점이다.

결국 중요한 것은 명칭보다 실제 기술의 방향성과 투명한 설명일 것이다.

‘독자’라는 수식어가 아니더라도, 어떤 부분을 자체적으로 만들었고 어떤 부분에서 글로벌 생태계와 협력했는지를 솔직하게 보여주는 것이 오히려 더 건강한 논의를 만들지 않을까 싶다.

음... 독자 단어 없어도 논란이 있을려나...

제목

Apache LogFormat 포맷 옵션 핵심 정리

핵심 태그(옵션)

요청 기본

• %h 클라이언트 IP
• %a 실제 클라이언트 IP
• %u 인증 사용자
• %t 요청 시간
• %r 요청 라인
• %m HTTP 메서드
• %U URI
• %q 쿼리 문자열
• %H 프로토콜

응답

• %s, %>s HTTP 상태 코드
• %b, %B 응답 바이트

헤더

• %{User-Agent}i
• %{Referer}i
• %{X-Forwarded-For}i

성능

• %D 처리 시간(μs)
• %T 처리 시간(s)

서버/연결

• %v 가상호스트
• %p 포트
• %A 서버 IP

SSL

• %{SSL_PROTOCOL}x
• %{SSL_CIPHER}x

기타

• %% % 문자 출력
• env=VAR 조건부 로그

개인 포트폴리오, 서비스 소개, 이벤트 안내처럼 간단한 웹사이트(원페이지) 가 필요할 때 가장 많이 쓰이는 조합이 바로 GitHub Pages + Cloudflare 입니다.

이 글에서는 도메인 연결부터 실제 배포까지, 처음 해보는 사람도 따라 할 수 있도록 설정 방법을 정리해봅니다.

1. 전체 구조 한눈에 보기

구성은 아주 단순합니다.

• GitHub Pages : HTML/CSS/JS 파일을 호스팅
• Cloudflare : 도메인 관리 + HTTPS + CDN

흐름은 다음과 같습니다.

브라우저 → Cloudflare → GitHub Pages

2. GitHub 저장소 생성

1. GitHub에 로그인
2. 새 Repository 생성
   • Repository 이름: username.github.io
   • Public 선택

⚠️ 반드시 내 GitHub 아이디.github.io 형식이어야 기본 도메인이 정상 작동합니다.

3. 원페이지 파일 작성

저장소 루트에 index.html 파일을 생성합니다.

<!DOCTYPE html>
<html lang="ko">
<head>
  <meta charset="UTF-8" />
  <title>My One Page</title>
</head>
<body>
  <h1>Hello World</h1>
  <p>GitHub Pages + Cloudflare</p>
</body>
</html>

커밋 후 푸시하면 기본 준비는 끝입니다.

4. GitHub Pages 활성화

1. Repository → Settings
2. Pages 메뉴 이동
3. Source
   • Branch: main
   • Folder: / (root)
4. Save

잠시 후 아래와 같은 주소가 생성됩니다.

https://username.github.io

이 주소로 접속해서 페이지가 보이면 성공입니다.

5. Cloudflare에 도메인 추가

이제 개인 도메인을 연결해봅니다.

1. Cloudflare 가입 및 로그인
2. Add a site 클릭
3. 보유한 도메인 입력
4. 요금제는 Free 선택

Cloudflare가 기존 DNS를 스캔한 후 네임서버(NS)를 제공합니다.

6. 네임서버 변경

도메인을 구매한 사이트(가비아, 카페24 등)에서

• 기존 NS 삭제
• Cloudflare에서 제공한 NS 2개 등록

적용까지 최대 수십 분 정도 걸릴 수 있습니다.

7. DNS 레코드 설정

Cloudflare DNS 메뉴에서 레코드를 추가합니다.

기본 설정

프록시(주황 구름)를 켜야 Cloudflare의 HTTPS/CDN 기능을 사용할 수 있습니다.

8. GitHub Pages에 커스텀 도메인 설정

GitHub Repository → Settings → Pages

• Custom domain에 내 도메인 입력
• example.com
• Save 클릭

저장하면 저장소에 CNAME 파일이 자동 생성됩니다.

9. HTTPS 강제 적용

Cloudflare에서 다음 설정을 확인합니다.

• SSL/TLS → Overview
  • 모드: Full
• Edge Certificates
  • Always Use HTTPS: ON

이제 접속 시 자동으로 HTTPS가 적용됩니다.

10. 배포 확인

브라우저에서 도메인 접속

https://example.com

정상적으로 페이지가 뜨면 모든 설정이 완료되었습니다 🎉

11. 이런 분들께 추천

• 서버 관리 없이 간단한 웹페이지가 필요한 경우
• 포트폴리오 / 랜딩페이지 / 소개 페이지
• 비용 없이 HTTPS + CDN을 쓰고 싶은 경우

개발자 블로그 플랫폼을 고를 때 가장 많이 비교되는 서비스는 단연 Medium과 Velog다.
나 역시 두 플랫폼 모두 써봤고, 장단점도 잘 알고 있다.

그럼에도 불구하고 지금 내가 티스토리(Tistory)를 메인 블로그로 사용하는 이유는 분명하다.

HTML/CSS 커스터마이징의 자유도

이 글에서는 Medium, Velog의 특징을 간단히 정리하고, 왜 “완전한 커스터마이징”을 원한다면 티스토리가 더 잘 맞는지 정리해보려고 한다.

Medium — 글에만 집중하기 좋은 플랫폼

Medium은 “읽기 경험”에 모든 초점이 맞춰진 플랫폼이다.

Medium의 장점

• 깔끔하고 통일된 디자인
• 글 자체에 집중할 수 있는 레이아웃
• 시리즈/컬렉션 구성 쉬움
• 커버 이미지, 헤더 스타일 설정 가능
• 유료 플랜에서는 커스텀 도메인 연결 가능

Medium의 한계

• HTML / CSS 직접 수정 불가
• 레이아웃 구조 변경 불가능
• 외부 JS, 위젯 삽입 제한적

“블로그를 꾸미는 사람”이 아니라
“글을 쓰는 사람”에게 최적화된 플랫폼이다.

Velog — 개발자 친화적인 기술 블로그

Velog는 국내 개발자들에게 특히 인기 있는 플랫폼이다.

Velog의 장점

• Markdown 기반 글 작성
• 코드 블록, 테이블, 이미지 사용 편리
• 태그/카테고리 정리 쉬움
• 개발자 커뮤니티 유입 효과 큼

Velog Plus (유료)

• 커버 이미지
• 추가 레이아웃 옵션
• 후원/구독 기능

Velog의 한계

• 전체 테마 CSS 직접 수정 불가
• 레이아웃 구조는 플랫폼이 제공한 범위 내에서만 가능
• “내 블로그 느낌”을 만들기엔 한계 존재

기술 글을 빠르고 효율적으로 공유하기엔 최고,
하지만 디자인까지 완전히 컨트롤하긴 어렵다.

그래서 나는 티스토리를 선택했다

Medium, Velog가 “플랫폼”이라면 티스토리는 블로그 그 자체에 가깝다.

티스토리의 결정적인 장점

HTML / CSS 완전 자유

• 레이아웃 구조 직접 수정 가능
• 반응형 직접 구현
• 폰트, 컬러, 애니메이션 전부 커스텀 가능

JS 사용 가능

• 외부 라이브러리 사용
• 커스텀 위젯 삽입
• 다크모드 직접 구현 가능

커스텀 도메인 + SEO

• 개인 도메인 연결 쉬움
• 검색엔진 최적화(SEO) 직접 컨트롤 가능

“이건 그냥 블로그가 아니라
내가 만든 웹사이트다”
라는 느낌을 원한다면 티스토리가 맞다.

플랫폼 선택 기준 정리

Medium, Velog가 나쁘다는 이야기가 아니다.
둘 다 목적에 맞으면 최고의 선택이다.

다만 나에게 블로그는

• 글 저장소가 아니라
• 포트폴리오이자
• 실험 공간이고
• 하나의 웹 프로젝트다.

그래서 나는 오늘도 티스토리를 쓴다.

HTML, CSS를 마음껏 만지작거리면서.

처음에는 주식 방송의 채팅 분위기를 분석해서 대시보드를 만들어보자는 아이디어로 시작했습니다. 하지만 대시보드를 만들려면 우선 데이터(채팅 내용)가 필요했죠.

쉽게 가보려고 구글링을 시작했는데, 아무리 찾아도 제가 원하는 스크래핑 관련 글이 없는 겁니다.

'나보다 뛰어난 천재 개발자들이 널렸는데 왜 없을까?' 의아해하던 찰나, 이유를 알게 되었습니다.

유튜브는 공식 API를 제공하니까 굳이 스크래핑할 필요가 없었던 거죠. (머쓱...)

하지만 개발자의 미덕은 '삽질' 아니겠습니까?

API 대신 직접 맨땅에 헤딩하며 스크래퍼를 만들어보기로 했습니다. 막상 유튜브를 뚫고 나니 욕심이 생기더군요.

내친김에 숲(SOOP), 팬더TV, 치지직까지 시도해봤는데... 이게 다 뚫립니다.

코드는 깃허브에 올려두었지만, 당분간은 비공개(Private)로 소중히 간직할 예정입니다.

유튜브 셀레니움 버전

유튜브 API 버전

Antigravity 에이전트에서

Planning 모드, Fast 모드 그리고 Images · Mentions · Workflows의 역할 정리

AI 에이전트 프레임워크를 쓰다 보면 자주 마주치는 개념들이 있다.
planning vs fast, 그리고 images / mentions / workflows 같은 구성 요소들이다.
이름은 직관적인데, 막상 “그래서 언제 뭘 써야 하는데?”가 헷갈린다.

이 글에서는 Antigravity 같은 에이전트 프레임워크 기준으로
이 개념들이 각각 어떤 역할을 하고, 어떻게 연결되는지 정리해본다.

1. Planning 모드 vs Fast 모드

Fast 모드란?

빠르게 결정하고 바로 실행하는 모드다.

• 내부적인 계획 수립을 최소화
• 다음 액션을 즉시 선택
• 응답 속도 빠르고 비용(토큰/연산) 적음
• 단순하거나 반복적인 작업에 적합

적합한 상황

• 간단한 질의응답
• API 호출 1~2번으로 끝나는 작업
• 목표와 절차가 명확한 경우

“일단 해보고 보자” 타입

Planning 모드란?

전체 전략을 먼저 세운 뒤 움직이는 모드다.

• 목표를 여러 단계로 분해
• 멀티스텝 계획 수립
• 중간 결과에 따라 재계획(replan) 가능
• 느리지만 안정성과 성공률이 높음

적합한 상황

• 복잡한 문제 해결
• 여러 에이전트/툴을 순차적으로 써야 할 때
• 실패 비용이 큰 작업
• 장기 목표가 있는 태스크

“화이트보드부터 찾는 전략가”

핵심 차이 요약

기본은 Fast,
막히거나 중요하면 Planning으로 전환

2. Images · Mentions · Workflows는 왜 필요할까?

에이전트가 하나일 때는 체감이 덜하지만,
멀티모달 + 멀티에이전트가 되면 이 세 가지가 핵심이 된다.

Images — “눈을 달아주는 입력”

역할: 이미지 데이터를 에이전트의 컨텍스트로 제공

• 이미지, 스크린샷, 다이어그램 입력
• 텍스트 + 시각 정보 기반 추론 가능
• 다른 워크플로의 트리거로 사용되기도 함

예시

• UI 스크린샷 → UI 자동화 에이전트
• 차트 이미지 → 데이터 해석
• 설계도 → 작업 계획 수립

한 줄 요약
Images = 에이전트의 시각 정보

Mentions — “누가 이 일을 할지 지정”

역할: 특정 에이전트나 툴을 명시적으로 호출

• @agent_name 형태로 사용
• 책임 분리와 역할 명확화
• planning / fast 모드 강제 호출에도 사용

예시

• @planner → 계획 수립
• @image_analyzer → 이미지 분석
• @executor → 빠른 실행

한 줄 요약
Mentions = 호출과 역할 지정

Workflows — “전체 흐름을 설계”

역할: 에이전트들의 협업 순서와 규칙 정의

• 여러 단계를 파이프라인으로 구성
• 조건 분기, 반복, 실패 처리 포함
• 어떤 단계에서 planning / fast를 쓸지 결정

예시

• 입력 → 분석 → 실행 → 검증
• 실패 시 재시도 또는 다른 에이전트로 fallback
• 병렬 실행 후 결과 종합

한 줄 요약
Workflows = 일의 동선과 규칙

3. 세 가지를 한 문장으로 정리하면

Images는 재료,
Mentions는 누가 할지,
Workflows는 어떤 순서로 할지다.

4. 전체 흐름 예시

사용자 입력 + Image
   ↓
Workflow 시작
   ↓
@planner (planning 모드)
   ↓
@image_analyzer (이미지 해석)
   ↓
@executor (fast 모드 실행)
   ↓
결과 검증 → 종료 or 재계획

이 구조 덕분에 에이전트는

• 단순할 땐 빠르게
• 복잡할 땐 신중하게
  행동할 수 있다.

Antigravity 같은 에이전트 프레임워크의 핵심은 “생각하는 방식과 일하는 흐름을 분리해서 설계할 수 있다”는 점이다.

• Fast / Planning → 사고 방식 선택
• Images → 입력 확장
• Mentions → 책임 분리
• Workflows → 전체 구조 제어

이걸 이해하면, 에이전트가 단순한 챗봇이 아니라 작업 수행 시스템처럼 보이기 시작한다.

우분투에서 구글 크롬 하드웨어 가속 문제 해결하기 우분투를 사용하다 보면 구글 크롬이 갑자기 멈추거나, 화면이 깨지거나, 영상 재생이 이상해지는 경우를 종종 겪게 됩니다. 이런 문제의 원인 중 하나가 바로 하드웨어 가속입니다. 다행히 설정을 조금만 바꿔주면 비교적 간단하게 해결할 수 있습니다.

1. 터미널에서 하드웨어 가속을 끄고 크롬 실행하기 (임시 방법)

문제가 발생했을 때, 우선 크롬을 하드웨어 가속이 꺼진 상태로 한 번만 실행해볼 수 있습니다. 터미널을 열고 아래 명령어를 입력해 주세요.

google-chrome --disable-gpu

이렇게 실행하면 GPU(그래픽 카드)를 사용하지 않고 크롬이 실행됩니다.

말 그대로 이번 한 번만 적용되는 임시 방법이기 때문에, 크롬을 종료하면 다음 실행부터는 다시 원래 상태로 돌아갑니다.

갑작스러운 오류를 확인하거나, 설정을 변경하기 위해 크롬을 열어야 할 때 유용한 방법입니다.

2. 다음부터 정상적으로 사용하려면 (권장 설정)

매번 터미널에서 실행하는 것이 번거롭다면, 크롬 설정에서 하드웨어 가속을 아예 꺼두는 것이 좋습니다.

설정 방법은 다음과 같습니다.

1. 크롬 우측 상단의 ⋮ 메뉴 클릭
2. 설정으로 이동
3. 왼쪽 또는 하단에서 시스템 메뉴 선택
4. “가능한 경우 하드웨어 가속 사용” 항목의 체크를 해제
5. 크롬 재시작

이렇게 설정하면 다음부터는 별도의 명령어 없이도 안정적으로 크롬을 사용할 수 있습니다.

우분투 환경에서는 드라이버나 그래픽 카드 호환성 문제로 하드웨어 가속이 오히려 문제를 일으키는 경우가 많습니다.

크롬이 자주 멈추거나 이상 동작을 보인다면, 위 방법을 한 번쯤 꼭 시도해 보세요.

작은 설정 하나로 체감 성능과 안정성이 훨씬 좋아질 수도 있습니다.
우분투 생활, 조금 더 쾌적해지길 바랍니다.

오늘 코딩 좀 해보려고 Antigravity IDE를 켰는데, 시작하자마자 Antigravity server crashed unexpectedly 라는 오류 메시지와 함께 AI 기능이 먹통이 되는 현상을 겪었다. 재시작 버튼을 눌러도 무한 루프...

다행히 프로젝트 코드가 날아간 건 아니고, 로컬 언어 서버 설정이 꼬인 문제였다. 해결 방법을 정리해 둔다.

1. 증상

• IDE 하단에 Restoring AI features...가 뜨다가 실패함.
• "Antigravity server crashed unexpectedly. Please restart..." 메시지가 반복됨.
• AI 자동 완성이나 챗 기능이 전혀 동작하지 않음.

2. 원인

대부분 로컬 설정 파일(Config/Cache)의 손상이나 방화벽 차단 문제라고 한다. 업데이트 도중 설정이 꼬였거나, Windows의 경우 방화벽이 로컬 서버 프로세스(antigravity.exe)를 막아서 발생할 수 있다.

3. 해결 방법 (순서대로 시도)

방법 1: 소프트 리셋 (가장 간단)

UI가 완전히 멈춘 게 아니라면, 명령 팔레트에서 초기화가 가능하다.

1. Ctrl + Shift + P (Mac은 Cmd + Shift + P) 입력.
2. Antigravity: Reset onboarding 검색 후 실행.
3. 로그인 창이 다시 뜨면 재로그인.

방법 2: 설정 파일 강제 삭제 (확실한 방법)

나는 방법 1로 해결이 안 돼서 이 방법으로 해결했다. 설정 파일(캐시)을 싹 지우는 건데, 작성 중인 코드는 삭제되지 않으니 안심해도 됨. (단, 테마나 단축키 설정은 초기화된다.)

Mac 사용자 (터미널)

rm -rf ~/.antigravity
rm -rf ~/Library/Application\ Support/Antigravity
rm -rf ~/Library/Caches/com.google.antigravity

Windows 사용자 (PowerShell 관리자 모드)

Remove-Item -Path "$env:AppData\Antigravity" -Recurse -Force
Remove-Item -Path "$env:LocalAppData\Antigravity" -Recurse -Force

이거 입력하고 IDE 다시 켜니까 깔끔하게 실행됨. 🎉

방법 3: 방화벽 예외 처리 (Windows)

윈도우 사용자라면 방화벽이 범인일 수 있다.

• Windows 보안 > 방화벽 및 네트워크 보호 > 앱이 방화벽을 통해 통신하도록 허용
• 여기서 antigravity.exe를 찾아 개인/공용 체크박스를 둘 다 켜줘야 한다.

요약 & 배운 점

• Antigravity IDE가 뻗었을 때 당황하지 말고 캐시 폴더(~/.antigravity 등)를 날려보자.
• 역시 개발 도구는 가끔 밀어주고 다시 설정하는 맛(?)이 있다.
• 주의: 구형 CPU(2013년 이전)에서는 AES 명령어 미지원으로 아예 실행이 안 될 수도 있다고 함. (이건 하드웨어 교체 말고 답 없음)

해결 방법 1: 하드웨어 확인
grep -o aes /proc/cpuinfo 실행 아무 출력도 없으면 해당 하드웨어는 지원되지 않음.

해결 방법 2: 그래픽 드라이버 업데이트
sudo ubuntu-drivers autoinstall 실행 또는 NVIDIA / AMD 드라이버를 직접 설치.

해결 방법 3: GPU 가속 비활성화 다음 명령으로 실행:

antigravity --disable-gpu

grep -o aes /proc/cpuinfo 결과가 비어 있었고, 그래도 나머지 두 가지 방법을 시도해봤지만 여전히 같은 오류가 발생함.

에휴. 그냥 VS Code로 돌아가야겠네요.