Offcanvas

���������

애자일 vs 워터폴··· 프로젝트 방법론 비교하기

애자일과 워터폴은 각각 장점과 단점이 있다. 각 방법론의 장단점 그리고 각 조직의 프로젝트에 적합한 방법론을 구별하는 방법은 아래와 같다. 프로젝트 개발에 적합한 방법론을 선택하는 일은 프로젝트 성공을 위한 첫걸음이다. 그러나 각 조직이 당면한 프로젝트에 어떤 방법론이 가장 적합한지를 구별하기는 쉽지 않다. 선택할 수 있는 프로젝트 관리 방법론의 가짓수가 너무 많을 땐 특히 그렇다.  널리 사용되는 대표적인 방법론은 애자일과 워터폴이다. 프로젝트 유형, 팀 구조, 역량, 인재 등의 요인에 따라 적합한 방법론의 유형은 다르다. 각 방법론의 개요, 장단점, 최적화된 조직 유형, 프로젝트 성공에 필요한 역량의 유형을 살펴본다.     애자일이란 무엇인가? 애자일은 1970년대 윌리엄 로이스가 대형 소프트웨어 시스템 개발에 관해 제출한 논문에서 처음 등장했으며, '스프린트'(sprint)라는 짧고 점진적인 개발 주기로 구성된 프로젝트 관리 방법론이다. 각 주기는 제품이나 서비스 개발을 지속적으로 향상시키는 데 초점이 맞춰져 있다. 애자일 방법론은 애자일 선언(Agile Manifesto)의 4가지 기본 가치와 12가지 원칙에 바탕을 두고 있으며, 반복적이며 사람 중심적인 개발 방식을 취한다. 프로세스는 다음과 같다.    계획: 고객과 주요 이해관계자들이 함께 프로젝트 개념화, 브레인스토밍, 정의, 우선순위설정, 필요 자원, 예산 책정을 논의한다. 그다음 승인 및 실행하는 작업이 이뤄진다.  설계: 사용자경험 전문가가 스크럼 마스터, 클라이언트, 제품팀 그리고 기타 주요 이해관계자와 협력해 제품의 모양새와 여타 요소들을 결정한다.  개발: 개발팀은 이 단계에서 ‘스프린트’라고 불리는 여러 반복 작업을 거치며 고객 요구사항에 맞는 제품을 개발한다. 테스팅: 테스팅 단계에서는 제품이 고객 요구사항을 충족하는지 확인한다. 만약 결함이 발견되면 해당 제품을 개발 단계로...

애자일 워터폴 개발 방법론 스프린트

2020.10.06

애자일과 워터폴은 각각 장점과 단점이 있다. 각 방법론의 장단점 그리고 각 조직의 프로젝트에 적합한 방법론을 구별하는 방법은 아래와 같다. 프로젝트 개발에 적합한 방법론을 선택하는 일은 프로젝트 성공을 위한 첫걸음이다. 그러나 각 조직이 당면한 프로젝트에 어떤 방법론이 가장 적합한지를 구별하기는 쉽지 않다. 선택할 수 있는 프로젝트 관리 방법론의 가짓수가 너무 많을 땐 특히 그렇다.  널리 사용되는 대표적인 방법론은 애자일과 워터폴이다. 프로젝트 유형, 팀 구조, 역량, 인재 등의 요인에 따라 적합한 방법론의 유형은 다르다. 각 방법론의 개요, 장단점, 최적화된 조직 유형, 프로젝트 성공에 필요한 역량의 유형을 살펴본다.     애자일이란 무엇인가? 애자일은 1970년대 윌리엄 로이스가 대형 소프트웨어 시스템 개발에 관해 제출한 논문에서 처음 등장했으며, '스프린트'(sprint)라는 짧고 점진적인 개발 주기로 구성된 프로젝트 관리 방법론이다. 각 주기는 제품이나 서비스 개발을 지속적으로 향상시키는 데 초점이 맞춰져 있다. 애자일 방법론은 애자일 선언(Agile Manifesto)의 4가지 기본 가치와 12가지 원칙에 바탕을 두고 있으며, 반복적이며 사람 중심적인 개발 방식을 취한다. 프로세스는 다음과 같다.    계획: 고객과 주요 이해관계자들이 함께 프로젝트 개념화, 브레인스토밍, 정의, 우선순위설정, 필요 자원, 예산 책정을 논의한다. 그다음 승인 및 실행하는 작업이 이뤄진다.  설계: 사용자경험 전문가가 스크럼 마스터, 클라이언트, 제품팀 그리고 기타 주요 이해관계자와 협력해 제품의 모양새와 여타 요소들을 결정한다.  개발: 개발팀은 이 단계에서 ‘스프린트’라고 불리는 여러 반복 작업을 거치며 고객 요구사항에 맞는 제품을 개발한다. 테스팅: 테스팅 단계에서는 제품이 고객 요구사항을 충족하는지 확인한다. 만약 결함이 발견되면 해당 제품을 개발 단계로...

2020.10.06

블로그 | 최고의 클라우드 마이그레이션 방법론은?

클라우드 마이그레이션 프로젝트는 두 가지 측면이 있다. 첫째는 단기 전력질주이다. 프로젝트팀은 몇 가지 애플리케이션 워크로드와 데이터를 하나 또는 여러 클라우드로 이전한다. 이 프로젝트는 독립적으로 움직이며, 아키텍처 측면의 규제나 통제도 적고 기간도 2~6개월 정도이다. 둘째는 보안, 거버넌스, 관리, 모니터링을 포괄하는 장기적인 아키텍처이다. 클라우드 사업부와 CTO 또는 클라우드 아키텍트가 방향을 잡으며, 이 과정은 지속된다.   문제는 여기에 있다. 전자가 후자를 덮어버리는 것이다. 즉 무작위적이고 개별적인 전력질주 방식을 사용해 클라우드로 마이그레이션하고, 공통된 보안이나 거버넌스, 관리나 모니터링에 대한 고려는 별로 없다는 것이다. 그 결과는 복잡성으로 나타난다. 뭔가 동작하는 것처럼 보이는 것을 만들었지만, 애플리케이션은 한 플랫폼에서 다른 플랫폼으로 옮겨지고, 다른 기술 스택을 이용해 배치된다. 이렇게 구축한 애플리케이션은 실제 운영 단계에 들어서면서 현재의 자원으로 운영하기에는 너무 복잡하다는 것이 드러난다. 실수는 이미 저질러졌고, 시스템은 금방 침해되고 서비스 중단은 일상화된다. 이 모든 것은 전력질주식 마이그레이션 프로젝트 때문이다. 그렇다고 이런 민첩한 방식이 잘못됐다는 것은 아니다. 대신 일종의 중앙통제센터가 필요하다. 예를 들어, 견고한 레퍼런스의 공통 아키텍처로 보안이나 거버넌스, 데이터, 관리, 그리고 애플리케이션에 적용되는 모든 시스템의 기초를 갖추는 것이다. 베스트 오브 브리드 방식이나 멀티클라우드 솔루션을 추구할 때 자칫 목표 클라우드 솔루션을 제대로 최적화해야 한다는 것을 놓칠 수 있다. 개별 프로젝트는 온전히 최적화된 클라우드 시스템에 집중할 수 있지만, 공통성이 별로 없는 수많은 다른 시스템의 맥락에서 이상적인 시스템을 만들어내지는 못한다. 따라서 제대로 된 접근방법은 두 방식을 모두 추구하는 것이다. 프로젝트의 길과 공통 아키텍처와 솔루션의 길이다. 이 두 가지는 충분히 연결되어 공통 기술 솔루...

마이그레이션 아키텍처 방법론

2019.12.12

클라우드 마이그레이션 프로젝트는 두 가지 측면이 있다. 첫째는 단기 전력질주이다. 프로젝트팀은 몇 가지 애플리케이션 워크로드와 데이터를 하나 또는 여러 클라우드로 이전한다. 이 프로젝트는 독립적으로 움직이며, 아키텍처 측면의 규제나 통제도 적고 기간도 2~6개월 정도이다. 둘째는 보안, 거버넌스, 관리, 모니터링을 포괄하는 장기적인 아키텍처이다. 클라우드 사업부와 CTO 또는 클라우드 아키텍트가 방향을 잡으며, 이 과정은 지속된다.   문제는 여기에 있다. 전자가 후자를 덮어버리는 것이다. 즉 무작위적이고 개별적인 전력질주 방식을 사용해 클라우드로 마이그레이션하고, 공통된 보안이나 거버넌스, 관리나 모니터링에 대한 고려는 별로 없다는 것이다. 그 결과는 복잡성으로 나타난다. 뭔가 동작하는 것처럼 보이는 것을 만들었지만, 애플리케이션은 한 플랫폼에서 다른 플랫폼으로 옮겨지고, 다른 기술 스택을 이용해 배치된다. 이렇게 구축한 애플리케이션은 실제 운영 단계에 들어서면서 현재의 자원으로 운영하기에는 너무 복잡하다는 것이 드러난다. 실수는 이미 저질러졌고, 시스템은 금방 침해되고 서비스 중단은 일상화된다. 이 모든 것은 전력질주식 마이그레이션 프로젝트 때문이다. 그렇다고 이런 민첩한 방식이 잘못됐다는 것은 아니다. 대신 일종의 중앙통제센터가 필요하다. 예를 들어, 견고한 레퍼런스의 공통 아키텍처로 보안이나 거버넌스, 데이터, 관리, 그리고 애플리케이션에 적용되는 모든 시스템의 기초를 갖추는 것이다. 베스트 오브 브리드 방식이나 멀티클라우드 솔루션을 추구할 때 자칫 목표 클라우드 솔루션을 제대로 최적화해야 한다는 것을 놓칠 수 있다. 개별 프로젝트는 온전히 최적화된 클라우드 시스템에 집중할 수 있지만, 공통성이 별로 없는 수많은 다른 시스템의 맥락에서 이상적인 시스템을 만들어내지는 못한다. 따라서 제대로 된 접근방법은 두 방식을 모두 추구하는 것이다. 프로젝트의 길과 공통 아키텍처와 솔루션의 길이다. 이 두 가지는 충분히 연결되어 공통 기술 솔루...

2019.12.12

애자일을 완성하는 코딩 프랙티스 7가지

애자일 원칙과 방법이 애자일 소프트웨어 개발의 전부는 아니다. 최종 사용자에게 긍정적인 영향을 미치고 기술 부채에 대처하고 안정적으로 배포되는 성공적인 소프트웨어 릴리스를 위해서는 민첩성을 유도하는 코딩 방법과 아키텍처 표준도 고려해야 한다.   기술 조직의 경우 더욱 중요한 고려사항이 있다. 소프트웨어 개발도 어렵지만 오랜 기간 동안 정기적으로 기능 향상과 업그레이드를 배포하기는 더욱 어렵다. 데브옵스 CI/CD와 IAC(Infrastructure as Code, 코드형 인프라)에서는 자동화가 안정적이고 반복 가능한 애플리케이션 배포 방법을 제공하므로 한 가지 중요한 문제가 부분적으로 해결된다. 개발 팀은 여기에 지속적 테스트를 더함으로써 코드 변경이 기존 기능에 영향을 미치지 않도록 할 수 있다.  그러나 애플리케이션이 나오고 시간이 지나면 최초 개발자는 다른 프로젝트, 때로는 다른 회사로 자리를 옮긴다. 팀에 합류한 신규 개발자가 코드를 안정적, 효율적으로 변경하려면 먼저 소프트웨어의 아키텍처를 배우고 코드를 이해해야 한다. 게다가 애플리케이션을 만드는 개발자는 많은 경우 새로운 애플리케이션을 개발하기를 원한다. 자신이 개발한 애플리케이션에 계속 붙어있는 것이 편안하고 안전하게 느껴질 수 있지만, 코드에 묶이는 것은 스스로의 경력, 또는 조직 관점에서 건강한 습관이 아니다. 새롭고 흥미로운 소프트웨어 개발 이니셔티브로 옮겨가는 최선의 방법은 다른 개발자가 손쉽게 지원할 수 있는 아키텍처, 애플리케이션, 코드를 만드는 것이다. 애자일 팀과 개발자는 지속적인 소프트웨어 개발을 지탱하는 코딩 원칙을 수립하고 시행해야 한다.   1. 불필요한 일을 하지 말 것 코딩의 제 1원칙 : 코딩할 필요가 없는 것을 코딩하지 말라! -    요구사항에 대해 질문을 하는 것이 좋다. 어떤 기능이 왜 중요한가? 누구에게 이익이 되는가? 더 구체적으로, 문제를 해결하기 위한 코딩 이외의 방법이 있는지 살펴보라. 아...

애자일 데브옵스 규칙 방법론 프랙티스

2019.10.23

애자일 원칙과 방법이 애자일 소프트웨어 개발의 전부는 아니다. 최종 사용자에게 긍정적인 영향을 미치고 기술 부채에 대처하고 안정적으로 배포되는 성공적인 소프트웨어 릴리스를 위해서는 민첩성을 유도하는 코딩 방법과 아키텍처 표준도 고려해야 한다.   기술 조직의 경우 더욱 중요한 고려사항이 있다. 소프트웨어 개발도 어렵지만 오랜 기간 동안 정기적으로 기능 향상과 업그레이드를 배포하기는 더욱 어렵다. 데브옵스 CI/CD와 IAC(Infrastructure as Code, 코드형 인프라)에서는 자동화가 안정적이고 반복 가능한 애플리케이션 배포 방법을 제공하므로 한 가지 중요한 문제가 부분적으로 해결된다. 개발 팀은 여기에 지속적 테스트를 더함으로써 코드 변경이 기존 기능에 영향을 미치지 않도록 할 수 있다.  그러나 애플리케이션이 나오고 시간이 지나면 최초 개발자는 다른 프로젝트, 때로는 다른 회사로 자리를 옮긴다. 팀에 합류한 신규 개발자가 코드를 안정적, 효율적으로 변경하려면 먼저 소프트웨어의 아키텍처를 배우고 코드를 이해해야 한다. 게다가 애플리케이션을 만드는 개발자는 많은 경우 새로운 애플리케이션을 개발하기를 원한다. 자신이 개발한 애플리케이션에 계속 붙어있는 것이 편안하고 안전하게 느껴질 수 있지만, 코드에 묶이는 것은 스스로의 경력, 또는 조직 관점에서 건강한 습관이 아니다. 새롭고 흥미로운 소프트웨어 개발 이니셔티브로 옮겨가는 최선의 방법은 다른 개발자가 손쉽게 지원할 수 있는 아키텍처, 애플리케이션, 코드를 만드는 것이다. 애자일 팀과 개발자는 지속적인 소프트웨어 개발을 지탱하는 코딩 원칙을 수립하고 시행해야 한다.   1. 불필요한 일을 하지 말 것 코딩의 제 1원칙 : 코딩할 필요가 없는 것을 코딩하지 말라! -    요구사항에 대해 질문을 하는 것이 좋다. 어떤 기능이 왜 중요한가? 누구에게 이익이 되는가? 더 구체적으로, 문제를 해결하기 위한 코딩 이외의 방법이 있는지 살펴보라. 아...

2019.10.23

목표 달성을 위한 전략적 툴, 'SWOT 분석' 이해하기

SWOT 분석은 목표를 달성하고, 기업 운영을 개선하며 시장의 변화에 발맞추기 위해 시행하는 전략적 플래닝 방법론이다. SWOT 분석에서는 해당 기업의 성장세, 제품 및 서비스, 비즈니스 목표, 시장 경쟁 상황과 관련된 강점(Strength), 약점(Weakness), 기회(Opportunity), 그리고 위협(Threat)을 분석하게 되며, 각 앞 글자를 따서 SWOT이라 부른다.  SWOT 분석에는 보통 2x2 매트릭스를 사용하며, 수평으로는 내부적 분석(강점과 약점)과 외부적 분석(기회와 위협) 요인을, 수직으로는 긍정적 요소(강점과 기회)와 부정적 요소(약점과 위협)를 정리한다.  이러한 분석을 통해 기업은 자사의 비즈니스 목표, 제품 및 서비스, 프로젝트 등이 전략적으로 적합한가를 판단할 수 있다. 이 때 최선의 전략은 기업의 내부 환경(강점과 약점)과 외부 환경(기회와 위협)이 어긋나지 않고 맞물려 돌아갈 수 있는 것이 된다. 강점과 약점 강점과 약점은 기업의 목표, 프로젝트, 이니셔티브 등에 의해 결정되는 내부적 요소들이다. 어떤 목표를 선택 하는가에 따라 달라지는 요소이므로, A 목표를 선택했을 때는 강점이던 것이 B 목표를 선택하면 약점이 될 수도 있다. 강점은 기업이 통제할 수 있는 무언가로써, 특정 목표, 이니셔티브, 프로젝트, 목적을 달성하기 위해 기업이 행하는 모든 긍정적인 활동이 포함될 수 있다. 또 목표 달성을 위해 기업에 이점을 주는 모든 것, 목표 달성 및 프로젝트 이행 과정에 도움을 주는 모든 요소가 강점에 포함된다.  약점 역시 기업이 통제할 수 있는 요소이지만, 여기에는 기업의 비즈니스 목표 달성, 프로젝트 이행 등을 방해하는 모든 것이 포함된다. 약점 카테고리에 포함된 사항들은 기업이 성공적인 목표 달성을 위해 변경하거나 수정해야 할 것들이다. 기회와 위협 기회와 위협은 외부 환경에 존재하며 기업의 목표달성 및 프로젝트 이행에 긍정적 또는 부정적 영향을 미칠 수 있는 요인들을 가리킨...

전략 약점 위협 기회 SWOT 방법론 강점

2018.12.31

SWOT 분석은 목표를 달성하고, 기업 운영을 개선하며 시장의 변화에 발맞추기 위해 시행하는 전략적 플래닝 방법론이다. SWOT 분석에서는 해당 기업의 성장세, 제품 및 서비스, 비즈니스 목표, 시장 경쟁 상황과 관련된 강점(Strength), 약점(Weakness), 기회(Opportunity), 그리고 위협(Threat)을 분석하게 되며, 각 앞 글자를 따서 SWOT이라 부른다.  SWOT 분석에는 보통 2x2 매트릭스를 사용하며, 수평으로는 내부적 분석(강점과 약점)과 외부적 분석(기회와 위협) 요인을, 수직으로는 긍정적 요소(강점과 기회)와 부정적 요소(약점과 위협)를 정리한다.  이러한 분석을 통해 기업은 자사의 비즈니스 목표, 제품 및 서비스, 프로젝트 등이 전략적으로 적합한가를 판단할 수 있다. 이 때 최선의 전략은 기업의 내부 환경(강점과 약점)과 외부 환경(기회와 위협)이 어긋나지 않고 맞물려 돌아갈 수 있는 것이 된다. 강점과 약점 강점과 약점은 기업의 목표, 프로젝트, 이니셔티브 등에 의해 결정되는 내부적 요소들이다. 어떤 목표를 선택 하는가에 따라 달라지는 요소이므로, A 목표를 선택했을 때는 강점이던 것이 B 목표를 선택하면 약점이 될 수도 있다. 강점은 기업이 통제할 수 있는 무언가로써, 특정 목표, 이니셔티브, 프로젝트, 목적을 달성하기 위해 기업이 행하는 모든 긍정적인 활동이 포함될 수 있다. 또 목표 달성을 위해 기업에 이점을 주는 모든 것, 목표 달성 및 프로젝트 이행 과정에 도움을 주는 모든 요소가 강점에 포함된다.  약점 역시 기업이 통제할 수 있는 요소이지만, 여기에는 기업의 비즈니스 목표 달성, 프로젝트 이행 등을 방해하는 모든 것이 포함된다. 약점 카테고리에 포함된 사항들은 기업이 성공적인 목표 달성을 위해 변경하거나 수정해야 할 것들이다. 기회와 위협 기회와 위협은 외부 환경에 존재하며 기업의 목표달성 및 프로젝트 이행에 긍정적 또는 부정적 영향을 미칠 수 있는 요인들을 가리킨...

2018.12.31

블로그 | 아이디어 평가에 '정석'을 경계하라

IT 매니저들은 하루의 상당 부분을 아이디어를 상대하며 보낸다. 초기 아이디어를 가다듬고, 평가한다. 다른 사람의 아이디어에 퇴짜를 놓거나 수락하기도 한다. 사실 매일 각종 아이디어에 치여 산다고 할 정도다. 자신의 아이디어일 수도, 부하 직원이나 상사, 심지어 미디어에서 본 아이디어일 수도 있다. - “SQL의 그 섹션을 다시 써서 커서 사용을 피할 수 있다면 퍼포먼스가 훨씬 더 좋아질 것이다.” - “모바일 리포팅 앱을 디플로이 할 경우 세일즈 파트에서도 클라이언트들이 이미 주문한 것들을 확인할 수 있을 것이다.” - “헬프 데스크를 우회하려는 유저들을 돕지 않으면 결국 우리가 의도한 지원 프로세스를 따르게 될 것이다.” IT 관련 아이디어를 누가 제기했든, 결국 그 과정과 결과를 감당할 인물은 IT 매니저다. 아이디어를 얼마나 잘 내놓고, 선택하고, 수집하고, 평가하고, 수정하고, 우선순위를 정하고, 테스트하고, 도입하고, 의논하는지에 사실상 매니저로서의 성공이 달려 있다 해도 과언이 아니다. 좋은 아이디어를 선택하면(다시 말해 옳은 의사결정을 내리면) 영웅이 되는 반면, 잘못된 선택을 할 경우 골치 아픈 일도 발생한다. 물론 가만히 앉아 컴퓨터를 두들기며 ‘옳은 선택을 해라’라고 말하는 건 쉽다. 하지만 복잡하고 정신 없는 일터에서 좋은 아이디어를 추려내려면 어떻게 해야 할까? 내 경험상 매니저들은 의사결정을 할 때 3옵션 중 하나를 선택한다(혹은 이들 중에 적합한 것들을 조합하기도 한다). 3 옵션 모두 각각의 장점이 있음은 물론이다. 방법 1: 아이디어의 철저한 분석. 각 아이디어를 실현 비용, 장점, 성공 확률, 문화적 적합성 등 다양한 각도에서 분석하는 방식이다. 아이디어의 기저에 깔려 있는 각종 가정들을 검토하고 기존의 팩트나 과거 경험들과 얼마나 잘 맞아 떨어지는지를 살펴본다. 그 후에야 비로소 그 아이디어가...

리더십 의사결정 관리자 아이디어 평가 직관 방법론

2015.10.14

IT 매니저들은 하루의 상당 부분을 아이디어를 상대하며 보낸다. 초기 아이디어를 가다듬고, 평가한다. 다른 사람의 아이디어에 퇴짜를 놓거나 수락하기도 한다. 사실 매일 각종 아이디어에 치여 산다고 할 정도다. 자신의 아이디어일 수도, 부하 직원이나 상사, 심지어 미디어에서 본 아이디어일 수도 있다. - “SQL의 그 섹션을 다시 써서 커서 사용을 피할 수 있다면 퍼포먼스가 훨씬 더 좋아질 것이다.” - “모바일 리포팅 앱을 디플로이 할 경우 세일즈 파트에서도 클라이언트들이 이미 주문한 것들을 확인할 수 있을 것이다.” - “헬프 데스크를 우회하려는 유저들을 돕지 않으면 결국 우리가 의도한 지원 프로세스를 따르게 될 것이다.” IT 관련 아이디어를 누가 제기했든, 결국 그 과정과 결과를 감당할 인물은 IT 매니저다. 아이디어를 얼마나 잘 내놓고, 선택하고, 수집하고, 평가하고, 수정하고, 우선순위를 정하고, 테스트하고, 도입하고, 의논하는지에 사실상 매니저로서의 성공이 달려 있다 해도 과언이 아니다. 좋은 아이디어를 선택하면(다시 말해 옳은 의사결정을 내리면) 영웅이 되는 반면, 잘못된 선택을 할 경우 골치 아픈 일도 발생한다. 물론 가만히 앉아 컴퓨터를 두들기며 ‘옳은 선택을 해라’라고 말하는 건 쉽다. 하지만 복잡하고 정신 없는 일터에서 좋은 아이디어를 추려내려면 어떻게 해야 할까? 내 경험상 매니저들은 의사결정을 할 때 3옵션 중 하나를 선택한다(혹은 이들 중에 적합한 것들을 조합하기도 한다). 3 옵션 모두 각각의 장점이 있음은 물론이다. 방법 1: 아이디어의 철저한 분석. 각 아이디어를 실현 비용, 장점, 성공 확률, 문화적 적합성 등 다양한 각도에서 분석하는 방식이다. 아이디어의 기저에 깔려 있는 각종 가정들을 검토하고 기존의 팩트나 과거 경험들과 얼마나 잘 맞아 떨어지는지를 살펴본다. 그 후에야 비로소 그 아이디어가...

2015.10.14

회사명:한국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.5.0.5