바로뉴스

교보문고에 가면 IT 서적은 넘쳐난다

교보문고에 가보면 IT 서적 코너는 항상 넓다.

자바, 파이썬, 리액트, AI, 데이터 분석… 매년 개정판이 쏟아진다.

그런데 나는 문득 이런 생각이 들었다.

"이 많은 개발 서적이 정말 필요한 걸까?"

단순히 “책이 필요 없다”는 말이 아니다. 학습 방식 자체가 시대에 맞는가? 라는 질문이다.

IT 개발 서적, 구조적 한계

IT 분야는 변화 속도가 매우 빠르다.

• 2~3년이면 프레임워크가 바뀌고
• 최신 문법이 추가되며
• 실무 트렌드가 달라진다

그런데 종이책은?

• 집필 → 편집 → 출판 → 유통 → 개정 이 과정을 거친다.

이미 출판 시점에서 일부 내용은 구버전이 된다.

더 중요한 문제

IT 개발은 이론이 아니라 실전 중심 기술이다.

• 실제 프로젝트 경험
• 문제 해결 경험
• 협업 경험
• 코드 리뷰 경험

이런 것들은 책으로 완전히 전달하기 어렵다.

책은 “설명”은 해주지만
“실력”을 만들어주지는 않는다.

내일배움카드 IT 코딩 교육, 정말 효율적인가?

내일배움카드는 취업 준비생과 직장인을 위한 정부 지원 교육 제도다.

취지는 좋다.

• 직무 전환 지원
• 취업 역량 강화
• 재교육 기회 제공

하지만 현실은?

문제점 1. 단기 양산형 개발자 구조

몇 개월 과정으로 “개발자”가 만들어진다.

• 기본 문법 학습
• 포트폴리오 하나 제작
• 취업 시도

하지만 기업이 원하는 건?

• 문제 해결 능력
• 알고리즘 사고력
• 시스템 이해도
• 협업 능력

단기 속성 과정으로는 한계가 있다.

문제점 2. 수요 기반이 아닌 공급 기반

교육기관은 수강생 모집이 목표가 되고
수강생은 수료가 목표가 된다.

하지만 산업 현장의 실제 수요와
완전히 일치한다고 보긴 어렵다.

그렇다면 대안은 무엇인가?

여기서 중요한 건

“IT 교육이 필요 없다”가 아니라
“지금 방식이 최선인가?”라는 질문이다.

정책 방향을 바꿔보면 어떨까?

나는 오히려 이렇게 생각한다.

초·중·고에서 IT를 필수 선택 교육으로

• 국·영·수처럼 기초 디지털 사고력 교육
• 코딩은 “직업 기술”이 아니라 “문해력” 개념으로 접근
• 알고리즘 사고 훈련
• 문제 해결 중심 수업

어릴 때부터 논리적 사고를 기르면
성인이 되어서 단기 코스에 의존할 필요가 줄어든다.

자격증 기반 체계화

• 단계별 디지털 역량 자격 체계
• 국가 공인 IT 사고력 인증
• 단순 문법이 아닌 문제 해결 능력 평가

그렇게 된다면

• 무분별한 학원 양산 감소
• 실력 중심 검증 체계 확립
• 기업 채용 기준 명확화

라는 효과를 기대할 수 있다.

왜 나는 이렇게 생각했는가?

나는 단순히 비판하고 싶어서 이 글을 쓴 것이 아니다.

• IT 서적의 한계
• 단기 코딩 교육의 구조적 문제
• 현장과 교육의 괴리

이 세 가지를 깊이 생각해본 결과다.

현재 시스템은 “기회를 제공하는 구조”는 맞다.

하지만 “근본적 역량을 키우는 구조”라고 보긴 어렵다.

나는 IT 교육 자체를 부정하지 않는다.

오히려 더 중요하다고 생각한다.

하지만

• 단기 속성 교육
• 트렌드 따라가기식 출판
• 취업 마케팅 중심 학원 구조

이 방식이 장기적으로 옳은가에 대해선 의문을 갖는다.

정부 정책도 단기 재교육 중심에서 초·중·고 디지털 사고력 기반 교육 강화로 무게 중심을 옮겨보는 건 어떨까?

그게 더 지속 가능하지 않을까?

이 글은 반박을 피하기 위해 쓴 것이 아니다. 생각해보자는 제안이다.

최근 XR(eXtended Reality, 확장 현실) 기술이 빠르게 성장하면서, AR, VR, MR 개발을 위한 언어와 도구에도 관심이 높아지고 있습니다. 그런데 막상 XR 개발을 시작하려고 보면 “도대체 어떤 언어를 써야 할까?”라는 고민이 생기죠. 오늘은 XR JS, 파이썬, 코틀린, 스위프트를 중심으로 각각의 특징과 활용 사례를 정리해보겠습니다.

1. XR JS: 웹 기반 XR의 시작점

XR JS는 정확히 말하면 하나의 언어가 아니라, 웹 브라우저에서 XR 경험을 구현하기 위한 JavaScript 기반 라이브러리와 프레임워크를 통칭하는 말입니다.

대표적인 예로는:

• Three.js: 3D 그래픽을 웹에서 렌더링할 수 있는 라이브러리
• A-Frame: HTML처럼 간단하게 VR/AR 콘텐츠를 만들 수 있는 프레임워크

특징:

• 웹 브라우저에서 바로 실행 가능 → 설치 없이 접근 가능
• HTML과 JS를 아는 개발자라면 비교적 쉽게 접근 가능

활용 사례:

• 웹 VR 게임
• 온라인 쇼룸에서 AR로 제품 미리보기
• 브라우저 기반 3D 시각화

2. 파이썬(Python): 범용 언어지만 XR 프로토타이핑 가능

파이썬은 데이터 과학, 머신러닝, 웹 개발 등 다방면에서 사랑받는 범용 프로그래밍 언어입니다.

XR과의 연관성:

• 직접 XR 전용 언어는 아니지만, 라이브러리를 활용하면 프로토타입 제작 가능
  • OpenCV: 컴퓨터 비전 기반 AR 구현
  • PyOpenGL / Panda3D: 3D 렌더링 가능

장점:

• 문법이 간단해서 초보자에게 접근성이 좋음
• 빠르게 아이디어를 테스트하고 싶을 때 유리

활용 사례:

• AR 필터 프로토타입
• 데이터 기반 3D 시각화

3. 코틀린(Kotlin): 안드로이드 XR 개발의 핵심

코틀린은 주로 Android 앱 개발용으로 사용되는 언어입니다. 자바(Java)와 완벽하게 호환되면서 현대적인 문법과 안전성을 제공합니다.

XR과의 연관:

• Android 기반 AR 앱 개발 시 ARCore와 함께 사용 가능

장점:

• 안드로이드 네이티브 앱과 자연스럽게 통합 가능
• 모던한 언어 특성 덕분에 코드 안정성 높음

활용 사례:

• AR 게임
• AR 내비게이션 앱
• AR 교육용 앱

4. 스위프트(Swift): iOS XR의 공식 언어

스위프트는 Apple 생태계(iOS, macOS, iPadOS) 앱 개발을 위한 주력 언어입니다.
ARKit과 결합하면 iOS 기반 AR 앱 개발이 가능합니다.

장점:

• 안전하고 빠른 코드 실행
• Apple 기기 전용 기능과 최적화 용이

활용 사례:

• iPhone/iPad용 AR 쇼핑 앱
• AR 측정 도구
• AR 게임

정리: 각 언어와 XR의 관계

결론

• 웹 기반 XR: XR JS(A-Frame, Three.js)
• 빠른 프로토타이핑: Python
• Android XR 앱: Kotlin + ARCore
• iOS XR 앱: Swift + ARKit

결국 어떤 플랫폼에서 XR을 구현하고 싶은지가 언어 선택의 기준이 됩니다.
웹에서 쉽게 접근할지, 모바일 앱으로 본격 배포할지에 따라 선택지가 달라지죠.

전 세계 개발자들이 애용하는 텍스트 에디터 Notepad++가 심각한 사이버 공격의 표적이 되었다는 충격적인 소식이 전해졌습니다.

가볍고 빠르며 강력한 기능을 갖춘 이 오픈소스 에디터는 오랜 시간 개발자들의 필수 도구로 자리 잡아왔습니다. 그러나 이번 사건은 단순한 해킹을 넘어, 소프트웨어 공급망 전체의 보안 문제를 다시금 조명하는 계기가 되고 있습니다.

이번 공격의 핵심: ‘공급망 하이재킹’이란?

이번 공격은 일반적인 웹 해킹이나 랜섬웨어와는 차원이 다른 공급망 하이재킹(Supply Chain Hijacking) 유형으로 분류됩니다.

공급망 공격이란?

소프트웨어의 개발 → 빌드 → 배포 → 업데이트 과정 중 하나를 침투해 정상 프로그램에 악성코드를 삽입하는 방식입니다.

사용자가 공식 웹사이트에서 다운로드했더라도 감염될 수 있는 매우 위험한 공격입니다.

보안 전문가들은 이번 공격의 정교함과 은밀함, 그리고 잠재적 영향 범위를 고려할 때, 단순 범죄 조직이 아닌 국가 차원의 지원을 받는 해킹 그룹(APT, Advanced Persistent Threat)의 소행일 가능성을 제기하고 있습니다. 특히 중국 정부와 연계된 APT 조직의 관여 가능성도 언급되고 있습니다.

단순한 소프트웨어 문제가 아니다

이번 사건은 단순히 하나의 에디터가 공격받은 사례가 아닙니다.

이것이 의미하는 것:

• 개발 도구 자체가 공격 경로가 될 수 있음
• 기업 내부망이 간접적으로 침투될 수 있음
• 오픈소스 생태계 전체가 잠재적 공격 표적이 됨
• IT 공급망 전반의 신뢰 모델이 흔들릴 수 있음

오늘날 기업은 자체 보안만 강화해서는 충분하지 않습니다.
사용하는 모든 서드파티 소프트웨어의 신뢰성과 무결성까지 검증해야 하는 시대입니다.

기업이 지금 당장 해야 할 보안 조치

1. 제로 트러스트(Zero Trust) 모델 도입

• 내부 네트워크라도 기본적으로 신뢰하지 않음
• 모든 접근을 지속적으로 검증

2. 서드파티 소프트웨어 감사

• 사용 중인 개발 도구 목록화
• 출처 및 디지털 서명 검증
• 정기적인 무결성 검사

3. 빌드 환경 격리

• 외부 인터넷과 분리된 환경에서 빌드
• 패키지 관리 서버 내부화

개인 개발자가 지켜야 할 보안 수칙

개인 사용자와 개발자도 더 이상 안전지대에 있지 않습니다.

반드시 실천해야 할 것

• ✔ 공식 웹사이트에서만 다운로드
• ✔ 다운로드 파일의 체크섬(Hash) 확인
• ✔ 디지털 서명 검증
• ✔ 자동 업데이트 기능 설정 점검
• ✔ 중요한 작업은 가상환경 또는 격리 환경에서 수행
• ✔ 정기적인 전체 시스템 보안 스캔

현재 상황과 대응

Notepad++ 개발팀은 긴급 보안 패치를 준비 중이며, 사용자들에게 공식 채널을 통한 업데이트만 진행할 것을 강력히 권고하고 있습니다.

또한 이미 설치된 버전의 무결성을 확인할 수 있는 도구도 곧 배포될 예정이라고 합니다.

우리가 배워야 할 교훈

이번 사건은 우리에게 중요한 질문을 던집니다.

우리는 우리가 사용하는 도구를 얼마나 신뢰할 수 있는가?

개발자는 코드만 작성하는 사람이 아닙니다.
자신의 개발 환경 전체를 관리하고 보호하는 책임도 함께 지고 있습니다.

지금이 바로:

• 사용 중인 개발 도구 점검
• 보안 설정 재확인
• 공급망 리스크 점검

을 해야 할 때입니다.

이번 Notepad++ 공급망 공격 사건은 단순한 보안 사고가 아니라, 현대 IT 생태계가 직면한 구조적 위협을 보여주는 사례입니다.

편리함과 신뢰 위에 세워진 오픈소스 생태계는 강력하지만, 그만큼 철저한 검증과 관리가 동반되지 않으면 언제든 위협에 노출될 수 있습니다.

최근에 모아모아 프로젝트의 백엔드를 정리하면서, 기존 Django 기반 구조를 FastAPI로 전환하는 작업을 진행했다. 단순한 프레임워크 교체라기보다는, 앞으로의 확장성과 실험을 염두에 둔 선택이었다.

왜 ? FastAPI

FastAPI를 선택한 가장 큰 이유는 API 중심 아키텍처에 대한 실험적인 고민 때문이다.

카카오, 텔레그램, 토스처럼 서로 성격이 다른 세 가지 플랫폼을 하나의 API 레이어로 통합 제어할 수 있을까? 라는 질문에서 출발했다.

각 플랫폼은 인증 방식도 다르고, 이벤트 흐름도 제각각이지만 FastAPI의 비동기 처리와 명확한 스키마 기반 설계라면 공통 인터페이스를 중심으로 충분히 정리할 수 있겠다는 판단이 들었다.

“한 번에 잘 만들자” 보다는 API로 어디까지 통제가 가능한지 실험해보자는 쪽에 가까운 선택이었다.

Django의 자산은 그대로

기존 Django에서 이미 검증된 기능들은 최대한 유지했다.
비즈니스 로직, 데이터 모델링, 운영 중 쌓인 노하우까지 전부 버리기엔 아까운 자산들이었기 때문이다.

그래서 접근 방식은 단순했다.

• 핵심 도메인 로직은 그대로 유지
• 프레임워크 의존적인 부분만 정리
• 외부 플랫폼 연동은 FastAPI 기준으로 재구성

결과적으로는 “새로 만든다”기보다는 Django에서 FastAPI로 옮겨 담는다는 느낌에 가까웠다.

3가지 플랫폼 통합

카카오, 텔레그램, 토스 — 각각의 요청과 이벤트를 FastAPI 엔드포인트로 흡수하면서 플랫폼별 어댑터 구조를 잡았다.

외부에서는 서로 다른 서비스처럼 보이지만, 내부에서는 동일한 흐름으로 처리되도록 만드는 것이 목표였다.

아직 완벽하다고 보긴 어렵지만, API 하나로 여러 채널을 통제할 수 있다는 가능성은 충분히 확인할 수 있었다.

모아모아 GitHub

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

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

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

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

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

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

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

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

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

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

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

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

어느 날 문득 영화 〈인 타임〉이 떠올랐다.
시간이 곧 돈이고, 손목에 남은 시간이 표시되는 그 세계관.

“이거… 스마트워치로 비슷한 거 만들어볼 수 있지 않을까?”

생각이 들자마자 바로 필요한 게 떠올랐다.

일단 스마트워치부터 필요했다

핵심은 손목이다.
그래서 후보는 자연스럽게 두 가지.

• 애플 워치
• 갤럭시 워치

하지만 현실적인 문제, 바로 가격.
애플 워치는 중고라도 부담이 컸고, 이것저것 알아보다 보니 갤럭시 워치가 그나마 저렴했다.

결국 선택은 갤럭시 워치.

가격은… 5만 원 어디서 샀는지는… 비밀

중고지만 상태는 만족

며칠 뒤 물건이 도착했다.
중고라서 살짝 걱정했지만,

• 외관 괜찮고
• 전원 잘 들어오고
• 터치도 문제 없음

“오케이, 이 정도면 충분하다.”

이제 진짜 중요한 단계로 넘어간다.

개발은 뭘로 하지?

평소에 Flutter를 쓰고 있었기 때문에
당연히 이렇게 생각했다.

“Flutter로 워치 앱도 만들 수 있겠지?”

…라고 생각했는데
조금 더 찾아보니 현실은 달랐다.

갤럭시 워치는 Flutter가 아니다

갤럭시 워치 앱 개발을 하려면 코틀린(Kotlin) 이 필요했다.

• 안드로이드 기반
• Wear OS
• 네이티브 개발 필수

Flutter로 한 번에 처리할 수 있을 줄 알았는데,
언어부터 다시 시작해야 하는 상황.

잠깐 고민, 그리고 결론

솔직히 잠깐 망설였다.

• 새로운 언어
• 새로운 플랫폼
• 새로운 환경

하지만 이런 생각이 들었다.

“그래, 어차피 재미로 시작한 건데
안 해보면 더 아쉽지.”

그래서 결론은 하나.

음… 그래, 만들어보자!

완벽하지 않아도 되고 영화처럼 멋지지 않아도 된다.

• 손목에 시간이 표시되고
• 시간이 줄어들고
• ‘인 타임’ 느낌만 나도 성공

이 프로젝트는 그렇게 시작됐다.

다음 목표는 코틀린으로 갤럭시 워치 첫 앱 띄워보기 과연 어디까지 갈 수 있을지는 모르겠지만, 일단은 한 걸음 내디뎠다.

계속 만들어보자.

그리고 갤럭시용 으로 제작이 완료 되면 바로 애플워치용 을 위해서 구매.

제목

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을 쓰고 싶은 경우