Offcanvas

���������

백엔드 개발자 경험을 위한 솔루션 열전

코드형 인프라와 데브옵스, 내부 플랫폼의 인기가 높아지면서 백엔드 개발자가 탄력적이면서 성능과 확장성이 우수한 서버 측 애플리케이션과 서비스를 구축하기에 훨씬 더 좋은 환경이 됐다. 그러나 너무 많은 부담을 짊어지고 있기도 하다. 현대 애플리케이션의 복잡함으로 인해 백엔드 개발자는 리눅스의 기본부터 스크립트 언어, 로깅, 모니터링, 클라우드 기반 네트워킹과 서비스 메시, 관찰 가능성, 쿠버네티스 클러스터, 그리고 공포의 YAML 파일에 이르기까지 갈수록 많은 툴과 기술, 기법을 마스터해야 한다.   백엔드 개발자에게는 숨을 쉴 공간, 명확히 말하자면 더 나은 개발 경험이 필요하다. 다행히 툴 제조 업체들이 앞다퉈 그런 경험을 제공하고 있다. 코드형 인프라의 장벽을 낮추는 것부터 쿠버네티스 워크플로우와 분산 앱 배포 과정을 원활하게 하고 필요에 따라 클라우드에 개발자 작업 공간을 마련하는 데 이르기까지, 새롭게 쏟아지는 여러 프로젝트는 서버 측에서 고난을 겪고 있는 개발자가 더 편하게 작업을 수행하는 데 도움이 될 것을 약속한다.   "백엔드 엔지니어도 감정이 있다" 오늘날의 클라우드 네이티브 세계에서 모든 유형의 개발자는 일반적으로 더 직관적이고 사용하기 쾌적한 툴에 자연스럽게 이끌린다. 간편함이나 사용 편의성과 거리가 먼 영역에서 일하는 경우라 해도 마찬가지다. 버셀(Vercel)이나 네트리파이(Netlify)와 같은 업체는 프론트엔드 개발자 경험에 초점을 두고 백엔드를 추상화하는 방식으로 큰 성공을 거두었지만, 많은 기업이 서버 인프라에 대한 어느 정도의 통제력을 원한다. 이런 백엔드를 담당하는 엔지니어도 더 나은 경험을 원할 수 있다. 레드몽크(RedMonk) 애널리스트 제임스 가버너는 “개발자가 이런 작업을 더 쉽게 할 수 있도록 서비스 업체가 지원에 나서는 것은 자연스러운 현상이며, 이 부분이 인프라와 소프트웨어 개발이 만나는 지점이다. 결국 헬름 차트, 연산자 또는 YAML을 수동으로 다룰 필요 없이 생산성을 높일...

개발자경험 백엔드 오픈소스 YAML 코드형인프라. IaC 클라우드네이티브 데브옵스

2022.05.11

코드형 인프라와 데브옵스, 내부 플랫폼의 인기가 높아지면서 백엔드 개발자가 탄력적이면서 성능과 확장성이 우수한 서버 측 애플리케이션과 서비스를 구축하기에 훨씬 더 좋은 환경이 됐다. 그러나 너무 많은 부담을 짊어지고 있기도 하다. 현대 애플리케이션의 복잡함으로 인해 백엔드 개발자는 리눅스의 기본부터 스크립트 언어, 로깅, 모니터링, 클라우드 기반 네트워킹과 서비스 메시, 관찰 가능성, 쿠버네티스 클러스터, 그리고 공포의 YAML 파일에 이르기까지 갈수록 많은 툴과 기술, 기법을 마스터해야 한다.   백엔드 개발자에게는 숨을 쉴 공간, 명확히 말하자면 더 나은 개발 경험이 필요하다. 다행히 툴 제조 업체들이 앞다퉈 그런 경험을 제공하고 있다. 코드형 인프라의 장벽을 낮추는 것부터 쿠버네티스 워크플로우와 분산 앱 배포 과정을 원활하게 하고 필요에 따라 클라우드에 개발자 작업 공간을 마련하는 데 이르기까지, 새롭게 쏟아지는 여러 프로젝트는 서버 측에서 고난을 겪고 있는 개발자가 더 편하게 작업을 수행하는 데 도움이 될 것을 약속한다.   "백엔드 엔지니어도 감정이 있다" 오늘날의 클라우드 네이티브 세계에서 모든 유형의 개발자는 일반적으로 더 직관적이고 사용하기 쾌적한 툴에 자연스럽게 이끌린다. 간편함이나 사용 편의성과 거리가 먼 영역에서 일하는 경우라 해도 마찬가지다. 버셀(Vercel)이나 네트리파이(Netlify)와 같은 업체는 프론트엔드 개발자 경험에 초점을 두고 백엔드를 추상화하는 방식으로 큰 성공을 거두었지만, 많은 기업이 서버 인프라에 대한 어느 정도의 통제력을 원한다. 이런 백엔드를 담당하는 엔지니어도 더 나은 경험을 원할 수 있다. 레드몽크(RedMonk) 애널리스트 제임스 가버너는 “개발자가 이런 작업을 더 쉽게 할 수 있도록 서비스 업체가 지원에 나서는 것은 자연스러운 현상이며, 이 부분이 인프라와 소프트웨어 개발이 만나는 지점이다. 결국 헬름 차트, 연산자 또는 YAML을 수동으로 다룰 필요 없이 생산성을 높일...

2022.05.11

칼럼 | 범용 DB의 귀환? 애초에 물러난 적이 없다

데이터베이스는 범용 모델에서 특화 모델로 발전해왔다. 하지만 최근 범용 모델로 돌아가려는 움직임이 보인다. 정말 그럴까?    작년 레드몽크(RedMonk) 애널리스트 스티븐 오그레이디는 ‘A Return to the General Purpose Database’(범용 데이터베이스의 귀환)이라는 제목의 글을 썼다. 글에 따르면 데이터베이스 시장 요구에 따라 ‘바닐라DB’(VanillaDB) 같은 관계형 데이터베이스를 넘어 NoSQL 같은 수많은 특화 데이터베이스가 만들어졌다(심지어 AWS는 수많은 종류의 맞춤형 데이터베이스를 만들어 판매했다). 그런데 10년 넘게 이어져 왔던 전환의 추세가 뒤집히는 듯했다는 것이 글의 핵심 주장이었다. 실제로 데이터베이스 관리 시스템별 사용률을 추적하는 DB엔진을 살펴보면 한때는 소수였던 데이터베이스가 2022년에는 무려 391개로 늘어났다. 오그레이디에 따르면 이제 소수의 범용 데이터베이스로 다시 간추려질 차례다. 과연 그럴까?  애초에 시장은 범용 데이터베이스를 떠난 적이 없다.  데이터 관리 도구를 만드는 모달 랩스(Modal Labs)의 CEO 에릭 베른하르트는 “궁극적으로 범용 도구(프로그래밍 언어, 데이터베이스, 프레임워크 등등)는 특화된 도구보다 더 많이 쓰일 수밖에 없다. 성능과 같은 특정한 측면에서 10배가 넘는 우위를 가졌더라도 말이다”라고 설명했다. 그는 “지난 10년 동안 데이터베이스, 프로그래밍 언어, 프레임워크의 역사를 통틀어봐도 범용 도구가 대부분 마지막 승자로 이름을 올려왔다”라고 덧붙였다.  왜일까? 개발자가 잡다한 특화 도구를 배울 여력이 없기 때문이다.   10년이 지나도 같은 도구가 상위권 유지  DB 엔진에 따르면 2012년 10월에 가장 많이 쓰인 데이터베이스는 다음과 같다.   오라클(Oracle) 마이크로소프트 SQL 서버(Microsoft SQL Server) 마이SQL(MySQL)&...

데이터베이스 백엔드 프로그래밍 언어

2022.04.19

데이터베이스는 범용 모델에서 특화 모델로 발전해왔다. 하지만 최근 범용 모델로 돌아가려는 움직임이 보인다. 정말 그럴까?    작년 레드몽크(RedMonk) 애널리스트 스티븐 오그레이디는 ‘A Return to the General Purpose Database’(범용 데이터베이스의 귀환)이라는 제목의 글을 썼다. 글에 따르면 데이터베이스 시장 요구에 따라 ‘바닐라DB’(VanillaDB) 같은 관계형 데이터베이스를 넘어 NoSQL 같은 수많은 특화 데이터베이스가 만들어졌다(심지어 AWS는 수많은 종류의 맞춤형 데이터베이스를 만들어 판매했다). 그런데 10년 넘게 이어져 왔던 전환의 추세가 뒤집히는 듯했다는 것이 글의 핵심 주장이었다. 실제로 데이터베이스 관리 시스템별 사용률을 추적하는 DB엔진을 살펴보면 한때는 소수였던 데이터베이스가 2022년에는 무려 391개로 늘어났다. 오그레이디에 따르면 이제 소수의 범용 데이터베이스로 다시 간추려질 차례다. 과연 그럴까?  애초에 시장은 범용 데이터베이스를 떠난 적이 없다.  데이터 관리 도구를 만드는 모달 랩스(Modal Labs)의 CEO 에릭 베른하르트는 “궁극적으로 범용 도구(프로그래밍 언어, 데이터베이스, 프레임워크 등등)는 특화된 도구보다 더 많이 쓰일 수밖에 없다. 성능과 같은 특정한 측면에서 10배가 넘는 우위를 가졌더라도 말이다”라고 설명했다. 그는 “지난 10년 동안 데이터베이스, 프로그래밍 언어, 프레임워크의 역사를 통틀어봐도 범용 도구가 대부분 마지막 승자로 이름을 올려왔다”라고 덧붙였다.  왜일까? 개발자가 잡다한 특화 도구를 배울 여력이 없기 때문이다.   10년이 지나도 같은 도구가 상위권 유지  DB 엔진에 따르면 2012년 10월에 가장 많이 쓰인 데이터베이스는 다음과 같다.   오라클(Oracle) 마이크로소프트 SQL 서버(Microsoft SQL Server) 마이SQL(MySQL)&...

2022.04.19

칼럼ㅣ‘스타게이트’, 데이터베이스 지형 뒤흔들 수 있을까? 

데이터용 오픈소스 API 프레임워크 ‘스타게이트(Stargate)’는 개발자가 원하는 모든 형태의 백엔드 데이터로 작업할 수 있도록 하겠다고 말한다.  기업에서 후원하는 많은 오픈소스 프로젝트와 마찬가지로, ‘스타게이트’ 역시 그 뿌리(roots)를 넘어설 때 가장 흥미로워진다.  미국의 데이터 관리 업체 데이터스택스(DataStax)는 ‘우리가 하고자 하는 작업에 따라 서로 다른 데이터베이스와 API를 사용하는 데 지쳐서’ 스타게이트를 오픈소스화했다고 밝혔다. 데이터스택스가 ‘데이터를 위한 오픈소스 API 프레임워크’라고 부르는 이 프로젝트의 목표는 ‘다양한 워크로드에 많은 API를 지원할 수 있는 프레임워크’를 제공하는 것이다.    그런데, 스타게이트는 데이터스택스가 사용하는 ‘아파치 카산드라(Apache Cassandra)’를 기반으로 한다. 애널리스트 토니 베이어는 스타게이트를 두고 “마침내 아파치 카산드라를 멀티모델 데이터베이스로 전환할 수 있는 오픈소스 API 프레임워크”라고 말했다. 틀린 말은 아니다. 하지만 이 때문에 스타게이트가 흥미로운 건 아니다.  바로 무엇이냐 하면, ‘스타게이트(편집자 주: 美 유명 SF 시리즈에서 등장하는 초공간 이동 장치)’가 제공하는 것을 달성하고자 커뮤니티가 성장한다면 흥미로워진다. 설명하자면, 멀리 떨어진 곳으로 즉각 이동할 수 있도록 하는 이른바 ‘웜홀 포털 장치(Einstein-Rosen bridge portal device)’로 기능하는 경우다.  즉 데이터스택스의 최고데이터책임자(CDO) 데니스 고스넬이 밝힌 바와 같다. 그는 "개발자가 API를 통해 원하는 형태의 데이터로 작업할 수 있도록 어떤 데이터베이스이든 플러거블(pluggable) 백엔드가 있는 멀티모델 데이터베이스로 바꿔주는 데이터 게이트웨이다"라고 설명했다.  동일한 데이터베이스 언어 사용하기 몇 날 며칠을 밤새워 데이터베이스만 생각하지 않는다고 가정해보자....

스타게이트 데이터스택스 오픈소스 데이터 데이터베이스 아파치 카산드라 쿠버네티스 구글 리프트 엔보이 몽고DB 백엔드 프론트엔드

2020.11.11

데이터용 오픈소스 API 프레임워크 ‘스타게이트(Stargate)’는 개발자가 원하는 모든 형태의 백엔드 데이터로 작업할 수 있도록 하겠다고 말한다.  기업에서 후원하는 많은 오픈소스 프로젝트와 마찬가지로, ‘스타게이트’ 역시 그 뿌리(roots)를 넘어설 때 가장 흥미로워진다.  미국의 데이터 관리 업체 데이터스택스(DataStax)는 ‘우리가 하고자 하는 작업에 따라 서로 다른 데이터베이스와 API를 사용하는 데 지쳐서’ 스타게이트를 오픈소스화했다고 밝혔다. 데이터스택스가 ‘데이터를 위한 오픈소스 API 프레임워크’라고 부르는 이 프로젝트의 목표는 ‘다양한 워크로드에 많은 API를 지원할 수 있는 프레임워크’를 제공하는 것이다.    그런데, 스타게이트는 데이터스택스가 사용하는 ‘아파치 카산드라(Apache Cassandra)’를 기반으로 한다. 애널리스트 토니 베이어는 스타게이트를 두고 “마침내 아파치 카산드라를 멀티모델 데이터베이스로 전환할 수 있는 오픈소스 API 프레임워크”라고 말했다. 틀린 말은 아니다. 하지만 이 때문에 스타게이트가 흥미로운 건 아니다.  바로 무엇이냐 하면, ‘스타게이트(편집자 주: 美 유명 SF 시리즈에서 등장하는 초공간 이동 장치)’가 제공하는 것을 달성하고자 커뮤니티가 성장한다면 흥미로워진다. 설명하자면, 멀리 떨어진 곳으로 즉각 이동할 수 있도록 하는 이른바 ‘웜홀 포털 장치(Einstein-Rosen bridge portal device)’로 기능하는 경우다.  즉 데이터스택스의 최고데이터책임자(CDO) 데니스 고스넬이 밝힌 바와 같다. 그는 "개발자가 API를 통해 원하는 형태의 데이터로 작업할 수 있도록 어떤 데이터베이스이든 플러거블(pluggable) 백엔드가 있는 멀티모델 데이터베이스로 바꿔주는 데이터 게이트웨이다"라고 설명했다.  동일한 데이터베이스 언어 사용하기 몇 날 며칠을 밤새워 데이터베이스만 생각하지 않는다고 가정해보자....

2020.11.11

풀스택 서버리스 잼스택 제공하는 ‘레드우드(Redwood)’ 살펴보기

기트허브(GitHub) 공동 창업자 톰 프레스턴워너를 필두로 하는 오픈소스 프레임워크 ‘레드우드(Redwood)’ 프로젝트 개발팀은 잼스택(Jamstack) 애플리케이션 개발을 지원하는 편향적인(opinionated) 풀스택 서버리스 웹 애플리케이션 프레임워크를 제공하고 있다.    ‘레드우드’는 애플리케이션 프론트엔드와 백엔드 모두에서 자바스크립트(JavaScript)를 기본언어로 사용한다. 이렇게 단일 언어를 사용하면 코드 재사용부터 개발자 채용까지 모든 것이 단순해진다고 개발팀은 설명했다.  개발팀은 공식 문서를 통해 ‘레드우드’ 혹은 ‘레드우드.js’를 설명하면서, CDN에 의해 정적으로 딜리버리되는 리액트(React) 자바스크립트 라이브러리 프론트엔드가 그래프QL(GraphQL)을 통해 전 세계의 AWS 람다(AWS Lamba)에서 실행되는 백엔드와 통신하며, 이를 모두 깃 푸시(git push)로 배포할 수 있다고 전했다.  이 밖에 ‘레드우드’를 사용하면, 그 자체로 운영상의 의사결정이 이뤄지기 때문에 다양한 기술과 구성을 선택하고 재선택하는 데 시간을 낭비하는 대신 애플리케이션 개발에 더 집중할 수 있다고 개발팀은 언급했다.  한편 사전 렌더링 및 디커플링 핵심 원칙을 활용하는 ‘잼스택’은 웹을 더 빠르고, 더 안전하며, 더 확장 가능하도록 하는 아키텍처를 제공한다. 잼스택은 최신 데브옵스 개발 철학을 정적 HTML 페이지와 결합한다.  레드우드는 현재 버전 0.20 상태다. 기트허브에서 액세스할 수 있다. 개발팀은 2020년 말에 스테이블 1.0 버전을 출시할 예정이라고 밝혔다. 표준 레드우드 애플리케이션에서 사용할 기술은 다음과 같다.  • 리액트(React) • 그래프QL(GraphQL) • 프리즘 데이터베이스 툴킷(Prism database toolkit) • 제스트 자바스크립트 테스팅 프레임워크(Jest JavaScript testing framework): 출시...

레드우드 잼스택 오픈소스 프레임워크 기트허브 리액트 자바스크립트 그래프QL AWS 람다 프론트엔드 백엔드 데브옵스

2020.11.04

기트허브(GitHub) 공동 창업자 톰 프레스턴워너를 필두로 하는 오픈소스 프레임워크 ‘레드우드(Redwood)’ 프로젝트 개발팀은 잼스택(Jamstack) 애플리케이션 개발을 지원하는 편향적인(opinionated) 풀스택 서버리스 웹 애플리케이션 프레임워크를 제공하고 있다.    ‘레드우드’는 애플리케이션 프론트엔드와 백엔드 모두에서 자바스크립트(JavaScript)를 기본언어로 사용한다. 이렇게 단일 언어를 사용하면 코드 재사용부터 개발자 채용까지 모든 것이 단순해진다고 개발팀은 설명했다.  개발팀은 공식 문서를 통해 ‘레드우드’ 혹은 ‘레드우드.js’를 설명하면서, CDN에 의해 정적으로 딜리버리되는 리액트(React) 자바스크립트 라이브러리 프론트엔드가 그래프QL(GraphQL)을 통해 전 세계의 AWS 람다(AWS Lamba)에서 실행되는 백엔드와 통신하며, 이를 모두 깃 푸시(git push)로 배포할 수 있다고 전했다.  이 밖에 ‘레드우드’를 사용하면, 그 자체로 운영상의 의사결정이 이뤄지기 때문에 다양한 기술과 구성을 선택하고 재선택하는 데 시간을 낭비하는 대신 애플리케이션 개발에 더 집중할 수 있다고 개발팀은 언급했다.  한편 사전 렌더링 및 디커플링 핵심 원칙을 활용하는 ‘잼스택’은 웹을 더 빠르고, 더 안전하며, 더 확장 가능하도록 하는 아키텍처를 제공한다. 잼스택은 최신 데브옵스 개발 철학을 정적 HTML 페이지와 결합한다.  레드우드는 현재 버전 0.20 상태다. 기트허브에서 액세스할 수 있다. 개발팀은 2020년 말에 스테이블 1.0 버전을 출시할 예정이라고 밝혔다. 표준 레드우드 애플리케이션에서 사용할 기술은 다음과 같다.  • 리액트(React) • 그래프QL(GraphQL) • 프리즘 데이터베이스 툴킷(Prism database toolkit) • 제스트 자바스크립트 테스팅 프레임워크(Jest JavaScript testing framework): 출시...

2020.11.04

블로그 | 데이터와 프로세싱을 클라우드에 둬야만 하는 이유

필자는 IEEE가 새로 부상한 클라우드 컴퓨팅 영역까지 관장하는 것을 적극 지지한다. IEEE 논문의 기술적인 깊이는 일반 IT 책임자를 독자로 끌어들이기에 너무 깊지만, 필자는 새로운 혁신에 중점을 두고 상세한 해법을 제시하며 혁신을 증명하는 데 중점을 둔다는 점을 좋아한다. 때로는 너무 자세하다는 문제는 있지만.   최근 필자는 “모바일 클라우드 오프로딩을 위한 에너지 효율적인 의사 결정(Energy-Efficient Decision Making for Mobile Cloud Offloading)”이란 논문을 읽었다. 이 논문을 읽고 모바일 컴퓨팅 디바이스가 클라우드와 함께 한지가 10년이 넘었다는 것을 새삼 생각하게 됐다. 그럼에도 우리는 아직 모바일 디바이스 프로세싱과 데이터 스토리지의 계층화에 관해서는 본격적인 시도도 하지 않았고, 베스트 프랙티스도 만들지 않았다. 이제 때가 된 것 같다. 이 논문은 모바일 컴퓨팅의 개념을 퍼블릭 클라우드의 이점과 모바일 ‘터미널’의 이점을 결합한 것으로 설명했다. 터미널이란 용어는 과거 정보를 보여주고 소비하지만 처리하지는 않는 더미 디바이스를 이르는 말이었다. IT는 이미 가능한 한 많은 프로세싱과 데이터 스토리지를 퍼블릭 클라우드로 배치하고 있다는 점을 생각하면, 당연한 유추이다. 한편으로는 기술을 소형화해 저렴한 가격으로 쉽게 이용할 수 있도록 한 덕분에 일부 프로세싱과 스토리지 역량을 모바일 디바이스에 유지하는 것이 쉬워졌다. 이 때문에 가능한 한 많은 것을 원격지 클라우드 기반 시스템으로 보내는 것이 베스트 프랙티스임에도 모바일 디바이스는 ‘스마트’ 터미널이 되었다.  논문에서 언급한 ‘오프로딩’은 모바일 컴퓨팅 애플리케이션이 수년 동안 다뤄 온 것이다. 프로세싱과 스토리지의 위치를 묻는 것은 매우 일반적이다. 모바일 디바이스에 프로세싱과 데이터 스토리지를 유지해야 한다는 요구도 있는데, 사용자와의 인터랙션에 지연이 거의 없어야 하는 애플리케이션이다. 물론 장단점이 있다. 프로세...

오프로딩 백엔드 베스트프랙티스 모바일클라우드

2020.06.30

필자는 IEEE가 새로 부상한 클라우드 컴퓨팅 영역까지 관장하는 것을 적극 지지한다. IEEE 논문의 기술적인 깊이는 일반 IT 책임자를 독자로 끌어들이기에 너무 깊지만, 필자는 새로운 혁신에 중점을 두고 상세한 해법을 제시하며 혁신을 증명하는 데 중점을 둔다는 점을 좋아한다. 때로는 너무 자세하다는 문제는 있지만.   최근 필자는 “모바일 클라우드 오프로딩을 위한 에너지 효율적인 의사 결정(Energy-Efficient Decision Making for Mobile Cloud Offloading)”이란 논문을 읽었다. 이 논문을 읽고 모바일 컴퓨팅 디바이스가 클라우드와 함께 한지가 10년이 넘었다는 것을 새삼 생각하게 됐다. 그럼에도 우리는 아직 모바일 디바이스 프로세싱과 데이터 스토리지의 계층화에 관해서는 본격적인 시도도 하지 않았고, 베스트 프랙티스도 만들지 않았다. 이제 때가 된 것 같다. 이 논문은 모바일 컴퓨팅의 개념을 퍼블릭 클라우드의 이점과 모바일 ‘터미널’의 이점을 결합한 것으로 설명했다. 터미널이란 용어는 과거 정보를 보여주고 소비하지만 처리하지는 않는 더미 디바이스를 이르는 말이었다. IT는 이미 가능한 한 많은 프로세싱과 데이터 스토리지를 퍼블릭 클라우드로 배치하고 있다는 점을 생각하면, 당연한 유추이다. 한편으로는 기술을 소형화해 저렴한 가격으로 쉽게 이용할 수 있도록 한 덕분에 일부 프로세싱과 스토리지 역량을 모바일 디바이스에 유지하는 것이 쉬워졌다. 이 때문에 가능한 한 많은 것을 원격지 클라우드 기반 시스템으로 보내는 것이 베스트 프랙티스임에도 모바일 디바이스는 ‘스마트’ 터미널이 되었다.  논문에서 언급한 ‘오프로딩’은 모바일 컴퓨팅 애플리케이션이 수년 동안 다뤄 온 것이다. 프로세싱과 스토리지의 위치를 묻는 것은 매우 일반적이다. 모바일 디바이스에 프로세싱과 데이터 스토리지를 유지해야 한다는 요구도 있는데, 사용자와의 인터랙션에 지연이 거의 없어야 하는 애플리케이션이다. 물론 장단점이 있다. 프로세...

2020.06.30

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.31