Tech Lead가 되면 반드시 듣게 되는 질문입니다. 팀원들은 자신이 어디로 가고 있는지 알고 싶어합니다. 내년에도 이 기술을 쓸 건지, 새로운 걸 배워야 하는지, 이 프로젝트가 끝나면 뭘 하게 되는지.

기술 로드맵은 이 질문에 대한 답입니다. 단순히 "이런 기술 쓸 거예요"가 아니라, 왜 그 방향으로 가는지, 언제쯤 도달할 수 있는지, 각자 무엇을 준비해야 하는지를 보여주는 지도입니다.

이 글에서는 실제로 활용할 수 있는 기술 로드맵 예시들을 공유합니다.

기술 로드맵이 필요한 이유

로드맵 없이 일하면 어떻게 될까요?

급한 일에 치여서 기술 부채만 쌓입니다. 팀원마다 다른 방향으로 학습합니다. 새로운 기술 도입이 "그때그때 기분"에 따라 결정됩니다. 결국 1년이 지나도 팀의 기술 역량은 제자리입니다.

로드맵이 있으면 달라집니다.

팀 전체가 같은 방향을 봅니다. 학습에 투자할 시간을 확보할 명분이 생깁니다. 기술 도입의 기준이 명확해집니다. 채용할 때도 "이런 역량을 가진 사람이 필요하다"고 말할 수 있습니다.

예시 1: 분기별 기술 로드맵

가장 기본적인 형태입니다. 분기별로 주요 기술 목표를 정리합니다.

2025년 기술 로드맵

Q1: 안정성 강화

지금 가장 아픈 곳부터 치료합니다. 장애가 나면 원인 파악에 너무 오래 걸린다는 피드백이 있었습니다.

주요 과제는 다음과 같습니다. Grafana 대시보드 구축으로 시스템 상태를 한눈에 볼 수 있게 합니다. 알림 체계를 정비해서 장애 감지 시간을 줄입니다. SLO(Service Level Objective)를 정의해서 "어느 정도면 괜찮은 건지" 기준을 만듭니다.

기대 효과는 장애 감지 시간 50% 단축입니다.

Q2: 성능 최적화

안정성이 확보되면 성능을 개선합니다. 주문 조회 API가 느리다는 CS가 꾸준히 들어오고 있습니다.

주문 조회 API에 캐싱 전략을 적용합니다. 슬로우 쿼리를 분석하고 인덱스를 최적화합니다. 불필요한 N+1 쿼리를 제거합니다.

기대 효과는 API 응답 시간 30% 개선입니다.

Q3: 확장성 확보

하반기 프로모션 시즌을 대비합니다. 작년 블랙프라이데이에 트래픽 2배 증가로 서버가 힘들었습니다.

주문 서비스를 MSA(Microservices Architecture)로 분리합니다. 이벤트 기반 아키텍처로 전환해서 서비스 간 결합도를 낮춥니다. Auto Scaling 정책을 고도화합니다.

기대 효과는 피크 트래픽 2배 대응입니다.

Q4: 개발 생산성

연말에는 내년을 준비합니다. 올해 불편했던 개발 환경을 개선합니다.

CI/CD 파이프라인을 개선해서 배포 시간을 단축합니다. 테스트 자동화 커버리지를 확대합니다. AI 코딩 도구를 공식 도입합니다.

기대 효과는 배포 주기를 주 1회에서 일 1회로 단축하는 것입니다.

예시 2: 카테고리별 로드맵

기술 영역별로 나눠서 보면 더 명확합니다.

Infrastructure 로드맵

현재 EC2 단일 서버에서 수동 배포하고 있습니다. CloudWatch 기본 모니터링만 사용 중입니다.

6개월 후에는 Auto Scaling을 적용하고, Jenkins로 CI/CD를 구축합니다. Grafana와 Prometheus로 모니터링을 고도화합니다.

12개월 후에는 EKS(Elastic Kubernetes Service) 전환을 검토합니다. GitOps 방식으로 ArgoCD를 도입합니다. 통합 Observability 플랫폼을 구축합니다.

Backend 로드맵

현재 Spring Boot 2.7 기반 모놀리식 구조입니다. JUnit 단위 테스트만 있습니다.

6개월 후에는 Spring Boot 3.x로 마이그레이션합니다. 도메인별로 모듈을 분리합니다. 통합 테스트를 확대합니다.

12개월 후에는 Virtual Thread를 적용해서 동시성을 개선합니다. 핵심 도메인을 MSA로 분리합니다. E2E(End-to-End) 테스트를 자동화합니다.

Data 로드맵

현재 MySQL 단일 DB에 로컬 캐시를 사용합니다. 배치 ETL(Extract, Transform, Load)로 데이터를 처리합니다.

6개월 후에는 Read Replica를 구성해서 읽기 부하를 분산합니다. Redis 클러스터를 도입합니다. 실시간 CDC(Change Data Capture) 파이프라인을 구축합니다.

12개월 후에는 샤딩 전략을 수립합니다. 캐시 히트율 95%를 달성합니다. 데이터 레이크를 구축합니다.

예시 3: 문제 해결 중심 로드맵

"어떤 기술을 쓸 것인가"보다 "어떤 문제를 해결할 것인가"에 집중하는 방식입니다. 팀원들이 공감하기 쉽습니다.

문제 1: 배포가 무섭다

롤백이 어렵고, 배포할 때마다 긴장됩니다. 금요일 오후에는 아무도 배포하려 하지 않습니다.

1월에 Feature Flag를 도입합니다. 코드는 배포하되, 기능은 플래그로 켜고 끌 수 있게 합니다. 문제가 생기면 플래그만 끄면 됩니다.

2월에 Blue-Green 배포를 구성합니다. 새 버전을 별도 환경에 띄우고, 문제없으면 트래픽을 전환합니다. 롤백은 트래픽을 되돌리면 끝입니다.

3월에 Canary 배포를 자동화합니다. 새 버전에 트래픽 1%만 보내서 테스트하고, 점진적으로 늘립니다.

문제 2: 장애 원인 파악이 오래 걸린다

장애가 나면 로그를 뒤지느라 30분 이상 걸립니다. 어디서 문제가 생겼는지 찾기 어렵습니다.

2월에 구조화된 로깅을 표준화합니다. JSON 형식으로 통일하고, 필수 필드를 정의합니다. 검색이 쉬워집니다.

4월에 분산 추적을 도입합니다. 요청이 여러 서비스를 거칠 때 하나의 ID로 추적할 수 있게 합니다. 어디서 느려졌는지 한눈에 보입니다.

6월에 자동 알림과 Runbook을 연동합니다. 알림이 오면 "이럴 때는 이렇게 하세요"가 같이 옵니다. 새벽에 장애 콜 받아도 당황하지 않습니다.

문제 3: DB가 병목이다

피크 시간에 DB CPU가 100%를 찍습니다. 커넥션 풀이 고갈되어 장애가 난 적도 있습니다.

1월에 슬로우 쿼리를 분석합니다. 상위 10개 쿼리를 최적화하고 인덱스를 추가합니다. 가장 빠르게 효과를 볼 수 있는 방법입니다.

3월에 Read Replica를 구성합니다. 읽기 트래픽을 분산해서 Primary DB 부하를 줄입니다.

4월에 핫 데이터를 Redis에 캐싱합니다. 자주 조회되는 데이터는 DB까지 가지 않습니다.

6월에 CQRS(Command Query Responsibility Segregation) 패턴을 부분 적용합니다. 쓰기와 읽기를 분리해서 각각 최적화합니다.

문제 4: 신규 입사자 온보딩이 오래 걸린다

새로 온 사람이 첫 PR을 올리기까지 2주 이상 걸립니다. 로컬 환경 세팅에서 막히고, 코드 구조를 파악하느라 힘들어합니다.

1월에 개발 환경을 Docker Compose로 통합합니다. 명령어 하나로 로컬 환경이 뜹니다. "내 PC에서는 되는데요"가 사라집니다.

2월에 아키텍처 문서를 정비합니다. 시스템 구조도, 핵심 플로우, 주요 컴포넌트 설명을 문서화합니다.

3월에 온보딩 체크리스트와 튜토리얼 과제를 만듭니다. 첫 주에 뭘 해야 하는지 명확하고, 작은 과제를 완료하면서 자신감을 얻습니다.

예시 4: 팀 역량 기반 로드맵

기술만 보면 안 됩니다. 그 기술을 다룰 사람이 있어야 합니다.

현재 팀 상황

인원은 5명입니다. 시니어 1명, 미드레벨 2명, 주니어 2명입니다. 강점은 Spring Boot와 MySQL입니다. 약점은 인프라, 모니터링, 테스트입니다.

역량 성장 로드맵

1~2월에는 Docker와 컨테이너 기초를 학습합니다. 내부 스터디로 주 1회 진행하고, 시니어가 리드합니다.

3~4월에는 Kubernetes 입문을 진행합니다. 외부 교육을 수강하고, 스테이징 환경에서 실습합니다.

5~6월에는 모니터링을 학습합니다. Prometheus와 Grafana를 실제 서비스에 적용하는 프로젝트를 진행합니다.

7~8월에는 테스트 자동화에 집중합니다. 커버리지를 50%에서 70%로 올리는 것이 목표입니다. 주니어 전원이 참여해서 테스트 작성 역량을 키웁니다.

9~10월에는 Kafka를 심화 학습합니다. 이벤트 소싱 패턴을 적용해봅니다.

11~12월에는 성능 테스트와 튜닝을 배웁니다. k6를 도입하고 부하 테스트를 정례화합니다.

중요한 것은 업무와 병행할 수 있는 속도로 계획하는 것입니다. 한 번에 너무 많은 것을 배우려고 하면 아무것도 제대로 못 합니다.

예시 5: OKR 연계 로드맵

회사에서 OKR(Objectives and Key Results)을 쓴다면, 기술 로드맵도 연계해야 합니다. 그래야 "기술 과제에 시간 쓰는 것"을 정당화할 수 있습니다.

Objective 1: 시스템 안정성 99.9% 달성

Key Result 1은 MTTR(Mean Time To Recovery) 30분 이내입니다. 이를 위해 자동 알림 체계를 구축하고 Runbook을 정비합니다. Q1에 완료합니다.

Key Result 2는 월간 장애 건수 2건 이하입니다. 카오스 엔지니어링을 도입하고 장애 훈련을 진행합니다. Q2에 완료합니다.

Key Result 3은 핵심 API 응답 시간 p99 500ms 미만입니다. 캐싱 전략을 적용하고 쿼리를 최적화합니다. Q1~Q2에 걸쳐 진행합니다.

Objective 2: 개발 생산성 2배 향상

Key Result 1은 배포 리드타임 1일 이내입니다. CI/CD 파이프라인을 개선합니다. Q1에 완료합니다.

Key Result 2는 테스트 커버리지 70%입니다. 테스트 자동화를 확대하고 TDD(Test-Driven Development) 교육을 진행합니다. Q1~Q2에 걸쳐 진행합니다.

Key Result 3은 코드 리뷰 응답 시간 4시간 이내입니다. 리뷰 가이드라인을 만들고 자동 할당을 도입합니다. Q1에 완료합니다.

이렇게 연계하면 경영진에게 "이 기술 과제가 왜 중요한지"를 설명하기 쉽습니다.

기술 로드맵 작성 팁

현실적으로 작성하라

리소스를 고려해야 합니다. 5명이서 1년에 할 수 있는 일은 한정되어 있습니다. 한 분기에 큰 변화 1~2개가 현실적입니다. 야심 찬 계획을 세우고 매번 실패하면, 로드맵에 대한 신뢰가 사라집니다.

Why를 명확히 하라

"왜 이 기술을?"에 대한 답이 있어야 합니다. "요즘 핫해서", "다른 회사도 쓰니까"는 이유가 아닙니다. 비즈니스 목표와 연결되어야 합니다. "피크 시간 장애를 줄이기 위해"처럼 구체적이어야 합니다.

유연하게 운영하라

로드맵은 계획이지, 계약이 아닙니다. 분기마다 리뷰하고 조정합니다. 비즈니스 상황이 바뀌면 우선순위도 바뀔 수 있습니다. 중요한 것은 방향성이지, 세부 일정이 아닙니다.

팀과 함께 만들어라

Tech Lead가 혼자 만들어서 "이거 해"라고 하면 실패합니다. 팀원들의 의견을 수렴하고, 공감대를 형성해야 합니다. 본인이 참여해서 만든 로드맵은 주인의식을 갖게 됩니다.

공유하고 투명하게 운영하라

팀 전체가 로드맵을 알고 있어야 합니다. 위키나 노션에 공개하고, 정기적으로 진행 상황을 공유합니다. 진행이 안 되면 안 되는 대로, 되면 되는 대로 솔직하게 이야기합니다.

마무리: 완벽한 로드맵은 없다

처음부터 완벽한 로드맵을 만들려고 하지 마세요. 시작이 중요합니다.

일단 만들어서 공유하고, 피드백을 받고, 수정하면 됩니다. 3개월만 지나도 "그때는 왜 저런 걸 중요하다고 생각했지?"라는 항목이 생깁니다. 괜찮습니다. 그게 정상입니다.

로드맵의 가치는 완벽함이 아니라, 팀이 같은 방향을 보게 만드는 것입니다.

다음에 팀원이 "우리 기술 방향이 뭐예요?"라고 물으면, 자신 있게 보여줄 수 있는 로드맵을 만들어 보세요.

이 글이 도움이 되셨다면 공유 부탁드립니다. 질문이나 의견은 댓글로 남겨주세요.

저는 직장을 다니면서 6년간 친구들과 창업을 준비했습니다. 자본이 넉넉하지 않았기에 모든 기술적 선택에서 "이게 정말 필요한가?", "더 저렴한 방법은 없는가?"를 고민할 수밖에 없었습니다. 그 경험이 지금의 비용 관점을 형성하는 데 큰 영향을 주었습니다.

이 글에서는 Tech Lead가 비용 관점에서 고려해야 할 구체적인 방안들을 정리해 보겠습니다.

1. 인프라 비용 최적화

클라우드 시대에 인프라 비용은 곧 운영 비용입니다. 잘못된 설정 하나가 매달 수백만 원의 차이를 만들 수 있습니다.

클라우드 리소스 관리

가장 흔한 실수는 over-provisioning입니다. "혹시 모르니까" 큰 인스턴스를 선택하고, 실제 사용률은 10%도 안 되는 경우가 많습니다.

• 실제 사용량을 모니터링하고 적정 인스턴스 타입 선정

• Reserved Instance나 Savings Plans로 장기 비용 30~50% 절감

• 배치 작업이나 테스트 환경에는 Spot Instance 활용

• 좀비 리소스 정기 점검 (미사용 인스턴스, 오래된 스냅샷, 방치된 EIP)

Auto Scaling 전략

트래픽 패턴을 분석하면 비용 절감 포인트가 보입니다. 대부분의 서비스는 피크 시간대가 정해져 있습니다.

• 피크 시간대만 스케일 아웃

• 야간, 주말에는 최소 인스턴스로 스케일 다운

• 개발/스테이징 환경은 업무 시간 외 자동 종료

데이터 비용

데이터는 쌓이기만 하고 지우지 않으면 비용이 계속 증가합니다.

• S3 스토리지 클래스 활용 (자주 접근하지 않는 데이터는 Glacier로)

• 데이터 전송 비용 최적화 (같은 리전 내 통신, CloudFront 활용)

• 로그 보관 주기 정책 수립 (무한정 보관은 비용 폭탄)

2. 기술 부채 관리

기술 부채는 "나중에 갚으면 된다"고 생각하기 쉽지만, 이자가 붙습니다. 방치된 기술 부채는 개발 속도 저하, 장애 빈도 증가, 팀원 이탈로 이어집니다.

측정과 가시화

보이지 않는 것은 관리할 수 없습니다. 기술 부채를 정량화해야 합니다.

기술 부채를 백로그에 등록하고, 가능하면 비용으로 환산합니다. "이 레거시 코드 때문에 매번 배포할 때마다 2시간씩 추가 작업이 필요하다"처럼 구체적으로 표현하면 비개발 직군도 이해할 수 있습니다.

전략적 상환

모든 부채를 한 번에 갚을 수는 없습니다. 전략이 필요합니다.

• 스프린트마다 일정 비율(예: 20%)을 기술 부채 해소에 할당

• 비즈니스 임팩트가 큰 부분부터 우선 처리

• "완벽한 리팩토링"보다 "점진적 개선" 추구

예방이 최선

새로운 부채가 생기는 것을 막는 게 가장 효율적입니다.

코드 리뷰에서 "빠른 해결책"과 "올바른 해결책"의 트레이드오프를 명시적으로 논의합니다. 일정 때문에 의도적으로 부채를 지는 경우, 반드시 문서화하고 상환 계획을 세웁니다.

3. Build vs Buy 의사결정

직접 만들 것인가, 사서 쓸 것인가. 이 결정이 수개월의 개발 시간과 수천만 원의 비용을 좌우합니다.

분석 프레임워크

단순히 "라이선스 비용"만 비교하면 안 됩니다.

총 비용 = 초기 구축 비용 + 유지보수 비용 + 기회비용

직접 개발하면 라이선스 비용은 없지만, 개발 시간, 버그 수정, 보안 패치, 문서화 등의 숨겨진 비용이 있습니다. 그 시간에 핵심 기능을 개발했다면 얻었을 가치(기회비용)도 고려해야 합니다.

판단 기준

• 핵심 역량인가?: 우리 서비스의 차별화 요소가 아니면 Buy

• 전문성이 있는가?: 팀 내 해당 기술 전문가가 없으면 Buy

• 유지보수할 여력이 있는가?: 만들고 방치할 거면 차라리 Buy

인증, 결제, 모니터링, 로깅 같은 범용 기능은 대부분 Buy가 답입니다. 반면 핵심 비즈니스 로직은 Build해야 합니다.

Vendor Lock-in 주의

SaaS 도입 시 vendor lock-in 리스크를 평가해야 합니다. 나중에 다른 솔루션으로 전환할 때 드는 비용도 총 비용에 포함시켜야 합니다.

4. 개발 생산성 = 비용

개발자의 시간은 가장 비싼 자원입니다. 생산성 향상은 곧 비용 절감입니다.

재작업 최소화

가장 큰 낭비는 재작업입니다. 요구사항이 불명확해서 다시 만들고, 기술 검증 없이 진행했다가 엎어지는 경우가 많습니다.

• 요구사항 명확화에 충분한 시간 투자 (PRD 리뷰, 기술 스펙 문서)

• POC(Proof of Concept)로 기술 리스크 조기 검증

• 점진적 배포로 피드백 루프 단축

개발 환경 효율화

"내 로컬에서는 되는데요"를 없애야 합니다.

• 로컬 개발 환경 세팅 자동화 (Docker Compose, 스크립트)

• CI/CD(Continuous Integration/Continuous Deployment) 파이프라인 최적화 (빌드 시간 단축)

• AI 도구 적극 활용 (GitHub Copilot, Claude Code 등)

현실적 일정 산정

낙관적 산정은 결국 야근 비용으로 돌아옵니다.

과거 유사 작업 데이터를 기반으로 추정하고, 적절한 버퍼를 포함합니다. "3일이면 될 것 같아요"라는 말을 들으면 "최악의 경우는요?"라고 물어봅니다.

5. 아키텍처 레벨 비용 설계

아키텍처 결정은 장기적인 비용 구조를 결정합니다. 한 번 잘못 선택하면 수정 비용이 매우 큽니다.

적정 기술 선택

기술적으로 멋진 것과 비즈니스에 적합한 것은 다릅니다.

작은 서비스에 Kubernetes를 도입하면 운영 오버헤드가 서비스 개발보다 커질 수 있습니다. 트래픽 규모, 팀 역량, 운영 비용을 종합적으로 고려해야 합니다.

• 서버리스 vs 컨테이너 vs VM 비용 비교

• 마이크로서비스 도입 시점 신중히 판단 (복잡성도 비용)

• "나중에 트래픽이 많아지면"보다 "지금 필요한 것"에 집중

데이터베이스 전략

데이터베이스는 보통 가장 큰 비용 항목 중 하나입니다.

• Read Replica 활용으로 읽기 부하 분산

• 캐시 레이어(Redis) 적극 활용으로 DB 부하 감소

• 적절한 인덱싱으로 쿼리 성능 최적화 (느린 쿼리 = 높은 비용)

6. 모니터링 & 비용 거버넌스

비용 관리는 한 번 설정하고 끝나는 게 아닙니다. 지속적인 모니터링과 개선이 필요합니다.

비용 가시화

보이지 않으면 관리할 수 없습니다.

• AWS Cost Explorer 대시보드 구성

• Budget Alerts로 임계치 초과 시 알림

• 팀/프로젝트별 태깅으로 비용 귀속

• 월간 비용 리뷰 정례화

이상 탐지

비정상적인 비용 증가를 빠르게 감지해야 합니다.

비용이 갑자기 급증하면 알림이 오도록 설정합니다. 원인 분석 프로세스를 미리 정해두면 대응 속도가 빨라집니다.

마무리: 비용 감각은 경험에서 나온다

이 글에서 다룬 내용들은 책이나 강의로도 배울 수 있습니다. 하지만 진짜 비용 감각은 실제로 돈이 부족한 상황에서 길러집니다.

저는 6년간의 창업 준비 과정에서 "이번 달 AWS 비용을 줄이지 않으면 다음 달 개발을 못 한다"는 절박함을 경험했습니다. 그 경험이 지금 Tech Lead로서 비용 관점의 의사결정을 하는 데 큰 자산이 되고 있습니다.

Tech Lead를 목표로 하는 분들께 권합니다. 사이드 프로젝트라도 좋으니 직접 돈을 내고 서비스를 운영해 보세요. 본인 돈이 나가기 시작하면 비용 최적화에 대한 감각이 급격히 발달합니다.

좋은 Tech Lead는 기술로 문제를 해결하고, 훌륭한 Tech Lead는 비용을 고려한 기술로 문제를 해결합니다.

이 글이 도움이 되셨다면 공유 부탁드립니다. 질문이나 의견은 댓글로 남겨주세요.

Spring Boot 애플리케이션을 개발할 때 외부 API 요청을 모니터링하고 디버깅하기 위해 HTTP Toolkit을 사용하는 경우가 많습니다. 이 글에서는 IntelliJ IDEA에서 HTTP Toolkit으로 프록시 설정하는 방법을 단계별로 설명하겠습니다.

1. HTTP Toolkit 설정

먼저 HTTP Toolkit을 실행하고 프록시 서버를 시작합니다.

1. HTTP Toolkit 실행

2. "Intercept HTTP" 클릭

3. 프록시 포트 확인 (기본값: 8000번 포트)

2. IntelliJ IDEA에서 사용하는 JDK 확인

프록시 설정 전에 IntelliJ에서 사용하는 JDK 버전을 확인해야 합니다. 이는 후에 HTTPS 인증서 문제를 해결할 때 중요합니다.

프로젝트 JDK 확인

1. File → Project Structure (또는 Cmd + ;)

2. Project Settings → Project

3. Project SDK 확인

   • 예: corretto-17.0.15, openjdk-11, Oracle OpenJDK 21 등

IntelliJ에서 JDK 경로 확인

터미널을 사용하지 않고 IntelliJ에서 직접 JDK 경로를 확인할 수 있습니다.

1. File → Project Structure (또는 Cmd + ;)

2. Platform Settings → SDKs 선택

3. 사용 중인 JDK 선택 (예: corretto-17)

4. JDK home path 확인

   • 예: ~/Library/Java/JavaVirtualMachines/corretto-17.0.15/Contents/Home

이 경로가 나중에 인증서를 추가할 때 필요한 Java 설치 경로입니다.

3. IntelliJ IDEA 프록시 설정

방법 1: Run Configuration에서 JVM 옵션 설정 (권장)

가장 간단하고 효과적인 방법입니다.

1. Run → Edit Configurations

2. 해당 Spring Boot 애플리케이션 선택

3. VM options 필드에 다음 옵션 추가:

-Dhttp.proxyHost=127.0.0.1
-Dhttp.proxyPort=8000
-Dhttps.proxyHost=127.0.0.1
-Dhttps.proxyPort=8000

방법 2: Environment Variables 설정

같은 Run Configuration에서 Environment variables에 추가:

HTTP_PROXY=http://127.0.0.1:8000
HTTPS_PROXY=http://127.0.0.1:8000

방법 3: IDE 전체 프록시 설정

IDE 전체에 프록시를 적용하려면:

1. File → Settings (또는 Cmd + ,)

2. Appearance & Behavior → System Settings → HTTP Proxy

3. Manual proxy configuration 선택

4. HTTP와 HTTPS 프록시 설정:

   • Host: 127.0.0.1

   • Port: 8000

5. Check connection 버튼으로 연결 테스트

4. HTTPS 인증서 문제 해결

HTTP 요청은 바로 캡처되지만, HTTPS 요청 시 다음과 같은 SSL 에러가 발생할 수 있습니다:

javax.net.ssl.SSLHandshakeException: PKIX path building failed: 
sun.security.provider.certpath.SunCertPathBuilderException: 
unable to find valid certification path to requested target

이 문제를 해결하기 위해 HTTP Toolkit의 CA 인증서를 Java keystore에 추가해야 합니다.

HTTP Toolkit CA 인증서 위치 확인

# macOS
ls -la ~/Library/Preferences/httptoolkit/ca.pem

# Windows
dir %APPDATA%\httptoolkit\ca.pem

# Linux
ls -la ~/.config/httptoolkit/ca.pem

Java keystore에 인증서 추가

앞서 확인한 JDK 경로를 사용하여 인증서를 추가합니다:

# 일반적인 macOS OpenJDK 경로
sudo keytool -import -alias httptoolkit \
  -keystore /Library/Java/JavaVirtualMachines/openjdk-11.jdk/Contents/Home/lib/security/cacerts \
  -file ~/Library/Preferences/httptoolkit/ca.pem \
  -storepass changeit -noprompt

# Amazon Corretto 17 예시
sudo keytool -import -alias httptoolkit \
  -keystore ~/Library/Java/JavaVirtualMachines/corretto-17.0.15/Contents/Home/lib/security/cacerts \
  -file ~/Library/Preferences/httptoolkit/ca.pem \
  -storepass changeit -noprompt

인증서 추가 확인

keytool -list -keystore /path/to/java/lib/security/cacerts \
  -storepass changeit | grep httptoolkit

성공 시 출력:

httptoolkit, 2025. 7. 8., trustedCertEntry,

5. 설정 확인 및 테스트

1. 애플리케이션 완전 종료

2. IntelliJ 재시작 (선택사항)

3. HTTP Toolkit 실행 및 프록시 시작

4. Spring Boot 애플리케이션 실행

5. API 요청 실행 후 HTTP Toolkit에서 캡처 확인

6. 문제 해결 팁

프록시가 작동하지 않는 경우

1. HTTP Toolkit 프록시 포트 확인 (기본값: 8000)

2. 방화벽 설정 확인

3. IntelliJ 재시작

4. JVM 옵션 오타 확인

인증서 관련 오류

1. 올바른 JDK 경로 사용 확인

2. keytool 명령어 실행 권한 확인

3. 이미 추가된 인증서 확인

# 기존 인증서 삭제 후 재추가
sudo keytool -delete -alias httptoolkit \
  -keystore /path/to/java/lib/security/cacerts \
  -storepass changeit

# 재추가
sudo keytool -import -alias httptoolkit \
  -keystore /path/to/java/lib/security/cacerts \
  -file ~/Library/Preferences/httptoolkit/ca.pem \
  -storepass changeit -noprompt

마무리

IntelliJ IDEA에서 HTTP Toolkit 프록시 설정은 API 디버깅과 모니터링에 매우 유용합니다. 특히 외부 API 연동 시 요청/응답 데이터를 실시간으로 확인할 수 있어 개발 효율성이 크게 향상됩니다.

권장 설정 순서:

1. JDK 버전 확인

2. Run Configuration에서 JVM 옵션 설정

3. HTTPS 인증서 추가 (필요시)

4. 애플리케이션 재시작 후 테스트

이 방법을 통해 모든 HTTP/HTTPS 요청을 HTTP Toolkit에서 캡처하고 분석할 수 있습니다.

1950년대: 기계 지능 개념의 출발점

앨런 튜링 (Alan Turing, 1912–1954, 영국)

• 인공지능 개념의 철학적 기초 제시자

주요 이력

• (1938) 프린스턴 대학교 박사

설명

• “기계가 생각할 수 있는가?“라는 질문을 던지며 인공지능의 철학적 기초를 마련했습니다.

• 1950년 논문에서 제시한 튜링 테스트는 기계가 인간처럼 행동할 수 있는지를 판별하는 기준으로, 오늘날까지도 AI 판단 기준으로 사용됩니다.

• 그의 이름을 딴 튜링상(Turing Award) 은 컴퓨터 과학 분야의 최고 권위 상입니다.

1960년대: AI 개념 정립과 언어의 등장

존 매카시 (John McCarthy, 1927–2011, 미국)

• “Artificial Intelligence” 용어 창시자

주요 이력

• (1951) 프린스턴 대학교 박사

• (1962 ~ 2000) 스탠퍼드 대학교 교수

설명

• 1956년 다트머스 회의에서 “AI”라는 용어를 처음 제안했습니다.

• LISP 언어 (LISt Processing language) 를 개발해 심볼 기반 처리에 최적화된 함수형 언어를 제공하였고, 이는 AI 연구의 핵심 언어가 되었습니다.

• 1971년 튜링상을 수상했습니다.

1970년대: 인공지능 겨울과 인지과학적 접근

허버트 사이먼 (Herbert Simon, 1916–2001, 미국)

• 인지과학 기반 인공지능 개척자

주요 이력

• (1943) 시카고 대학교 박사

• (1949 ~ 2001) 카네기멜론 대학교 교수

설명

• 앨런 뉴웰과 함께 General Problem Solver (GPS) 를 개발하여 인간의 문제 해결 능력을 모사하려는 시도를 했습니다.

• GPS는 논리적 추론과 수단-목적 분석(means-ends analysis)을 이용해 초기 상태에서 목표 상태까지 문제를 단계적으로 해결하는 방식의 프로그램이었습니다.

• AI와 심리학을 통합한 인지과학 기반 접근으로 1975년 튜링상을 수상했습니다.

1980년대: 전문가 시스템과 지식 기반 AI

에드워드 파이겐바움 (Edward Feigenbaum, 1936– , 미국)

• 전문가 시스템의 선구자

주요 이력

• (1960) 카네기멜론 대학교 박사

• (1965 ~ 2000) 스탠퍼드 대학교 교수

설명

• 전문가 시스템 (Expert System) 은 인간 전문가의 판단을 규칙으로 표현해 컴퓨터가 특정 문제를 해결할 수 있도록 만든 시스템입니다.

• 대표 사례인 MYCIN은 600개 이상의 if-then 규칙을 기반으로 세균성 감염을 진단하고 항생제를 추천했으며, 역방향 연쇄 추론과 설명 기능을 갖췄습니다.

• 전문가 수준의 정확도를 보였으나 의료 책임 문제로 실제 상용화되진 않았습니다.

• 1994년 튜링상을 수상했습니다.

1990년대: AI 비판과 미래 예측의 대두

레이 커즈와일 (Ray Kurzweil, 1948– , 미국)

• 특이점 이론을 통해 AI의 미래를 조망한 인물

주요 이력

• (1970) MIT 학사

• (2012 ~ ) Google 엔지니어링 디렉터

설명

• 『특이점이 온다』를 통해 인간-기계 융합과 초지능 도래 시점을 제시하며 대중적 관심을 이끌었습니다.

• TTS, OCR, 전자 음악 장비 등 실용적 AI 기술도 선도했습니다.

• 1999년 미국 기술훈장을 수상했습니다.

2000년대: 딥러닝 부흥과 구조적 이론 정립

딥러닝 3대장: 힌턴, 르쿤, 벤지오

제프리 힌턴 (Geoffrey Hinton, 1947– , 영국/캐나다)

• 딥러닝 역전파 알고리즘의 부활을 이끈 인물

주요 이력

• (1978) 케임브리지 대학교 박사

• (1987 ~ ) 토론토 대학교 교수

• (2013 ~ ) Google Brain 연구자

설명

• 역전파(backpropagation) 알고리즘을 재조명하며 2012년 AlexNet을 통해 이미지넷 대회 우승을 이끌었습니다.

• AlexNet은 ReLU, 드롭아웃, GPU 병렬 처리 등의 기술로 컴퓨터 비전 성능을 획기적으로 높였으며 딥러닝 대중화의 기폭제가 되었습니다.

얀 르쿤 (Yann LeCun, 1960– , 프랑스/미국)

• 합성곱 신경망(CNN)을 개발한 컴퓨터비전 선구자

주요 이력

• (1987) 피에르 마리 퀴리 대학교 박사

• (2003 ~ ) 뉴욕대학교 교수

• (2013 ~ ) Facebook AI Research 소장

설명

• CNN 구조를 문자 인식, 영상 분석, 자율주행 등에 응용하며 비전 AI의 기틀을 마련했습니다.

요슈아 벤지오 (Yoshua Bengio, 1964– , 캐나다)

• 표현 학습과 심층 신경망 이론의 정립자

주요 이력

• (1991) 맥길 대학교 박사

• (1993 ~ ) 몬트리올 대학교 교수

• (2016 ~ ) Mila 연구소 설립자

설명

• 표현 학습 (Representation Learning) 은 데이터를 이해하기 쉬운 내부 표현으로 자동 변환하는 기술입니다.

• 심층 신경망 (Deep Neural Network) 구조 정립을 통해 오늘날 딥러닝 모델의 이론적 기반을 구축했습니다.

• GAN 창시자인 이안 굿펠로우의 박사 지도교수로도 유명합니다.

2010년대: 초거대 모델과 딥러닝 대중화

일야 수츠케버 (Ilya Sutskever, 1985– , 캐나다)

• GPT 모델 설계와 생성형 AI의 핵심 개발자

주요 이력

• (2012) 토론토 대학교 박사

• (2013 ~ 2015) Google Brain 연구원

• (2015 ~ ) OpenAI 공동 창립자, 수석 과학자

설명

• 힌턴의 박사 제자로서 AlexNet, Seq2Seq (Sequence-to-Sequence) 모델을 개발했고, 이후 GPT 시리즈를 설계하며 생성형 언어모델 기술을 확립했습니다.

• Seq2Seq는 입력 시퀀스를 고정된 벡터로 인코딩하고, 이를 다시 출력 시퀀스로 디코딩하는 구조로, 기계 번역, 요약, 질의응답 등에 널리 사용됩니다.

2020년대: 생성형 AI 상용화와 윤리적 논의

이안 굿펠로우 (Ian Goodfellow, 1985– , 미국)

• 생성적 적대 신경망(GAN) 창시자

주요 이력

• (2014) 몬트리올 대학교 석사

• (2014 ~ 2016) Google Brain 연구원

• (2016 ~ 2022) Apple 및 DeepMind 재직

설명

• GAN (Generative Adversarial Network) 은 생성기와 판별기의 경쟁 구조를 통해 고품질 데이터를 생성하는 모델로, 이미지 생성, 딥페이크 등에 활용됩니다.

샘 알트먼 (Sam Altman, 1985– , 미국)

• OpenAI CEO, 생성형 AI 상용화 선도자

주요 이력

• (2005) 스탠퍼드 대학교 중퇴

• (2014 ~ 2019) Y Combinator 대표

• (2019 ~ ) OpenAI CEO

설명

• GPT-3, ChatGPT 상용화를 통해 생성형 AI를 전 세계에 확산시켰으며, 기술 경영과 윤리 논의 모두를 이끄는 대표적 인물입니다.

데미스 하사비스 (Demis Hassabis, 1976– , 영국)

• 강화학습 기반 인공지능 AlphaGo 개발자

주요 이력

• (2009) UCL 박사

• (2010 ~ ) DeepMind 공동 창립자, CEO

설명

• 강화학습 (Reinforcement Learning) 을 기반으로 한 AlphaGo를 통해 인간 바둑 챔피언을 이긴 최초의 AI를 만들었습니다.

• AlphaFold는 단백질 서열을 입력받아 3차원 구조를 정확히 예측하는 모델로, 생물학 분야에서 AI의 가능성을 증명한 사례입니다.

• AlphaTensor는 딥러닝을 통해 효율적인 행렬 곱셈 알고리즘을 발견한 시스템으로, 수학 문제 해결에 AI를 활용한 대표 사례입니다.

퀵소트(QuickSort)는 분할정복(Divide and Conquer) 전략을 활용한 정렬 알고리즘입니다.

피벗(Pivot)을 기준으로 배열을 분할하고, 각 부분 배열에 대해 재귀적으로 정렬을 수행하여 전체 정렬을 완성합니다.

⚙️ 작동 원리: 분할정복

퀵소트는 다음 세 단계로 구성됩니다.

📌 분할(Partition)의 의미

• 배열의 값을 피벗보다 작거나 같은 값은 왼쪽, 큰 값은 오른쪽으로 분리

• 자기 자신과도 비교하고 필요하면 스왑

• 이 과정에서 피벗의 위치는 정렬된 상태로 확정됨

• 이후 좌/우 하위 배열을 계속 퀵소트로 정렬

🧠 피벗과 파티셔닝은 어떻게 이루어지는가?

파티셔닝이란 피벗 기준으로 배열 요소를 비교하며 자리를 바꾸는 과정입니다.

• 일반적으로 모든 인덱스를 피벗과 비교합니다.

• 자기 자신도 비교 대상이며, 조건 충족 시 자기 자신과도 스왑이 발생합니다.

• 비교 방식 및 스왑 방식은 분할 알고리즘에 따라 달라집니다.

🧭 분할 방식 종류: Hoare vs. Lomuto

🧪 실행 예시 비교 (공통 배열:

[34, 7, 23, 32, 5, 62]

)

✅ Hoare 방식 (피벗: 23)

1. swap(0,4) → [5, 7, 23, 32, 34, 62]

2. left=3, right=2 → 종료

→ 결과: [5, 7, 23, 32, 34, 62]

✅ Lomuto 방식 (피벗: 62)

• 자기 자신과 6번 스왑 발생

• 값 재배치 없이 그대로 [34, 7, 23, 32, 5, 62]

→ 분할만 완료된 상태 (정렬은 이후 진행됨)

💻 자바 구현 예제

1. Hoare 분할 방식

int pivot = arr[(left + right) / 2];
while (left <= right) {
    while (arr[left] < pivot) left++;
    while (arr[right] > pivot) right--;
    if (left <= right) {
        swap(arr, left, right);
        left++; right--;
    }
}

2. Lomuto 분할 방식

int pivot = arr[high];
int i = low - 1;
for (int j = low; j < high; j++) {
    if (arr[j] <= pivot) {
        i++; swap(arr, i, j);
    }
}
swap(arr, i + 1, high);

✅ 정리 요약

ICMP는 단순해 보이지만, 네트워크의 동작과 장애 감지에 매우 핵심적인 역할을 한다.

ICMP란?

ICMP는 IP 패킷 내부에 포함되어 전송되는 제어 메시지용 프로토콜이다.

OSI 7계층 중 3계층인 네트워크 계층 (Layer 3)에서 동작하며,

오류 메시지 전송, 경로 진단, 상태 보고 등 다양한 제어 기능을 담당한다.

어떤 상황에서 쓰일까?

대표적인 메시지 타입

ICMP는 포트가 없다. 그럼 어떻게 구분할까?

보통 TCP나 UDP는 포트 번호로 통신 대상 애플리케이션을 구분한다.

그러나 ICMP는 포트를 사용하지 않는다.

ICMP는 IP 패킷 안의 특별한 필드인 Protocol 번호로 식별된다.

IP 헤더의 Protocol 번호란?

IPv4 헤더에는 다음과 같은 필드들이 포함되어 있는데, 그중 하나가 Protocol이다.

이 값이 다음과 같으면?

즉, 운영체제는 IP 헤더의 이 필드를 보고 이 패킷은 ICMP구나 하고 인식하게 된다.

포트가 없어도 구분 가능한 이유가 여기에 있다.

실제 네트워크 장비에서는?

방화벽, IDS, 트래픽 필터 등은 이 Protocol 번호를 기반으로 ICMP 트래픽을 감지하거나 차단한다.

예를 들어, ping 요청을 막는 것은 Protocol 번호 1번 패킷을 필터링하는 것과 같다.

요약

• ICMP는 네트워크 계층의 제어용 프로토콜이며, ping, traceroute 등에 사용됨

• 오류 상황과 네트워크 진단 메시지를 전달

• 포트 번호는 없지만, IP 헤더의 Protocol 필드 값 1번으로 식별됨

• Layer 3(네트워크 계층)에서 동작하며, IP와 함께 인터넷의 기본 구조를 형성함

1. JWT 구조 예시

JWT는 다음과 같이 3개의 파트로 구성된 문자열입니다:

<헤더>.<페이로드>.<서명>

예시 JWT 문자열

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiJ1c2VyMTIzIiwianRpIjoiYTIzNC1iNTY3LWQ4OWEtZmdoIiwiaWF0IjoxNzE2MjAwMDAsImV4cCI6MTcxNjIwMzYwMCwicm9sZSI6ImFkbWluIn0.
gnI4FbpyNdo7M43OsldBb4XZ9EMWHUuBh6ilAEM_0BE

Base64 디코딩 후 구성 요소

Header (헤더)

{
  "alg": "HS256",
  "typ": "JWT"
}

• alg: 서명 알고리즘 (HMAC-SHA256)

• typ: 토큰 타입 (JWT)

Payload (페이로드)

{
  "sub": "user123",
  "jti": "a234-b567-d89a-fgh",           // JWT ID (고유 식별자)
  "iat": 1716200000,                      // 발급 시각 (UNIX timestamp)
  "exp": 1716203600,                      // 만료 시각 (UNIX timestamp)
  "role": "admin"
}

• sub: 사용자 식별자

• jti: 고유 토큰 ID

• iat: 발급 시각 (예: 2024-05-21 12:00:00)

• exp: 만료 시각 (예: 2024-05-21 13:00:00)

• role: 권한 정보

Signature (서명)

gnI4FbpyNdo7M43OsldBb4XZ9EMWHUuBh6ilAEM_0BE

• 위 Header + Payload를 조합한 후 비밀 키로 HMAC-SHA256 서명한 결과

• 토큰 위조 여부 검증에 사용

2. Signature vs jti: 왜 둘 다 필요한가?

✅ Signature 검증

• 항상 수행

• 토큰 위조 여부 확인

• 비밀 키로 서버가 직접 서명 재생성 → 원본 서명과 비교

Claims claims = Jwts.parser()
  .setSigningKey("my-secret-key".getBytes())
  .parseClaimsJws(jwt)
  .getBody();

✅ jti (JWT ID: JSON Token Identifier) 검증

• 토큰 자체의 고유 식별자

• 블랙리스트, 로그아웃 처리, 재사용 탐지 등에 사용

• 서버는 Redis/DB에서 jti 존재 여부나 상태를 별도로 확인함

String jti = claims.getId();
if (redis.exists("blacklist:" + jti)) {
  throw new TokenRevokedException();
}

3. Redis와 함께 jti 관리하기

예시: RefreshToken 발급 시

• jti(UUID) 생성: a234-b567-d89a-fgh

• Redis 저장

Key: refreshToken:a234-b567-d89a-fgh
Value:
{
  "userId": "user123",
  "ua": "Chrome/122",
  "ip": "192.168.0.1",
  "expiresAt": 1716800000
}
TTL: 7일

로그아웃 시 처리

• 해당 jti를 블랙리스트로 이동

• 이후 모든 요청에서 jti 확인 후 거부 처리

4. AccessToken vs RefreshToken 비교

5. 클라이언트에서 AccessToken 디코딩은 가능할까?

✅ 디코딩은 가능하지만, ❌ 신뢰해서 사용하면 안 됩니다.

안전한 사용 예

6. 최종 정리

• 서명(Signature) 은 토큰이 변조되었는지 판단

• jti (JWT ID) 는 토큰이 아직 유효한지, 서버가 허용하는지 판단

• 보안은 두 단계 모두 필요합니다

마무리

JWT는 위조 방지를 위한 서명 검증(Signature)과

상태 추적을 위한 토큰 식별자(jti)를 함께 활용할 때,

안정적이면서 보안성 높은 인증 시스템을 만들 수 있습니다.

서명은 위조를 막고, jti는 남용을 막는다.

🔍 BPFDoor란 무엇인가?

BPFDoor는 2021년경부터 활동이 관찰된 리눅스 기반의 백도어 악성코드로, Berkeley Packet Filter(BPF)를 악용하여 포트 없이도 외부 명령을 수신할 수 있는 특징을 가집니다. 이는 방화벽이나 침입 탐지 시스템(IDS)을 우회하여 탐지를 어렵게 하며, 특정 “매직 패킷”을 수신할 때만 활성화되어 은밀하게 작동합니다.

🧭 SKT 해킹 사건 개요

• 침입 시점: 2022년 6월 15일경부터 BPFDoor가 SKT 시스템에 잠입하여 활동을 시작한 것으로 추정됩니다.

• 침해 대상: SKT의 핵심 인증 시스템인 Home Subscriber Server(HSS)를 포함한 23대의 리눅스 서버가 감염되었습니다.

• 유출 정보: 국제이동가입자식별번호(IMSI), 유심 고유 식별번호(ICCID), 유심 인증 키 등 약 9.82GB의 데이터가 유출되었습니다.

• 악성코드 종류: BPFDoor 변종 24종과 웹 셸 1종 등 총 25종의 악성코드가 발견되었습니다.

⚠️ BPFDoor의 특징과 위험성

• 포트리스닝 불필요: BPF를 활용하여 포트를 열지 않고도 외부 명령을 수신하므로, 방화벽이나 IDS에 탐지되지 않습니다.

• 은폐성: 정상적인 시스템 프로세스로 위장하고, 로그를 남기지 않아 장기간 탐지되지 않을 수 있습니다.

• 다양한 통신 프로토콜 지원: TCP, UDP, ICMP 등 다양한 프로토콜을 통해 명령을 수신할 수 있습니다.

• APT 공격에 활용: 중국계 해킹 그룹인 Red Menshen이 주로 사용하며, 통신사, 금융기관 등 주요 인프라를 대상으로 한 APT 공격에 활용됩니다.

🛡️ SKT의 대응 조치

• 유심 교체 서비스 제공: 전국 매장에서 무료 유심 교체 서비스를 제공하여, 유출된 인증 정보를 무력화하였습니다.

• 유심 보호 서비스 확대: 유심 복제 및 무단 변경을 방지하는 유심 보호 서비스를 무료로 전환하여 제공하였습니다.

• 보안 시스템 강화: 이상 접근 패턴을 탐지하여 차단하는 시스템을 최고 보안 수준으로 격상시켰습니다.

📌 결론 및 시사점

이번 SKT 해킹 사건은 BPFDoor와 같은 고도화된 악성코드가 국내 주요 인프라에 침투할 수 있음을 보여주며, 통신사 및 기업의 보안 체계 강화의 필요성을 강조합니다. 특히, 포트리스닝 없이도 통신이 가능한 BPFDoor의 특성은 기존 보안 시스템의 한계를 드러내며, 보다 정교한 보안 전략과 실시간 모니터링 체계의 구축이 요구됩니다.

스트리밍 응답 vs 일반 응답

스트리밍의 장단점

장점

1. 빠른 사용자 반응성

   • 전체 결과를 기다리지 않고, 생성되는 즉시 전송 가능

   • 사용자에게 실시간 타이핑 효과 등의 자연스러운 경험 제공

2. 낮은 메모리 사용량

   • 서버나 클라이언트 모두 결과 전체를 메모리에 저장할 필요 없이 처리 가능

3. 대용량 데이터 전송에 적합

   • 수십 MB 이상의 응답을 쪼개서 안정적으로 전송 가능

4. 실시간 처리 가능

   • 로그 스트림, AI 생성, 뉴스 피드 등 실시간 처리에 매우 유리

단점

1. 후처리 어려움

   • 전체 결과를 한 번에 받지 않으므로, 요약이나 정렬 등 후처리가 어려움

2. 구현 복잡도

   • 클라이언트는 스트리밍 조각을 실시간으로 조합하거나 출력해야 하므로 복잡성 증가

3. 중간 끊김에 민감

   • 연결 중단 시 복구가 어려울 수 있고, 전체 요청을 다시 보내야 할 수도 있음

4. 디버깅 어려움

   • 응답이 점진적으로 오기 때문에 중간 상태를 디버깅하거나 테스트하는 것이 번거로움

Transfer-Encoding: chunked 구조

HTTP/1.1에서 스트리밍 응답을 구현하기 위해 사용하는 표준 방식은 chunked transfer encoding입니다.

구조:

[청크 길이 (16진수)]\r\n
[청크 데이터]\r\n

각 청크는 이렇게 반복되고, 마지막에 0\r\n\r\n을 보내며 스트림 종료를 알립니다.

예시:

HTTP/1.1 200 OK
Content-Type: application/json
Transfer-Encoding: chunked

1c
{"response":"Black ","done":false}

1a
{"response":"holes are ","done":false}

1b
{"response":"very dense.","done":true}

0

curl로 확인하는 방법

curl을 사용하면 스트리밍 응답을 쉽게 관찰할 수 있습니다.

curl -vN http://localhost:11434/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "prompt": "Explain black holes.",
    "stream": true
  }'

• -v: HTTP 요청/응답 로그 출력

• -N: 출력 버퍼링 비활성화 (stream 대응)

출력은 다음과 같이 한 줄씩 출력됩니다:

{"response":"Black ","done":false}
{"response":"holes are ","done":false}
{"response":"very dense.","done":true}

한번에 받으려면?

스트리밍이 아닌 일반 응답으로 전환하려면 stream 옵션을 false로 설정하면 됩니다.

curl http://localhost:11434/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "prompt": "Explain black holes.",
    "stream": false
  }'

이 경우에는 전체 결과가 완성된 후 한 번에 출력됩니다.

마무리

LLM API의 응답을 스트리밍 방식으로 처리할 수 있다는 것은 빠른 사용자 경험과 메모리 효율을 제공하는 강력한 기능입니다. 하지만 이를 제대로 활용하기 위해서는 HTTP 수준의 작동 방식과 스트리밍의 특성을 이해하는 것이 중요합니다. 이 글이 Chunked Transfer Encoding의 구조, 장단점, 활용법에 대한 이해를 높이는 데 도움이 되었기를 바랍니다.

1. 로그(log)란?

✔️ 정의

로그는 "몇 번 곱해야 이 수가 되나요?"라는 질문입니다.

예를 들어,

2 × 2 × 2 = 8 → log₂(8) = 3
10 × 10 × 10 = 1000 → log₁₀(1000) = 3

즉, log₂(8)은 2를 몇 번 곱해야 8이 되는지를 묻습니다 → 정답은 3입니다.

2. 알고리즘에서 log n은 log₂(n)

❗ 주의

수학에서는 log n을 log₁₀(n)으로 보는 게 일반적이지만,
알고리즘에서는 항상 log₂(n), 즉 밑이 2인 로그를 기본으로 합니다.

왜냐하면 컴퓨터는 2진수(Binary)를 쓰고,
많은 알고리즘이 데이터를 반씩 나누며 처리하기 때문입니다.

3. O(log n)이란?

개념

• 입력 크기 n을 반씩 줄여가며 처리하는 구조

• 탐색 범위가 계속 절반이 되는 알고리즘

대표 예시

• 이진 탐색 (Binary Search)

• 힙에서 삽입/삭제

• 균형 이진 트리에서 삽입/검색

예

n = 1024일 때 log₂(n) = 10
→ 단 10번만 비교하면 결과에 도달

4. O(n log n)이란?

개념

• 전체 데이터를 n개 모두 훑으면서,
  각 원소마다 log n만큼 추가 작업이 들어가는 구조

대표 예시

• 병합 정렬 (Merge Sort)

• 힙 정렬 (Heap Sort)

• 우선순위 큐 정렬

• 세그먼트 트리 계산

예

n = 1024
→ log₂(n) = 10
→ 1024 × 10 = 약 10,000번 작업 → O(n log n)

5. 차이점 비교표

6. 한 줄 정리

O(log n): 반씩 줄이며 찾는다
O(n log n): 전체를 보되, 그 안에서 log n 반복이 있다

이 글에서는 React 기반 웹에서 새창이 열릴 때의 화면을 정확하게 캡처하는 방법을 단계별로 정리합니다.

1. 부모창에서 리액트 컴포넌트의 클릭 이벤트에 브레이크포인트 걸기

먼저, 새창을 여는 버튼의 클릭 이벤트부터 추적합니다.

1. 크롬 개발자도구(DevTools)를 열고 Components 탭 또는 Elements → Event Listeners → click 경로를 따라 이벤트를 찾습니다.

2. 새창을 여는 버튼의 클릭 핸들러 코드로 진입하여, window.open()이 호출되는 위치에 브레이크포인트를 겁니다.

// 예시 코드
const handleClick = () => {
  const win = window.open('/popup', '_blank');
  win?.focus();
};

브레이크포인트는 window.open() 호출 직전에 거는 것이 가장 효과적입니다.

2. 새창이 열리면 자동으로 연결된 DevTools는 닫히므로, 브레이크포인트에서 멈춘 상태 유지

클릭 시점에 브레이크포인트가 걸리면 새창이 열리기 전이라 부모창은 멈춰 있게 됩니다. 이 시점에서 새창의 준비를 할 수 있습니다.

1. window.open() 이후 win.document가 생성되면서 새창이 로드되기 시작하지만, 이때 DevTools가 자동으로 연결되지 않습니다.

2. 수동으로 새창을 활성화한 뒤 F12를 눌러 새창의 개발자도구를 엽니다.

3. 새창에서

DOMContentLoaded

리스너를 설정

이제 새창이 열리고 있는 상태에서, DOM이 준비되는 시점에 브레이크포인트를 걸어야 합니다.

1. 새창의 DevTools에서 Sources → Event Listener Breakpoints → Load → DOMContentLoaded 체크박스를 활성화합니다.

2. 이 설정은 새창에서 DOM이 완전히 로드되는 시점에 중단되도록 합니다.

4. 부모창에서 resume (▶️) 을 눌러 새창 로딩 진행

이제 부모창으로 돌아가서 Resume script execution (F8)을 눌러 브레이크포인트를 해제합니다.

• 그러면 새창이 실제로 로드되며, 방금 설정한 DOMContentLoaded 브레이크포인트에서 멈추게 됩니다.

• 이 상태에서 DOM 구조나 네트워크 요청, 렌더링 타이밍 등을 분석할 수 있습니다.

보너스 팁: 새창에서 네트워크 캡처까지 하고 싶다면?

크롬의 DevTools는 새창에서 네트워크 탭을 자동으로 유지하지 않으므로, 개발용 프록시(예: Charles, Fiddler)를 사용하는 것도 방법입니다. 또는 새창이 띄워지는 시점을 window.open() 대신 a target="_blank" 형태로 바꾸고, 새창 자체를 명시적으로 열 수 있도록 구조를 바꾸는 것도 고려해볼 수 있습니다.

정리

이 글에서는 팝업 창이 열릴 때 DevTools가 자동으로 따라 열리게 설정하는 방법을 단계별로 소개합니다.

사용 환경

• 브라우저: Google Chrome (최신 버전 권장)

• OS: macOS, Windows 모두 가능

1. Chrome DevTools 열기

먼저 팝업을 띄우는 원래 창에서 Chrome의 개발자 도구를 엽니다.

• macOS: Cmd + Option + I

• Windows: Ctrl + Shift + I

2. Command Menu 실행

DevTools 상단에서 명령어를 실행하기 위해 Command Menu를 열어야 합니다.

• macOS: Cmd + Shift + P

• Windows: Ctrl + Shift + P

상단에 검색창이 열립니다.

3. Auto-open DevTools for popups 검색

검색창에 아래 명령어를 입력합니다.

Auto-open DevTools for popups

이 명령은 새 창(팝업)이 열릴 때마다 자동으로 개발자 도구를 함께 실행하게 설정합니다.

4. 명령어 활성화

Auto-open DevTools for popups 항목이 보이면 클릭하여 활성화합니다.

• 활성화되면 앞에 ✅ 표시가 붙습니다.

• 다시 비활성화하고 싶다면 같은 명령어를 한 번 더 실행하여 끌 수 있습니다.

5. 팝업 다시 열기

이제부터 window.open() 등으로 팝업이 열릴 때, 해당 창에서도 자동으로 DevTools가 함께 열립니다.

팝업 창의 콘솔 로그, 네트워크 요청, Elements 구조 등 모든 정보를 바로 확인할 수 있으므로 디버깅이 훨씬 수월해집니다.

참고 사항

• 이 설정은 한 번만 해두면 이후에도 유지됩니다.

• 만약 DevTools가 자동으로 열리지 않는다면 브라우저의 팝업 차단 기능이 원인일 수 있습니다. 이 경우 [설정 > 개인정보 및 보안 > 사이트 설정 > 팝업 및 리디렉션]에서 허용 도메인에 현재 사이트를 추가해 주세요.

팝업 디버깅이 잦은 웹앱 개발자라면 꼭 활성화해두면 유용한 설정입니다. 자주 쓰는 옵션인 만큼, 명령어 이름을 기억해 두면 필요할 때 빠르게 적용할 수 있습니다.

AI 개요 → 기술 분야 → 알고리즘 → 신경망 → 모델 → 데이터 → 학습 → 추론 → 평가 → 윤리

1. 인공지능이란 무엇인가? (AI: Artificial Intelligence)

인공지능은 인간의 지능을 모방해 문제를 해결하거나, 언어를 이해하고, 이미지를 인식하는 등 다양한 작업을 자동으로 수행하는 컴퓨터 시스템입니다. 대표적인 예로 챗봇, 번역기, 자율주행차, 추천 시스템 등이 있습니다.

2. 주요 기술 분야 (Technology Areas)

AI는 다양한 분야에 적용됩니다. 각 분야는 처리 대상 데이터(텍스트, 이미지, 음성 등)에 따라 특화된 기술로 구성됩니다.

3. 대표적인 알고리즘 (Algorithm)

알고리즘은 데이터를 처리해 예측하거나 분류하는 계산 절차입니다. 문제 유형에 따라 회귀(Regression), 분류(Classification), 군집화(Clustering), 강화학습(Reinforcement Learning) 등으로 나뉩니다.

4. 신경망 구조 (Neural Network Architecture)

신경망은 입력 데이터를 여러 계층(layer)을 거쳐 처리하고 출력하는 구조로, 복잡한 패턴을 학습할 수 있는 심층 구조입니다.

5. AI 모델 (AI Models)

모델은 신경망 구조에 데이터를 학습시켜 만들어진 결과물입니다. 실제로 사용하는 AI의 '실체'라고 볼 수 있습니다.

6. 데이터 (Data)

AI는 데이터를 기반으로 학습합니다. 다양한 형태의 데이터가 있으며, 품질이 좋을수록 더 정교한 예측이 가능합니다.

7. 학습 (Training)

AI는 학습을 통해 데이터를 기반으로 문제 해결 능력을 획득합니다. 학습 방식은 여러 종류가 있습니다.

8. 추론 (Inference)

추론은 학습된 모델이 새로운 입력에 대해 예측을 수행하는 과정입니다. 실시간 또는 일괄처리 방식으로 동작합니다.

9. 성능 평가 (Evaluation)

모델의 성능을 수치적으로 측정하여 실제 환경에서 신뢰할 수 있는지를 판단합니다.

10. 윤리와 책임 (Ethics and Governance)

AI는 사회적 책임이 요구됩니다. 공정성과 개인정보 보호, 편향 방지 등 다양한 윤리 이슈를 고려해야 합니다.

이로써 인공지능의 전반적인 구성과 원리를 주제별로 구조화해 이해할 수 있게 되었습니다. 이제 관심 있는 주제를 중심으로 더 깊이 탐구해보세요!

신경망(Neural Network)이란?

신경망은 인간의 뇌 구조를 모방한 계산 구조로, 데이터를 입력받아 처리하는 알고리즘 설계도입니다. 이 구조는 아직 학습되지 않은 상태이며, 입력과 출력의 연결 방식, 계층 구조 등을 정의합니다.

신경망의 정의

신경망은 입력 데이터를 전달받아 내부 연산을 통해 출력을 도출하는 "연산 구조(architecture)"입니다. 학습이 적용되기 전의 추상적 구조라고 볼 수 있습니다.

주요 신경망 종류

모델(Model)이란?

모델은 특정 신경망 구조에 데이터를 학습시켜 생성된 실체입니다. 학습이 완료된 모델은 신경망 구조 + 학습된 가중치(weight) + 하이퍼파라미터 + 입출력 정의 등을 포함합니다.

모델의 정의

모델은 데이터를 기반으로 학습된 신경망의 구현체이며, 실제로 예측이나 생성에 사용되는 "완성된 인공지능 엔진"입니다.

주요 AI 모델 목록 (기반 신경망 포함)

결론: 신경망과 모델은 무엇이 다른가?

• 신경망(Neural Network): 알고리즘의 "설계도" — 학습 전 구조

• 모델(Model): 학습이 완료된 "구현체" — 실제로 사용 가능한 AI 시스템

RNN(Recurrent Neural Network) 순환신경망은 자연어 처리나 시계열 데이터와 같이 순서가 중요한 입력을 다루는 데 효과적인 모델입니다. 그러나 긴 시퀀스를 학습할 때 성능이 급격히 떨어지는 문제가 있는데, 그 중심에는 그래디언트 소실(Vanishing Gradient) 현상이 있습니다.

그래디언트 소실(Vanishing Gradient)이란?

신경망은 출력값과 정답의 차이(오차)를 계산하고, 그 오차를 역전파(backpropagation) 를 통해 각 층에 전달하여 가중치를 조정합니다. 이때 오차가 기울기(gradient) 형태로 전달되는데, RNN에서는 시퀀스가 길어질수록 다음과 같은 문제가 생깁니다:

• 기울기의 연속적인 곱셈 → 값이 점점 작아져서 거의 0에 수렴

• 이전 시점에 대한 학습이 거의 이루어지지 않음

즉, 앞부분의 단어에 대한 정보는 뒤쪽에 도달하지 못하고 소멸됩니다. 이것이 바로 그래디언트 소실입니다.

예시로 살펴보기

예를 들어 다음과 같은 문장이 있다고 합시다.

“나는 오늘 아침에 학교에 갔다.”

이 문장에서 동사 “갔다” 는 주어 “나는” 과 연결되어야 합니다. 하지만 둘 사이 거리가 멀어질수록, RNN은 “나는”이라는 단어의 의미를 기억하지 못하게 됩니다.

결국, 문맥이 무너지고 잘못된 예측이나 번역이 발생하게 됩니다.

왜 중요한가?

그래디언트 소실 문제는 단순한 수치상의 이슈를 넘어서, 문장 이해나 시간 흐름을 반영한 예측을 불가능하게 만드는 핵심적 장애 요소입니다.

이로 인해 RNN은 다음과 같은 한계에 부딪히게 됩니다:

• 문장이 길어질수록 성능 저하

• 앞 단어의 의미가 뒤에 반영되지 않음

• 의미 단위의 연결 실패

어떻게 해결할 수 있을까?

이 문제를 해결하기 위해 등장한 대표적인 모델들이 있습니다:

그리고 현재 가장 널리 쓰이는 구조는 다음과 같습니다:

트랜스포머(Transformer)

• Self-Attention 구조를 통해 장기 의존성 학습과 병렬 처리 모두 가능

정리

2017년 구글 브레인 팀의 논문 “Attention is All You Need” 에서 처음 등장한 트랜스포머(Transformer)는 그 이름처럼 입력을 변환(transform) 하는 데 초점을 맞춘 구조입니다. 기존의 RNN 계열 모델과 달리, Self-Attention 메커니즘만으로 시퀀스를 처리하는 새로운 접근이었습니다.

왜 Transformer라고 불릴까?

1. 입력 시퀀스의 표현을 변환하기 때문

   • 예: 영어 문장을 프랑스어로 번역

   • 입력을 더 유의미한 표현으로 바꿔서 출력 생성 → 변환(transform) 중심 사고

2. 기존 모델을 완전히 변환한 아키텍처

   • RNN, LSTM, GRU 등과는 다른 새로운 구조로의 전환

   • 모델 자체의 패러다임을 바꾼다는 의미에서도 ‘변환자’

3. 논문 자체에서 명시한 모델 이름

   • “We call our model the Transformer.” (논문 중)

RNN/LSTM vs 트랜스포머 구조 비교

트랜스포머는 입력 문장 전체를 한꺼번에 바라보며, 중요한 위치에 Self-Attention을 적용합니다. 그 덕분에 병렬 처리가 가능하고, 장기 의존성 문제도 자연스럽게 해결할 수 있습니다.

마무리

트랜스포머는 단순한 구조 변경이 아니라 시퀀스 처리 방식의 패러다임 전환을 의미합니다. 이름 하나에도 그 철학이 담겨 있는 셈이죠. 오늘날 GPT, BERT, T5 등 다양한 모델들이 트랜스포머를 기반으로 만들어진 것도 이 구조의 강력함을 증명합니다.

Cloudflare는 별도의 메일 서버 없이도 도메인 기반 이메일 주소를 설정하고 Gmail 등으로 포워딩할 수 있는 Email Routing 기능을 제공합니다. 이 글에서는 hello@yourdomain.com 형태의 메일 주소를 만들어 Gmail로 수신하는 방법을 단계별로 설명합니다.

1. 사전 준비

• Cloudflare에 연결된 도메인

• 수신할 이메일 주소 (예: Gmail)

2. Email Routing 기능 활성화

1. Cloudflare 대시보드 접속

2. 도메인 선택

3. 왼쪽 메뉴에서 Email 클릭

4. Email Routing 탭에서 Set up Email Routing 클릭

3. 수신 이메일 주소 등록

1. Destination address 입력란에 Gmail 주소 입력

2. 해당 주소로 인증 메일 전송됨

3. 수신 메일에서 Verify 클릭하여 인증 완료

4. 도메인 이메일 주소 생성

1. Custom address 항목에 원하는 도메인 기반 이메일 입력
   예: contact@yourdomain.com

2. 포워딩할 Gmail 주소 선택

3. Create address 클릭

5. DNS 레코드 확인

Cloudflare는 자동으로 아래 레코드를 생성합니다:

• MX 레코드: Cloudflare의 메일 서버로 설정

• TXT 레코드: SPF, DKIM, 도메인 검증 용도

설정이 누락되었거나 기존 메일 설정과 충돌이 있다면 DNS > 레코드 탭에서 수동으로 조정해야 합니다.

6. 테스트

1. 외부 메일(예: Naver, 회사 메일)에서 contact@yourdomain.com으로 메일 전송

2. Gmail에서 메일 수신 확인

참고 사항

• Email Routing은 수신 및 포워딩 전용 기능입니다.

• 도메인 주소로 메일을 발송하려면 Gmail의 SMTP를 별도로 설정해야 합니다.
  설정 방법은 공식 가이드를 참고하세요.

• Gmail의 SMTP 인증 후 contact@yourdomain.com 주소로도 직접 답장이 가능합니다.

요약

Cloudflare Email Routing 기능은 개인 블로그, 포트폴리오, 스타트업 초기 서비스 등에서 도메인 이메일을 간편하게 설정할 수 있는 실용적인 방법입니다.

⸻

🔍 쿼리 설명

1. Publication 쿼리

query Publication {
  publication(host: "100lab.hashnode.dev") {
    posts(first: 20) {
      edges {
        node {
          id
          title
          brief
          url
          coverImage {
            url
          }
        }
      }
    }
  }
}

• 목적: 특정 호스트(100lab.hashnode.dev)의 최신 게시글 20개를 조회합니다.
• 출력: 각 게시글의 id, title, brief, url, coverImage.url 정보를 제공합니다.

• 사용 예시: 블로그 목록 페이지를 만들 때 유용합니다.

• GetPost 쿼리

  query GetPost {
  post(id: "68105f5f7017d96ea7cdb1e5") {
   title
   content {
     markdown
     text
   }
   brief
   slug
   url
   coverImage {
     url
   }
   author {
     name
     username
   }
  }
  }
  

  • 목적: 특정 게시글 ID에 해당하는 상세 정보를 가져옵니다. • 출력: • title, brief, slug, url • content.text: 게시글 본문 내용 (Plain Text 형식) • coverImage.url: 커버 이미지 • author.name, author.username: 작성자 정보 • 사용 예시: 게시글 상세 페이지를 렌더링할 때 사용합니다.

⸻

💡 참고 사항 • 이 API는 Hashnode GraphQL API에 요청을 보내야 작동합니다. • 인증이 필요한 경우, x-api-key 또는 Authorization 헤더가 필요할 수 있습니다. • post(id: "...")에서 사용하는 id는 Publication 쿼리의 node.id에서 얻을 수 있습니다.

⸻

이 쿼리를 활용해서 어떤 기능을 구현하고자 하시나요?

2025년 4월, 금융위원회는 금융지주회사법 및 시행령 개정안을 입법예고했습니다.
이번 개정안은 금융지주회사가 핀테크 기업에 보다 자유롭게 투자할 수 있도록 규제를 완화하는 내용을 담고 있는데요.
핀테크 기업에게 어떤 의미가 있을지 함께 살펴보겠습니다.

금융지주회사의 핀테크 기업 투자, 무엇이 달라지나?

기존에는 금융지주회사가 비금융회사(핀테크 기업 포함)에 직접 출자할 수 있는 범위가 매우 제한적이었습니다.
이에 따라 복잡한 투자 구조를 짜야 했고, 파트너십을 맺는 데에도 많은 제약이 따랐습니다.

하지만 이번 개정안으로, 금융지주회사는 핀테크 기업의 지분을 최대 15%까지 출자할 수 있게 됩니다.
이는 보다 간편하게, 그리고 전략적으로 핀테크 기업에 투자할 수 있는 길을 열어주는 변화입니다.

핀테크 기업에 미치는 3가지 주요 영향

1. 투자 구조가 간단해집니다

그동안은 금융지주회사가 핀테크 기업에 투자하기 위해
여러 계열사를 통해 우회하거나 복잡한 구조를 설계해야 했습니다.

이제는 금융지주회사가 직접 15%까지 투자할 수 있어,
투자 구조가 훨씬 단순해지고 효율화됩니다.

2. 전략적 파트너십이 강화됩니다

금융지주회사는 단순 재무적 투자(FI) 이상의 관계를 맺을 수 있습니다.
핀테크 기업과 함께 공동 상품을 개발하거나, 디지털 혁신 프로젝트를 추진하는 등
전략적 파트너십을 맺는 기회가 확대됩니다.

이는 핀테크 기업에게도 안정적인 파트너를 확보하고,
시장 내 입지를 빠르게 강화할 수 있는 기회를 의미합니다.

3. 경영 독립성을 지키면서도 지원을 받을 수 있습니다

15% 이내의 소수 지분 투자이기 때문에,
핀테크 기업은 경영권을 유지하면서도 필요한 자금과 금융지주의 인프라를 활용할 수 있습니다.

즉, 독립성과 성장 지원을 동시에 확보할 수 있는 좋은 환경이 마련됩니다.

앞으로의 기대

이번 금융지주회사법 개정은 핀테크 산업 전반에 긍정적인 파급효과를 가져올 것으로 보입니다.
핀테크 기업들은 자금 조달이 용이해지고,
금융지주회사는 혁신 기술을 빠르게 흡수하며 시장 대응력을 높일 수 있습니다.

디지털 금융 생태계의 확장, 맞춤형 금융 서비스의 대중화, 대안 신용평가 모델 발전 등
여러 분야에서 눈에 띄는 변화가 기대됩니다.

앞으로 금융권과 핀테크 업계의 협력이 어떤 시너지를 낼지 주목해볼 만합니다.

https://kcg.korea.kr/multi/visualNewsView.do?newsId=148941965