IT담당자를 위한 DB완전정복 세미나 후기

IT담당자를 위한 DB완전정복 세미나 후기
2019년 1월18일(금) 오후1시30분 부터 6시까지 강남역 1번출구 마이워크스페이스 세미나룸에서 2019년 첫 번째 SharedIT 세미나가 진행 되었습니다. 이번 세미나는 SharedIT 회원이신 '양성환'님의 재능기부로 진행 되었는데요. 평소 SharedIT의 많은 게시게시물에 양질의 답변을 달아주셨던 '양성환'님께서 국내의 몇 안되는 Microsoft SQL Server 튜닝전문가로 활동 하시면서 경험한 튜닝 노하우를 바탕으로 교육을 진행 해 주셨습니다. 외부로 많이 알려지면 곤란한 내용들이 더러 있어 전체 내용을 상세히 다루지는 못하지만 어떤 내용들이 다뤄졌는지에 대한 맛보기 형태로 정리 해 보겠습니다.


기대 이상으로 회원 분들의 관심이 많았던 세미나라 자리가 모자르면 어쩌지 하는 걱정도 있었지만 다행히 24석 중 21석을 채워 주셔서 자리가 모자르지는 않았네요. 그래도 너무 많은 분들이 마지막날까지 오신다고 답변 주셔서 불안불안 했습니다. 더군다나 전시간에 세미나룸을 사용한 분들이 한달 동안 예약해 뒀다고 하셔서 잠깐 멘붕상태에 빠질뻔 했으나 다행히 저희가 실수한 것이 아니어서 이상 없이 세미나룸을 이용할 수 있었습니다.



1시30분 경 찍은 사진입니다. 군데 군데 자리가 비어있긴 한데, 이때 이미 19명이나 오셨었네요. 2시정도 되자 두 분이 더 오셔서 총 21명이 참석해 주셨네요. 




오늘의 아젠다 입니다. 1시간 교육 10분 휴식으로 진행되었는데요. 내용이 좋았던 탓인지 끝날때까지 모두 자리를 지켜 주셨습니다. 





교육을 위해 준비하신 장표는 위와 같이 어려운 내용을 한가득 담고 있었습니다. 그런데 정작 강사님께서는 '이런거 다 알 필요 없고요'하시면서 중요한 부분은 화이트보드에 판서하시면서 설명 해 주셨네요. (세미나 당일 새벽까지 자료 준비하신것으로 알고 있는데, 장표의 내용 설명을 많이 안해주셔서 당황.....) 아무튼, DB란 '파일에 기록을 쌓고 원하는 자료를 처리하기 위한 파일 단위에서 시작'되었다고 하셨습니다. 그리고 강조하신 것이 바로 색인(INDEX)입니다. DB는 INDEX로 시작해서 INDEX로 끝난다고도 강조 하셨는데요. 많은 애플리케이션 개발자들의 작업에 의해 이 INDEX를 쓰지 못하게 될 수도 있고, 아주 잘 활용할 수도 있다고 합니다.



DB의 경우 위와 같이 크게 RDBMS와 NOSQL 두 종류로 나뉩니다. 역시나 그냥 '알 필요 없습니다'라고 하시며 넘어가시려고 해서 당황..... 전 이때 NOSQL이 Not Only SQL 즉, SQL이 아니라는 것이 아니라 SQL 외에 다른 것들도 지원하는 DBMS라는 것이죠. No SQL인줄 알았는데... 또 당황했네요. ㅋ 그리고 가장 유명한 Oracle DB의 경우 DBA(Database Administrator, DB관리자)가 반드시 필요한 DB지만 Microsoft SQL은 DBA가 필요없는 DB, DBA가 없어도 운영하는 데에 큰 무리가 없는 잘 만들어진 DB라는 말씀을 하셨습니다. 그럼 이쯤에서 DB시장 점유율 한번 보고 가실게요.




한국데이터진흥원이 발간한 2018데이터산업백서를 살펴보면 위와 같이 DBMS의 시장이 2017년(추정) 기준 6,192억원이라고 합니다. 어떤 기사에서는 6,500억원 정도 된다고도 나와 있던데 대략 시장 규모는 이정도라고 보시면 될 것 같네요. 소폭 상승하고 있는데 다른 영역에 비해서 성장률이 둔화 된 것이 눈에 띕니다. 하지만 전체 영역 중 가장 높은 비중을 차지하고 있는 것이 DBMS분야입니다. 즉, Oracle이나 Micorosft SQL같은 DBMS솔루션 라이센스 + 유지보수(기술지원) 비용이 데이터솔루션 영역에서 가장 많은 비용을 지불하고 있는 영역이라고 보시면 되겠습니다.



한국IDC의 자료에 따르면 2016년 국내 DBMS 점유율은 위와 같습니다. Oracle이 여전히 가장 높은 점유율을 차지하고 있지만 매년 소폭 하락하고 있는데요. 아무래도 악명높은 유지보수요율(18%라고 하죠 아마?)때문에 매년 이탈하는 고객들이 늘어나는 것 같습니다. 오늘 교육의 주인공인 Microsoft의 SQL은 15.5%인데 국내에서 많이 사용하는 ERP솔루션들이 .NET기반으로 개발되어 Microsoft SQL서버를 사용하고 있는 것도 SQL서버 보급에 일조하지 않았나 하는 생각이 듭니다. IBM DB2는 점점 점유율이 빠지고 있고요. 신규고객이 거의 늘지 않는다는 이야기도 들은 것 같습니다.

SAP는 HANA로 점점 점유율을 높여가고 있긴 한데 무지막지하게 비싸죠. 비싼만큼 성능 역시 엄청 나다고 합니다. SAP HAHA의 HANA가 한국이름인건 아시나요? 개발자가 한국분이신데 딸 이름으로 지으셨다고 합니다. 이렇게 1위~4위까지 외산 DBMS가 91.6%를 차지하고 있고 나머지를 국산 DBMS가 차지하고 있는데요. 최근 점유율 역시 외산 DB가 90% 넘게 차지하고 있고 나머지를 국산 DBMS가 경쟁하고 있는 형국이라고 보시면 되겠습니다. 



위 순위는 DB엔진 인기도를 보여주는 db-engines.com의 결과입니다. 역시나 Oracle이 1등이네요. 전 세계에서 가장 많이 사용되고 있는 DBMS라고 보시면 되겠네요. 글로벌 점유율은 40%가 넘는다고 합니다. 2위 MySQL은 Linux 진영에서 많이 사용하고 있죠. 제 전 회사의 시스템도 MySQL 기반이었네요. Microsoft SQL은 3위이고 4위와 5위가 오픈소스DBMS인데 인기가 점점 오르고 있습니다. PostgreSQL은 EnterpriseDB에서 기술지원을 바탕으로 한 국내 비즈니스를 하고 있고 MongoDB는 2018년 7월 한국지사가 설립되어 코오롱베니트에서 비즈니스를 하고 있습니다. 

그 외에도 다양한 웹서비스에 활용되고 있는(특히 스타트업들의 서비스) 검색엔진인 Elasticsearch, 빅데이터 분석에 최적화된 Splunk, Hive, Hbase도 있고 aws의 DynamoDB도 보입니다. 더 자세한 내용이 궁금하신 분들은 위 db-engines.com에서 살펴보시기 바랍니다. 그럼 다시 교육자료로 돌아가볼게요.



Microsoft SQL Server의 역사 입니다. 빨간색으로 표시 된 것들이 뭔가 큰 변화가 있거나 SQL Server 역사에서 중요한 때라고 보시면 되겠습니다. 저는 SQL이 Sybase사에서 만들었고 1994년 4.21버전 때 Microsoft가 소스코드를 인수했다는 것을 처음 알았네요. 1998년 7.0 때 국내 벤처 열풍으로 인해 SQL의 점유율이 크게 올라갔고 9.0인 SQL 2005부터 지금과 유사한 모습을 갖추게 되었다고 합니다. 아마 2008R2가 가장 많이 사용되고 있지 않을까 하는 생각도 드네요. 2016버전 부터는 그냥 설치만 잘 하면 별다른 튜닝 없이 아주 좋은 성능을 보여줄 정도로 많이 좋아졌다고 합니다. 그리고 당연히 최신 버전을 설치할 수록 성능 역시 더 좋다고 하고요. SQL Developer 버전의 경우 2014 버전부터 공짜로 제공되며 Enterprise License와 기능이 동일하나 내부 테스트용으로만 활용해야 하는 제약사항이 있습니다.

하지만 이 SQL Server들은 Windows Server에 설치해서 사용하는 On-Premise 버전입니다. 클라우드로 구동되는 Azure SQL은 가장 최신 버전인 SQL 2019보다 더 뛰어나다네요. DBA가 해야 할 일들을 Azure가 머신러닝을 바탕으로 알아서 처리 해 준다고 합니다. 정말 클라우드의 위력은 므시므시 하네요. 



SQL Server 엔진은 Relation Engine과 Storage Engine으로 나뉩니다.(SQL도 자체 OS를 가지고 있다고 하셔서 깜놀했네요. 당연히 Windows Server라는 OS위에서 바로 구동되는 것인 줄 알았거든요.) 위와 같이 나눠져있는 이유는 처리하는 곳 따로, 저장하는 곳 따로라는 것입니다. OS라는 것은 메모리를 제어하는 역할을 하고 있습니다.

DB에서 데이터를 불러와! 라고 명령을 내리는 것이 바로 쿼리죠. SQL은 이 쿼리를 메모리에 저장하는데 이것을 Buffer Pool이라고 부릅니다. 그런데 이 쿼리를 날리면 SQL 자체적으로 컴파일을 한 뒤 메모리에 올립니다. 그 뒤 실행계획을 만들고 스토리지에 저장하여 실행을 하는 것입니다. 



위와 같이 하나의 쿼리가 실행됨에 있어서 복잡한 과정을 거치게 됩니다. 즉, DB성능의 관건은 저 쿼리를 빨리빨리 처리해야 하는 것인데, 이를 위해 쿼리를 메모리에 올려두고 이미 컴파일 된 쿼리를 불러와서 바로 실행시키면 되는 것이죠. 그런데 SQL은 대소문자를 구분할 수 있습니다. 즉 SELECT라는 쿼리와 Select라는 쿼리를 실행했을 때 결과는 같지만 SQL의 Optimizer는 이 두 쿼리를 다른 쿼리로 인식하여 메모리에 저장합니다. 이 때문에 용량을 두배로 잡아먹게 되는거죠. 그래서 이런 현상을 방지하기 위해 Procedure(프로시저)를 사용해야 합니다. 이미 Procedure에 쿼리가 미리 입력되어 있어서 쿼리의 대소문자가 달라질 수가 없는거죠. 그 만큼 다른 쿼리로 인식해서 컴파일 할 일들이 줄어들기 때문에 빠른 속도로 처리할 수 있는 것입니다. DB성능을 높이려면 직접 쿼리를 날리지 말고 Procedure를 사용해라! 오늘의 첫 번째 꿀팁이었습니다.



SQL Server의 버전 별 특징입니다. 2012부터 이중화(Always-On), In-Memory를 지원하기 시작 했습니다. 2014부터는 BPE(Buffer Pool Extend, 버퍼풀확장)을 지원하여 SSD디스크를 활용해 성능을 높여줍니다. 2016부터는 성능상으로 Standard와 Enterprise의 차이가 없어질 만큼 성능이 좋아졌고 2017부터 Linux를 지원하기 시작 했습니다. 그리고 SQL이 스스로 튜닝을 하기 시작했습니다.(Azure는 이 자가튜닝 기능이 ML덕분에 사람보다 더 뛰어나다고 하네요... ㄷㄷㄷ)



SQL은 호환성 문제로 실제 구매하고 설치한 DB보다 낮은 버전의 Engine을 사용하고 있습니다. 위와 같이 가장 많이 사용하고 있는 SQL Server 2008R2버전이 설치되어 있지만 실행되고 있는 Engine은 SQL2000 입니다. 이 때문에 Optimizer가 모든 쿼리를 SQL 2000 Engine으로 해석하기 때문에 성능이 떨어집니다. 즉, 구매한 SQL보다 낮은 성능으로 사용하고 있다는 이야기가 됩니다. 

하지만 무턱대고 호환성 수준을 가지고 있는 최신 버전으로 변경하면 안됩니다. 소스코드(쿼리) 때문인데요. SQL 2000, 즉 80버전의 경우 연결된 애플리케이션의 소스코드를 변경하지 않는 한 마이그레이션을 하지 않는 것이 좋습니다. 개발자의 지원을 받아 소스코드 변경이 가능하다면 '양성환'님 같은 전문가에게 의뢰하여 마이그레이션을 진행하는 것이 안전합니다.(실제로 이 문제 때문에 연락 많이 받으셨다고 하네요. 무턱대고 호환성 수준 변경했다가 장애나는 경우가 발생한거죠.)

만약 SQL 2000(80)버전을 사용하고 있는 것이 아니라면 저 호환성 수준을 최신 버전으로 변경하여 성능 향상 효과를 누릴 수 있습니다. 언제든지 내렸다 올렸다 실시간으로 변경할 수 있습니다. 80은 건들면 안됩니다! 아, SQL 2014 RTM버전(120)도 Service Pack이 설치되어 있지 않다면 문제가 생길 수 있으니 건드리지 말라고 하시네요. 오늘의 두번째 꿀팁이었습니다! 애플리케이션이 잘 만들어져있다는 전제 하에 이 호환성 수준 변경을 통해 성능 향상을 꾀할 수 있습니다.



2012 이전에는 메모리 문제로 DB장애가 발생하는 경우가 많았으나(특히 연결된 애플리케이션 서버에서 XML파싱 할 경우) 2012 이후에는 메모리 관리 아키텍쳐가 변경되면서 메모리 관리기능이 대폭 강화되어 메모리 문제로 인핸 DB장애가 현저하게 줄어들었다고 합니다. Buffer Pool에 저장할 수 있는 공간이 늘어났기 때문입니다.



WSFC는 Windows Server Failover Clustering의 약자로 간단히 말해 서버에 장애가 발생했을 때 조치를 취해주는 기능입니다. 이것은 SQL Server에 있는 기능이 아니고 Windows Server에 있는 기능으로 SQL Server가 Windows Server 위에서 돌아가기 때문에 WSFC로 SQL 장애에 대비할 수 있습니다.

여기서 장애대응을 위한 기술은 크게 HA와 DR이 있는데요. HA는 High Availability 즉 고가용성으로 서버의 자원을 최대한 많이 활용할 수 있게 해 주기 위한 기능으로 Always-On과 유사합니다. 즉 서비스 관점에서 장애 발생 시 작동하는 것입니다. 서비스가 죽지 않기 위해 HA를 활용한다고 보시면 됩니다. DR은 Disaster Recovery의 약자로 재해복구 입니다. 즉, DR은 장애가 발생했을 때 서비스는 죽을 수 있으나 그 데이터가 유실되지 않게끔 해 주는 기능입니다. HA는 서비스야 죽지마! DR은 데이터야 사라지지마! 정도로 요약할 수 있으려나요.(이 부분을 설명 하시는 데에 20분 가까이 할애 하시면서 열심히 화이트보드에 판서 하셨는데요. HA, DR 개념 잡는데에 아주 유용한 시간이었습니다.)



System DB의 경우 master와 msdb는 월 1회 정보 백업을 해 주시는 것이 좋습니다. 저 master에 장애가 발생하는 경우가 가끔 발생 하는데요. 주로 3rd party 이중화 솔루션에서 문제가 발생해서 master DB에 장애가 발생하는 경우가 있다고 하니 꼭 백업을 해 주시는 것이 좋겠습니다. tempdb는 성능에 가장 많은 영향을 끼치기 때문에 별도의 스토리지에서 가장 빠른 디스크를 활용하시는 것을 권장합니다.



또 하나 중요한 부분이 파일 증가단위 입니다. 2014 이전 버전에서는 자동 증가 단위가 10%로 설정 됩니다. DB크기가 1GB라면 100MB지만 1TB라면 100GB 입니다. 이 10%만큼의 용량에 문제가 발생하면 이 용량 만큼 초기화 작업을 해야 합니다. 그 동안 DB는 멈추게 되는거죠. 용량이 클 수록 작업 시간은 오래 걸릴 수 밖에 없습니다. 그래서 2014 이후 버전에서는 저 파일 자동 증가 단위를 64MB 단위 혹은 더 크게 설정할 수 있습니다. DB 용량이 640MB보다 작지 않다면 64MB는 매우 작은 용량이기 때문에 문제가 생기더라도 빨리 고칠 수 있습니다. 2014 이후 버전에서는 저 자동 증가 단위를 변경하는 것 만으로도 DB운영의 안정성을 대폭 향상시킬 수 있습니다. 오늘의 세 번째 꿀팁! 이었습니다.




SQL 2016 이상 버전에서는 볼륨 유지 관리라는 것이 매우 중요합니다. SQL Server 설치 시 많은 기능들을 설치되어 메모리에 올라갑니다. 즉, 쓰지도 않는 기능들이 설치되어 메모리를 잡아먹으니 느려질 수 밖에 없는거죠. SQL 서버 구성 관리자 -> 시작계정으로 가시면 볼 수 있는데요. 불필요한 기능들을 사용안함으로 바꿔서 메모리를 확보하여 좀 더 나은 성능을 기대할 수 있습니다. aws같은 클라우드 서비스 위에 올라가 있는 SQL들은 모든 기능이 다 설치된다고 하네요. 그만큼 메모리 낭비가 심하다고 할 수 있겠습니다. 오늘의 네 번째 꿀팁! 되겠습니다.




이후 진행된 교육에서 장표 마다 DB튜닝을 위한 꿀팁들이 쏟아졌습니다. 더 공개하면 '양성환'님 일에 지장이 생길 수도 있기 때문에 이정도로 마무리 하겠습니다. 온라인으로 배포하기 애매한 내용들이 많아 자료 역시 참석하신 분들께만 배포해 드릴 예정입니다.




이번 교육을 통해 DB성능관리의 실질적인 팁을 대량 방출 해 주신 '양성환'님께 다시 한번 감사의 말씀을 드립니다. 더불어 바쁘신 시간 어렵게 쪼개어 이번 세미나에 참석해 주신 회원 분들께도 감사의 말씀을 드립니다. 참석자 분들을 대상으로 설문을 돌려보니 위와 같이 서버 튜닝에 대한 만족도와 인덱스 활용도에 대한 만족도가 높았습니다. 실질적인 튜닝팁 내용이기 때문에 만족도가 높지 않았나 라는 생각이 듭니다.




오늘 교육 이후 추가 교육을 원하시는 응답률이 85%였는데요. 위와 같이 좀 더 자세한 세부적인 내용과 모니터링, 실습(데모시연?)에 대한 요청 사항이 많았습니다. 위 내용들에 대해서는 어떻게 교육을 진행할 지 '양성환'님과 논의 후 조만간 공지 해 드릴 수 있도록 하겠습니다. 아, 오프라인 세미나에 참석하지 못하신 분들을 위한 온라인 웨비나도 계획하고 있습니다. 2019년 첫번째 쉐어드아이티LIVE는 '양성환'님과 함께 하는 방송이지 않을까 싶습니다.



더불어 다른 주제에 대한 교육을 여쭤보니 DB관리 솔루션, 서버 모니터링이 높은 비중을 차지했고 네트워크에 대한 요청도 꽤 있었습니다. 오늘 참석하신 분들이 DB에 관심이 많으신 분들이라 DB쪽 요청사항이 많았을 것으로 예상되기에 조만간 자유게시판을 통해 다시 한번 회원분들의 의견을 듣고 이후 교육 세미나를 준비 해 보겠습니다.

전체 내용을 정리해서 알려드리지 못한 점 양해 부탁 드리고, 내용이 궁금하신 분들은 꼭 오프라인 교육에 참여 해 주세요. 회원 분들의 열화와 같은 성화가 있어야 '양성환'님을 또 모실 수 있답니다. 또한 DB튜닝 및 활용에 대한 기업 맞춤형 강의도 가능하니 혹시 필요하신 분이 계시면 댓글 혹은 쪽지로 요청 해 주세요.

그럼 이것으로 2019년 첫 번째 SharedIT 세미나, IT담당자를 위한 DB완전정복 세미나 후기를 마칩니다. 끝!



 

19개의 댓글이 있습니다.

9달 전

지방이라서 못 가서 아쉽습니다..

Reply

9달 전

아쉽네요 ㅜ.ㅣㅣ

Reply

댓글 남기기

댓글을 남기기 위해서는 로그인이 필요합니다.

로그인 회원가입

1st 5stars

9달 전

잘 읽었습니다~
몰랐던 내용들도 많이 알게 되었네요.
그런데... 살짝 오타가 하나 보이네요~ ㅎㅎㅎ
고가용성 : High Availity -> High Avaliability
그리고...
HA를 서비스 유지, DR을 데이터 유지로 비교 요약해 주셨는데...
제가 생각하는 HA는 서버의 연속성, DR은 업무의 연속성이 아닐까 생각하네요.
제 의견이 맞는 것이라 주장하는 건 아니고~
제가 생각하는 관점과 차이가 있는 것 같아 참고가 될 수도 있을 것 같아 의견 남겨 봅니다~ ^^

Reply

9달 전

HA는 서비스의 입장에 연속성
DR은 데이터의 입장 연속성입니다.

Reply

1st 5stars

9달 전

HA가 서비스의 연속성이라 하셨는데...
그렇다면, 서버 2대로 HA를 구성했는데 네트워크가 죽어버렸다면...
서비스가 계속 진행될 수 있을까요..?
데이터 입장의 연속성이란 어떤 의미를 말씀하는지 잘 이해가 안되는데요~
HA도 미러링 방식으로 구성한다면 데이터를 계속 유지하는 것인데...
이런 의미에서라면 HA 또한 데이타의 연속성을 유지하는 것이 아닐까요?
데이타 연속성이 유지되지 못하는데 서비스가 연속성을 유지할수 있을 까요?
HA를 구현하려면 데이터 연속성은 기본적으로 갖춰져야할 점이라 생각되는데요..?
HA보다 DR 구현이 비용도 많이들고 더 어려운 것인데...
데이터 연숙성보다는 서비스 연속성이 더 어려운 게 아닐까요..?
데이터는 디스크 레이드1로도 가능하고 백업이나 아카이브 로그로드 가능할 것 같은데...
이해가 안 되는 부분들이 많아 보이네요~

Reply

9달 전 | 쉐어드아이티 | 031-212-1710

오타 제보 감사합니다 수정 했습니다!
다음엔 좀 더 꼼꼼히 보도록 할게요.

Reply

9달 전

네트워크문제 때문에 망도 이중화하고,서버들도 랜카드가 많은거지요..
일반적으로,미러는 데이터는 넘어오지만 서비스전환을 하지않습니다.
HA는 공유형 (RAC도 성향은 다르지만 S-S방식, MS는 S-N 방식)의 서비스전환하는 방식을 사용하구요.

Reply

댓글 남기기

댓글을 남기기 위해서는 로그인이 필요합니다.

로그인 회원가입

9달 전

그 짧은 시간에 많은 내용을 하셨고 정리도 기가막히게 하셨네요.
설문 응답 하신 내용만 봐도 정말 알찬 시간이었다는 느낌이 팍팍 오는군요.

Reply

댓글 남기기

댓글을 남기기 위해서는 로그인이 필요합니다.

로그인 회원가입

9달 전

히스토리쪽 내용중 SQL SERVER는 윈도우 서버 온프레미스라고 되어 있는데, 2017부터 리눅스에서 동작되지 않나요???

Reply

9달 전 | 쉐어드아이티 | 031-212-1710

온프레미스(On-Premise)라는 것은 서버에 직접 설치되어 동작하는 구축형, 설치형 제품을 말합니다. SQL Server는 기본적으로 Windows Server에 설치되어 동작하는 On-Premise형 제품이라는 의미입니다. 말씀하신 것 처럼 SQL 2017부터 Linux를 지원하기 시작했고, Windows Server OS가 아닌 Linux OS에서도(Cent OS, SUSE, Ubuntu, RHEL 등) On-Premise 형태로 동작이 가능하다는 의미입니다. 기존에 운영중인 IT인프라가 Linux 계열이라면 SQL 2017을 설치해서 운영할 수 있다는 거죠.

On-Premise와 반대되는 용어가 Off-Premise인데요. Cloud환경을 뜻합니다. Microsoft Cloud인 Azure에서 동작하는 SQL이 Azure SQL이고요. 이 Azure SQL은 Azure Cloud에서 OS가 Windows Server이건 Linux이건 관계없이 구동됩니다.

Reply

댓글 남기기

댓글을 남기기 위해서는 로그인이 필요합니다.

로그인 회원가입

9달 전

내용 너무 좋네요
업무 미루고라도 갔어야 했는디 ㅠㅠㅠㅠ

Reply

9달 전

오시지그랬어요 ㅜ

Reply

댓글 남기기

댓글을 남기기 위해서는 로그인이 필요합니다.

로그인 회원가입

9달 전

SQL Developer 2014 부터 무료입니다 :)

Reply

9달 전 | 쉐어드아이티 | 031-212-1710

넵, 수정 했습니다.

Reply

댓글 남기기

댓글을 남기기 위해서는 로그인이 필요합니다.

로그인 회원가입

9달 전

역시 정리 잘하시네요 :)

Reply

댓글 남기기

댓글을 남기기 위해서는 로그인이 필요합니다.

로그인 회원가입

9달 전

꿀팁 정리 잘 보았습니다... 감사합니다.

Reply

9달 전

오셨으면 조금 더 꿀팁이 있었는데요 ^_^

Reply

댓글 남기기

댓글을 남기기 위해서는 로그인이 필요합니다.

로그인 회원가입

9달 전

좋은 시간 마련해주셔서 감사합니다.

Reply

9달 전

와주셔서 감사합니다.

Reply

댓글 남기기

댓글을 남기기 위해서는 로그인이 필요합니다.

로그인 회원가입

댓글 남기기

댓글을 남기기 위해서는 로그인이 필요합니다.

로그인 회원가입