[카테고리:] Tech

작성일자

회사 메일·캘린더·Teams를 Claude가 읽고, 중요한 건 Telegram으로 알려준다

지난번에 LLM Wiki + Telegram Bot을 만들었다. Claude Code가 개인 위키를 관리하고, Telegram으로 원격 조종하는 구조였다. 이번에는 여기에 Microsoft 365 연동을 붙였다. 회사 메일, 캘린더, Teams 대화를 자동으로 가져와서 위키에 쌓고, 중요한 건 Telegram으로 알려주는 시스템이다.

문제: 정보가 흩어져 있다

하루에 확인해야 할 채널이 너무 많다. Outlook 메일, Teams 채팅, 캘린더 일정이 각각 다른 앱에 흩어져 있다. 중요한 메시지를 놓치거나, “오늘 뭐 해야 하지?” 하고 여러 앱을 번갈아 열어보는 시간이 아깝다.

원하는 건 단순하다:

  • 메일, 캘린더, Teams를 한 곳에 모아서 보고
  • 중요한 건 알아서 알려주고
  • 나머지는 나중에 찾을 수 있게 쌓아두기

해결: mogcli + Claude + Telegram

mogcli라는 오픈소스 CLI 도구를 발견했다. Microsoft Graph API를 래핑해서, 터미널에서 메일/캘린더/Teams를 조작할 수 있다. 이걸 5분마다 자동 실행하고, Claude가 중요도를 판단해서 Telegram으로 알려주는 파이프라인을 만들었다.

전체 구조

systemd timer (5분 주기)
    |
    v
m365-sync.sh (bash 스크립트)
    |
    +-- mogcli: 메일, 캘린더 가져오기
    +-- Graph API: Teams 대화 가져오기
    |
    v
raw/m365/ (JSON 원본 축적)
    |
    +-- latest-mail.json      (항상 최신)
    +-- latest-calendar.json
    +-- latest-teams.json
    +-- 2026-04-16/           (일별 히스토리)
    |       mail-1043.json
    |       calendar-1043.json
    |       teams-1043.json
    |
    v
새 메시지 감지 (이전 스냅샷과 비교)
    |
    v
claude -p --model haiku (중요도 판단)
    |
    +-- 중요하면 --> Telegram 알림
    +-- 아니면 --> 조용히 넘어감
    |
    v
Claude가 위키에 ingest (CLAUDE.md 규칙에 따라)

1단계: mogcli 설치

mogcli는 Go로 작성되어 있어서 go install로 바로 설치할 수 있다.

# Go 설치 (mise 사용)
mise use -g go@latest

# mogcli 설치
go install github.com/jaredpalmer/mogcli/cmd/mog@latest

2단계: Microsoft Entra 앱 등록

mogcli가 회사 Microsoft 365에 접근하려면 Entra(구 Azure AD)에 앱을 등록해야 한다.

  1. entra.microsoft.com에서 App registrations > New registration
  2. Authentication 탭에서:
    • Mobile and desktop applications 플랫폼 추가
    • https://login.microsoftonline.com/common/oauth2/nativeclient 체크
    • Settings 탭에서 Allow public client flows > Yes
  3. API permissions에서 Microsoft Graph Delegated 권한 추가:
    • Mail.Read, Calendars.Read, Contacts.Read, Tasks.Read, User.Read
    • Teams용: Chat.Read, ChannelMessage.Read.All
  4. Grant admin consent 클릭 (Teams 권한에 필요)

3단계: 인증

mog auth
# Application (client) ID 입력
# Tenant ID 입력
# 브라우저에서 디바이스 코드 인증 완료

인증이 완료되면 바로 사용할 수 있다:

# 메일 가져오기
mog mail list --max 20 --json

# 이번 주 캘린더
mog calendar list --from 2026-04-14 --to 2026-04-20 --json

Teams는 mogcli에서 아직 지원하지 않아서, mogcli의 토큰을 꺼내서 Graph API를 직접 호출한다:

TOKEN=$(cat ~/.config/mogcli/keyring/... | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")

curl -s -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/me/chats?\$top=10&\$expand=lastMessagePreview"

4단계: 5분마다 자동 수집

bash 스크립트를 만들어서 systemd user timer로 5분마다 실행한다.

# systemd service
# ~/.config/systemd/user/m365-sync.service
[Unit]
Description=Microsoft 365 Sync

[Service]
Type=oneshot
ExecStart=/home/user/llmwiki/bot/m365-sync.sh
# systemd timer
# ~/.config/systemd/user/m365-sync.timer
[Unit]
Description=Microsoft 365 Sync every 5 minutes

[Timer]
OnBootSec=1min
OnUnitActiveSec=5min
Persistent=true

[Install]
WantedBy=timers.target
# 활성화
systemctl --user daemon-reload
systemctl --user enable --now m365-sync.timer

스크립트는 매번:

  1. 메일, 캘린더, Teams 원본 JSON을 raw/m365/에 축적
  2. latest-*.json으로 최신 스냅샷 유지
  3. 이전 스냅샷과 비교하여 새 메시지 감지
  4. 내가 보낸 메시지, 뉴스레터, GitLab 알림 등은 자동 필터링

5단계: Claude가 중요도 판단

여기가 핵심이다. 키워드 매칭이 아니라, Claude가 내용을 읽고 판단한다.

# 새 메시지를 Claude에게 파이프
echo "$NEW_MESSAGES" | claude -p --model haiku \
  "이 메시지들 중 즉시 확인해야 할 중요한 것이 있는지 판단하라.
   중요하면 Telegram 알림 메시지를 작성하라.
   출처를 명시하라 (메일/Teams).
   중요한 게 없으면 NONE만 출력하라."

Claude(haiku 모델)가 빠르게 판단해서:

  • 팀원의 업무 요청, 장애 보고, 미팅 변경 등은 알림
  • 광고, 뉴스레터, 단순 정보 공유는 무시

알림이 결정되면 Telegram Bot API로 발송한다. 각 메시지에 출처(메일/Teams)가 명시되어 있어서, 어디서 온 건지 바로 알 수 있다.

6단계: Claude가 위키에 정리

축적된 raw JSON은 Claude가 위키에 정리한다. CLAUDE.md에 ingest 규칙을 정의해두면, Claude가 대화 중에 자연스럽게 데이터를 읽고 일간 노트에 정리한다:

  • 오늘 일정을 타임라인으로 표시
  • 중요 메일만 필터링하여 목록
  • Teams 대화에서 액션 아이템 추출
  • 할 일 목록 업데이트

결과

이제 아침에 Telegram만 확인하면 된다. 중요한 메일이나 Teams 메시지가 오면 Claude가 알아서 판단해서 알려준다. Outlook이나 Teams 앱을 열지 않아도, 놓치는 게 없다.

raw 데이터는 날짜별로 쌓이니까, 나중에 “지난주에 누가 뭐라고 했더라?” 같은 질문에도 Claude가 검색해서 답해줄 수 있다.

지난번 LLM Wiki + Telegram Bot이 “내가 Claude에게 물어보는” 구조였다면, 이번에는 “Claude가 먼저 알려주는” 구조가 추가된 셈이다. 수동 질의에서 능동 알림으로.

사용한 도구

  • mogcli – Microsoft Graph CLI (Go, MIT)
  • Claude Code – CLI에서 claude -p로 파이프 분석
  • systemd user timer – 5분 주기 실행
  • Telegram Bot API – 알림 발송
  • Microsoft Entra – 앱 등록 및 OAuth 인증
작성일자

나의 첫 하네스 — Telegram으로 LLM Wiki 원격 조종하기

오늘 하루 만에 개인 지식 베이스를 만들고, 그걸 Telegram으로 원격 조종하는 시스템을 만들었다. 돌이켜보면 이것이 나의 첫 하네스 엔지니어링이었다.

시작: Karpathy의 LLM Wiki

모든 것은 Andrej Karpathy의 LLM Wiki 패턴에서 시작했다. 핵심 아이디어는 간단하다 — RAG처럼 매번 원본에서 검색하는 대신, LLM이 위키를 점진적으로 구축하고 유지관리하게 만드는 것이다.

구조는 3계층이다:

  • Raw sources (raw/) — 원본 자료. 불변.
  • Wiki (wangsyObsidian/) — LLM이 유지관리하는 마크다운 파일들. Obsidian vault.
  • Schema (CLAUDE.md) — LLM에게 “이렇게 일해라”를 알려주는 규칙서.

Claude Code를 열고 Karpathy Gist를 공유하면서 시작했다. Claude가 기존 Obsidian vault 구조를 분석하고, CLAUDE.md 스키마를 작성하고, index.md와 log.md를 생성하고, 기존 42개 페이지를 색인했다. 한 시간도 안 걸렸다.

문제: 이 컴퓨터 앞에 앉아 있어야 한다

위키가 돌아가기 시작하니까 바로 문제가 보였다. 원격에서는 쓸 수가 없다.

출퇴근길에 흥미로운 기사를 발견해도, 회의 중에 메모할 것이 생겨도, 집 컴퓨터 앞에 앉아서 Claude Code를 열어야만 ingest할 수 있다. 지식 베이스는 24시간인데 입력 통로는 컴퓨터 앞에 있는 시간만큼만 열려 있는 셈이다.

내가 원한 것은 세 가지였다:

  1. 어디서든 URL이나 텍스트를 보내면 즉시 ingest
  2. 어디서든 질문하면 위키 기반으로 답변
  3. 이미 매일 쓰고 있는 앱에서

답은 Telegram Bot이었다.

아키텍처: 봇은 얇게, 두뇌는 Claude에게

설계 원칙을 하나 잡았다: 봇은 메시지를 중계할 뿐, 모든 지식 작업은 Claude Code가 한다.

스마트폰 → Telegram → Bot 서버(내 PC) → Claude Code CLI → Wiki

봇의 역할은 정말 단순하다:

  1. Telegram 메시지를 받는다
  2. claude -p로 Claude Code에 전달한다
  3. 결과를 Telegram으로 돌려보낸다

위키의 모든 규칙(어디에 저장할지, 어떻게 교차참조할지, index를 어떻게 업데이트할지)은 CLAUDE.md에 있고, Claude Code가 그대로 따른다. 봇 코드에는 위키 로직이 한 줄도 없다.

이게 왜 중요한가? 하네스 엔지니어링의 핵심 원칙과 연결된다:

“에이전트가 실수하면 에이전트가 아니라 하네스를 고쳐라”

봇이 위키 로직을 갖고 있으면, 규칙을 바꿀 때 봇 코드와 CLAUDE.md 두 곳을 고쳐야 한다. 봇을 얇게 유지하면 CLAUDE.md만 고치면 된다. 하네스(CLAUDE.md)가 단일 진실의 근원이 된다.

구현: 생각보다 간단했다

Telegram Bot 생성

BotFather에게 /newbot — 30초면 끝난다. 토큰을 받는다.

봇 코드 (Python, 약 100줄)

핵심은 run_claude 함수 하나다:

async def run_claude(prompt: str) -> str:
    proc = await asyncio.create_subprocess_exec(
        "claude", "-p",
        "--allowedTools", "Read,Write,Edit,Glob,Grep,WebFetch,...",
        cwd=str(WIKI_DIR),
        stdin=asyncio.subprocess.PIPE,
        stdout=asyncio.subprocess.PIPE,
        stderr=asyncio.subprocess.PIPE,
    )
    stdout, stderr = await proc.communicate(input=prompt.encode())
    return stdout.decode().strip()

claude -p는 Claude Code의 비대화형 모드다. stdin으로 프롬프트를 넘기면 stdout으로 결과가 나온다. --allowedTools로 필요한 도구(파일 읽기/쓰기, 웹 가져오기)를 허용한다.

나머지는 Telegram 핸들러를 붙이는 것 뿐:

  • URL이 오면 → “이 URL을 ingest해줘”
  • 텍스트가 오면 → “위키에서 이 질문에 답해줘”
  • 파일이 오면 → raw/에 저장 → “이 파일을 ingest해줘”
  • /lint 명령 → “위키를 lint해줘”

systemd로 상시 운영

.service 파일 하나 만들고 systemctl enable --now — PC가 켜져 있는 한 봇은 항상 살아 있다.

실사용 흐름

출퇴근길에 기사 발견:
Telegram에 URL 붙여넣기 → 봇이 자동 ingest → raw/에 원본 보존 → Atlas/에 요약 페이지 생성 → index.md 업데이트 → log.md 기록

회의 중 떠오른 질문:
Telegram에 “지난 프로젝트 설정이 어떻게 됐더라?” 입력 → 봇이 위키 검색 → 답변 도착

누군가 전달한 정보 기록:
Telegram에 /ingest 김과장이 내일 미팅에서 예산안 가져온다고 함 → raw/에 보존 → 위키에 통합

삽질 기록

순탄하지만은 않았다. 기록해둔다.

  1. --prompt 옵션은 없다 — claude --print --prompt "..." 가 아니라 claude -p "..." 이다. prompt는 위치 인수.
  2. --allowedTools와 위치 인수 충돌 — claude -p --allowedTools "..." "prompt" 에서 prompt가 인식 안 됨. stdin 파이프로 해결.
  3. 비대화형 모드에서 도구 권한 — -p 모드는 도구 승인 프롬프트를 띄울 수 없다. --allowedTools로 사전 허용 필수.

이런 삽질들이 모두 하네스를 이해하는 과정이었다. 에이전트(Claude)의 문제가 아니라 하네스(호출 방식, 권한 설정)의 문제였고, 하네스를 고치니 해결됐다.

이것이 하네스 엔지니어링인가?

돌이켜보면, 오늘 한 것은 정확히 하네스 엔지니어링이었다:

  • Schema 설계 — CLAUDE.md에 위키의 규칙과 워크플로우를 정의
  • 입출력 채널 설계 — Telegram Bot으로 원격 접근 경로 구축
  • 도구 권한 설계 — --allowedTools로 에이전트가 쓸 수 있는 도구 범위 지정
  • 얇은 중계층 — 봇은 로직 없이 메시지만 전달, 모든 판단은 에이전트가

긱뉴스에서 읽었던 그 문장이 떠오른다:

“남이 만든 하네스를 그대로 복사해 쓰는 것은 남의 옷을 입는 것과 비슷하다”

Karpathy의 LLM Wiki 구조를 가져왔지만 그대로 쓰지 않았다. 내 Obsidian vault 구조에 맞추고, Calendar를 raw source로 재정의하고, Telegram 입력 채널을 추가했다. 남의 패턴을 가져와서 내 것으로 만드는 과정 — 그것이 하네스 엔지니어링의 시작이었다.

다음 단계

  • 이미지 ingest 지원 (Telegram 사진 메시지)
  • 긴 응답의 마크다운 포맷팅 개선
  • Obsidian URI 연동 (응답에서 바로 페이지 열기)
  • 주기적 자동 lint

하루 만에 여기까지 온 것이 믿기지 않는다. 대부분의 코드는 Claude가 짰고, 나는 방향을 잡고 결정을 내렸다. 이것도 하네스 엔지니어링의 일부인 것 같다 — 에이전트가 일하는 구조를 설계하는 것이 곧 에이전트와 함께 일하는 방식이니까.

작성일자

Amazon Cloud Drive CLI

Amazon Cloud Drive의 unlimited plan을 사용중에 있다. (올해말까지 프로모션으로 공짜로 쓰고 있다)
이게 정말 무한대이다 보니, 무한 백업 장소로 쓰고 싶은 욕망이 무럭 무럭 자랐다.
Ubuntu 서버에 있는 데이타를 Amazon Cloud Drive로 옮겨야 하는데, 뭔가 CLI 프로그램이 필요했다. 검색하니 딱 있네.
https://github.com/yadayada/acd_cli
그런데, 이상하게도 데스크탑 클라이언트에서 올리는 것보다 현저하게 속도가 떨어진다. 뭔가 아마존에서 제약을 걸어놨을까?

작성일자

MacBook 이 살아났다

MacBook 12 가 처음 구매했을 때부터, 잠자기모드에서 깨어나기에 자주 실패했다. 잠자기로 들어갔을 때, 뚜껑을 열면, 켜져있는 것도 아니고, 꺼져있는 것도 아니어서 강제로 (파워버튼을 20초간 눌러서) 셧다운 시킨 다음 다시 켜야만 했었다.
그러다, 아주 결정적인 순간 (폭풍 코딩을 하고, 서버에 푸시는 전혀 안한 바로 그 순간) 다시 깨어나기를 거부했다. 부팅디스크를 찾을 수 없다고 한다. 나는 처음에는 시동디스크 셋업이 잘못되었다고 생각해서 초기화를 한다던지, 부팅옵션을 바꾼다던지 했는데, 먹히지 않았다. 인터넷 복구로 들어가서 복구를 시도할려고 해서 디스크가 아예 보이지 않았다. 그래도 그때는, 그냥 SSD가 충격으로 살짝 빠졌나 생각했다. 그런데, MacBook 12는 SSD가 착탈식이 아니고, 온보드라고 한다. 그래서 접촉불량 이런거로 인식이 안되는 것이 아니다. 보드가 아주 맛이 갔다는 뜻이다.

메인보드를 교체한 다음부터는 아주 잘 깨어난다. 사실 맥쓰는 사람에게 이건 별거 아닌데, 한 7-8개월동안 못느끼던걸 느끼느라 아주 황홀하다.

작성일자

iMac 5k에 32G 메모리 추가

2010년식 iMac 27″ 에서 2015년 iMac 5k로 업그레이드를 했는데, 어찌 더 느려졌다. 특히 느린것은 Mission Control 에서 상단 데스크탑 화면을 보여줄 때 매우 느려졌다. 왜일까 고민을 하면서 의심을 한 것이

  • 5k 해상도에 4k 외장 모니터까지 있는데, 부담이 아닐까?
  • 이전에는 SSD로만 썼는데, 이번에는 Fusion Drive 라서 느릴까?
  • 이전에는 32G 였는데, 이번에는 8G라서?

이런 저런 의심을 하다가, 리부팅 후 깨끗한 상태에서 Mission Control 을 해 보니 부드럽게 돌아가는 것을 보고, 이것은 분명 메모리 문제다라고 확신.
그리고, danawa.com 에서 메모리를 알아보는데, 이상하게도 iMac 5k 에 딱 맞는 메모리가 국내에는 판매가 안된다. iMac 5k 는 1867MHz DDR3 메모리를 쓰는데, 다나와에서는 1600MHz 밖에 없다.
한 블로그를 보니, 기존에 있는 4G 메모리(1867HMz) 2개를 그대로 두고, 1600MHz 8G 짜리 두개를 더 추가하였다. 그리고, 결과 화면을 보니 1600MHz 로 전체가 정상 동작하였다.
사실 1600MHz 와 1867MHz 속도 차이는 거의 없을 거라 생각한다. 하지만 찝찝한 기분이 있으니, 해외사이트에서 1867MHz 로 주문하기로.
다나와 기준 8G에 38,200원. 내가 주문한 해외사이트에서는 8G 기준 $55 니 66,400 정도. 거기에 운송료+부가세 하면 꽤 나올 듯. 그래도 찝찝하니깐…
 

작성일자

iPad mini 를 위한 쉴드

나름 iPad mini 에 대해서 예측해 보았고, 어떤 것은 음… 역시 예측 대로군 이지만, 어떤 것은 매우 당혹스럽게 만들었다. 이제 다시 애플의 입장에서 합리화를 해 볼 시점이다. 애플의 시점에서 합리화를 해 보는 것은, 애플빠의 입장에서 단순한 옹호일 수도 있지만, 아직까지는 시장에서 가장 유효한 상품을 만들어 내는 기업으로 인정한다면 그 인사이트를 해석할 수 있는 한 방법이기도 하기 때문이다.

레티나가 아니라고?

iPad mini 는 실망스럽게도 레티나가 아니다. 이것은 거꾸로 해석하자면 애플의 분명한 목표는 “10시간 지속 사용 가능한 300g iPad” 를 만드는 것이라고 해야겠다. 10시간 사용 + 300g + 레티나디스플레이 제품을 현실적 가격으로 만들어 내는 것이 현재 기술로는 불가능 하기 때문에, 3개중 하나는 버려야 했을 것이고, 애플은 레티나 보다는 10시간과 300g 을 선택했다고 봐야 할 것이다. 물론 목표는 분명하다. 내년 아니면 내후년 이라도, 10시간 사용 + 300g + 레티나디스플레이는 반드시 나올 것이다. 그다음 가치는 반드시 레티나가 될 테니까.
나를 비롯하여, 많은 사람들이 iPad 에서 글을 읽는 것을 너무나도 사랑한다. 이제껏 iPad 없이 어떻게 글을 읽었을까 의문이 들 정도이다. 그런데 이제와서 아무리 미니라도 레티나가 아닌 디스플레이에서 글을 읽으라니 당치도 않는 소리이다. 충격이 크다. 하지만 고개를 들어서 많은 사람들을 보면, iPad 에서 글만 읽고 있는 것은 아니다. 게임을 주로하고, 동영상을 감상하고, 사진을 감상하고, 트위터 페이스북 등 가벼운 SNS 를 한다면, 굳이 레티나가 중요한 요소가 아니다. 사실은 이들이 다수의 사용자이고, 위 3가지 요소중 레티나는 그래서 나머지 2개보다 우선순위에서 밀린거라고 정리가 된다.

과연 잘 팔릴까?

요즘 애플 제품들 특히, iPhone, iPad 가 워낙 대작이라서, 이들과 비교하면 쉽게 말하기 어렵다. 하지만 타사 제품과 비교하면 비교적 쉬워진다.
첫째, 휴대용 게임기와 비교해 보자. PSP Vita, Nintendo 3DS 등과 비교하자면, 가격 경쟁력이 그렇게 떨어지지 않는다. 1-20만원 더 비싼 가격이지만, 범용적인 활용성을 생각한다면, 오히려 공격적인 가격으로 보인다.
둘째, 킨들, 넥서스7 등과 비교해 보자. 이들이 아무리 가격대비 성능이 뛰어나도 한가지 막히는 것이 있다면 바로 소프트웨어다. 이전에 Mac 이 윈도우 계열보다 아무리 뛰어나다고 주장해도 사람들이 쉽사리 Mac 으로 건너올 수 없었던 이유가 자신이 늘 사용하는 애플리케이션이 없었기 때문이다. 요즘은 반대 현상이 나타나고 있다. 안드로이드 디바이스가 아무리 탐나더라도 자신이 늘 사용하는 앱이 iOS 디바이스에서 더 편리하게 사용할 수 있다면, 쉽게 넘어가기가 어려워 진다. 마찬기지 이유에서 아직는 안드로이드 계열의 태블릿이 경쟁력이 없다. 폰은 그나마 어느정도 따라왔다면, 태블릿은 그에 비하면 아직 많이 부족하다. 특히 iPad 사용경험이 있는 경우에는 더더욱 어렵다.
iPad mini 를 보면서 처음 느꼈던 감정이, 애플이 아무리 혁신을 잃는다 해도, 아무리 특장점 없는 제품을 만들어 낸다고 해도, 당분간은 경쟁력을 잃지 않겠다 라는 생각을 했다. 한마디로 “잘” 만든다(well-made?)는 것이다. 제품의 품질과 완성도에서 기본적인 구매욕구에 대한 설득이 끝나기 때문이다.

오히려 아쉬운 점은

이전 애플 제품은 잘 팔릴것 같지는 않지만 고집스러웠다면, 요즘 애플 제품은 그런 면에서 심심하다. 비유하자면, 예전에는 까칠하고 거북스럽지만 매력적인 캐릭터의 사람이라면, 요즘엔 단정하고 부드러운 인상의 영업사원 같은 느낌이다. 어떤 사람들은 스티브잡스 생전에 비해서 더 완벽하지 못하다고 말하지만, 나는 오히려 반대다. 예전엔 더 불완전 하였고, 더 울퉁불퉁 했었다. 20년 이상 애플빠로 살아왔지만, 그런 나같은 팬과도 타협할 수 없는 점들도 많이 있었다. 하지만 요즘은 아니다. 좋은게 좋은거고, 많은 사람들이 원한다면 그것을 해 준다.
그래서 나온것이 iPad mini 가 아닌가 하는 생각이 든다.

작성일자

iPad mini 나올 것인가?

iPad mini 출시를 보면, 내속에서 마치 이중인격자처럼 두가지 의견이 팽팽하다. 사실 나도 결론은 잘 모르겠다.

쟁점 나온다 안나온다
 7인치 과연 애플이 영구히 10인치 태블릿만 만들까?이제는 Post-PC 시대다. PC 가 없어질 수도 있다. 그 자리를 현재의 10인치 iPad가 모든 것을 대체할 수 있을까? 심지어 노트북도 4가지 크기 (11, 13, 15, 17)로 나온다. 왜 더 다양한 태블릿이 불가한가? iPad 10인치는 그냥 나온게 아니다.애플이 수년간 연구를 통해서, 내린 결론이 바로 10인치라는 것이다.7인치 안만들어 봤을거 같나? 만들어보고, 유용성이 없으니 안만드는 것이다.
 파편화 iPhone 5 를 봐라. 이미 파편화 시작 되었다. 스스로 깬 것이다. 개발자의 혼란은 생각보다 크지 않다. 이런 식으로 가랑비 옷 젓듯이 서서히 진행할 것이다. 애플이 스스로 안드로이드처럼 파편화를 스스로 초래할 것인가? 안드로이드야 서로 다른 제조사가 서로 경쟁하면서 어쩔수 없이 생긴 것이라면, 애플이 스스로 그런 문제를 만들리 없다.
시장점유 애플은 시장 대세에서 밀려서는 안된다. 이제껏 안드로이드 계열에서 나온 태블릿은 다 실패했다. 하지만 지금은 다르다. 비록 Kindle Fire 가 일단 실패라 하더라도, Nexus 7, Kindle Fire HD 등으로 이어지는 라인에서 자리를 잡을 것이다.이렇게, 안드로이드 태블릿의 시장이 형성되면, 자연스럽게 앱도 구축될 것이고, 그러면 다시 안드로이드 태블릿 성장이 촉진될 것이다.애플은 이참에 싹을 잘라줄 대책이 필요한 시점이다. 저럼하고, 가벼운 iPad 를 출시하여, 안드로이드 생태계가 생성되는 것을 막아야 할 것이다. 애플을 몰라서 하는 말이다. 애플은 지금까지 시장 점유율 향상을 위해서, 가격에 맞춘 제품을 만들어 온 적이 없었다. 가격경쟁력이 좀 떨어지더라도, 제품의 완성도에 촛점을 맞추어 왔다. 오히려 소품종 대량생산을 통해서 가격 경쟁력을 키웠을 뿐이다. iPad mini 는 이에 완전 역행하는 것이다.
 라인업 7인치, 1024×768 해상도, 199불의 iPad mini 는 iPod shuffle 의 역할을 할 수 있다. 애플의 마케팅을 위한 라인업을 완성할 것이고, 다양한 요구에 대한 답이 될 수 있다. 10인치, 1024×768 을 그냥 7인치로 줄이는 것은 말이 안된다. 애플은 손가락의 크기와 버튼의 크기를 픽셀단위로 맞추어 놓았다. 단지 라인업을 위해서, 이런 일관성을 해칠 리가 없다.잘 생각해봐라. 2012년형 iPod nano 에는 왜 앱이 올라가지 않을까? 판매향상을 위해서, 충분히 SDK를 열어줄 수도 있다. 하지만 하지 않는다. 그건 현재의 일관성으로 불가능에 가깝기 때문이다.
 제살먹기 스티브잡스는 말하였다. 남들에 의해 먹히기 전에, 자기가 먼저 먹는게 맞다. 7인치가 대세가 되면 어떻게 할거냐. 미리 보험 드는게 맞다. 저가의 iPad는, 현재 마진이 좋은 10인치 iPad 의 시장을 깎아먹을 뿐이다. 시장만 커지면 뭐하나 남는게 없는데.

일단 나에게 iPad mini 에 대한 의견을 물어본다면, 내가 아는 애플은 199불, 1024×768의 해상도 iPad mini 는 내 놓지 않을 것이다. 만약 내놓는다면, 아마도 전혀 다른 이야기를 하면서 내 놓을 것이다.
예를들면

  • iBooks 를 매우 강조 할 것 같다. 책읽기에 최적화 된 디바이스 이런 식으로
  • 물론, iTunes Store 를 통한, 음악, 동영상 접근은 기본이다.
  • 애플의 앱들이 해당 디바이스에 최적화 된 UI 로 나올 것이다. (단순히 iPad 앱을 약간 작은 화면에서 쓰도록 하지는 않게 할 것이다)
    • 최근 업데이트 된, AppStore 앱들의 변화가 이런 조짐을 보인것 갈기도 하다.
  • AppStore 는 당장 열지 않을 것이다. 아니면, 적어도, iPad mini 에 최적화 된 앱만 별도로 몇개 준비 시키고, 최적화된 앱만 받을 수 있도록 할 것이다. (물론 iPad 에서 iPhone 앱 실행시키는 식의 방법은 열어줄 것이다)
  • 이건 예측이라기 보다는 희망사항이지만, 1024×768보다는 고해상도이지 않을까 싶다.

써 놓고 보면, 같은 말이라도, 저가의, 7인치의 태블릿이 아닌, 또다른 라이프 패턴에 최적화 된 디바이스 뭐 이런 식으로 나오지 않을까 싶다.

작성일자

구글 아저씨, 스토리가 없어요

구글 I/O 가 얼마전에 끝났다. 다들 이번만큼 흥미로운 발표는 없었다고 하지만, 나는 개인적으로 공감을 가질 수 없었다. 어쩔 수 없이,애플과 비교될 수 밖에 없었다. 개인적으로는 뼈속까지 애플빠이기도 하지만, 애플이 매번 나를 흥분시키는 그 뻔한 수작, 그 뻔함이 구글의 것에서는 없었다.
그게 무엇이냐면,
애플의 제품 발표는 늘 똑같은 포맷을 가진다. 특히 애플 제품 발표때마다 5분짜리 짤막한 비디오가 나오는데, 나는 이 비디오를 매우 좋아한다. 아니 볼 때마다 마치 파블로브의 개처럼 묘한 감동에 빠진다. 이 비디오의 구조는 다음과 같다

  • 조나단 아이브 : 우리는 기존 제품에서 한계를 발견했다. 이것을 개선해야 한다고 생각했다. 아니, 근본적으로 새롭게 처음부터 시작해야 겠다고 생각했다.
  • 밥 맨스필드 (이젠 떠났지만) : 완전히 새로운 하드웨어가 필요했다. 이전과는 다른 근본적인 새로움 ( 유니바디 시리즈, 레티나 시리즈 등) 을 시도하였다. 또한 업계를 앞서는 시도 (플래시 메모리, 매립형 배터리 등) 로 혁신 하였다.
  • 조나단 아이브 : 과거로 부터의 단절 ( 커버 글래스의 제거를 통한 선명함을 높이고, 더욱 실감나는 영상 ) 새로운 시도 ( 비대칭 팬을 통한 저소음 )  이런것은 애플만이 가능한 것 아이디어다.
  • 필 쉴러 : 제품 사양이 얼마나 시장에서 경쟁력 있는지. 제품의 구성이 얼마나 사용자들이 원하는 것들인지. 시장이 원하는 제품을 시장에 적기에 내놓은 것임을 강조한다.
  • 스캇 포스톨(iOS) 혹은 크렉 페데리기 (OS X) : 하드웨어는 소프트웨어로 완성된다. 이러한 새로운 하드웨어의 신기능을 충분히 활용하기 위해서, 소프트웨어 세트를 완전히 새로 구성했다. 모든 애플 소프트웨어가 이러한 새로운 기능을 충분히 발휘할 수 있도록 재작성 되었다.
  • 조나단 아이브 : 혁신이란 ….

이런 식이다. 어떠한 제품을 발표하더라도, 거의 동일한 패턴이다. 등장 인물은 바뀌더라도 이 포맷은 계속 유지해 왔다. 스티브 잡스 생전부터, 본인은 등장하지 않고 이 비디오를 연출해 온 듯 하다. 이것은 마치 헐리우드 히어로 무비 영화 패턴과 똑같다. 각 배역에게 캐릭터를 주고, 그 캐릭터에 맞는 초능력을 선사하고 나면, 그 다음부터 스토리는 늘 뻔하다. 어떠한 악당이 나와도 이 캐력터가 초능력을 발휘해서 적을 물리친다는 것이다. 우리는 늘 반복되는 이 패턴에 즐거워하고 재미있어 한다.
애플 제품 발표도 마찬가지다. 문제 상황이 주어지고, 이것을 혁신하라는 지령이 떨어진다. 각 능력자들은 자신의 능력을 동원하여 이 문제를 풀어냈다. 각자의 방식으로. 그들의 협공은 늘 언제나 성공적이다. 마치 픽사의 인크레더블 가족을 보는 것 같다. 늘 감동적일 수 밖에 없다.
이번 구글 발표에서는 구글 글래스를 끼고 공중에서 뛰어 내렸다. 그 장면을 실시간 중계하는가 하면, 스카이다이버가 발표회 장으로 뛰어 들어왔다. 사람들은 흥분의 도가니에 빠졌고, IT 제품 발표회 장인지, 유니버셜 스튜디오인지, 미래로 초대된 것인지 구분이 안 갈 정도 였다.
하지만, 나는 개인적으로 보고 있으면서 – 유튜브로 현장감 없이 봐서 인지 몰라도 – 저거 어디다 쓰는 물건일까?, 나는 과연 필요할까? 아니 공짜로 줘도 쓰고 다닐까? 쓰고 다닌다면 무엇을 위해서? 의문에 의문만 계속 들었다. 현란한 쇼는 잠시 이지만, 이런 의문에 대한 공감대를 주지는 않았다.
마치 재미없는 헐리우드 영화의 판박이 처럼, 엄청난 화력과 엄청난 규모의 전투씬. 화려한 CG. 하지만, 도대채 저들은 왜 싸우는지 공감할 수 없는 그런 느낌이었다.
그래 구글은 역시 대단한 회사야. 첨단 기술을 이끄는 것은 구글이었어. 이런 말 밖에는 해줄게 없었다. 나와 구글 사이에는 아무런 연결고리가 없이, 그냥 구글만의 쇼라는 느낌만 들었다.
왜 글래스를 하게 되었고, 구글이 글래스에 대해서 얼마나 진지하게 고민을 하고 있고, 이것을 통해서 얼마나 유용하고 가치있는 것을 발견했는지 그런 공감대를 만들기 위한 노력이 보이지 않았다. 단지 내 아이의 두손을 잡아주면서 비디오를 찍고 싶었다는 것 말고는 말이다.
물론 나는 구글이 하는 글래스 프로젝트를 매우 높게 평가한다. 아직은 그 유용함을 설득해 주지는 못했지만, 오랜기간 동안 컴퓨터과학 연구실에서 잠자고 있는 웨어러블컴퓨팅을 소비자제품으로 이끌어내는 역사적인 작업을 하고 있기 때문이다. 제품으로 만들어서 보급하고, 사람들이 쓰다보면 그 가치를 언젠가는 발견할 것이라 생각한다면,  구글은 정말 힘든 일을 해내고 있는 것은 정말 장한 일이다. 무인 자동차 역시 마찬가지다.
하지만, 이건 이거고, 저건 저거다. 장하고 대단하지만, 스토리가 없고, 재미가 없다.
 

작성일자

대항마들은 왜 레티나를 미리 내지 못했을까?

3월 8일 예상대로 iPad 3 가 발표 되었고, 예상 밖으로 이것은 The New iPad 라 불렸다. “새로운 iPad” 의 특징은 5가지로 정리되는데, 그중 하나만 꼽으라면 당연 레티나 디스플레이이다. 그리고, 이 레티나의 적용은 사실 iPad 2 가 나올때부터 점쳐 오던 것이었다. 더 정확히는 iPhone 4 가 레티나를 적용하면서, iPad 에 적용하는 것은 당연한 수순이라고 생각 되었다.
그런데, 여기서 잠깐 궁금한게 있다. 대체 왜 대항마들은 이렇게 오래전(대략 1년반전)부터 예측되어 오던 레티나 태블릿을 왜 먼저 내놓지 못했을까? 먼저 선빵을 날리며 선두마로 나갈 수 있었는데 말이다. 여기에 대해서 나 나름대로의 추측을 해 보자면,

첫째, 애플은 이미 힘으로도 압도하고 있는 것이 아닐까?

레티나 디스플레이는 잘 알려진 바대로, 애플이 만든다기 보다는, LGD, 삼성, 샤프 이 세회사가 만든다고 알려져 있다. 그리고 가격은 대략 70불로 추정한다고 한다. 작년 한해만 대략 4천8백만대의 iPad 를 팔았다. 아무리 보수적으로 봐도, 설마 올해 5천만대 못팔까? 애플은 최소 5천만대 이상 판매계획을 세웠을 것이고, 이들 디스플레이 회사에 선주문을 넣었을 것이다. 금액으로 환산하면 대략 3조 7천억에 해당하는 금액이다. 세 회사가 균등히 나눠도 1조 이상의 매출이 간다.
하지만, 상황은 어떤가? 대략의 들려지는 바로는, 이제 막 새로운 공정을 세우고, 새롭게 시작하는 단계라 쉽지만은 않다. 올해 5천만대 공급도 버겁다는 이야기가 들려 온다. 이러한데, 애플은 어떻게 했을까. LG 디스플레이에 1조원 선수금 넣어주고 물량 확보 했다는 말도 있다. 그렇다면, 경쟁자들은 이 상황에서 과연 물량 확보가 가능할까? 5천만대는 커녕 1백만도도 자신 없는데, 누가 과연 지를 수 있을까? 그럼 반대로 LGD 는 어떨까? 선수금 꽂아주고, 5천만대 물량확보 해 주는데, 다른데서 1백만대만 빼 달라면 과연 줄 수 있을까? (양산 라인이 안정화 이후라면 모를까)
애플이 최초의 레티나 태블릿을 출시하는 것은 우연이 아닌, 힘에 의한 결과가 아닌가 하는 추측이 들게 하는 대목이다.

둘째, 레티나에 맞는 OS 는 누가 만들어 주나?

어찌어찌 해서, 레티나 디스플레이를 확보 했다고 치자. 그럼 레티나에 OS(아마도 안드로이드) 최적화는 누가 시켜야 하나? 그보다 먼저, A5X 칩셋 처럼, 4배향상된 GPU 도 받쳐줘야 한다. 이거 어디서 구하나? 그리고 디바이스 드라이버 최적화 부터, 웹 브라우저까지 모두 재정비에 들어가야 한다. 성능적인 문제는 오히려 간단하다. UI 위젯 콤포넌트 부터, 전반적인 모든 앱 라인에 이르기까지, 레티나가 빛을 볼 수 있도록 해야 한다.
구글이 해줄까? 아니면 디바이스 제작업체마다 해야 할까? 이것 참 애매하다. 그리고 구글이 나선다 해도, 앱개발사들에게 레티나 최적화를 선도할 수 있을지도 의문이다. 여러모로 난감하다. 아직 태블릿 환경도 정착되지 않은 상태에서 레티나 최적화라는 주제는 앞서나가도 너무 앞서 나간 것일 수도 있다. 그리고, 파편화로 어깨가 무거운 개발사들은 어떻게 위로해 줄까?
누군가 제조사 내에서 레티나를 적용하자고 주창했을때, 네가 나서서 해 보라고 하면, 아마 천문학적인 비용을 감내해야 한다고 하지 않았을까?

세째, 레티나가 좋다는 것을 입증할 방법이 있었을까?

만약, 그 누군가가, 애플과 같이 디스플레이 업체에 배팅도 하고, 그에 맞는 OS 및 환경 셋업을 위해 천문학 적인 투자도 마다하지 않았다고 했을때, 그렇다면, 레티나를 촛점으로 마케팅 해서, 팔아 낼 수 있어야 할 것이다. 그 전에, 내부적 보고라인 안에서라도 레티나로 인상을 줄 수 있어야 할 것이다. 지금껏 투자한 것 이상의 가치가 있을 것이다는 것을 보여 주어야 한다. 무엇을 어떻게 보여 줄 수 있을까?
애플은 레티나를 빛나게 할 PC 급 소프트웨어, iWork, iLife 로 시작해서, 최근 발표한 iBooks 까지, 그리고 결정적 한방. 레티나에 최적화 된 인피니티 블레이드까지 준비할 수 있었다.
내가 만약 대항마의 입장이라면 어떤쪽으로 마음이 기울까? 레티나 디스플레이 생산이 안정화 되고, 물량이 확보되기까지 기다렸을 테고, 구글이 애플의 레티나 iPad 성공에 자극을 받아서 움직여 주기를 기다릴 테고, 그리고 애플의 레티나 iPad 를 보고 아이디어와 힌트를 얻고 비집고 들어갈 곳을 찾고 난 다음, 그리고 움직이지 않을까? 미리 움직여 득을 볼 것이 전혀 없는 것이 아닌가. 매우 당연한 결론에 이르렀지만, 이렇게 곰곰히 생각해 보지 않았을 때에는 매우 궁금한 것이었었다.
또 한가지,
내가 레티나 iPad 에 대해서 매우 흥분을 하고, 새로운 역사의 시작이라는 평가를 하고 다니니, 가끔 궁금해 하며 묻는 분도 계신다. 단지 해상도 하나 좋아 진 것 뿐인데, 뭘 그리 호들갑을 떠나요? 애플도 속내를 들어내기를 iPad 가 Post-PC 로 자리잡기를 기대한다. 사람들은 과거 PC 에서 했던 많은 것들을, PC 가 아닌 iPad 에서 쉽게 할 수 있다는 것을 발견하고 있는 중이다. PC 에 익숙하지 않을 수록, PC 비전문가 일수록 이 발견의 속도가 더 빠르고, 더 빨리 적응을 한다. 레티나는 이 Post-PC 시대로 넘어가기 위한 (아마도 내 생각에는) 마지막 장애물을 넘어가게 해 주는 것이 아닐까 생각된다.
과거를 돌아보면, PC 시대는 사실 애플컴퓨터의 탄생 만으로 시작되지 않았다. IBM PC 의 탄생도 아니다. 애플컴퓨터는 여전히 컴퓨터 광들의 취미에 불과했다. 아마도 VisiCalc의 등장으로, PC 가 모두에게 유용할 수 있다는 것을 보여주지 않았나 싶다. 물론 더 크게는 IBM PC의 LOTUS 1-2-3 일 것이다.
레티나 디스플레이는 iPad 가 보여 준 가능성을 조용히 자연스러운 일상의 모습으로 만들어 줄 것이다. 예를 들어, iBooks 2를 통해서, 전자책으로서 가능성만을 보여주었다면, 레티나로 인해서 자연스럽게 전자책으로 쓰이게 되는 계기가 될 것이다. 여러 기업에서도 iPad 사용을 적극 도입하고 있다. 아예 PC 를 사용하지 않고, iPad 만으로 업무가 가능한 직군도 늘어나고 있다고 한다. 레티나 디스플레이는 이러한 PC 없이 iPad 만 사용하는 것을 놀랍지 않은 일로 만들 것으로 보인다. LOTUS 1-2-3 가 PC 를 보통사람의 집과 사무실 책상위에 두는 것을 놀랍지 않은 일로 만든 것처럼.
나는 거의 1년반을 레티나 iPad 를 기다려 오면서, 꼭 애플이 아니더라도 레티나만 장착해 준다면 누구라도 충성을 맹세할 준비가 되어 있었다. 하지만, 이 소원을 맨 먼저 들어 준 것이, 애플이라는 점이 참 묘하다. 나는 이 레티나와 함께 애플은 올해도 또한번 도약한다에 배팅을 한번 걸어본다.