개발자 블로그 플랫폼을 고를 때 가장 많이 비교되는 서비스는 단연 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를 마음껏 만지작거리면서.

원본 소스코드는 보유하고 있지 않고, 상세한 이력 또한 확인이 어려운 상태였다.
.live 서비스 종료 이후 복구 요청이 접수되어, 가능한 범위 내에서 최대한 복구를 진행했으며,
이를 기반으로 디자인 리뉴얼을 진행하였다

https://sip48.taecheonin.com

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

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

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

유튜브는 공식 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로 돌아가야겠네요.

'태천인', 개인 사업자에서 소프트웨어 셀러로의 도약

AI를 공부하며 익힌 Python, 그리고 실무를 통해 알게 된 PHP와 워드프레스. 이 기술들이 제게 새로운 가능성을 열어주었습니다.

낮에는 직장인으로서 커리어를 쌓고, 밤에는 '태천인'이라는 이름으로 저만의 소프트웨어를 판매하는 'N잡러'의 길을 걷고자 합니다.

거창한 투자보다는 내실 있는 시작을 위해, 이미 보유한 개인 사업자를 활용하여 소프트웨어 판매 쇼핑몰을 구축할 계획입니다.

초기 고정 비용은 도메인 비용 정도로 최소화하고, 제가 가진 기술력만으로 어디까지 갈 수 있을지 도전해보려 합니다.

https://taecheonin.com/

우리는 흔히 대한민국을 민주주의 국가라고 말한다.

정치에서는 1인 1표, 사회 전반에서도 평등과 참여가 중요한 가치로 여겨진다.

그런데 이상하게도, 대부분의 성인이 하루 중 가장 많은 시간을 보내는 ‘직장’ 안에서는 민주주의가 멈춰 있다.

기업의 담장 안에서는 여전히 1인 1표가 아니라 1원 1표, 즉 자본이 모든 의사결정을 좌우한다.

이 질문에서 출발한 제도가 바로 노동이사제다.

서울시가 던진 꽤 과감한 질문

서울시는 공기업을 중심으로 노동이사제 도입이라는 실험을 시작했다.

노동자가 단순히 지시를 따르는 존재가 아니라, 이사회에 참여해 기업의 주요 의사결정에 목소리를 내는 구조를 만들겠다는 시도다.

이건 단순한 인사 제도 변화가 아니다.

민주주의를 직장 안으로 확장하겠다는 선언에 가깝다.

이미 프랑스는 1980년대에 공기업부터 근로자 임원제도를 도입했고, 독일을 비롯한 유럽 여러 나라에서는 노동자 경영참여가 제도적으로 보장되고 있다.

그러니 서울시의 시도는 뜬금없는 실험이 아니라, 국제적으로 검증된 흐름을 한국 현실에 맞게 적용해보는 과정이라고 볼 수 있다.

“기업에 민주주의가 가능할까?”라는 오래된 의문

물론 반대 의견도 있다.
“노동자는 경영 전문성이 부족하다”, “의사결정이 느려지고 효율이 떨어질 것이다” 같은 주장이다.

하지만 이 질문을 뒤집어 보면 이렇게도 묻고 싶다.

과연 지금까지의 기업 경영은 충분히 효율적이고 공정했을까?

정치학자 로버트 달은 이미 오래전에 국가에 민주주의가 정당하다면, 기업에도 민주주의는 정당하다고 말했다.
노동자는 기업의 가장 핵심적인 이해관계자이자, 현장을 가장 잘 아는 사람들이다.

오히려 노동자의 참여는 단기 이익이 아니라 장기적 안정과 지속 가능성을 높이는 장치가 될 수 있다.

독일은 왜 노동이사제를 유지하고 있을까

흥미로운 점은, 노동이사제가 “한물간 제도”라는 주장과 달리 유럽연합 다수 국가에서는 여전히 이 제도를 유지하고 있다는 사실이다.

특히 독일은 노동자 경영참여가 경제 위기 속에서 사회적 갈등을 완화하는 역할을 했다는 평가를 받는다.
세계경제포럼 역시 독일의 위기 대응력 뒤에는 노동자 공동결정 구조가 있다고 분석했다.

즉 노동이사제는 이념이 아니라 위기 대응 전략이기도 하다.

혁신은 언제나 ‘다양성’에서 나온다

요즘 우리 사회에는 협동조합, 사회적 기업, 마을기업 같은 다양한 기업 형태가 빠르게 늘고 있다.
노동자가 소유자이자 경영자인 기업도 더 이상 낯설지 않다.

그런 시대에 “노동자가 이사회에 몇 명 들어오는 것조차 안 된다”고 말하는 게 과연 현실적인 태도일까?

혁신은 늘 다양성을 허용할 때 나타난다.

노동이사제는 기업 경영 방식의 정답을 강요하는 제도가 아니라, 다른 선택지를 하나 더 열어두는 실험이다.

지금 필요한 건 찬반이 아니라 ‘숙의’

노동이사제는 만능 해결책이 아니다.
당연히 제도 설계, 역할 범위, 책임 구조에 대한 충분한 논의가 필요하다.

하지만 분명한 건 하나다.
이 제도를 이념이나 시기상조라는 말로 밀어낼 문제가 아니라, 혁신·다양성·민주주의라는 관점에서 진지하게 검토해야 할 시점이라는 것.

기업의 담장 안에서도 민주주의가 가능할지 묻는 이 질문, 이제는 외면하기 어려워 보인다.

다음은 이 부분에 대해서 몇가지 아이디어를 정리 해 볼 생각이다.