빅데이터 분석 기획DIKW - 데이터 정보 지식 지혜byte 크기 순 - 킬 메 기 테 페 엑 제 요빅데이터의 3v - Volume Varieyl Velocity역량 교육 체계 설계의 절차요구사항 직무별역량모델검토 역량차이분석 직무역량매트릭스 교육체계설계조직성과 평가목표 설정 , 모니터링 , 목표 조정 , 평가 실시 , 결과의 피드백 순임균형 성과표 (BSC : balanced Score Card) 의 4가지 관점 - 과거 성과를 바탕으로 미래 성과를 창출 (재무적 , 고객 , 업무 프로세스 , 학습과 성장) 관점빅데이터 플랫폼구성 요소수집 , 저장 , 분석 , 활용수집에는 ETL , 크롤러 , EAI 등이 있음.플랫폼의 데이터 형식html , xml , csv , jsonxml 은 sgml 문서 형식을..

NLP란? 자연어 처리의 정의자연어 처리(Natural Language Processing, NLP)는 컴퓨터가 인간의 언어를 이해·처리하도록 돕는 기술 분야이다. 즉, 사람이 일상적으로 사용하는 언어(텍스트나 음성)를 컴퓨터가 해석하여 의미를 이해하거나 생성할 수 있도록 한다. 일반적으로 NLP는 통계적 방법과 머신러닝·딥러닝 기법을 결합해 동작하며, 인공지능(AI)의 하위 분야로 분류된다. 예를 들어 IBM은 “NLP는 머신러닝을 활용해 컴퓨터가 인간의 언어를 이해하고 소통하도록 돕는 AI의 하위 분야”라고 정의하고 있으며, AWS 역시 “컴퓨터가 인간 언어를 해석·조작하고 이해할 수 있도록 하는 기술”이라 설명한다. NLP 기술은 검색 엔진의 질의 처리나 챗봇, 음성비서(예: Alexa, Siri)..

자연어 처리에서 가장 기본적인 질문 중 하나는 이것이다. “이 문장이 얼마나 자연스러운가?” 사람은 문장을 보면 어색한지 자연스러운지 어느 정도 직관적으로 판단할 수 있다. 하지만 컴퓨터는 문장을 사람처럼 이해하지 못한다. 대신 지금까지 관찰한 데이터로부터, “이런 단어 다음에는 어떤 단어가 나올 가능성이 높은가”, 혹은 “이 문장 전체가 실제로 등장할 가능성이 얼마나 되는가”를 확률적으로 계산한다. 이러한 관점에서 등장한 것이 바로 언어 모델(Language Model) 이다. 이번 글에서는 언어 모델이 어떤 문제를 풀기 위해 등장했는지부터 시작해서, 전통적인 N-gram Language Model, 임베딩을 도입한 Neural Probabilistic Language Model(NPLM), 그리고..

이번에 Next.js 프론트를 ECS Fargate + ALB 구조로 배포하면서 이상한 현상을 겪었다.컨테이너는 분명히 살아있는데 ECS는 계속 태스크를 죽이고 다시 올렸다. 증상 ECS 서비스 이벤트 로그task ... port 3000 is unhealthy in target-group ... reason: Health checks failed Amazon ECS replaced 1 tasks due to an unhealthy status. 그리고 무한 반복.태스크 → 실행됨Target group → UnhealthyECS → 태스크 교체다시 Unhealthy또 교체무한 루프 1차 의심: 컨테이너 문제?ECS Exec으로 직접 들어가서 확인했다. 200/ health /api/health 전부 ..

[ Internet ] | v[ Route53 ] | v[ ALB ] ← (여기에 WAF를 "나중에" 붙일 예정) | v[ ECS Fargate ] | v[ Spring Boot App ] 이번 글에서는 특정 기능 구현 이야기가 아니라,Spring Boot 기반 API 서버를 SaaS 구조로 설계하고 AWS 상에 배포하면서 고민했던 아키텍처 포인트를 정리해보려 한다.단순히 애플리케이션을 배포하는 것을 넘어, 멀티테넌시 구조, 무중단 배포 전략, 헬스체크 설계, 네트워크 경계 설정, 관찰성까지 고려한 “운영 가능한 구조”를 목표로 설계했다. (트래픽 분산처리는 하지 않음.)EC2 vs ECS 초기에는 EC2에 직접 배포할지, ECS를 사용할지 고민..

문제 배경SpeakNote를 GCP 환경에서 운영하던 중,GCP Billing 리포트에서 Network egress 비용이 비정상적으로 급증한 것을 확인했다.트래픽이 갑자기 폭증한 것도 아니고,기능을 대규모로 추가한 시점도 아니었기 때문에 단순 사용량 증가로 보기에는 이상한 상황이었다.조사를 진행하면서 egress 비용 증가의 원인은 하나가 아니라 여러 개라는 것을 알게 되었다.Docker 이미지 빌드 시 캐시 없이 반복 빌드되던 문제외부 AI API 연동 구조그리고 GCP 네트워크 아키텍처 자체의 문제이 글에서는아직 해결 중인 빌드/코드 레벨 이슈는 제외하고, GCP 아키텍처 재배포로 실제 비용을 줄인 과정만 정리한다. 초기 상황: “같은 서버끼리 통신하는데 왜 egress가 나가지?”SpeakNot..

SpeakNote 프로젝트의 고도화 기간 중, 기존에는 로컬로만 테스트를 돌렸었는데아무래도 운영 환경에서의 테스트도 중요할 거 같아 배포를 미리 해두기로 마음을 먹었다.다만, 1월 24일경 시작을 했는데 크레딧의 반절을 써버림.. (뭔가 단단히 잘못됨..) 한번도 이랬던 적이 없어서 우선 인스턴스를 중지 시킴. (고정 ip 와 디스크로 몇천원 결제되는게 더 나을 듯해서...) 우선 요금이 폭등하게 된 원인부터 찾으려 함. Google cloud 의 billing -> 보고서를 클릭 오잉??그룹화 기준을 날짜 > SKU 로 변경 (1월 29일날 인스턴스 중지를 시켰습니다. 나온 974는 아마도 고정 ip와 디스크 값이겠죵?)뭔지 정확히 확인하기 위해 csv 다운로드를 클릭합니다. (27일만 많이 나온..

SSH 키 등록했는데 로컬에서 접속이 안 됐던 문제 (해결까지 한 번에 정리)Compute Engine 인스턴스를 생성하면서초기 설정 화면에서 SSH 공개키를 분명히 등록했습니다.하지만 인스턴스 생성 이후, 로컬 터미널에서 다음과 같이 접속을 시도했을 때ssh user@SSH 접속이 정상적으로 이루어지지 않았습니다.즉,VM 생성 단계에서 SSH 키를 넣었음GCP 콘솔에서는 인스턴스가 정상적으로 떠 있음그런데 로컬 터미널에서는 SSH 접속 실패라는 상황이었습니다.당시 문제 상황 정리이 시점에서 확인했던 사항은 다음과 같습니다.VM에는 외부 IP가 정상적으로 할당되어 있었고방화벽에서도 22번 포트는 열려 있는 상태였으며SSH 키 자체도 로컬에 정상적으로 존재했습니다즉, 네트워크나 포트 문제라기보다는 SSH ..

Compute Engine 생성부터 전역 Load Balancer 연결까지본 글은 SpeakNote 서비스를 GCP 환경에 배포하면서Compute Engine 생성 → SSH 접속 → 서비스 실행 → Load Balancer 선택 및 설정 → 도메인 연결까지의 과정을 순서대로 기록한 글입니다.설계 배경보다는 실제로 어떤 설정을 했는지를 중심으로 정리합니다. 나중에 운영 서버는 AWS 에서 진행할 거지만,, (Upstage 와 제휴업체인걸로 알고있어서!)AWS 는 현재 start up 신청 대기 중이기 때문에, 개발 단계는 GCP 로 진행을 하려 합니다. GCP 계정 설정처음 가입하면 , First Project 라고 뜨는걸로 알고있는데, 우선 저는 프로젝트별 관리를 편안히 하기 위해 새프로젝트를 만들었..

병목 현상을 줄이기 위한 실시간 아키텍처 설계— SpeakNote의 설계 선택과 그 이유https://ye-seul0-0.tistory.com/185 [CS | 실시간 시스템] 병목이 발생하는 이유실시간 시스템에서 병목이 발생하는 이유실시간 시스템을 처음 설계할 때 가장 많이 착각하는 부분 중 하나는“성능을 충분히 높이면 병목은 없앨 수 있다”는 생각입니다.저 역시 SpeakNote 프로ye-seul0-0.tistory.com 이전 글에서는 실시간 시스템에서 병목 현상이 왜 필연적으로 발생하는지, 그리고 병목이 단순한 성능 문제가 아니라 구조적인 문제라는 점을 정리했습니다.이번 글에서는 그 연장선에서, SpeakNote에서는 병목을 줄이고, 병목이 전체 시스템으로 확산되는 것을 막기 위해 어떤 아키텍처를..

실시간 시스템에서 병목이 발생하는 이유실시간 시스템을 처음 설계할 때 가장 많이 착각하는 부분 중 하나는“성능을 충분히 높이면 병목은 없앨 수 있다”는 생각입니다.저 역시 SpeakNote 프로젝트를 시작할 당시에는, 처리 속도를 빠르게 만들면 실시간성은 자연스럽게 따라올 것이라고 생각했습니다.하지만 실제로 실시간 음성 스트리밍, STT, AI 요약, 그리고 PDF 주석 렌더링까지 연결해보니 병목은 ‘없앨 수 있는 문제’가 아니라, 반드시 관리해야 하는 대상라는 점을 체감하게 되었습니다.이 글에서는 SpeakNote 프로젝트를 진행하며 느꼈던 경험을 바탕으로, 왜 실시간 시스템에서는 병목이 필연적으로 발생하는지, 그리고 이를 어떻게 바라봐야 하는지 정리해보려고 합니다.1. 실시간 시스템은 항상 “흐름”으..

환경 일관성과 데이터 관리의 용이성 때문에 온프레미스로 구현되고 있는 서비스의 서버에 database 를 Docker 를 이용하여 배포하고 운영하고 있습니다. 해당 Postgres 의 컴포즈 파일을 설정하다가, 계속적인 부팅 이슈가 발생하길래 그것을 수정하여 개선해보려 합니다. postgres: image: ${POSTGRES_IMAGE:-postgres:15} container_name: ${POSTGRES_SERVICE_NAME:-postgres} env_file: .env.postgres ports: - "${POSTGRES_PORT:-5432}:5432" volumes: - ${ROOT_HOST}/postgres-data:/var/lib/postg..

이번 작업에서는 Spring → FastAPI → OCR Server 구조에서 파일을 직접 전달하지 않고 공유 스토리지(NFS) 를 통해 처리하도록 아키텍처를 변경했습니다. 기존에는 FastAPI에서 파일을 /tmp에 다시 저장한 뒤 OCR 서버로 넘기는 구조였는데, 서버가 분리되고 트래픽이 늘어나면서 중복 I/O, 디스크 낭비, 관리 복잡도 문제가 커졌기에 결론적으로 서버 간 공유 마운트(NFS) 를 적용했고, 그 과정에서 발생한 실제 에러와 해결 과정을 정리하려 합니다. 파일은 Spring에서 한 번만 저장FastAPI / OCR Server는 경로만 전달받아 읽기서버 간 파일 전송 제거 NFS 패키지 설치sudo apt updatesudo apt install -y nfs-kernel-serve..

이전 글에서는 OCR 파이프라인을 API 서버와 GPU 워커 서버로 분리하고, GPU 리소스를 중앙 집중식으로 관리하는 구조까지 설계해보았습니다. 이번 글에서는 그 구조를 실제로 서버 운영 환경에 올리기 위해 반드시 마주치게 되는 문제, 바로 공유 스토리지(NFS)와 보안 설계에 대해 다뤄보려 합니다. 단순히 “파일을 공유한다” 수준이 아니라, 여러 서버가 동시에 접근해도 안전한지 root 권한 남용 위험은 없는지 컨테이너 환경에서도 파일 권한이 꼬이지 않는지 같은 운영 관점의 고민을 중심으로 정리해보려 합니다. OCR 워커를 서버 한 대(Server 2)에만 올리는 구조를 선택하면서, 자연스럽게 생긴 요구사항이 있습니다.Server 4 (운영), Server 5 (개발), Server 6 (온디맨드) ..