Background Image
나머지...
2018.12.28 10:24

DBMS? 힐끗 다른 쪽을 바라봤다

조회 수 990 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부

Databases-comparisons-on-DBEngine.jpg


 시스템 소프트웨어 개발자로 딱 60살까지만 이런저런 시스템, 특히 대용량 데이터를 다루는 시스템을 직접 설계하고 만들어보고 싶은 마음은 지금도 여전하다.

그리고 그러한 미련에 들어온 DBMS 개발바닥이다. 원래 우직하니 한 우물만 파는 스타일은 아닌데.. 어찌어찌 하다보니 10년째 데이터 처리 엔진쪽으로만 일하고 있는 자신을 바라보며 기특하단 생각도 든다. 하지만 최신 유행하는 다른 분야로 발빠르게 움직이지 못한 것이 못내 아쉬울 때도 종종 있다. 


이런 내 마음에는 아랑곳 없이 데이터환경이 휙휙 바뀌면서 하루가 멀다하고 새로운 모양의 시스템, DB들이 마구 쏟아져 나온다. 이런 추세속에서 여전한? 것들을 하고 있는 내 자신을 바라보고 있자면 old school에서 벗어나지 못하고 있는 듯 느껴져 왠지 마음이 급해진다. 이 글을 쓰고 있는 지금도 어디에선가는 새로운 DB(용어따지기 좋아하는 사람들을 위해 여기서 'DB'는 데이터베이스 자체가 아니라 DBMS혹은 DMS를 의미한다는 것을 밝힌다)가 글로벌 DB시장에 런칭하는 소리가 들리는 듯 하니 말이다.


그러나 이쪽 분야에서 일을 하면 할수록 데이터를 다루는 일에 신구라는 것이 없다는 생각이다. 다만 어떤 정보들을 관리할 것인가가 시스템의 선택에 중요한 역할을 하는 시대라는 것..

이젠 RDBMS(Relational Database Management System)를 두고 흔히 '전통적인 DBMS'라는 말을 쓰는 것을 자주 듣는다. 그 전통적인 DBMS의 엔진개발자로 오래 일해왔지만 보면 볼수록 공부할 부분이 많아진다는 생각엔 변함이 없다. 그와 더불어 이젠 요즘 유행하는 블록체인이나 인공지능쪽을 공부해볼까 하는 생각도 간혹 할때가 있지만 아직은 데이터를 처리하는 시스템 소프트웨어 개발자로 일하는 것이 더 즐겁다. 물론 블록체인이나 인공지능쪽이 데이터와 무관해서는 아니다. 오히려 그것들은 데이터의 처리방식보다는 데이터의 내용과 더 직접적인 관계가 있는 영역이라고 생각한다. 


전통적인 RDBMS에서 데이터는 관계성을 가지며 릴레이션 혹은 테이블이라는 스키마들로 모델링 된다. 모든 데이터는 도메인을 갖고 있으며 도메인에 추가된 제약조건들을 만족하는 값으로만 그 identity를 갖는다. 

E. F. Codd 박사가 'A Relational Model of Data for Large Shared Data Banks'를 통해 대용량(그 당시의) 데이터를 어떻게 다룰 것인지 릴레이션과 튜플, 그리고 정규화에 대해 이야기했던 시점으로부터 약 50년의 세월이 흘렀다. 그리고 대용량 데이터의 기준이 달라졌다. 아니 그 후로 지금까지 죽 계속 달라져왔다고 해야 맞을 것이다. 


비즈니스 쪽에서 '빅데이터'를 거론하며 마치 '빅데이터 시스템'이라는 것이 존재하는 것 마냥 사람들이 '빅데이터!''빅데이터!'를  외칠 때에도 시스템 소프트웨어 개발자들은 기존과 동일한 기술기반으로 빅데이터라는 놈을 해결했다. 그러나 아직까지도 빅데이터가 하둡을 의미하는 것으로 생각하는 사람이 존재하듯 특정 시스템을 모든 빅데이터문제를 해결해줄 답안으로 생각하는 사람도 분명 있을거라 생각한다. 


그러나 수많은 데이터 처리 기술들이 존재하는 이유는, 무엇을 정보로 볼 것이며 데이터를 어떻게 바라볼 것인가이다. 다시말해 정보를 어떻게 관리할 것인가가 시스템을 선택하고 설계하는데 있어 최우선적으로 고려해야 할 사항이다. 


RDBMS는 릴레이션이라는 관계성을 데이터에 부여함으로써 정보를 관리하는 한 가지 효과적인 방법을 제시했을 뿐이고 지금까지도 수많은 정보들을 관리하는데 유용하게 쓰이고 있을 따름이다. 


몇달 전 회사 근처에서 그래프 데이터베이스(이하 GDBMS) 관련 밋업이 있어 참석했던 적이 있다. 
그 회사에서 GDBMS를 개발하고 있는 개발자의 과반수가 예전, 같은 연구실 혹은 같은 회사 동료로 함께 일했던 경험이 있다보니 그네들이 만들고 있다는 것이 도대체 무언지 더 궁금한 것도 있었지만, 예전부터 GDBMS에 조금은 관심이 있던 차에 잘됐다 싶었다.


GDBMS는 DBMS시장에서 아직까지도 전통적인 강자인 RDBMS에 비하면 아직 갈 길이 멀지만 시장 성장세가 아주 빠른 제품에 속한다. 

그도 그럴것이 GDBMS는 SNS로 대변되는 '실시간으로 쏟아지는 대량의 비정형 데이터' 를 처리하기에 전통적인 RDBMS보다 우월한 면도 없지 않기 때문에, 최근 SNS를 통해 늘어나는 데이터의 처리가 곧 비즈니스가 되는 현실에선 RDBMS보다 나아보일 수도 있다.


그럼 GDBMS는 RDBMS랑 뭐가 어떻게 다른 것일까?

Graph라는 단어가 의미하듯 GDBMS는 그래프를 이용한? DBMS임에는 분명하다. '그래프'라는 용어를 수학적으로 이해하지 못하는 경우, 혹은 DBMS에 관해 전혀 지식이 없거나 데이터 관리 시스템에 대해 잘 알지 못하는 사람들은 그래프와 그래픽을 혼동하는 경우도 꽤 많다. 그래서 밋업에서 "그래픽데이터베이스라고 하는데 도대체 그래픽으로 뭘 보여준다는 건가요?" 라는 질문을 하는 경우도 봤다. 

그래프는 간단히 말하면 점(vertex)과 선(edge)으로 표현된다. 여기서 점은 흔히 객체로 모델링 되고 선은 관계 내지는 행동(상태의 변경)을 표현하기 위한 수단이 된다. 

GDBMS는 쉽게 말하자면 사용자에게 이러한 그래프의 개념으로 데이터를 모델링할 수 있도록 해주는 DBMS이다. 


앞서 데이터를 처리하는데 있어 중요한 것은 무엇을 정보로 볼 것인가와 데이터를 어떻게 바라볼 것인가라고 썼다. 

정보는 데이터 그 자체일 수도 있고 관련있는 데이터들의 집합 혹은 데이터의 위치, 데이터가 존재하는 이유, 데이터가 생성된 이력 등 무수히 많은 형태가 존재한다. 그동안 사람들, 그리고 수많은 조직들은 정말 제한적인 데이터모델 안에서 아주 많은 일들을 처리하며 살아왔다. 

하지만 90년대 초반부터 꿈틀대더니 이젠 이것 없이는 못살게 된 인터넷의 발달부터 인터넷기술을 밑에 깔고 등장한 많은 문화들, 그 중에 텍스트, 이미지, 사운드를 안가리고 매초마다 엄청난 정보데이터를 양산하는 SNS라는 문화적 기재로 인해 처리해야하는 정보의 성격에 아주 큰 변화가 일어났다. 불과 20년 남짓만에 정보의 구성요소가 되는 데이터를 바라보는 뷰가 하나 더 늘어야 하는 시대가 된 것이다. 데이터를 바라보는 뷰가 바로 데이터 모델이다. RDBMS는 릴레이션이라는 뷰를 제공함으로써 데이터를 모델링하기 쉽도록 해준 것 뿐이다. 


RDBMS가 주류시스템 소프트웨어가 된 당시에는 월스트리트로 대변되는 금융, 보험업무로부터 발생하는 데이터가 여러 비즈니스 영역들 가운데서도 가장 많았다. 또한 이 데이터들은 한 번 잘못 기입되거나 누락되면 엄청난 책임을 져야하는 경우가 많았기 때문에 이들에 대한 보장을 안정적으로 해줄 수 있는 시스템이 필요했다. 말로 풀어썼지만 간단히 말하자면 ACID속성을 갖는 트랜잭션 정보의 처리가 무엇보다 중요했다는 것이다. 그러한 데이터 처리환경에서 마치 자연선택설에 의한 결과인듯 DBMS는 트랜잭션처리에 특화된 성능과 안정적 우월성을 바탕으로 대부분의 데이터 처리 시스템의 기반으로 자리매김했다. 


수십년의 세월동안 데이터의 속성이 바뀌어도 데이터의 양과 응용방식이 바뀌어 왔음에도 DBMS가 아직까지도 그 자리를 내어주지 않은 것은 DBMS또한 그러한 환경변화에 매우 잘 적응하며 발전해왔기 때문이다. 2000년 초반 '클라우드'라는 개념이 대두되고 5년남짓일까 너도나도 여기저기서 클라우드 클라우드할 때만해도 DBMS는 위기를 느끼지 않았던듯 하다. 그러나 뭔가 얻어맞은 듯한 느낌이 들정도로 DBMS시장의 근간을 흔든 일이 2010년 초반 '빅데이터'라는 개념의 대두와 더불어 일어났다. 바로 NoSQL 이었고  MongoDB, Cassandra 등 수많은 NoSQL 제품들이 재조명되거나 봇물터지듯 시장으로 쏟아져 나왔다. 시스템의 구상과 개발이야 이전부터 있어왔지만 NoSQL의 약진은 빅데이터의 유행과 그 근간을 함께 한다. 빅데이터가 과연 무엇이냐를 놓고 2010년 초반 그 정의나 분류에 대해 참 말이 많았다. 아니 개념조차 제대로 잡지 못한채 스스로 자신이 빅데이터 전문가라며 당시 컨설팅을 하고 다닌 사람들이 이젠 어엿하게 빅데이터 시장에서 명함만 내밀어도 인정받는 사람들이 된 2010년 말에와 회상해 보면 NoSQL은 ACID를 다 만족시키지 않아도 된다는 어찌보면 당연한 것을 '그래 난 내가 원하는 것만 보장할래'라는 배짱 튀기기로 밀고 나간 것이었다.


이래서 DBMS보다 가볍다. 그래서 DBMS보다 특정 연산에 빠르다. 저래서 DBMS보다 싸다. 그래서.. 등등 

많은 이유들이 특정 트랜잭션 혹은 데이터 처리환경에서 그들의 손을 들어줬다. 그만큼 전통적인 DBMS는 비즈니스 레벨에서 데이터 처리 영역이 보다 세분화되어 대부분의 데이터 처리가 아닌 특정 데이터처리에 적합하다는 말을 들어야 하는 때가 왔다. 사실 아직도 ACID를 만족하는 트랜잭션 처리 분야는 데이터 처리 시장에서 매우 큰 부분을 차지하는 중요한 시장이다. 그럼에도 불구하고 상대적인 박탈감? 같은 것이 느껴진달까.. 예전에는 DBMS로 다 했는데 이젠 이건 뭐가 저건 뭐가 더 낫다는 결과들이 제시되며 왠지 '야 그동안 많이 해먹었으니 이젠 내려와라' 하는 느낌이다. 


그러나 과연 그럴까..? 데이터 처리 엔진을 굳이 유형별로 구분하고 분류해 두고 이런 환경엔 이게 최고 저런 환경엔 저게 최고라는 식의 논리로 한 시점에 베스트인것으로 보이는? 시스템을 설계하는 것으로 다 된 것일까? 데이터의 본질을 생각하면 정보의 본질을 생각하면 정보의 사용성이 어디에서 기인하는지를 생각해보면 그리고 거기에 더해 사용자의 편의성 정보관리의 주체와 기간 데이터의 유지비용 및 데이터 흐름의 적시성 등을 생각해보면 왜 지금도 새로운 데이터 처리 시스템들이 시장에 등장하고 있는지 알 수 있다. 


그럼에도 불구하고 데이터 처리의 기본은 데이터에 요구하는 속성에 기인한다. 

트랜잭션에 관한 이론은 이러한 데이터 처리에 있어 가장 근본적인 문제를 다룬 것이다. 마치 경제학에서 수요와 공급이 수많은 경제이론을 설명하는 이유와 시발점이 되는 것처럼 트랜잭션은 처리할 데이터의 가장 중요한 속성을 어떻게 볼 것인가를 짚고 있는 것이다. 그리고 그러한 것을 연구하는 분야가 바로 데이터 처리 시스템 연구분야이고 DBMS는 개발이 완료된 더이상 생각할꺼리가 별로 없는 시스템이 아니라 끊임없이 발전해나가고 있고 발전해 나가야 하는 시스템이다. 그래서 DBMS는 아직도 파야할 것이 많다. 


혹자들은 DBMS를 이미 legacy라 부르거나 기술하고 있을지도 모른다. 하지만 television을 레거시라 하진 않는다. 

DBMS는 브라운관TV가 아니다. television이다. 


  1. DBMS? 힐끗 다른 쪽을 바라봤다

    시스템 소프트웨어 개발자로 딱 60살까지만 이런저런 시스템, 특히 대용량 데이터를 다루는 시스템을 직접 설계하고 만들어보고 싶은 마음은 지금도 여전하다. 그리고 그러한 미련에 들어온 DBMS 개발바닥이다. 원래 우직하니 한 우물만 파는 스타일은 아닌데.. 어찌어찌 하다보니 10년째 데이터 처리 엔진쪽으로만 일하고 있는 자신을 바라보며 기특하단 생각도 든다. 하지만 최신 유행하는 다른 분야로 발빠르게 움직이지 못한 것이 못내 아쉬울 때도 종종 있다. 이런 내 마음에는 아랑곳 없이 데이터환경이 휙휙 바뀌면서 하루가 멀다하고 새로운 모양의 시스템, DB들이 마구 쏟아져 나온다. 이런 추세속에서 여전한? 것들을 하고 있는 내 자신을 바라보고 있자면 old school에서 벗어나지 못하고 있는 듯 느껴져 왠지 마음이 급해진다. 이 글을 쓰고 있는 지금도 어디에선가는 새로운 DB(용어따지기 좋아하는 사람들을 위해 여기서 'DB'는 데이터베이스 자체가 아니라 DBMS혹은 DMS를 의미한다는 것을 밝힌다)가 글로벌 DB시장에 런칭하는 소리가 들리는 듯 하니 말이다. 그러나 이쪽 분야에서 일을 하면 할수록 데이터를 다루는 일에 신구라는 것이 없다는 생각이다. 다...
    Date2018.12.28 Category나머지... By조성룡 Views990 Votes0
    Read More
  2. GitHub Desktop을 활용한 소중한 소스 코드 관리

    1) 소중한 자신의 소스 코드가 손상 되거나 손실 되는 경우 2) 외부에서 자신의 소스 코드를 열람해야할 경우 3) 소스 코드의 변경 된 부분을 찾아야 하는 경우 소스 코드를 사용하다 보면 위와 같은 문제로 업무의 연속성이 끊어지는 경우가 발생 합니다. 이러한 문제를 GitHub Desktop을 통해 아주 간단하고 편리하게 사용 및 관리 하는 기능을 소개 하려 합니다. - 비용 : 무료 단, 소스 코드를 비공개하려면 과금 필요 - GUI 프로그램으로 git bash(커맨드 라인) 보다 편리하며, 손 쉽게 사용할 수 있습니다. [1 : GitHub 회원 가입] - 회원 가입 URL : https://github.com/ - IMAGE #1 GitHub 공식 홈페이지 접속 화면 사용할 정보 입력 : Username, Email, Password - IMAGE #2 STEP 1 : 계정 생성 동의 하기 - IMAGE #3 STEP 2 : 계정 유형 선택 - IMAGE #4 사용자 유형 선택 (Skip 해도 무관) - IMAGE #5, 6, 7 STEP 3단계 모두 마치면, Email 확인 후 계정 사용 가능 [2 : GitHub Desktop 설치] - 설치 URL : https://desktop.github.com/ - 지원 OS : Windows, OS X(MAC) - IMAGE #1 공식 홈페이지에서 GitHub Desktop 설치 파일을 받으 실 수 있습니다. (약 80MB) ...
    Date2018.12.03 Category나머지... By윤준수 Views12410 Votes0
    Read More
  3. No Image

    Y2K38, "UNIX Millennium Bug"

    시작하며 당신은 소프트웨어 엔지니어 입니까.  정보시스템 매니저 입니까, 아니면 평범한 회사원 입니까? 당신이 무엇을 하던지간에 50세 이하라면 당신은 Y2K Millennium Bug를 만나실 수 있습니다. 1990년대 후반의 Y2K 이슈 1990년대 후반에 전 세계가 떠들석했던 이슈가 있었는데 연도를 2자리로 표기해서 생긴 “Y2K”입니다.  1997-12-23이 아니라 97-12-23 형태로 말입니다.  90년대 이전 대부분의 정보시스템은 연도를 ‘1997’과 같이 4자리로 표기하지 않고 ‘97’과 같이 2자리로 표현했는데,  이런 관행이 정보시스템이 2000년과 1900년을 구분을 못하는 문제의 원인이 되었던 것이지요.  2000년 10월 23일에 태어난 신생아의 주민등록번호는 001023로 시작되는데 이것은 1900년에 태어난 100살의 노인도 마찬가지 입니다,  주민번호가 고유하지 않을 가능성이 생긴 것입니다.  정보시스템에서는 치명적이라 할 수 있지요.  온 세계의 정보 시스템 관리자가 자기의 시스템에서 사용하는 날짜가 4자리로 되어있는지 검사하고 감리하느라고 분주했고 “Y2K 비즈니스”라는 사업분야가 생길 정도였습니다.  Y2K의 위력에 버금가는 아니 그것보다 클 수 있는 이슈가 Y2K38 Uni...
    Date2017.12.07 Category나머지... By한기수 Views1559 Votes0
    Read More
  4. 연말에도 기술지원은 쉬지 않는다.~!!

    2009 12월, 누구나 그런 것처럼 12월말은 일이 손에 잡히지 않는게 사실이다. 송년회다 신년 사업계획에다 정신 없이 한 해를 마무리할 때쯤, 불길한 예감의 전화가 걸려왔다. 전화의 내용은 백업 본을 이용하여 DB를 복구하였는데 구동이 되지 않는 다는 것이다. 복구를 하게 된 이유는, DB의 size가 증가하여 DB를 백업한 후 삭제하고 파티션을 할당하여 여유공간을 확보하고 백업 본을 이용하여 복구를 하기 위해서였다고 하였다. DB백업 본이 있으니 문제가 없을 거라는 안도의 한 숨을 쉬면서 원격을 요청하여 DB를 구동시켰으나 역시나 구동되지 않고 죽어버린다. 땡~!! 머리 속에서 제야의 종이 울리기 시작했다. 연말이라 종소리의 충격이 거세어 졌다…. 다행히 core파일이 존재하여 코어를 분석하니 log recovery과정 중에 죽은 것으로 되어 있어 가볍게 “로그복구를 하면 되겠지” 라고 생각했었는데 뒤끝의 찜찜함은 무엇일까…. 역시나 IT에서의 찜찜함은 그냥 넘어 갈리가 없다. DB구동은 되었으나 어느 순간 오류 메시지를 출력하고 데이터입력이 되지 않는 것이다. 연말 왕건이 걸렸구나 흑흑…. 에러의 메시지는 DB의 구성파일인 몇몇 볼륨들을 찾을 수 없다는 ...
    Date2010.01.21 Category나머지... Byjanus Views39098 Votes0
    Read More
  5. 고객지원 중 얼음이 되다.

    벌써 12월의 끝자락…. 지난달 초 생각만해도 아찔한 지원이슈가 생각이 난다. 이른 오전 핸드폰에서 나를 부르는 진동이 느껴졌다. 그간 별탈 없이 유지되었던 고객사의 발신이라 편한 마음으로 전화를 받았다. 그런데 이런…. 고객사의 DB에서 사진데이터가 나오지 않는 다는 것이다. 부랴부랴 원격으로 고객사의 서버에 접근하여 확인을 하는 순간 얼음이 되어 버렸다. 누군가 “땡” 하면서 터치를 해줄 사람이 있었으면…. DB의 특성상 데이터 보존이 중요하고 또한 저장된 데이터들이 고객의 자산과 같다. 설마 고객사에서 데이터를 삭제했을 일은 없을 것이고 어떻게 처리해야 할지 난감한 상황에 봉착했다. 별다른 수가 없어 백업을 이용하여 복구를 수행하려 하였으나, 이미 사진데이터가 없는 상태에서 운영이 되어 앞으로도 뒤로도 갈수 없는 사면초가인지 진퇴양난인지에 빠지게 되었다. CUBRID에서는 GLO(Generalized Large Object) 시스템 클래스를 이용하여 사진과 같은 멀티미디어 데이터를 저장하도록 되어 있다. 문제의 DB에서는 데이터영역에는 사진데이터가 있지만 ROW에서 참조하는 링크정보가 깨진 것으로 보인다. 고민에 고민을 하던 중 잡머리가 비상하게 ...
    Date2009.12.08 Category나머지... Byjanus Views39386 Votes0
    Read More
  6. 고객지원 엔지니어의 패션 스타일

    큐브리드 고객지원의 패션 스타일~ 요즘은 대통령도 셔츠에 타이를 매지 않는 노타일 스타일이 유행이다. 형식과 겉모습보다는 업무의 편안함과 효율성을 강조하는 게 대세이기 때문일 것이다. 하지만 이런 대세에도 불구하고, 최근 사내에서는 고객의 접점에 있는 고객지원팀의 신뢰도와 인지도 향상을 위해 기존의 캐쥬얼 스타일에서 정장을 입는 게 어떠냐는 의견이 개진되었다. 사실 회사의 규모가 크면 혹은 그 브랜드가 널리 알려지면 엔지니어의 복장은 크게 문제가 되지 않을 수 있을 것 같지만, 큐브리드 같이 이 업계에서는 규모면에서는 작은 회사인 경우에는 고객지원팀이 바로, 큐브리드의 회사나 이미지를 보여주는 막강한 홍보도구일 수 있는 게 사실이다. 그러한 의미에서 전문 기술력과 프로정신의 강한 인상을 심어주기 위해 정장을 입자라는 의견인 것이다. 이슈를 제기한 분은 글로벌 벤더의 실 사례를 보여주면서 고객 접점에서의 복장이 얼마나 중요한 것인가를 실험을 통해 보여주시기도 하였다. 그 실험 내용은 정장의 대표격인 흰색 셔츠에 대한 고객의 반응이였던 것이다. [다음은 고객사의 중역 106명에게 한 실험이다.] 컴퓨터 업계에서 I사는 세...
    Date2009.10.16 Category나머지... Byjanus Views40855 Votes0
    Read More
  7. No Image

    4회 CUBRID Inside 후기

    지난 9월 16일 CUBRID Inside가 강남 토즈에서 있었습니다. 사실 Deview가 다음날이라 참석하지 못하시는 분들이 많을까 걱정했었는데 역대 최고! 신청수/참가수를 기록한 역사적인~ 날이었습니다. 샤롱스판(면스판)님과 저는 선발대로 5시 30분쯤 출발, 6시쯤 도착해서 뒷풀이 장소 예약 확인하고 어떤게 맛있을지 고민하고 ^^; 토즈로 올라가 예약장소 확인하고 준비물 확인하고.. 노트북 세팅하고 이런저런 준비작업들을 진행했습니다. 예전에는 잘 몰랐으나 행사를 진행하는 일이 그렇게 쉬운 일만은 아니라는 것을 알게 되었네요. ^^; 멋 옛날에 500인 규모의 행사를 진행한 적도 있었지만 그땐 도우미(?)의 역할만 했었으니까요. 많은 분들에게 뜻깊은 CUBRID Inside가 되도록 노력하고 있다는 것! (알아주시면 감사하겠습니다 ~_~;;) 이번 Inside는 예전과 달리 오픈소스 세션 외에 응용 세션이 추가 되었었지요. 큐브리더(CUBRID 매니아)를 비롯한 여러 응용개발자 분들에게 도움이 되고자 개편된 것이지요! 많은 분들이 하나 둘 씩 행사장에 도착하시고 간단한 음료와 맛있는 샌드위치를 시식하며 Inside가 진행되었습니다. (여담인데 샌드위치 아이디어가 참 좋더군...
    Date2009.09.21 Category나머지... By시난 Views39416 Votes0
    Read More
  8. DeView 2009에서 만난 큐브리드

    작년에 이어 올해 두번째로 열리는 DeView 2009 행사가 어제 9월 17일 있었다. 지난 해 국내 웹 환경의 발전을 위해 콘텐츠의 생산과 유통, 소비를 유기적으로 지원하는 정보 플랫폼 기술들을 오픈소스와 오픈API 형태로 공개하면서 많은 개발자들의 관심이 되어온 NHN이 올해로 두번째 행사를 개최한 것이다. 이번 행사에서는 지난 1여년 동안 정보 플랫폼 공개 이후의 성과와 적용 사례들을 위한 세션들이 대거 마련되었는데, 그 중에서도 무엇보다, 세션 이외에 별도로 마련된 튜토리얼이 눈에 띄었다. 이 튜토리얼 세션은 공개된 오픈소스 기술들을 현장에서 직접 학습하고 구현해 봄으로써 실제 개발자들의 많은 관심과 참여를 불러일으키기에 충분했던 것 같다. 이번 행사에서 CUBRID는 본 세션 뿐 아니라 튜토리얼, 데모부스까지 선보이면서 많은 관심을 받았다. 특히 튜토리얼의 경우에는 CUBRID 내부 개발자가 아니라 외부 개발자인 pcraft님이 직접 세션을 진행해 주셔서 더욱더 의미가 있었던 것 같다. 지난번 큐브리드 인사이드 행사 때 뵈었을 때보다, 더 의욕에 찬 모습이 너무 보기 좋았다. 내친 김에 관심 갖고 데모부스까지 찾아주신 마당발 블로터닷넷의 도...
    Date2009.09.19 Category나머지... By멜라니 Views39559 Votes0
    Read More
  9. No Image

    개발자.. 사용자...제품...

    고객지원이라는 타이틀을 달고 여러 고객들을 만나서 이야기를 하다 보면 참 많은 이야기들이 나온다. 사는 이야기부터, 개발자가 된 사연, 이 제품/저 제품 만나면서 고생한 이야기, 그리고는 CUBRID에 대하여 구구절절 말들이 나온다. 본격적으로 제품 이야기를 하다보면 불편한 사항들이 주를 이루고, 그 중에는 꼭 되었으면 하는 것들에 대하여 이야기를, 참 많이도 주신다... 그럼 그런 이야기를 가지고 와서 여기저기서 들어오는 이야기를 정리해보면 이 많은 것들을 어떻게 정리해야 할지 참 난감하다... 나름대로 정리해서 개발자들과 이야기를 하고, 그리고 또 정리되고... 나름대로들의 논리를 가지고 소위 우선순위라는 것을 정한다. 그런데 그 논리라는 것이 참 어렵다. 뭐 민주주의라는 근본에 여럿이 원하고 이게 정말 필요하고 이런 것들인데... 그 참 간단한 원칙에 생각보다 많은 것들이 밀려나간다... 어쩔수 없는 선택의 상황이고, 대다수가 논리에 의해 이해하고 참고 기다리겠지만... 한편으로는 언제까지 소수는 기다려야만 하는지 그런 생각이 든다. 네비게이션에 동영상을 볼수있는 기능이 있는데, 그걸 같이 볼수는 없다... 아니 내 네비에서 지원하...
    Date2009.07.01 Category나머지... By남재우 Views43571 Votes0
    Read More
  10. 스티브 잡스의 교훈

    조정래 작가의 소설 <태백산맥>을 접했던 때가 고등학교 2학년 때였다. 흥미 진진한 줄거리, 진솔함이 베어나는 전라도 사투리, 생생한 묘사, 그리고 가슴 벅찬 감동 때문에 열권의 책을 끝낼 때까지 교과서를 팽개치고 내내 이 책만 파고 들었던 기억이 있다. 그로부터 시간이 많이 흘렀지만 그때의 깨달음을 한시도 잊어본 적이 없는데, 그것은 "민초, 개개인의 삶이 모여 역사를 만든다."는 교훈이었다. 첫번째 직장에서의 5년, 그리고 생소한 분야로의 이직, 현 직장에서의 적응을 위해 고군분투를 하던 작년의 어느 날, 또 다른 감동이 찾아왔다. 작년 "영어명연설문"이라는 책을 통해 스탠포드 대학 졸업식에서의 스티브 잡스 연설문을 처음 접했을 때, 출근길 지하철 안에서 그만 감동에 겨워 눈물, 콧물을 빼며 읽고 또 읽었다. 이미 스티브 잡스의 연설 동영상은 2년이 지난 지금에도 많은 네티즌들에 의해 회자되고 있다. 그의 연설은 세가지 파트로 나뉘는데, 그 첫번째는 현재와 미래의 연관성에 관한 이야기였고, 두번째는 사랑과 상실에 관해서였고, 세번째는 죽음과 함께 한 이야기였다. 그리고 마지막 결론 파트에서는 "배고픔과 함께 하라, 어리석음과 함께 ...
    Date2009.06.15 Category나머지... ByCUBRID_DEV Views66759 Votes0
    Read More
Board Pagination Prev 1 2 3 Next
/ 3

Contact Cubrid

대표전화 070-4077-2110 / 기술문의 070-4077-2113 / 영업문의 070-4077-2112 / Email. contact_at_cubrid.com
Contact Sales