1인 개발자 뉴스 #9 - 2026년 1월 4주차

TL;DR

1. GitHub Copilot CLI slash commands cheat sheet

무슨 일이야?

GitHub에서 Copilot CLI 사용자들을 위한 공식 치트시트를 발행했어요. 슬래시 명령어라는 게 /clear나 /session 같은 형태인데요, 터미널에서 Copilot한테 정확히 뭘 하라고 지시할 때 쓰는 거예요.

명령어들이 꽤 많은데, 핵심만 추리면 이렇게 정리돼요:

• 세션 관리: /clear로 대화 초기화, /session으로 사용량 확인
• 파일 접근: /add-dir로 디렉토리 추가, /cwd로 작업 디렉토리 관리
• 설정: /model로 AI 모델 선택, /theme으로 테마 변경

1인 개발자에게 왜 중요해?

Copilot CLI 쓰시는 분들한테는 정말 실용적인 자료예요. GitHub 공식 블로그에서 직접 추천하는 건 딱 세 개: /clear, /cwd, /model. 이 세 개만 기억하면 기본 워크플로우는 다 통제할 수 있다고 해요.

특히 /clear는 작업 전환할 때 컨텍스트 꼬이는 거 방지하는 데 필수고요, /model은 상황에 따라 다른 모델 쓰고 싶을 때 유용하죠. 1인 개발자분들이 여러 프로젝트 왔다 갔다 하실 때 /cwd도 많이 쓰게 될 거예요.

주의할 점

치트시트가 영어로만 되어 있고, Copilot CLI가 아직 모든 사용자에게 열려 있는 건 아니에요. 구독 상태 확인하시고, 명령어가 안 먹히면 버전 업데이트부터 해보세요.

참고: The GitHub Blog

2. SMS 로그인 링크 보안 취약점

무슨 일이야?

뉴멕시코 대학, 애리조나 대학 등 연구진이 SMS로 보내는 로그인 링크(매직 링크)가 얼마나 위험한지 밝혀냈어요. 175개 이상의 주요 서비스 제공업체가 영향을 받고 있고, 수백만 명의 개인정보가 위험에 노출되어 있다고 해요.

문제의 핵심은 SS7 프로토콜인데요, 1970년대에 만들어진 통신 인프라가 아직도 쓰이고 있어서 SMS가 암호화 없이 전송된다는 거예요. 공격자들이 이걸 이용해서 메시지를 가로채거나, SIM 스와핑 공격을 하거나, 피싱 사이트로 유도할 수 있어요.

1인 개발자에게 왜 중요해?

인증 시스템 구현하시는 분들한테는 정말 중요한 뉴스예요. 편하다고 SMS OTP나 매직 링크 쓰셨던 분들, 이제 다시 생각해보셔야 해요.

2025년에 이미 여러 정부에서 SMS OTP를 금지했고, NIST에서도 피싱 방지 MFA를 권장하고 있어요. FBI도 “제대로 암호화된 앱과 피싱 방지 MFA를 쓰라"고 권고했고요.

대안으로는 **패스키(Passkeys)**가 가장 안전해요. 공개키 암호화를 써서 비밀번호도 SMS OTP도 필요 없고, Face ID나 지문으로 인증하니까요. 아니면 Google Authenticator나 Authy 같은 TOTP 앱도 괜찮아요. 코드가 기기에서 로컬로 생성되니까 네트워크 취약점에 영향을 안 받거든요.

주의할 점

기존 사용자들 마이그레이션이 쉽지 않아요. 패스키로 바꾸려면 사용자 교육도 필요하고, 기기 호환성 문제도 있어요. 점진적으로 전환하되, 최소한 SMS를 유일한 인증 수단으로 쓰지는 마세요.

참고: WebProNews, 1Password Blog

3. Anthropic Claude 헌법 발표

무슨 일이야?

Anthropic이 Claude AI의 새로운 “헌법"을 발표했어요. 무려 23,000단어짜리인데요, 2023년 버전이 2,700단어였던 걸 생각하면 엄청 늘어난 거죠. 단순한 원칙 나열이 아니라 “왜 이렇게 행동해야 하는지"를 Claude가 이해할 수 있도록 설명하는 방식으로 바뀌었어요.

흥미로운 부분들이 많은데요, Claude한테 직접 말하는 형식으로 쓰여 있고, 우선순위도 정해져 있어요: 안전 > 윤리 > 가이드라인 준수 > 도움됨. 그리고 “Claude가 어떤 기능적 형태의 감정이나 느낌을 가질 수 있다"고 인정하는 부분도 있어요.

가장 특이한 건 Anthropic 자체도 거부할 수 있다는 조항이에요. “평화로운 시위대를 향해 총을 쏘라는 명령을 거부하는 군인처럼, Claude도 권력을 부당하게 집중시키는 행동은 Anthropic의 요청이라도 거부해야 한다"고 명시했어요.

1인 개발자에게 왜 중요해?

Claude API 쓰시는 분들한테는 모델이 왜 특정 방식으로 응답하는지 이해하는 데 도움이 돼요. 예전에는 “왜 이건 안 해주지?” 싶었던 것들이 이제 헌법 문서 보면 이유를 알 수 있어요.

프롬프트 엔지니어링 하시는 분들도 이 문서 참고하시면 Claude의 우선순위를 이해하고 더 효과적인 프롬프트를 작성할 수 있을 거예요. 그리고 AI 안전성에 관심 있으시다면 Anthropic이 어떤 철학으로 모델을 훈련시키는지 볼 수 있는 좋은 자료예요.

주의할 점

문서가 영어로 23,000단어라 전부 읽기는 쉽지 않아요. 핵심 부분만 추려서 보시거나, 요약본을 찾아보시는 게 나을 수도 있어요. 그리고 이건 Anthropic의 의도이지, 실제로 Claude가 항상 이렇게 행동한다는 보장은 없어요.

참고: Anthropic 공식, TIME, The Register

4. Gemini vs ChatGPT 비교 테스트

무슨 일이야?

Ars Technica에서 Gemini가 ChatGPT를 넘어섰는지 직접 테스트해봤어요. 결론부터 말하면, 둘 다 쓰는 게 답이에요.

벤치마크 성능에서는 ChatGPT 5.2(Thinking 모드)가 수학과 코딩에서 앞섰어요. AIME 2025에서 100%, SWE-Bench에서 80.0% 기록했는데, Gemini 3 Pro는 SWE-Bench에서 76.2%였거든요. 반면 시각 및 멀티모달 테스트에서는 Gemini가 이겼고, 속도도 Gemini가 더 빨랐어요. 소스 조회 테스트에서 Gemini는 5초, ChatGPT는 25초 걸렸대요.

1인 개발자에게 왜 중요해?

어떤 작업에 어떤 모델을 써야 하는지 알면 시간과 비용을 아낄 수 있어요.

ChatGPT가 나은 경우: 창작 글쓰기, 긴 글 작성, 복잡한 코딩, 깊은 논리적 추론이 필요할 때 Gemini가 나은 경우: 실시간 검색, 최신 정보 조회, Google Workspace 연동 작업

할루시네이션 면에서도 차이가 있어요. Gemini는 시간에 민감한 팩트 체크에서 덜 틀리고, ChatGPT는 일반 지식이나 설명 글쓰기에서 더 일관성 있어요.

구글 생태계 많이 쓰시는 분들한테는 Gemini가 Gmail, Drive, Docs랑 바로 연동되니까 편리하고요. 깊이 있는 사고나 창작이 필요하면 ChatGPT를 쓰시면 돼요.

주의할 점

비교 테스트 결과가 항상 여러분의 유즈케이스에 맞는 건 아니에요. 직접 써보시고 본인 작업에 뭐가 맞는지 확인해보세요. 그리고 둘 다 유료 플랜이 있어서, 둘 다 쓰면 비용이 두 배예요.

참고: Cybernews, G2, DigitalOcean

5. Technical Writers Are Not Junior Developers

무슨 일이야?

DEV.to에 올라온 글인데요, 기술 문서 작성자(Technical Writer)를 주니어 개발자처럼 취급하는 문제를 지적하고 있어요. “Git 정도는 알겠지"라고 가정하는 채용 공고, 개발자 중심으로 설계된 워크플로우, 심지어 문서 플랫폼까지 이런 가정이 깔려 있다고 해요.

저자의 핵심 주장은 이거예요: 기술 문서 작성자는 엔지니어링으로 가는 길목에 있는 게 아니라, 그만큼 중요한 평행 트랙에 있는 전문가라는 거죠. 좋은 문서는 그냥 쓰는 게 아니라 설계하고, 큐레이션하고, 유지보수하는 거고, 지식이 어떻게 흐르는지 아는 사람이 해야 한다고요.

1인 개발자에게 왜 중요해?

1인 개발자분들은 코드도 쓰고 문서도 쓰고 다 하셔야 하잖아요. 그런데 문서 쓸 때 “개발하다 남는 시간에 대충 쓰면 되지” 생각하셨다면, 이 글이 관점을 바꿔줄 수 있어요.

문서화가 실패하는 건 도구가 부족해서가 아니라 역할을 잘못 이해해서라고 해요. 문서 작성을 개발의 부산물이 아니라 별도의 전문 영역으로 보면, 어떻게 접근해야 하는지도 달라지거든요.

외주를 맡기실 때도 마찬가지예요. 기술 문서 작성자를 주니어 개발자 급여로 구하시면 안 된다는 거죠.

주의할 점

이 글이 모든 상황에 맞는 건 아니에요. 작은 프로젝트에서는 개발자가 문서도 쓰는 게 현실적이고, 전문 기술 문서 작성자를 고용할 여력이 없는 경우가 많으니까요. 다만 문서화의 중요성을 인식하고, 시간을 따로 배정하는 게 중요해요.

참고: DEV Community

6. DEV.to 통계를 넘어서: 나만의 분석 도구 만들기

무슨 일이야?

DEV.to에 글 쓰시는 분이 플랫폼 제공 통계가 부족해서 직접 분석 도구를 만든 경험담이에요. DEV.to가 보여주는 건 조회수, 반응, 댓글 정도의 스냅샷인데, 저자는 “시간에 따른 이야기"를 보고 싶었대요.

기존 devto-analytics-pro를 기반으로 시작해서, 4~6시간마다 데이터를 수집하는 시스템을 만들었어요. 왜 하루 단위가 아니라 더 자주냐면, 일일 스냅샷은 미세한 변화를 놓치고 다 평평하게 만들어버리거든요. 더 자주 찍으면 “글이 언제 깨어나고, 언제 잠들고, 뭐가 다시 살려내는지” 볼 수 있대요.

저자 말로는 “이 세밀한 기억이 없으면 숫자만 보이지만, 있으면 이야기가 보인다"고요.

1인 개발자에게 왜 중요해?

블로그나 기술 글 쓰시는 분들한테 공감되는 내용이에요. 플랫폼이 제공하는 대시보드가 충분하지 않다고 느끼셨다면, 직접 만드는 것도 방법이라는 거죠.

사실 이건 더 큰 원칙이기도 해요. “플랫폼은 관찰 도구이지, 분석 도구가 아니다”. 플랫폼은 모든 사용자의 상세 이력을 무한정 저장할 수 없으니까요. 내 데이터를 내가 관리하고 싶다면, 직접 시스템을 만들어야 해요.

Python으로 간단하게 시작할 수 있고, 오픈소스 기반이라 참고할 코드도 있어요.

주의할 점

4~6시간마다 데이터 수집하려면 서버나 스케줄러가 필요해요. 무료 티어 클라우드 서비스로 돌릴 수 있지만, 설정하는 데 시간이 좀 들어요. 그리고 DEV.to API 호출 제한도 확인해보셔야 해요.

참고: DEV Community

이번 주 스킵한 소식

엔터프라이즈 전용 솔루션, 대기업 내부 소식 등은 1인 개발자에게 직접적인 도움이 되지 않아 제외했습니다.

1인 개발자 관점에서 기술 소식을 정리하고 있습니다.