Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

칼럼ㅣ"개발자 생산성 측정, 객관적 지표 필요"

소프트웨어 개발팀의 강점은 개발자 개인이다. 각 개발자의 강점은 팀이다.  약 10년 전 필자는 ‘개발자의 생산성을 측정할 수 있는가(Can we measure developer productivity)?’라는 블로그 게시물을 썼다. 글에서 개발자의 생산성을 측정하기 위한 여러 객관적인 시도, 예를 들면 코드 라인, 기능 포인트 등을 논의했다. 아울러 몇 가지 주관적인 조치도 제안했다. 하지만 결론은 KPI를 사랑하는 관리자의 바람에도 불구하고 개별 소프트웨어 개발자의 생산성을 측정할 수 있는, 실행 가능한 방법은 없다는 것이었다.    10년 전에 쓴 글을 언급하는 이유는, 그 이후 몇 년 동안 상황이 크게 달라졌기 때문이다. 글을 썼을 시점에는 깃(Git)과 머큐리얼(Mercurial) 모두 유명하고 인기 있는 소프트웨어 소스 제어 시스템이었다. 당시 필자는 소프트웨어 관리자였고, 마이크로소프트의 비주얼 소스 세이프(VSS; 현재는 개발 중단된 소스 관리 프로그램)을 바꾸기로 하면서 윈도우에 더 친화적이었던 머큐리얼(Mercurial)을 선택했다.  잘못된 선택이었다. 당시에는 몰랐지만 이후 깃(Git)이 사실상의 버전 관리 표준으로 자리 잡았기 때문이다. 그 결과, 깃 저장소를 중심으로 가내 산업이 생겨났다. 깃허브(GitHub)는 마이크로소프트가 미화 75억 달러를 지불한 거대한 사업이다. 이제 많은 기업이 깃의 코드에 관한 측정 기준을 제공한다. 그리고 이러한 기업의 대다수가 소프트웨어 개발자의 생산성을 측정할 것이라고 주장한다.  지표 제시  만약 개발자 생산성을 측정하는 게 가능하다는 것을 인정한다면 그렇게 해야 하는지 물어봐야 한다.  그렇게 하고 싶은 욕구는 확실하긴 하다. 관리자는 유능한 개발자가 누구인지 알고 싶어 하며, 성과 평가 시 도움이 될 지표를 원한다. HR은 성과를 문서화하길 원한다. CEO는 지출이 효과적으로 사용되는지 알고 싶어 한다.  개별 개...

개발자 생산성 2022.11.18

개발자 개인의 성과 평가는 의미 없다…팀 단위 성과에 집중하라

소프트웨어 개발팀의 강점은 개발자 개인이다. 그리고 각 개발자의 강점은 팀이다.  약 10년 전 ‘개발자의 생산성을 측정할 수 있는가(Can we measure developer productivity)?’라는 블로그 게시물을 썼다. 글에서 개발자의 생산성을 측정하는 여러 객관적인 시도로 코드 라인, 기능 포인트 등을 논의했다. 아울러 몇 가지 주관적인 조치도 제안했다. 하지만 결론은 관리자는 KPI를 사랑하지만, 개별 소프트웨어 개발자의 생산성을 측정하는 실행 가능한 방법은 없다는 것이었다.    10년 전에 쓴 글을 언급하는 이유는, 이후 상황이 크게 달라졌기 때문이다. 글을 쓸 시점에는 깃(Git)과 머큐리얼(Mercurial) 모두 유명하고 인기 있는 소프트웨어 소스 제어 시스템이었다. 당시 필자는 소프트웨어 관리자였고, 마이크로소프트의 비주얼 소스 세이프(VSS, 현재는 개발 중단된 소스 관리 프로그램)을 바꾸기로 하면서 윈도우에 더 친화적이었던 머큐리얼을 선택했다.  잘못된 선택이었다. 당시에는 몰랐지만 이후 깃이 사실상 버전 관리 표준으로 자리 잡았기 때문이다. 그 결과 깃 저장소를 중심으로 많은 관련 산업이 생겨났다. 깃허브(GitHub)는 마이크로소프트가 미화 75억 달러를 내고 인수할 만큼 거대해졌다. 이제 많은 기업이 깃 코드의 측정 기준을 제공한다. 그리고 이러한 기업의 대다수가 소프트웨어 개발자의 생산성을 측정하겠다고 나서고 있다. 지표를 내놓아라  내키지는 않지만, 만약 개발자 생산성 측정이 가능하다는 것을 인정한다면 왜 그렇게 해야 하는지를 질문해야 한다.  욕구는 확실하다. 관리자는 유능한 개발자가 누구인지 알고 싶어 하며, 성과 평가에 도움이 될 지표를 원한다. HR은 성과를 문서화하기를 원한다. CEO는 지출이 효과적으로 사용되는지 알고 싶어 한다.  하지만 개별 개발자의 생산성을 측정하기 위해 새로운 도구를 사용하더라도 이러한 측정 기준은 조작...

개발자 생산성 2022.11.18

애플, 사파리 엔진 '웹킷' 깃허브로 이전

애플 사파리 웹브라우저의 핵심인 오픈소스 웹브라우저 엔진 ‘웹킷(WebKit)’의 개발이 깃허브로 마이그레이션됐다.    웹킷 프로젝트 팀이 지난 6월 23일 서브버전(Subversion; SVN) 트리를 동결하고, 소스코드 관리 및 인터랙션을 깃 버전 제어 시스템과 깃허브 저장소 호스팅 서비스로 전환했다고 8월 31일(현지 시각) 발표했다. 공식 블로그 게시물은 깃 및 깃허브로 이전한 이유를 다음과 같이 설명했다.  ■ 깃허브 이전 시 얻을 수 있는 이점  • 깃허브에는 웹킷 프로젝트가 엔진을 개선하기 위해 긴밀하게 협력하는 대규모 개발자(웹 개발자) 커뮤니티가 있다.  • 코드 변경 피드백을 제공하는 현대적이고 안전한 플랫폼을 제공한다.   • 깃허브 API를 사용하면 기존 인프라를 약간 수정하여 고급 사전-커밋 및 사후-커밋 자동화를 구축할 수 있다.  ■ 깃(Git) 이전 시 얻을 수 있는 이점  • 깃의 분산된 특성으로 인해 여러 개발자 및 조직이 단일 프로젝트에서 협업할 수 있다. • 깃허브는 소프트웨어 엔지니어링 어디에서나 사용된다.   • 깃의 로컬 변경 기록을 통해 쉽고 빠르게 브랜치 간 커밋을 이동하거나 변경사항을 되돌릴 수 있다.   • 깃의 작성자 및 커밋터 모델은 웹킷과 같은 대규모 소프트웨어 프로젝트가 코드를 작성하고 관리하는 복잡한 방식을 잘 나타낸다.  반면 웹킷 프로젝트 팀이 지적한 깃의 한 가지 단점은 해시가 자연스럽게 정렬되지 않는다는 것이다. 웹킷 팀은 프로젝트 저장소의 커밋 순서를 쉽게 추론할 수 있는 기능이 제로-톨레랑스 성능 회귀 정책에 중요하다는 점을 발견했다. 따라서 이분법이 필요한 워크플로우에서는 ‘커밋 식별자(commit identifiers)’를 사용하기로 했다고 덧붙였다. ciokr@idg.co.kr  

애플 깃허브 웹킷 2022.09.06

데브옵스 전사적 확장 이끈다··· 성능·확장성·안정성 모두 갖춘 ‘퍼포스’에 주목할 이유 - IDG Summary

데브옵스를 시작했고 이제 익숙해졌다고 판단한 기업이 전사적 확장을 고민하고 있다면? 형상 관리 측면에서 폭발적으로 증가하는 리포지토리, 버전 관리를 필요로 하는 수많은 파일을 어떻게 관리할 것인가? 여기에 파일 크기까지 엄청나다면? 글로벌로 분산된 팀이 함께 작업하는 대규모 프로젝트라면? 또 이에 부합하는 성능은 어떻게 지원할 것인가? 전사적으로 끊임없는 변화를 수용해야 하는 상황에서 변경 관리 프로세스를 일관되게 확장할 수 있게 하는 것은 엔터프라이즈 데브옵스에서 가장 어려운 부분 가운데 하나다. 데브옵스의 전사적 확장 과정에서 발생하는 이같은 문제를 해결하는 '퍼포스(Perforce Helix Core)'를 알아보는 한편 이 솔루션이 성공적인 엔터프라이즈 데브옵스에서 어떤 의미를 갖는지 살펴본다. 주요 내용 - '성공적인 데브옵스 확장'을 지원하다  - 쉽게 사용할 수 있는 인터페이스와 도구  - 엔터프라이즈 데브옵스, 성공하려면 '확장성'에 집중하라 

플래티어 퍼포스 데브옵스 2021.05.06

글로벌 칼럼ㅣ‘리눅스’는 여전히 ‘표준’이다

'리눅스(Linux)'는 오픈소스의 성공 기반을 닦았을 뿐만 아니라 오픈소스 커뮤니티의 운영 방식을 구체화했다. 우리는 리눅스에 대해 충분히 이야기하고 있는가? 오픈소스 세상에서 자라난 사람뿐만 아니라 오픈소스를 처음 접한 사람 모두 리눅스 커뮤니티의 선구적인 역할에 감사해야 한다. 어쨌든 리눅스는 오픈소스가 무엇을 의미하는지, 그리고 이것이 개인, 기업, 정부에 무엇을 의미할 수 있는지를 보여주는 대표적인 첫 모델이었다.    리눅스 창시자 리누스 토발즈를 포함한 ‘리눅스 커뮤니티’는 오늘날 오픈소스가 작동하는 방식 또한 정의했다. 깃(Git)부터 조직 구조(메인테이너, 커미터 등)에 이르기까지 리눅스는 오픈소스 커뮤니티 운영 방식에 직접적으로 또는 간접적으로 영향을 미쳤다.  여기서는 리눅스 재단의 ‘2020년 리눅스 커널 역사 보고서(2020 Linux Kernel History Report)’에 따라 리눅스가 어떻게 오픈소스의 기반을 닦아 놓았는지를 살펴본다.  대규모 협력 리눅스는 모든 것이 크다(임베디드 리눅스 배포판을 실행하는 수많은 IoT 장치는 예외다). 올해로 리눅스는 탄생 29주년을 맞았다. 현재까지 2만 명이 넘는 기여자(contributors)가 참여했고, 100만 개의 커밋(2020년 8월 기준)이 추가됐다. 지난 몇 년으로 따지자면 평균 7만 5,000개의 커밋이 추가됐다. 놀라운 기록이다.  물론 처음부터 이렇진 않았다.  리눅스는 토발즈의 단독 프로젝트로 시작됐다. 그리고 1996년경 앨런 콕스와 존 네일러가 합류했다. 이들은 서로를 ‘메인테이너’라고 불렀다. 같은 기간 동안 아파치 웹 서버와 같은 다른 프로젝트도 조직적인 형태를 갖췄지만, 필자가 아는 한 메인테이너 계층을 중심으로 이렇게 빠르게(그리고 공식적으로) 조직화된 사례는 없었다.  이러한 계층은 중요했다. 최초의 MAINTERS 파일(커널 v1.3.68용)에서 밝힌 바와 같이 프로젝트 커뮤니케...

리눅스 리누스토발즈 커미터 2020.09.14

깃랩 13.0 업데이트, 보안 중심의 신기능 추가 

깃랩(GitLab)이 5월 22일 소프트웨어 개발, 배포 및 프로젝트 관리 툴을 통합한 자사의 데브옵스 플랫폼을 버전 13.0으로 업데이트했다. 이번 버전은 여러 보안 및 협업 기능을 추가한 것이 특징이다.  깃랩에 따르면 깃랩 13.0에는 깃(Git) 오픈소스 분산 버전 관리 시스템, CI/CD, 설계 및 협업 도구가 결합됐다. 이 밖의 새로운 기능들은 다음과 같다.   • 보안 스캐닝: 보안 스캐닝을 위해 닷넷(.NET) 프레임워크용 SAST(Static Application Security Testing)를 제공한다. REST API에 대해서는 DAST(Dynamic Application Security Testing) 스캐닝을 지원한다. 또한 깃랩 13.0은 오프라인 환경 스캐닝을 위한 지원도 확대한다. • 취약성 분리: 취약성 및 관련 리스크의 우선순위를 정하고 관리할 수 있도록 취약성 관리 방법을 재설계했다. • 컴플라이언스 관리: 컴플라이언스 프레임워크 구축을 자동화하고, 규제 제어를 적용하며, 감사보고를 간소화할 수 있게 됐다. 이와 함께 보안 가드레일을 단순화하는 초기 보안정책 UI도 개발 중이라고 회사 측은 설명했다. • 설계 관리: 제품을 설계하는 사용자를 개별 기여자로 인식할 수 있도록 설계 관리를 핵심 부문으로 이전했다. • 대시보드: 운영 대시보드는 여러 변수를 사용하도록 허용해 사용자 정의가 용이해졌다. 보안 대시보드는 깃랩 외의 사용자들과도 협업할 수 있도록 내보내기가 가능하다. 쿠버네티스 클러스터(Kubernetes clusters) 지원은 향후 제공될 예정이다. • 깃앨리 클러스터(Gitaly Cluster): 깃 리포지토리(Git Repository) 스토리지에 장애가 발생하는 경우 이를 즉시 복구하는 웜 레플리카(Warm Replica)를 제공할 수 있도록 깃앨리 클러스터가 지원된다. • 가치 흐름 관리(Value Stream Management): 병목현상 및 낭비 요소를 빠르게 식별할 수...

깃랩 데브옵스 2020.06.08

비주얼 스튜디오 업데이트…깃과 모바일 개발 지원 강화

마이크로소프트의 대표적인 통합개발환경(IDE)인 비주얼 스튜디오 2019 버전 16.6 프리뷰 3가 4월 16일 공개됐다. 툴 자체적으로 깃을 지원하고 모바일 개발 기능이 추가됐다. 비주얼 스튜디오 웹사이트에서 다운로드할 수 있으며, 주요 개선점은 다음과 같다.   깃 버전 제어 기능을 개선해, 이제는 클론 생성을 끝낸 후 자동으로 솔루션을 로딩한다. 커밋과 스태싱 관련 사용자 인터페이스를 업데이트했고, 톱 레벨 깃 메뉴에 키보드로 쓸 수 있는 새 기능을 추가했다. 예를 들면 리포지토리 복제, 파일 탐색기나 커맨드 프롬프트에서 리포지토리 열기, 브랜치 히스토리 열기, 글로벌 리포지토리 설정 바로가기 등이다. 원격 브랜치 관리도 강화됐다. 모바일 개발 관련해서, XAML 핫 리로드(XAML Hot Reload)가 더 빨라졌다. 페이지에서 변화가 있을 때 상태를 더 잘 유지해, 이제는 XAML이 바뀐다고 해서 전체 페이지를 다시 열지 않는다. '리로드만 수정(Changes Only Reload)' 설정 덕분이다. 프리뷰에서는 이 리로드 기능을 활성화하거나 끌 수 있다. 또한 AAC(Android Apply Changes) 속도가 빨라져 자마린 안드로이드 개발자가 더 쉽게 UI를 편집할 수 있게 됐다.  비주얼 스튜디오 터미널의 폰트와 색깔 대화창에서 글꼴과 크기를 바꾸는 기능이 추가됐다. 격리 테스트 프레임워크인 마이크로소프트 페이크(Microsoft Fakes)가 이제 닷넷 코어를 지원한다. 한편 비주얼 스튜디오 2019 버전 16.6의 이전 프리뷰는 3월 16일과 26일에 나왔다. 이 프리뷰에서는 깃 경험을 개선하고 리모트 호스팅 서비스를 지원하고 스냅샷 디버깅을 강화했다. C++ 기능 개선과 새 XAML 기능도 추가됐다. editor@itworld.co.kr

비주얼스튜디오 개발자 2020.04.21

업데이트 | 가장 위험한 깃 실수 6가지와 빠른 수습 방법

개발자들이 깃(Git) 같은 소스 제어 시스템을 사용하는 주된 이유는 대형 사고를 피하기 위해서다. 실수로 파일 하나를 삭제한 경우 또는 파일 몇 개에 적용된 변경이 잘못되었음을 알게 되는 경우에는 어렵지 않게 되돌릴 수 있다.   이중에는 경험 많은 깃 사용자라 해도 되돌리기가 어려운 실수도 있다. 설령 프로그래머들이 듣더라고 깜짝 놀랄 최악의 실수를 저질렀다 해도 패닉에 빠지지 않고 신중하게 대처하면 롤백이 가능하다.   깃에서 저지를 수 있는 큰 실수와 함께 이를 되돌리고 애초에 방지하기 위한 팁을 소개한다. 목록 마지막으로 갈수록 더 심각한 사고다.   깃 실수 1: 마지막 커밋에 깜박하고 변경을 추가하지 않았을 때 깃 실수 중에서 복구하기가 가장 쉬운 실수에 속한다. 예를 들어 로컬 분기에 작업을 커밋한 이후에 필요한 일부 파일을 스테이징하지 않았다는 사실을 알게 되거나, 커밋 메시지에 세부 정보를 추가하지 않았다는 것을 뒤늦게 깨닫는 경우다. 걱정할 필요 없다. 먼저 스테이징할 새로운 변경 사항이 있다면 스테이징을 한다. 그 다음 git commit --amend를 입력해서 커밋 메시지를 편집한다. Esc를 누른 다음 :xq를 입력해서 저장하고 편집기에서 나온다. (기본 깃 편집기의 특징을 잘 모르는 깃 초보자는 이 마지막 단계에서 당황하는 경우가 많다.) 파일만 변경하고 커밋 메시지를 수정할 필요는 없다면 git commit --amend --no-edit를 사용해서 파일을 추가하고 메시지 편집 과정을 생략할 수 있다.   이와 같은 종류의 실수를 피하려면 깃에서 커밋하는 방법을 바꿔야 한다. 증분적 리비전을 추적하기 위해 수시로 작게 커밋하는 작업은 임시 분기에서 한다. 그리고 이 과정에서 중요한 변경은 git commit 명령을 하는 시점까지 기다리지 말고 다른 곳에 문서로 작성한다. 그런 다음 중요한 이정표에 도달하면 임시 분기에서 git merge --squash를 사용해서 정규 작업 분기에 ...

2020.03.12

깃허브 대 비트버킷 대 깃랩: 개발자의 마음을 사기 위한 치열한 경쟁

오늘날의 소프트웨어 개발은 너무 복잡해져서 만들어야 할 소프트웨어를 이해하고 제작하는 데 도움이 되는 소프트웨어를 만들어야 할 판이다. 코드가 코드를 낳고, 그 코드가 또 다른 코드를 낳는다 깃(Git)이라는 이름의 코드 리포지토리가 소프트웨어를 관리하기 위한 툴로 각광받고 있지만, 이것으로도 충분하지는 않다. 대부분의 프로그래머와 이들이 속한 팀은 다양한 부가적인 분석 및 프레젠테이션 계층을 더해 광활한 늪지와 같은 코드를 헤쳐 나갈 수 있게 해주는 온라인 버전의 깃을 애용한다. 정규식과 익명 함수, 재귀적 트리 워킹 등을 쌓아 두기 위한 최적의 장소는 깃허브(GitHub), 비트버킷(Bitbucket), 깃랩(GitLab) 세 곳인데, 이 세 플랫폼이 소스를 보관할 최적의 장소를 두고 경쟁 중이다. 셋 중 어느 것이 가장 좋을까? 팀에서는 어느 것을 사용하는 편이 가장 유리할까? 셋을 비교해 보고 어느 것이 가장 뛰어난지 확인해 보자. 깃허브가 가장 크다 깃 리포지토리 호스팅에 전문화된 최초의 대규모 웹사이트. 오픈소스 커뮤니티에서의 긍정적인 활동, 이유가 무엇이든 순수한 코드 양을 기준으로 보면 깃허브가 가장 크다. 깃허브에 따르면 사용자 수는 2,800만 명, 리포지토리는 8,500만 개에 이른다. 비트버킷 사용자는 600만 명이고 깃랩은 무슨 이유에선지 사용자 수를 묻는 질문에 답을 하지 않았다. 규모를 중시하는 사람도 있다. 여러 프로젝트 사이를 자주 오가는 오픈소스 개발자들은 한 번 로그인해서 모든 작업을 연결할 수 있다. 고양이를 좋아하는 사람들이 유튜브에서 인기 고양이 비디오 제작자들을 팔로우하듯이, 깃허브에서도 인기 개발자를 팔로우할 수 있다. 인터넷을 지배하는 네트워크 효과가 깃허브에서도 제대로 힘을 발휘하고 있다. 반면 규모를 그다지 중시하지 않는 사람도 있다. 많은 개발자가 공개 코드는 기꺼이 연결하더라도 클라이언트를 위한 작업은 연결하고 싶어하지 않는다. 그 코드를 별도로, 비공개로 보관해야 한...

소스코드 깃허브 Git 2018.07.11

프로그래머 개발 도우미 ‘깃허브’ 완전정복 - IDG DeepDive

소스코드를 저장, 공유하는 리포지토리가 소프트웨어 개발의 필수 툴로 부상하고 있다. 특히 오픈소스 리포지토리 서비스인 ‘깃허브’는 개인 개발자부터 중소기업, 대기업까지 거의 모든 개발 조직의 주목을 받고 있다. 깃허브를 도입한 한 대기업은 오랜 병폐 중 하나인 관료주의를 몰아내고 혁신을 이뤘다고 평가하기도 했다. 개발자가 사랑하는 필수 프로그래밍 도우미 ‘깃허브’의 활용 가치와 그 세계에 입문하는 필수 팁을 살펴보자. <주요 내용> - 점점 달아오르는 기업용 리포지토리 ‘삼국지’ - 깃허브 처음 시작하기 - ‘깃 스마트!’ 깃허브 사용자를 위한 20가지 필수 팁 - 월마트, 오픈소스로 관료주의를 몰아내다 - 기업의 미래를 보는 특별한 기준 ‘깃허브 수용도’

오픈소스 깃허브 2017.01.11

올해가 가기 전에 반드시 배워야 할 6가지 IT 기술

기술은 빠르게 변한다. 그래서 자바 1.3 코드 편집이나 파워빌더(PowerBuilder)에만 집착하면 새로운 취업 기회를 잡기가 점점 어려워질 것이다. 그렇다면 어떤 기술을 배워야 할까? 자신의 경력을 계속 발전시키고 시장 수요에 맞춰 연봉을 높이려면 지금 제시하는 6가지 기술 정도는 알고 있어야 한다. 1. 하둡 : 신기술 시장의 지배자 아직 하둡에 대해 잘 모르고 있다면 서둘러 하둡(Hadoop)에 통달해야 한다. 맵리듀스(MapReduce) 개념과 이용 방법도 알아야 한다. 하둡은 인기와 수요 등 모든 기준에서 신기술 시장을 지배하고 있다. 다른 기술을 배울 능력도 있을 수 있지만 하둡은 더 어렵다. 'Hello world' 이상을 터득하기 위해서는 더 많은 시간과 노력을 기울여야 한다. 가장 어려운 작업 중 하나는 스스로 공부를 할 간단한 주제를 찾는 것이다. 그러나 이조차도 그리 쉽지는 않다. 충분한 데이터를 확보하는 것도 마찬가지다. 위키피디아(Wikipedia)같이 인기는 있지만, 덩치가 커서 별 쓸모없는 데이터들이 있다. 어쩌면 이를 다른 것들과 결합해, 누가 누구를 '편집하는 것'을 좋아하는지 보여주는 일종의 소셜 그래프를 만드는 것도 방법이다. 호튼워크(Hortonwork)는 깃허브(GitHub)와 관련해 유사한 개념을 입증해 보였다. 일단 '손을 더럽히고 나면' 맵리듀스가 대답할 수 있는 다른 질문 결과를 화면에서 확인할 수 있게 될 것이다. 이 분야에는 호튼워크 같이 하둡에만 전문화된 회사에서 (VM웨어/EMC에서 분사한) 피보탈(Pivotal) 같이 여러 기술을 취급하는 업체, 자신들의 제품에 하둡을 도입하기 시작한 오라클(Oracle) 등 기존 업체까지 많은 기업이 있다. 이 가운데 어떤 회사도 성장 가능성은 무궁무진하다. 2. 몽고DB : 객체지향형 백 엔드의 출발점 하둡만큼 거대하지는 않지만 몽고DB(MongoDB) 또한 중요한 기술이다. 또 훨씬 배우기 쉽다....

스칼라 어셈블리 하둡 2013.08.26

IDG 설문조사

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

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

Copyright © 2022 International Data Group. All rights reserved.