여기저기 기웃거리기

Tibero4 migration 모험기 (4) 중간정리
Oracle DBA의 Tibero 사용기
 사용기나 감상문 정도로 적으면 될걸 굳이 모험기라는 조금은 부정적인 의미의 단어를 사용한건, Tibero라는 생소한 제품으로의 이전이 제게는 모험에 가깝다고 생각되어서입니다. 아주 주관적인 얘기니까 혹시 티맥스 관계자분들이 보시면... 걍 얘가 겁이 많구나... 이 정도로 생각하시면 됩니다. 현재 Tibero를 아주 잘 사용하고 있습니다. ^^

 그동안 Oracle을 사용하다가 Tibero RDBMS로 이전을 하기로 결정이 내려졌고, 현재 하나의 시스템을 제외하고는 Tibero로 이전을 하였습니다. 처음 Tibero를 접했을때는 너무 자료가 없고, 폐쇄적이라 테스트 해보기 힘들었다는게 문제였고, 실제 서비스에 일부 사용하고 있는 현재는 타업체의 DB, 솔루션과 함께 사용할때 생기는 다양한 문제점의 원인 파악 및 해결이 어렵다는게 가장 큰 문제입니다. 서두에 이미 결론을 내버려서 이 글을 끝까지 읽지 않으실지도 모르지만, 도입 결정 후 시스템 이전 과정과 서비스 과정에서 생긴 일을 하나씩 얘기해보려 합니다.

 * Tibero 도입을 결정하다.
 제가 이전에 블로그에 남겼던 글을 읽으셨다면 어느 정도 감을 잡으셨겠지만, Tibero 도입의 결정적인 이유는 다음과 같습니다.
첫째, Oracle RAC 도입 가격에 비해서 아주 저렴한 가격에 Shared Disk 방식의 Cluster DB를 도입할 수 있다.
둘째, Oracle에서 사용하던 Query, Procedure, Function 등이 수정없이 Tibero에서 사용할 수 있다.
셋째, 필요한 기능 추가 및 시스템 에러에 대한 빠른 대응 가능(국내에 연구 개발을 담당하는 조직이 있어서 가능한거죠.)

 위의 세가지 이유로 도입이 결정되었었습니다.

2010/02/18 - [Database] - DBA의 고민 (1) 고성능, 고가용성 시스템 구축. 안정성과 성능의 두 마리 토끼를 잡아야 하는데... ㅜㅜ
 위의 글을 보시면 왜 RAC같은 Cluster DB 제품을 도입하려하는지에 대한 내용이 들어 있습니다.


 * 테스트와 이전 작업을 진행하다.
도입이 결정되고는 내부 테스트와 이전 작업이 진행되었습니다. 작업 중 Oracle과는 다른점이 여러가지 발견되었습니다.

 [다르긴 하지만 크게 문제는 없어서 넘어간 점들]
첫째, 리스너는 하나 밖에 사용할 수 없다. 정책적으로 서비스나 솔루션별로 서로 다른 리스너를 사용할 수 없습니다.
둘째, log file들이 저장되는 위치를 마음대로 바꿀수 없다. Oracle에 비해서 자유도가 떨어지더군요.

 [문제가 있지만, 아직 패치가 되지 않은 점들]
첫째, Index rebuild를 할때 저장되는 Tablespace를 바꿀 수 없다. 여기에 관해서는 제가 예전에도 글을 올렸던 적이 있습니다. 2010/02/01 - [Database] - Tibero4 migration 모험기 (3) Index rebuild 기능

둘째, 서로 다른 Tibero instance간에 Materialized View를 생성해서 쓰면 성능 문제가 생길 수 있다.
  저희가 Materialized View(이하 M-View)를 사용하면서 격은 문제입니다. M-View에는 Fast라는 옵션을 줄 수 있습니다. 아시겠지만, 이 옵션을 쓰면 원본 Table에서 변경된 Data만 가져와서 M-View에 적용을 해줍니다. 이러면 M-View의 Data 동기화 작업 시간을 줄여주고, CPU 부하도 줄여주고... 뭐 이런저런 장점이 있습니다. 그런데 문제는요  동일한 인스턴스에서 M-View를 생성하면 Fast 옵션을 줄수 있는데, 서로 다른 티베로 인스턴스에서 DB Link를 이용해서 M-View를 생성하면 Fast 옵션을 줄 수 없다는겁니다. 어쩔 수 없이 Force 옵션을 주고 생성을 하게 되는데, 이러면 아카이브 파일이 엄청나게 쌓이더군요. M-View를 Refresh할때 마다 대량의 아카이브 파일이 생겨서 운영하기가 힘들 정도였습니다. 언제 패치가 나올지 확답을 받지 못한 상태입니다. 혹시 M-View를 많이, 그리고 여러 DB Instance에서 운영하시는 분들은 참고하시길 바랍니다.



이건 tbAdmin 사용자들을 위한 팁입니다.

* tbAdmin에서의 PSM 실행
 Oracle에서 DBMS_JOB 패키지를 사용하여 job을 설정하죠. Tibero에서도 동일하게 job을 설정합니다. 문제는 tbAdmin(TmaxData에서 Tibero client로 배포하는 이클립스 기반의 프로그램입니다.)의 sql 편집창에서 해당 PSM(Oracle의 PL/SQL에 해당합니다.)을 실행시켜도 job이 설정되지 않습니다. 그렇다고 에러 메세지도 보이지 않습니다.
 해결 방법은 간단하더군요. SQL 편집창 말고 PSM 편집창이 따로 있습니다. 거기에서 실행시키면 잘 됩니다.

 그동안 여러 세미나에 다녀왔지만, 아마 MS SQL Server만 다루는 세미나는 처음인걸로 기억합니다. 바로 지난 금요일(2010년 6월 11일)에 열린 "SQL Unplugged 괴물 이야기"라는 세미나입니다.
 처음에는 MicroSoft에서 개최하는 행사인줄 알았는데, PASS(SQL Server 전문가 협회(PASS_Professional Association for SQL Server))라는 커뮤니티의 한국 회원분들의 주도하에 진행된 행사더군요. 그동안 Oracle을 주로 사용해왔던터라 PASS라는 이름도 그날 처음 들었습니다. 엑셈이 MS-SQL 분야에서도 컨설팅을 한다는 것도 신선한 소식이었고, 무엇보다 제가 듣고 싶었던 HA, BI, 대용량 DB, Query tunning 등에 대한 다양한 세션이 준비되어있어서 아무 맘에 들었었습니다. 문제는 제가 DBA 세션만 들었다는 겁니다. 동영상 편집이 완료되는대로 업로드한다고 하니까 곧 나머지도 볼 수 있을거라 생각합니다.

1. 엑셈의 MS SQL Server 컨설팅
 사실 Oracle 관련 정보만 평소에 접하다보니 엑셈이라는 이름이 아주 친숙했었습니다. 근데, SQL Server 세미나에서 엑셈이라는 이름을 듣게 될줄은 몰랐었습니다. 엑셈의 컨설턴트가 발표하는 세션을 들었는데, DMV(Dynamic Management View)라고 Oracle의 v$ 혹은 DBA_로 시작하는 각종 Dictionary View에 해당하는 것이 존재하는것도 알게되었고, 이를 튜닝, 트러블슈팅에 이용하는것도 조금은 알게되었습니다. 앞으로 공부할게 너무 많아져서 고민입니다.


2. HA. DB 복제와 MSCS에 대한 얘기
 DBMS에서 HA 구성에 대한 얘기를 하면 흔히 Oracle의 RAC를 떠올리게됩니다. 시장에서 가장 많이 알려진 제품이고, 구축 사례도 많기 때문이죠. 이와 비슷한(사실 비슷하지만 많이 다른것 같습니다. IBM의 P시리즈의 가상화를 이용한다는걸로 알고있습니다.) IBM의 pureScale이라는 DB2 제품이 나왔습니다. 다만, SQL Server에서는 아직 이런식의 Cluster 제품은 나오지 않았습니다. 그래서인지 DB 복제와 MSCS에 대해서 발표자들이 소개했고, 참석자들의 질문은 DB 복제에 집중되었습니다. 복제 관련 질문이 너무 많아서인지 사회자가 복제에 대한 질문을 제한하기도 했었죠. 복제에 대한 질문이 너무 많아서인지 제가 궁금했던 점과 인식하지 못했던 점까지 알게되어서 좋았습니다.
 세미나에서 들은바로는 현재 많이 사용하고 있는 복제는 2008 이후 버전에서는 P2P 복제가 대체하게 된다고합니다. 앞으로 P2P 복제에 대해서 공부를 좀 해야 겠다는 생각을 해봅니다.

 그리고 MSCS(MicroSoft Cluster Service의 약자)에 대해서 얘기하자면, 현재 잡코리아에서 이를 이용해서 Active-Standby 구성의 HA를 운영중이며, 장애 발생시 1분 이내에 처리가 완료된다고 합니다. 3rd party Cluster 제품을 이용하는 업체도 MSCS로 재구축하는 사례가 있다는 얘기를 하던데요. Windows 환경에서의 Cluster 구성은 이제는 MSCS가 제일 안정적인가봅니다.


3. Business Intelligence
 사실 이 부분은 제가 지금 근무하는곳으로 이직 하기전에 했던 DW구축 및 운영 업무와 관련이 있어서 듣고 싶었던 세션입니다. HA와 튜닝 등의 세션에 밀려서 듣지 못했지만, 동영상 편집이 끝나는대로 볼 수 있게 해준다고 하시네요. 기대하고 있어요~ ^^
앞으로 이 부분은 실무에도 적용을 해보고 싶은데, 현재는 정보 부족으로 테스트도 해보지 못했습니다. 예전에 썼던 DataStage만큼만 해주면 참 좋을것 같은데...


 MS SQL Server는 중소형 서비스에 적합한 쉽게 설치해서 쉽게 쓰는, 그래서 세세한 튜닝이나 운영은 필요없는 초보용 DBMS라는 인식이 많았던게 사실입니다. 저 역시 그렇게 생각해왔었구요. 그런데 이번 SQL Unplugged에 참석하고나서 생각이 많이 바뀌었습니다. 충분한 교육과 정확한 자료만 있다면 아주 파워풀하게 사용할 수 있겠다는 생각이 듭니다.
앞으로 SQL Server에 투자하는 시간이 좀더 늘어날것 같습니다.

 저희 회사의 시스템 구축 목표 중 아주 중요하게 생각하는 항목은 "가능한 모든 DB는 저렴하게 Active - standby를 구현하자"입니다. 결국 "저렴하게 안정성 향상과 성능 극대화를 추구한다."라는 말인데, 이 문구를 보시면 많은 분들은 "저렴하게"라는 부분만 빼면 가능한 일이라고 생각하실겁니다. 저도 그렇게 생각하구요. 예산만 풍부하다면...

 제가 생각하는 아주 좋은 회사는 장비(시스템)와 직원에게 비용을 아끼지 않는 회사입니다.(낭비가 아니라 "아끼지 않는다"입니다. 내가 원하는 기능, 성능 및 안정성을 제공하는 장비나 서비스를 구매하고 이에 비용을 지불하는건 낭비가 아니라고 생각합니다. 물론 사원에게도 마찬가지로 적절한 보수와 특근, 야근 수당을 다 챙겨주는...) 물론 이런 회사에 근무하는건 아주 드문 일이라고 생각합니다. 제가 DW 구축 및 Oracle DB 운영 업무(능력있는 사수님이 계셨었죠. 제가 부사수였습니다. ^^;)를 맡았었던 K사의 모 시스템에서도 비용을 절감하고, 보유한 자원을 최대한 활용하려는 노력은 끊이지 않았었죠. 대한민국 사람이라면 다 아는 큰 회사에서도 비용 절감은 중요한 사항이었죠.

 제가 비교적 시스템 자원이 풍부한 곳에서 일을 해왔었던 탓인지 현재 재직중인 회사에 와서 좀 충격을 받았었습니다. 안정성 향상을 위해 Cluster 혹은 Standby 시스템을 구축하는데는 보통 비용이 많이 들기 마련인데, 그 비용에서 타협을 하면 안정성이나 성능도 어느정도 타협을 해야 하는데... 그렇게 생각을 하지 않으니...

 암튼 초고속 인터넷이 보편화되어있는 대한민국의 IT 환경에서 안전한 백업보다도 고객들이 원하는건 중단되지 않는 서비스가 아닐까합니다. 그리고 실시간으로 Data 동기화 등의 작업이 이루어지길 원하죠.
 경영진으로서는 당연히 직원들이 해결해야할 문제이고, 실무진으로서는 돈도 적게 주면서(예산, 연봉 및 수당을 말합니다.) 품질만 최고를 원한다는 불만을 가지게 됩니다. 아~ 힘들다.

 DB Cluster를 구성하려고 여러가지 고민을 해봤습니다.
이번 글에서는 DBMS Cluster에 어떤 것들이 있는지 나열해보고, 제가 근무중인 곳에서 도입한 TAC에 대한 감상을 적어보겠습니다. 다른 DBMS Cluster에 대해서는 다음에 정리해서 올리도록 하겠습니다.

1. Oracle RAC
 말이 필요없죠. 좋습니다. 가격이 너무 비싸다는걸 빼면요. 저렴하게 구축하려면, Linux 기반으로해서 공유 스토리지는 Oracle ASM을 이용하는 방법도 있습니다. Oracle 11g 이후 버전에서는 Raw device를 지원하지 않고 ASM을 기본으로 할지도 모른다고 하니까 성능에는 자신이 있는 모양입니다.

 당연한 얘기지만 관련 서적도 제법 있습니다. RAC 자체에 대해서는 영문판 책이 대부분이며, 한글판으로는 RAC에서의 성능 문제에 대한 엑셈의 책도 있습니다.

ADVANCED OWI INTERNALS AND PERFORMANCE IN ORACLE 10G RAC 카테고리 컴퓨터/IT 지은이 조동욱 (엑셈, 2007년) 상세보기

2. IBM DB2 PureScale
 메인프레임의 기술을 유닉스에서... Cluster 도입을 고려하던 당시에는 자료가 별로 없어서 제외했습니다.
Oracle RAC에 대항마로서 나온 제품 같습니다.(예전에 DB관련 세미나에 갔더니 고객들이 "RAC~ RAC~"한다고 한 숨을 쉬시더군요.) Oracle RAC처럼 모든 노드를 Active로 사용할 수 있다고 합니다. 단점은 아직까지는 AIX에서만 사용 가능하다는 점입니다.


3. MySQL Cluster
 Active-Standby Cluster입니다. Standby DB는 평소에 읽기 전용으로 사용하기를 권장하더군요. 저희쪽에 제안을 들어온 업체의 제안 내용에 따르면, 일반적인 Intel CPU 장비를 제안해놓고는 메모리는 가득 채워서 설치하기를 요구하더군요. 쿼드코어 CPU 두장에 메모리는 128GB이던가... 그것만으로도 가격이 상당히 뛰더군요. 업체측에서는 Active-Active로 궁성을 해도, 거의 실시간으로 모든 노드에 Data 동기화가 이루어져서 Data 정합성이 깨지지 않는다고 하지만... 타 DBMS 업체에서는 이런 구조는 필연적으로 정합성에 문제가 생긴다고 하더군요... 뭐...
 좋은 점은 공유 스토리지를 필요로 하지 않아서 SAN 및 공유 Storage 구축 비용이 절감된다는 장점이 있습니다. 그런데 개별 서버에 대용량의 메모리를 설치해야 한다는 점이 조금 걸립니다.  다양한 관련 서적이 있으며, HA관련 서적이 한글판으로도 출판되어 있습니다.

MYSQL 5.1 REFERENCE GUIDE(레퍼런스 가이드) 카테고리 컴퓨터/IT 지은이 박장규 (혜지원, 2009년) 상세보기

MY SQL 5.1 H A 매뉴얼 카테고리 컴퓨터/IT 지은이 (글로벌, 2009년) 상세보기

4. MS SQL Server Cluster
 Active-Standby Cluster입니다. 일반적으로 얘기하는 HA구성이죠. MS-SQL 라이센스에 Cluster 라이센스를 구매해야하며, 당시엔 이에 대한 사내의 인식과 자료가 좀 부족해서 제외되었었습니다. 또한 MS SQL Server 자체에 대한 책은 많이 출판되어 있으나 HA에 대한 자료는 거의 없습니다.


5. Cubrid Cluster
 NHN에서 Open source로 제공하는 Cubrid를 Cluster로 구성하는 방법입니다. Cubrid야 NHN에서 서비스에 사용중이니 안정성 등은 믿음이 가지만, Cluster는 아직 개선의 여지가 많이 필요한거 같아 보입니다. 큐브리드 부설 연구소에서 2008년도에 출판된 책이 한 권 검색되네요. 음... 최근 버전에 관한 내용은 큐브리드 홈페이지에서 찾으시면 됩니다. 그리고 Naver 개발자 센터의 CUBRID프로젝트와 큐브리드 공부하기 카페에서도 관련 정보를 찾으실 수 있습니다.

데이터베이스 이해와 실습 카테고리 컴퓨터/IT 지은이 큐브리드 부설 연구소 (정익사, 2008년) 상세보기

 앞으로의 발전 가능성에 꾸준히 관심을 갖고 지켜보고 있는 제품입니다.


6. Tibero Active Cluster (TAC)
 TmaxData의 Tibero RDBMS를 Oracle RAC 형태로 구성한 Cluster입니다. 영진 전문 대학이라는 레퍼런스가 존재했고, 견적을 냈을때 Oracle의 10분의 1에 해당하는 가격이라 이걸로 결정되었었습니다.

 혹시 Tibero Active Cluster(이하 TAC)를 도입하려고 검토하시는 업체라면, 아주 신중히 결정하시라고 말씀드리고 싶습니다. TAC는 Tibero라는 DBMS를 Cluster로 구성한거라 Tibero의 약점을 그대로 가지고 있습니다. Oracle과 같은 문법을 제공하기에 기존 개발자가 적응하기 쉽다는 장점이 있지만, Oracle에서 당연히 되던 기능들이 작동을 안 하기도 합니다. 제가 썼던 글을 참조하세요.(2010/02/01 - [Database] - Tibero4 migration 모험기 (3) Index rebuild 기능)

 그리고 기존의 DB 보안, DB 복제, ETL tool 등이 정상 작동을 하지 않는 부분이 많습니다. 관련 업체의 인증을 받았다지만, 관리 툴이 Tibero에서는 완벽하게 사용할 수 없다던지, 중요 기능이 대용량 Data 환경에서는 정상 작동을 하지 않는다는 문제가 있습니다. 관련 솔루션 테스트 중에 몇 십만건 단위의 Data 처리를 시키니까 DB가 뻗어버리더군요. ㅜㅜ

 또 하나의 문제점이라면... Oracle RAC의 경우에 좀 저렴하게 구성하려면 Linux에 Oracle을 올리고, Oracle ASM을 이용하면, Veritas CFS 등의 Cluster filesystem을 구매하지 않아도 Cluster 구성이 가능한데, Tibero에는 자체적으로 제공하는 Cluster filesystem이 없어서 공유 스토리지 구성에 상당한 비용이 소요됩니다. 제 기억엔 TAC 자체 가격과 Veritas CFS 가격이 비슷했던것 같은 기억이...

 또한 시중에 출판된 Tibero 혹은 TAC 관련 서적은 없습니다. TmaxData에서 제공하는 Tibero 관련 메뉴얼이 있으며, 테크넷(technet.tmax.co.kr)에서 PDF 파일로 다운로드 가능합니다. 왠만한 명령은 Oracle과 비슷한 문법을 제공해서인지 메뉴얼만으로도 해결이 가능합니다. 사실 이게 최대의 장점이죠.

 DBA로 살기 위해 여러 세미나와 각종 교육 등을 받아보면, 자주 등장하는 강사(혹은 발표자)의 농담 섞인 얘기들이 있습니다.
"DBA가 할 일이 별로 없는 회사가 시스템이 잘 굴러가는 곳이다."
"가장 효과적이고 확실한 튜닝은 돈을 투자하는 것이다."
"오늘 설명한 작업은 시스템에 사용자가 별로 없는 시간대에 하거나, 외부의 접속을 끊고 진행하는것이 좋습니다."
라는 얘기죠.
 흔히 낮에는 하지 말자라는 작업을 몇가지 생각나는대로 읇어보면...(물론 어떤 시스템이냐, 어떤 장비를 쓰느냐에 따라 달라지긴 합니다.)

1. 대용량 Data file 추가
2. 대용량 Data table의 이전 혹은 여기에 생성되어 있는 Index의 rebuild 작업
3. online full backup
4. 통계 Data 정리
음... 이거 말고도 부하를 줄만한 작업이 꽤 많죠. 음... DW구축 등의 작업이 보통 새벽이나 밤에 시작되죠.
예전에 근무했던 곳에서는 내부 업무용 DW DB라 그런지 9시 쯤부터 배치 작업이 돌아갔었던거 같습니다. 음... 일년 정도 지나니까 생각이 잘 안나네요.

 암튼... 이런 얘기를 하는건...
뭔가 원인이 있었겠지만, 저희 팀의 윗분 한분이 사용자가 많은 시간에 인덱스 리빌드를 몇개 돌리시더군요. 저한테는 DBA가 왜 낮에 시스템에 부하를 주는 작업을 하냐고 타박을 주시던 분인데...
DB 서버에 Wait가 걸리고, 웹 서버 프로세스 수가 급증하는 통에 전화기에는 불이나고...

음... 그대로 놔뒀으면 사용자들이 조금은 느리더라도 서비스를 이용할 수 있었을텐데, 굳이 그런 작업을 해서 서비스가 중단되는 테러를 자행하다니...

전화 폭탄과 SMS에 스트레스가 쌓여서 요렇게 글로 풀어봅니다. ^^;

 요즘 DB가 거의 매일 문제를 일으켜서 성능관련 문서들을 많이 찾아보며 분석중에 있습니다. 그러다보니 wait event에 많은 시간을 투자하고 있죠.

OTN에는 많은 Oracle 관련 문서들이 있는걸 아시죠. 그중에서 이번에 찾은 [Oracle Wait Event 모니터링]이라는 문서가 눈에 띄더군요.

원문보러가기~!
(주)웨어벨리의 책임 컨설턴트인 안진철님이 2003년경에 작성한 문서로 순서는 아래와 같습니다.

 이 글을 읽으면서 맘에 와닿았던 글귀가 있습니다.

다음은 시중에 나와있는 OWI(Oracle Wait Interface) 관련 책들입니다.

오라클 진단 & 튜닝 카테고리 컴퓨터/IT 지은이 RICHMOND SHEE (엑셈, 2005년) 상세보기

OWI Advanced Oracle Wait Interface in 10g 카테고리 컴퓨터/IT 지은이 조동욱 (엑셈, 2006년) 상세보기

PRACTICAL OWL IN ORACLE 10G 카테고리 컴퓨터/IT 지은이 엑셈 (엑셈, 2007년) 상세보기

ADVANCED OWI INTERNALS AND PERFORMANCE IN... 카테고리 컴퓨터/IT 지은이 조동욱 (엑셈, 2007년) 상세보기

이직을 할때 어느 정도 예상은 했었지만, 팀내에서 저의 역활이 DBA로서 DBMS 관리, 튜닝 등의 업무 못지 않게 장비(O/S, 운영, H/W 등등)쪽 일도 많은 자리라는 걸 느끼면서... 장애 처리를 어느정도 하고나니 이젠 장비 대/교체 준비라는걸 하게 되었습니다. 물론 신규 장비가 들어오고 DB Migration을 해야하므로 제가 할 일이 많아지는 거죠. 어쩌면 OS 버전이 더 올라갈 수도 있고, DBMS 버전도 덩달아 올라갈 수도 있으니 이것저것 준비할게 많습니다. 그래도 마음씨 좋은 사수님이 옆 자리에 있어서 대책없이 믿음으로 충만한 회사 생활을 하고 있습니다. ^^

어제까지 했던 작업이 tpmC 계산이었습니다. 사실 수 많은 어려움이 있었죠. 월요일에 마신 술이 깨질 않아서 오후 세시정도까지는 몇번이나 오타때문에 다시 계산을 하는 삽질을 했었죠.

기본적으로 동시 로그인 유저수에 분당 트랜잭션수를 곱하면 tpmC가 나오더군요. 물론 각종 보정치를 적용시켜야 실제로 사용할 수치가 나오긴 하지만요.



이제 보정치를 적용해야 하는데, 보정치가 참 다양합니다. 실제로 서비스를 하려면 여러가지 문제에 부딪치게 되는데 이때를 위한 보정치 없이 tpmC를 계산해서 서버 용량을 결정하면 난감한 문제에 맞닥뜨리게 되겠죠. 구매한지 반년도 안된 서버가 성능 부족에 시달린다던지하는 그런 문제죠. ㅋㅋ



첨부한 파일들은 Google로 검색해서 찾은 tpmC관련 문서들입니다.
혹시 이 문서관련해서 문제가 있으면 알려주세요. 삭제하도록 하겠습니다.
메일 주소는 miho77 _AT_ gmail.com 입니다.