[Linux] 파일에서 한줄씩 읽어서 command 실행하기

안녕하세요, 하마연구소입니다.

file.txt 파일에서 한줄씩 읽어서 curl로 호출하기 위한 커맨드는 아래와 같습니다.

more file.txt | xargs -I {} curl -X GET http://111.222.333.444/{}.json

감사합니다.
Tags:

댓글

댓글 쓰기

Popular Posts

AI 시대, SEO가 아닌 GEO에 포커싱해야 하는 이유

이미지
안녕하세요, 하마연구소입니다. 정보를 제공하고 수익을 내야하는 기업 웹페이지가 AI 시대를 준비하며 GEO(Generative Engine Optimization) 를 신경써야 한다고 합니다. GEO는 또 뭐야? 최적의 검색엔진 대응을 위하여 과거와 현재 웹페이지는 SEO(Search Engine Optimization) 에 관심을 두고 있습니다. 최적화된 SEO를 제공하면 검색엔진 노출에 많은 도움이 되며, 이것은 트래픽 유입을 증가시키고 그만큼 수익을 늘릴 수 있습니다. 따라서 SEO는 검색엔진에 정보를 효과적으로 제공하는 구조로 되어 있으며, 웹페이지는 사람눈에 맞춰 메뉴, 목차, 본문구조 등을 구성해야 합니다. 하지만 AI 시대에서는 조금 다릅니다. 사용자가 웹페이지에 들어가서 원하는 정보를 얻으며 구매를 하고 또는 광고를 클릭하는 흐름이 아니라, AI와 대화하면서 정보를 얻고 구매도 AI에게 시킵니다. 즉, 사용자는 더이상 웹페이지에 직접 방문하지 않습니다. 따라서 웹페이지에 노출되는 구조가 사람의 눈이 아닌 AI 엔진(에이전트)에 포커싱 되어야 합니다. AI가 활발해지는 앞으로는 기업 웹페이지 입장에서 사용자의 질문으로부터 AI 엔진이 유입되기 때문에 그에 맞춰 Q&A 형태의 정보, 표나 리스트로 명확하게 정리된 정보, 무엇보다 입력된 질의 상황에 맞춰 동적으로 정보를 제공하는 웹페이지가 되어야 합니다. 아직 감이 오지 않습니다. 하지만 분명한 것은 더이상 사람이 직접 웹페이지에 방문하는 빈도수는 줄어들 것입니다. 따라서 미래 웹페이지 기획과 개발은 검색엔진과 사람이 보기 좋은 구성이 아니라, AI를 위한 맞춤 제공할 수 있는 구성이 되어야 합니다. 그리고 트래픽 유입에 따른 디스플레이 광고 수익이 아닌, AI가 상품을 직접 구매 하기 때문에 이 구매율을 높이기 위한 알맞은 정보를 제공하는 서비스에 신경써야할 것입니다. 예상했지만 AI가 많은 것을 바꾸고 새로운 표준을 잡아가...
Read more »

지금까지 S/W 개발하면서 경험했던 캐시(Cache)들 소개

이미지
안녕하세요, 하마연구소입니다. 컴퓨팅에서 캐시(Cache)는 데이터에 빠르게 접근하기 위한 레이어로 데이터 로딩이 지연되거나 병목이 예상되는 앞단에 위치합니다. CPU와 메모리 사이에 있는 L1, L2, L3 캐시나 빠른 I/O 처리를 위하여 스토리지(HDD, SSD 등)에도 사용됩니다. H/W뿐만 아니라 S/W에서도 자주 사용되며 적절한 캐시 설계에 따라 성능을 극대화할 수 있습니다. 보통 어플리케이션과 영구저장소 또는 다른 어플리케이션 사이에 위치합니다. 요즘은 분산 클러스터링 환경에서 편리성과 훌륭한 속도를 내는 Memcached나 Redis를 많이 사용하며, 언젠가부터는 Memcached도 캐시 설계할 때 도입 대상에서 제외되는 추세로 보입니다. 왠만하면 Redis 사용합니다. 제가 지금까지 경험했던 캐시 솔루션을 정리해 보려고 합니다. 보통 Java 기반으로 어플리케이션을 작성하였기에 그에 맞는 캐시를 많이 경험한 점 참고하시기 바랍니다. 1. 로컬캐시 Ehcache Java 기반 어플리케이션 개발하면 가장 쉽게 접하는 캐시입니다. 어렵지 않은 설정으로 다양한 캐시 기능을 사용할 수 있으며, 역사도 꽤 길기에 믿고 사용하면 됩니다. 다양한 기능으로는 영속성을 보장하기 위한다면 캐시 데이터 디스크 저장할 수 있으며, 어플리케이션의 여러 프로세스들 간에 공유하여 분산 캐시를 구성할 수도 있습니다. 단, 캐시 기능에 더이상 새로운 기능을 넣을께 없어서 그런지 라이브러리 업데이트가 활발하지는 않습니다. https://www.ehcache.org/ Caffeine 2010년대 중후반 부터 Spring Boot에서는 기본 캐시 라이브러리를 Ehcache에서 Caffeine으로 변경하였습니다. 아마 Spring Boot 버전 2부터였던 것으로 기억합니다. Ehcache가 제공하는 기능이 많아지고 그만큼 무거워졌기 때문에 로컬 캐시라는 본연 기능에 충실하고자 심플한 카페인 캐시 라이브러리가 각광 받았습니다. 또한 스프링에서 아주아주 간단한 설정만으로 쉽게 캐...
Read more »

AI 메모리 HBM 외에 HBF도 주목

이미지
안녕하세요, 하마연구소 입니다. AI 관련 하드웨어 중에 GPU가 가장 중요하지만 연산을 위하여 빠른 메모리도 매우 중요합니다. AI 확산으로 고대역폭메모리(HBM, High Bandwidth Memory) 시장이 유래없는 호황을 맞이하고 있습니다. HBM은 휘발성 메모리이기 때문에 GPU가 처리할 데이터를 유지하려면 지속적인 전력이 필요하며, 그에따라 전력량과 발열이 증가하게 됩니다. 따라서 이러한 한계 때문에 더 빠르게 처리해야할 GPU 연산 환경에 한계가 있다는 평가가 나오고 있습니다. 물론 HBM3, HBM3E에 이어 HBM4까지 개발되며 발전하고 있지만, 더 높은 고층으로 쌓기에는 한계가 있기에 더 큰 용량을 확보하지 못하고 있습니다. 이에 고대역폭낸드플래시메모리(HBF, High Bandwidth Flash Memory) 가 주목받고 있습니다. 낸드플래시는 최대 321층 쌓은 제품이 사용화 되어 용량 확대에 유리하고, 무엇보다 데이터 유지를 위하여 지속적인 전력 공급이 없어도 되며 발열량과 전력소모는 HBM 대비하여 낮습니다. 이는 마치 일반 컴퓨터에서 RAM과 SSD의 차이점과 유사합니다. CPU 연산에 필요한 데이터를 빠르게 접근하기 위하여 RAM을 이용하고 대량의 데이터를 임시 또는 영구 저장하기 위하여 SSD를 이용한 것과 비슷하게, GPU의 고속연산에 필요한 데이터를 HBM과 HBF를 혼합해서 사용하는 것입니다. HBM과 HBF 비교 HBF를 표준화하기 위하여 해결해야할 과제가 있습니다. 바로 낸드플래시의 10만번 쓰기 수명을 극복해야 합니다. 매우 빠르게 처리되는 AI 연산에서 하드웨어의 수명을 늘리는 것은 비용문제를 해결할 수 있는 핵심 과제입니다. 이에 SK하이닉스는 전통적인 낸드플래시 메모리 강자인 샌디스크와 양해각서(MOU)를 체결하여 전략적인 행보를 취하고 있습니다. SSD가 RAM을 대신하지 못하는 것처럼, HBF가 HBM을 대체하지는 않을 것입니다. 어쩌면 HBM의 성능이 더 좋아지고 단점이 줄어든다면 지금처럼 HBM만 사용...
Read more »