2013.03.19 11:18

모두가 원하는 개발자 되기 10단계


Andrew Oliver | InfoWorld

개발자가 되기 위해 프로그래밍 기술만 있으면 된다고 생각한다면, 틀렸다!
 
코드를 잘 쓰는 것도 중요하지만, 일의 능률을 높이고 더 높은 연봉을 받기 위해서는 많은 이에게 자신이 누구인지 알리는 것이 중요하다. 다시 말해, 스스로를 마케팅해야 한다. 여기에서 성공적인 셀프 마케팅 방법을 소개한다.
 
모두의 개발자 팁 No.1 : 블로그 
블로그를 개설 후 한 달에 한 번 이상 포스팅을 올려라. 블로그에 올리는 글은 꼼꼼히 리서치하고, 바보 같아 보이는 말은 하지 않는다. 
 
농담이 아니고, 개발자들도 정말 작문 실력을 높이기 위해 노력해야 한다. 학교 다닐 때 국어 선생님이 가르쳐준 것들을 활용해보자. 글을 쓰기 전 개요를 작성하고, 서술 기법을 정하고, 문법이나 맞춤법을 확인하는 것 말이다. 
 
그런 후에는 아깝더라도 필요 없는 부분은 잘라내 지나가는 사람이 한번 훑어만 보아도 무슨 이야기인지 알 수 있을 만큼 단순하게 만들어라. 필자의 글을 읽는 에디터도 마찬가지지만 인터넷에서는 대화문과 같은 '뉘앙스'를 완벽히 전달할 수 없다. 
 
모두의 개발자 팁 No.2 : 오픈 소스
오픈 소스에 대한 거짓말들을 믿지 마라. 나이가 조금 어린 개발자들은 개발자가 실업자가 될 수 있었던 시절을 기억하지 못할 지도 모르지만, 경제 불황이 아주 최악일 때도 오픈 소스 프로젝트 개발자들은 빠른 시간 안에 일자리를 구할 수 있었다. 
 
오픈 소스 코드를 만들 때 자신이 원하는 직업이 어떤 것인지를 충분히 반영하기 바란다. 필자는 가능한 한 간단한 솔루션으로 어려운 문제를 해결하려 했지만, 그간 인터뷰해 온 개발자들은, 그들의 오픈 소스 코드에서도 분명히 알 수 있었듯, 간단한 문제를 복잡하게 만들기를 원했다. 
 
믿거나 말거나지만, 이런 시장도 형성이 되어 있으며 자신이 속한 시장을 반드시 코드에 반영시키기 바란다. 
 
모두의 개발자 팁 No.3 : 한 직장에 너무 오래 머물지도, 너무 자주 이직하지도 마라 
너무 자주 이직하지 마라. 농담이 아니다. 개발자들의 취업이 어려워지는 시절은 반드시 다시 온다. 그 때가 되면, 잦은 이직만큼 자신을 끈질기게 따라다닐 꼬리표도 없을 거다. 
 
반면, 한 직장에서 10년 가까이 머물며 한 가지 일만 하는 것도 좋지 않다. 한 곳에 너무 오래 머물다 보면 그 일이 일상화 돼버린다. 자신의 가치를 높이기 위해서는 IBM에서 IBM식으로 IBM 스택 코드를 쓰는 것에 만족해서는 곤란하다. 
 
필자는 개인적으로도 IBM이나 이와 비슷한 조직에서 1, 2년 이상 머무른 사람은 고용하지 않는다. 이들은 대체로 면접에서는 아주 훌륭한 모습을 보여주지만 프로그래밍 테스트에서 떨어지고 만다. 
 
모두의 개발자 팁 No.4 : 눈으로는 새로운 것을 좇되, 실용적인 것에서 손을 놓지 마라
나이가 어린 개발자들은 화려하고 눈에 띄는 일을 좇는 경향이 있다. 필자가 가장 좋아하는 프로그래밍 언어는 루비(Ruby)지만, 루비는 평균적으로 봤을 때 자바(Java)만큼 돈을 많이 받지도 못하고 시장도 더 좁다. 
 
그렇지만 항상 그런 것은 아니다. 스칼라(Scala)가 강세를 얻고 있는 것처럼 보이지만, 시장 규모는 속일 수 없다. 반면 한 곳에 너무 오래 머무르다가 미래의 코볼(COBOL)이나 파워빌더(PowerBuilder) 개발자가 돼버려서도 곤란하다. 
 
모두의 개발자 팁 No.5 : 읽는 사람을 배려해 문서를 작성하라 
필자는 회사 임원들이 읽고 한 번에 이해할 수 있는 문서나 프레젠테이션을 만들었다는 이유만으로 프로젝트에 참여하거나 경영진 미팅에 참여하게 된 경험이 수없이 많다. 
 
필자는 항상 임원진들을 위한 개요를 서두에 작성해둔다. 다시 말해, 꼭 읽어야 하는 페이지는 개요뿐이고 나머지는 개요를 잘 이해하지 못했을 때 읽으면 된다. 이 때 고려해야 할 것은 엄청나게 바쁜 일정을 소화해야 하는 사람에게 이 주제에 대해 얘기하려면 어떤 정보를 골라서 설명해 줘야 하는가다. 
 
대부분 매니저들은 '누가 일의 진척 상황에 대해 자신을 귀찮게 하지 않고 이 일을 끝까지 이끌어 갈 수 있는가'를 가장 궁금해 한다. 이 부분에 중점을 두고 보고서를 쓰길 바란다.
 
모두의 개발자 팁 No.6 : 간결성이 생명이다
경영진들을 가까이 하다 보면 바로 알 수 있는 특징 가운데 하나는, 말을 잘 하는 사람일수록 짧고 정확한 답변을 한다는 것이다. 
 
답변이 길고 복잡해진다는 건 그 사람이 주제에 대해 잘 모르거나 별로 성실하게 일을 하지 않는다는 의미다. 또, 주제의 중요도와 목소리 톤은 반비례하는 것도 사실이다. 
 
정말 나쁜 소식을 전할 땐 조용히 문을 닫고 들어와 속삭이듯 말하는 법이다. 그다지 중요한 일은 아닌데 그냥 짜증 나는 소식일 경우 격앙된 목소리로 그 문제에 대해 목소리를 높이게 된다. 
 
중요하지 않은 일에 대해 목소리를 높이는 사람이 되지 마라. 자신이 무슨 이야기를 하는지 정확히 알고, 그 이야기를 어떻게 요약할 지 고민하되 세부적 사항들을 포함시키려 노력해야 한다. 
 
그렇지만 문장 하나 하나를 전부 세부 사항들을 곁들여 설명할 필요는 없고, 하늘이 무너진 것도 아닌데 작은 일에 호들갑을 떨지 마라(단지 한동안 괜찮은 빌드(build)가 없었기에 젠킨스(Jenkins)를 살펴봐야 할 지도 모를 뿐이다).
 
말로 하는 게 정 안 되면, 비용으로 승부봐야 한다. 숫자를 신중히 선택해 차트에 기입하고, 비용적인 측면에서 이것이 다른 것보다 더 낫다는 것을 확실히 보여줘라. 

모두의 개발자 팁 No.7 : 관중을 놀라게 해라
관중 앞에서 발표하고 프레젠테이션을 잘 하는 방법에 대해 고민하라. 한 가지 주제에 대해 리서치하고 그 주제에 대해서는 '유일한' 권위자가 되지는 못하더라도 '전문가' 정도는 돼야 한다. 여러 사람을 상대로 하는 프레젠테이션은 재미적인 요소가 가미돼 있으면 좋다. 
 
이런 기술은 낯뜨거운 실수를 몇 번씩 반복하지 않고는 얻을 수 없는 것이다. 
 
그렇지만 경영진에게 한 주제에 대해 분명한 말로 잘 설명해 낼 수 있고 이에 대해 전문 지식을 가지고 있다면 그렇지 못한 사람에 비해 높은 연봉을 받게 된다는 건 장담할 수 있다.
 
모두의 개발자 팁 No.8 : 현실적인 개발자가 되라
자신이 설령 얼랑(Erlang)을 좋아한다고 해도, 이 시장은 그다지 크지 않다. 개발자라면 하나 이상의 프로그래밍 언어를 알아야 하며, '새로운' 주제나 새롭게 떠오르는 주제에 대해서도 잘 알아야 한다. 
 
그러나 충분한 고려 없이 '얼랑이 아니면 코드를 하지 않겠다'는 식의 미숙한 발언은 하지 않아야 한다. 좁은 분야의 전문가가 되는 것도 돈을 벌 수는 있겠지만, 거기에도 비용이 따른다. 
 
결국 자신은 전문 분야에 따라 그 분야에 국한된 배역만을 맡게 될 것이며, 그 분야가 유행을 탈 때는 좋겠지만 그 후에 자신이 뭍에 올라온 물고기처럼 바싹 말라갈 일만 남은 것이다. NoSQL이 자신이 진행하는 프로젝트에 더 잘 맞을 수도 있다. 그렇지만 기업에서는 일회성 시스템에 투자를 하지는 않을 것이다. RDBMS으로도 충분히 할 수 있는 프로젝트이기 때문이다.
 
모두의 개발자 팁 No. 9 : 툴을 이용해 어려운 문제를 해결하라
따로 시간을 내 다른 사람들이 잘 모르는 툴을 몇 가지 배워둬라. 다른 이들이 잘 모르거나, 사용하지 않는 툴은 무엇인가? 그 가운데 자신의 효율성을 더욱 높여줄 툴은 무엇인가?
 
예를 들어, 아스펙트4j(Aspect4j)는 사용하는 사람이 얼마 되지 않지만, 필자는 개인적으로 이를 아주 유용히 사용한다. 필자는 아스펙트4j를 잘못된, 아주 잘못된 것들에 사용한다. 아스펙트4j를 웹스피어(WebSphere) 대신 톰캣(Tomcat)에서 작동시키기 위해 클래스 파일 오퍼레이션(class file operations)을 만들었다. 비록 오리지널 소스는 없었지만 말이다. 
 
또한 상용 소프트웨어의 메모리 누수 문제도 고쳤다. 필자는 윌리 인트로스코프(Wily Introscope)를 도입했다. 그럴 때마다 사람들은 필자가 다른 이들이 잘 사용하지 않는 툴을 사용한다는 점 때문에 천재처럼 여기곤 했다. 
 
그리고 다른 이들이 개발업체를 기다리기로 결정했을 때에도 필자에게는 계속 진행하라고 하기도 했다. 필자는 eclipse.org/mat과 함께 살고 숨쉬었으며 그 결과 메모리 누수 문제를 해결할 수 있었을 뿐 아니라 어떤 행동과 한도가 OOME(Out Of Memory Error)를 초래하는지도 말해줄 수 있었다. 
 
복잡한 문제를 해결해 주는 이런 간단한 툴 덕분에 필자는 다른 개발자 사이에서도 돋보일 수 있었다.
 
모두의 개발자 팁 No.10: 겸손을 잃지 마라
개발자에게는 겸손이라는 자질이 아주 부족하다. 겸손해진다는 건, 때로는 원하는 것 이상으로 힘든 일을 도맡아야 함을 의미한다. 
 
또한 문제를 해결했다고 해서 이에 대해 자만해서는 안됨을 의미하기도 한다. 유명세는 오고 가는 것이지만, 한 가지 기억해야 할 것은 자신이 최근에 한 일 덕분에 유명세가 찾아오는 것이라는 사실이다. 그런 다음, 한 주만 지나도 유명세는 사라져 버릴 지도 모른다. 
 
타일러 더든의 말을 빌리자면, "당신은 특별한 사람이 아니다." 그렇다, 필자도 이 말의 아이러니에 대해서는 잘 알고 있다.
 
자신이 인기있는, 모두의 개발자가 됐는지 어떻게 알 수 있을까?
자신이 서 있는 곳에서 양 옆을 살펴 보자. 자신이 하고 있는 일과 같은 일을 하는 사람들이 보이는가? 그렇다면, 아직 멀었다.
 
자신이 많은 이들이 원하는 개발자가 됐다는 신호에는 다음과 같은 것들이 있다. 
 
사람들과 함께 있는데 다들 자신을 주목하고 있다든지, 특별한 상황이 아님에도 자신과 함께 사진을 찍고 싶어 한다든지, 자신의 연설을 모두가 기다린다든지, 혹은 자신의 연설을 얼마나 좋아하는지 직접 얘기한다든지 하는 것들이다. 
 
덧붙여, 영업 및 마케팅 직원들이 자신의 의견에 귀 기울여 듣는지도 봐야 한다. 딱 자신의 얘기라고? 그렇다면 축하한다, 이미 모두의 개발자가 된 것이다. 
 
그러나, 명성과 성공은 한 순간일 뿐이다. 이를 지속하기 위해서는 끊임없이 발전해야 한다. 아이러니하게도, 인기 있는 개발자가 될수록 정작 코드는 점점 더 적게 쓴다. 
 
다른 사람들과 소통하고 그들에게 동기를 주는 것이, 그리고 자신의 성공 비결을 전파하는 것이 경제적으로 더 효율적이 되기 때문이다. 자신이 원했든 원하지 않았든 말이다.
 
앞서 말했지만, 소프트웨어 개발자들이 일자리를 원한다고 해서 다 가질 수는 없는 시기가 다시 한 번 찾아올 것이다. 특히 '적자생존' 식의 분위기가 만연해지면, 묵묵히 제 할 일만 하는 사람보다는 '셀프 마케팅'을 잘 하는 개발자가 살아남게 될 것이다. editor@itworld.co.kr




부족한 것도 많고

그만큼 해야할 일이 너무 많다...

평생 심심하지 않아...
즐겁구만~ ㅋㅋ



Posted by 열라착한앙마

댓글을 달아 주세요

2008.01.16 19:40
현장에서 마주칠 수 있는 10가지 타입의 프로그래머

Justin James ( TechRepublic )   2008/01/02  
프 로그래머들은 특별한 사람이라고 평가되는 것을 좋아한다. 사실은 어떤 모범적인 프로그래머들은 다른 프로그래머들의 이상한 점을 개발자들의 커뮤니티 내에서도 발견한다. 아래에 10가지 타입의 프로그래머를 소개한다. 여러분은 이 중에 어떤 타입인가?

#1: 간달프(Gandalf)

이 프로그래머 타입은 ‘반지의 제왕’에 나오는 마법사 간달프와 닮았다. 이 타입의 외관은 턱수염을 기르고, 이상한 모자를 쓰고, 겨울에 망토 같은 외투를 입을지도 모르며, 좋게 보면 간달프와 같은 마법으로 팀을 위하고, 안 좋은 면은 팀원들이 간달프가 눈길을 걸어올라 오는 시간을 기다리듯이 그가 전산실에 오는 시간을 오랫동안 기다려야 한다는 것이다.

이런 타입은 실력이 아주 뛰어난 중요한 인물이지만 보통은 같이 일하기를 꺼려한다. 하지만 문제가 해결이 안 될 때는 간달프의 마법이 필요하듯 이런 타입의 도움도 필요한 법이다.

#2: 순교자

다른 업종에서는 순교자(The Martyr)는 워커홀릭이다. 하지만 개발 분야에서 순교자는 그 차원을 넘어 선다. 워커홀릭은 최소한 집에 가서 샤워하고 잠은 자기 때문이다. 순교자 타입은 다 먹은 피자 박스에 둘러싸인 책상에 엎드려 자는 것을 자랑스럽게 생각한다.

문제는 아무도 이렇게 일하는 것을 원하지 않았다는 것이다. 순교자 타입은 다른 팀원에게 부담스러운 말을 한다. “먼저들 들어가. 저녁 맛있게 먹고…. 나는 오늘밤에 3주 동안 해야 할 코딩을 모두 하고 들어갈래.”라는 식으로 말이다.

#3: 팬보이

팬보이(Fanboy)는 조심해야 한다. 이런 사람이 여러분 주의에 있다면, 그는 드래곤볼 Z와 건담 윙 중 어느 것이 재미있는지 또는 플레이스테이션3와 X박스 360중 어느 것이 더 좋은지에 관해 과장 좀 해서 3시간 동안은 이야기를 들어야 할 것이다.

팬보이의 책상 주변에는 일본에서 수입한 액션 피규어, 포스터 또는 장식품 등을 진열해 놓았을 것이다. 이들은 자신들이 가지고 있는 장식품을 가지고 생각하는 것을 좋아해서, 그 생각에 시간을 많이 허비한다. 이런 타입은 가끔 무엇 때문에 채용을 했는지 모를 때가 가끔 있다.

#4: 빈스 닐(Vince Neil): 미국 밴드 머틀리 크루의 리드싱어

마치 1984년으로 돌아간 것 같은 타입이다. 긴 머리카락, 찢어진 청바지에 큰 스카프를 목에 두르고 업무 시간 동안 본 조비, 데프 레퍼드(Def Leppard)와 같은 음악을 따라 흥얼거리며 일한다. 빈스 타입은 일반적으로 재미있고 경험도 많지만 발전이 없다. 게다가 힙합 스타일과 아웅다웅할지도 모른다. 이런 타입과 매일 일하는 것은 꽤 힘들 것이다.

#5: 닌자

닌자 타입은 여러분 팀의 MVP이지만, 아무도 누구인지 모른다는 것이다. 전설적인 자객처럼, 닌자 타입은 일을 하는 건지 안 하는 건지 모르지만 아침이 되면 결과물이 나와 있는 것을 발견할 수 있다.

여러분이 소스 제어 시스템을 가동하고, 새벽 4시에 한번 확인 해보라. 여러분은 닌자가 그 프로젝트를 알고 있을 것이라고 생각하지도 않았지만, 여러분이 일주일 동안 작업한 계획의 문제를 코드 레벨에서 확인하고 알려 두었을 것이다. 여러분이 다른 회의에 참석해 있을 때, 닌자 타입은 일을 하고 있을 테니 확인해 보라.

닌자 타입은 아주 비밀스럽게 일을 한다. 여러분은 그 사람의 이름조차 모르지만 모든 프로젝트마다 아주 깔끔하게 정리되어 있는 것을 볼 수 있다. 이런 타입은 신중하게 다가가야 한다. 이런 사람을 조직 내에서 순위를 매기거나 파일로 업무를 관리하려고 하지 마라. 닌자 타입은 혼자 일하는 전사이며, 관리 당하는 것을 싫어한다.

#6: 이론가(The Theoretician)

이 타입은 프로그래밍에 관해 알아야 하는 모든 것을 알고 있다. 이 타입은 애매한 프로그램 언어의 역사에 관해 4시간 정도 떠드는데 시간을 소비하거나 어떻게 프로그래밍 하면 런타임을 줄이고, 최적화 프로그래밍을 할 수 있는지에 대해 시간을 허비할 수 있다.

문제는 이런 타입은 소프트웨어 개발에 관한 것을 알지 못하고 있다는 것이다. 이론가 타입이 코딩을 하면 정말 말도 안 되게 ‘엘레강스’하다. 또 좋아하는 기술은 ‘반복’이며, 모든 코드는 최대한 꼬여 있어 읽는 데 시간이 많이 걸린다.

이런 타입은 주의가 산만해 쉽게 다른 일에 관심을 돌린다. 몇 시간이면 개발할 수 있는 일을 이런 타입은 석 달은 족히 걸린다. 왜냐하면 기존의 툴은 충분하지 않다며 새로운 라이브러리를 만들어 새로운 툴을 만들어 사용하려고 하기 때문이다.

이런 타입은 잘만 컨트롤 하면 아주 잘 활용할 수 있다. 프로젝트에서 정확히 할 일에 대한 범위를 정해 주고 다른 일에 시간을 허비하지 못하게 한다면 말이다.

#7: 코드 카우보이(The Code Cowboy)

이 타입은 절대 스스로 멈추는 법이 없다. 이런 타입은 거의 항상 최고의 프로그래머이며, 다른 사람보다 두세배는 빠르게 일을 할 수 있다. 하지만 문제는 그렇게 빠르게 하는 일의 반을 대충 한다는 것이다. 소스 컨트롤 하는 코드 확인에 시간이 걸리고, 외부 컨피규레이션 데이터 저장에 시간이 걸리고, 다른 사람과 대화중에 생각을 이해하는 데도 시간이 걸린다.

이 타입의 코드는 스파게티처럼 혼란스럽다. 이유는 프로그래밍 하면서 리팩토링 하는 것이 절대 일어나지 않게 빨리 하기 때문이다. 프로그래밍 책에 예제로 되어 있는 “이렇게 하지 마세요”라고 7페이지에 걸쳐 중요하게 설명되어 있는 것과 비슷하게 프로그래밍을 했지만 신기하게도 프로그램은 돌아간다.

코드 카우보이 타입은 다른 사람과 함께 일을 잘 하지는 못한다. 그리고 여러분이 이런 타입 두 명을 같은 프로젝트에 투입시키면, 서로의 변화에 대해 인정을 하지 않고 싸우기 때문에 확실히 실패 한다.

이 타입은 정확하게 해야 하는 프로젝트보다 납기 일정이 더욱 중요한 프로젝트에 투입하는 것이 좋고, 코드는 항상 일정 전에 완성되어 있을 것이다. 코드 카우보이는 ‘시끄러운 닌자 버전’이라고 보면 된다. 닌자가 정교한 외래 수술을 하는 것에 비유한다면, 코드 카우보이는 성난 소처럼 저돌적으로 자신의 길을 달려가는 것에 비유할 수 있다.

#8: 공수부대요원(The Paratrooper)

여러분은 영화에서 적지 깊숙이 침투하여 비밀스럽게 업무를 수행하는 특공대 요원을 본적이 있을 것이다. 이 타입은 소프트웨어 개발 세계에서 ‘공수부대 요원’이라고 한다. 이 요원은 다 죽어 가는 프로젝트를 살리기 위해 마지막으로 보내는 프로그래머이다.

이 요원은 장기 프로젝트에 대해서는 부족하지만, 그들의 최대 자산은 친숙하지 않는 코드를 배워서 작업을 하는 불가사의한 능력이다. 다른 프로그래머들은 이러한 것을 충분히 배워서 프로젝트를 실행하는 데 몇 주 내지 몇 달이 걸릴지도 모르지만, 공수 부대 요원들은 몇 시간 또는 하루 정도면 충분하다.

이 요원들은 그 코드의 핵심을 알 정도로 배우지는 못하지만, 전체의 팀이 실패할지도 모르는 곳에서 성공할 수 있는 것을 의미한다.

#9: 보통사람(Mediocre Man)

“충분히 좋다”라고 듣는 것이 이 ‘보통사람’ 타입에게서 들을 수 있는 최고의 찬사이다. 이 이름에 속지 말아라. ‘보통사람’이라는 타입에는 엄청난 다양함이 있다. 그리고 이들은 다른 팀원들보다 더 나쁜 코드를 만드는 데 시간이 더 걸린다.

이 타입들의 특징은 느리고 침착하게 하지만 프로젝트가 언제 끝날지 모르며, 회사에 오랫동안 일을 하기 위해 항상 “충분히 좋다”라는 슬로건을 외친다.

이런 타입을 인터뷰 할 때 그들은 많은 프로젝트에 관여한 사실을 여러분에게 이야기 하겠지만 실제로 관여한 프로젝트는 많지 않다. 이러한 타입을 알아내는 것은 쉬운데 그들이 한 일에 대한 자세한 질문을 하면 아마 갑자기 건망증 증세를 보일 것이다. 이런 타입을 채용한다면 퇴사시키는 데 몇 년은 걸릴 것이다.

#10: 이반젤리스트(The Evangelist)

여러분이 어떤 환경에 처해 있더라도, 이반젤리스트는 지금 사용하고 있는 툴, 프로세스를 버리고 다른 것들로 대체해 업무 향상을 할 수 있다고 주장한다. 이반젤리스트는 실제로 이론가(The Theoretician)와 정반대이다. 이들은 솔직하고, 소프트웨어 개발에 관하여 많이 알지만 실질적으로 프로그래밍 작업은 거의 하지 않는다.

이들은 자신이 프로젝트 매니저나 부서장이라고 마음속으로 생각하고 있으나 지식이나 프로젝트 경험은 부족하다. 따라서 이들은 순수하게 경영자 역할을 할 수 있으므로 다른 사람들은 이들이 변혁을 시도하는 것을 참을 필요가 있다. @


--------------------------

퍼오긴 했는데..
이렇게 프로그래머를 나누는건 뭔가 이상한데?
나조차도 도대체 어디에 포함되어있는 것인지 모르겠단 말씀;;

이런 잣대로 모든 프로그래머를 규정지으려 하지 말 것이다!!


[ 출처 : http://blog.naver.com/oyukihana?Redirect=Log&logNo=60040277323 ]
Posted by 열라착한앙마

댓글을 달아 주세요

  1. 2008.01.24 09:06  댓글주소  수정/삭제  댓글쓰기

    닌자가 제일 좋은 건가?

  2. 2008.01.31 15:27  댓글주소  수정/삭제  댓글쓰기

    이반젤리스트?

2007.08.14 01:27
--- 반대 글 (http://youngrok.com/moin.cgi/%EC%8A%A4%ED%94%84%EB%A7%81%EB%85%B8%ED%8A%B8_%EA%B8%B0%EC%88%A0%EB%B3%B4%EA%B3%A0%EC%84%9C)

Subversion 아직 CVS를 쓰고 있다면 Subversion으로 옮겨 타지 말라. Subversion이 CVS보다 나은 점은 없다. 같은 개발진이 만들었다면서, 더 낫게 만들려고 했다면서 왜 이 모양인지. 가장 심각한 문제는 툴의 완성도가 낮다는 것이다. 이클립스에서 편리하게 쓸 수 있는 CVS에 비해 Subversion을 이클립스에서 쓰려면 대단한 인내심이 필요할 것이다. 버그가 너무 많다. 커밋이 잘 안되는 경우는 부지 기수고 merge도 잘 안되고 삭제나 이동도 일반적인 기대와 다르게 동작한다. subclipse는 정말 후졌고 subversive는 그나마 조금 쓸만하지만 여전히 CVS 플러그인에 비하면 너무 부족하다. 더 심각한 문제는 커맨드 라인에서 써도 버그가 발생한다는 것이다. 많은 파일과 디렉토리를 한 번에 커밋하면 락이 걸려서 안되기도 하고 엄청나게 느린 속도로 되는 경우도 있다. 버 그가 좀 있어도 기능이 더 좋다면 이해해 줄 수도 있다. 그러나 실제로 기능을 체감하는 것은 도구를 통해서인데 실질적으로 이클립스의 CVS 플러그인보다 나은 클라이언트를 갖지 못한 Subversion은 기능적으로 더 떨어진다고도 할 수 있다. 그리고 Subversion이 내세우는 장점인 changeset 단위의 revision number도 장점보다는 단점인 것 같다. 실제로 commit은 파일 단위로 일어나는 경우가 훨씬 더 많다. 한 번 생각해보라. commit하는 단위가 하나의 의미적 작업 단위와 일치하는지를. 두 개 이상의 작업 단위를 한 번에 commit하는 경우도 있고 파일에 따라 다른 commit log를 남겨야 해서 한 작업 단위를 여러 번에 나눠서 commit하는 경우도 많을 것이다. 이런 상황에서 changeset 단위 rollback이 큰 의미가 있는 것은 아니다. 어차피 CVS도 시간과 태그로 changeset 단위와 비슷한 개념을 활용할 수 있기 때문에 파일별 revision이 더 나은 것 같다. changeset 때문에 한 저장소에 여러 프로젝트를 관리하기 어렵다는 것도 문제다. revision이 공유되기 때문에 다른 프로젝트의 변경 내용 때문에 내 프로젝트의 revision이 올라가는 현상이 생기는 것이다. 이것 때문에 내 프로젝트의 이전 버전을 찾는데 고생할 때도 있고 export하거나 할 때도 revision이 너무 많아서 오래 걸리는 문제가 있다. 태깅도 좀 문제가 있다. subversion 태깅은 단순 copy라서 더 쉽다고 하는데 그래서 오히려 더 오래 걸리고 무거운 동작이 되버려서 잘 활용 안하는 경향이 있다. 물론 changeset 개념이 있기 때문에 반대로 태깅이 별로 필요 없기도 하지만. CVS는 오랫동안 많은 사람들이 써왔고 몇 가지 부족함이 있긴 하지만 그 부족함은 대부분 툴로 커버할 수 있다. 그리고 거의 모든 배포판에 기본으로 설치된다. 별다른 이유가 없다면 그냥 CVS 쓰기를 권한다. ClearCase 등 상용 SCM도 좋은 기능을 제공하긴 하지만 실제 사용할 때 CVS보다 월등히 나은 점을 발견하기는 쉽지 않을 것이다. 단순 기능 목록에 현혹되지 말고 자신이 실제로 사용하는 기능에 초점을 맞춰서 도구를 선택해야 한다.



--- 찬성 글(http://kldp.org/node/81558)

cvs vs. subversion 새 글 Submitted by 익명 사용자 (미확인) on 수, 2007/06/20 - 11:34am. 제가 있는 회사에서 옛날에는 CVS를 이용해서 개발을 하다가 2년쯤 전부터 subversion으로 바꿔서 개발하고 있습니다. 도끼로 나무하다가 전기톱 들고 하는 기분입니다. 정말 강력하다, 아니 그보다는, 그냥 version control system이라면 기본적으로 제공해야 하는 기능이 이런 건데 우리가 그동안 모르고 있었구나, 그런 기분입니다. 특별히 버그가 문제가 된 적은 없습니다. (솔직히 버그가 있다고 전기톱 버리고 도끼 쓰시겠습니까?) CVS는 이력을 파일 단위로 관리하고, subversion은 repository 전체 단위로 관리합니다. 그래서 "언제부터 언제 사이에 무슨 일이 있었나" 같은 걸 subversion은 아주 쉽게 알아볼 수 있지만 CVS는 어렵습니다. Branch를 나눠서 작업하는 것도 CVS에서는 눈물나는 일이지만 subversion은 큰 문제없이 가능합니다. (사실 요즘 나오는 다른 툴만큼 branch를 멋지게 지원하지는 않습니다. 이런 기능은 arch, git, bazaar 등등에선 때깔나게 지원한다고 하는데 써본 적이 없어서...) CVS는 atomic commit을 지원 안하기 때문에 빌드를 자동화하는 게 곤란합니다. "다른 사람이 커밋을 반쯤 하는 도중에 빌드를 하려고 소스를 받아서 빌드가 깨지는 상황"이 이론적으로 언제든지 발생할 수 있습니다. 기타 등등 subversion의 장점이 한두 가지가 아닙니다. » svn에 대한 의견이 새 글 Submitted by 김성진 on 수, 2007/06/20 - 10:47am. svn에 대한 의견이 이렇다니 의외입니다. 저의 경우 회사에서 CVS를 약 5년간 쓰다가 작년에 SVN으로 바꿨습니다. code commit, revision 관리, 추적, simple한 개념 등등에 있어서 cvs보다 낫다고 저는 평가를 했습니다. 버그의 경우도 심각한 경우를 발견하지 못했는데, 사용 domain에 차이가 있어서 그런 것도 있겠네요. svn이 cvs보다 나은 결정적인 부분은 branch관리나 tag 만들 때 입니다. 단지 revision을 복사하면 되는 것이지, cvs처럼 모든 소스코드에 대해서 tag를 달기위해 몇십분동안 repository를 뒤지는 경우는 없거든요. 소스코드의 양이 몇백메가가 되다 보니..이런 문제가 cvs에선 쉽게 해결이 안되더군요. 환경의 차이라고 생각됩니다. 혹시나 윗 들을 읽고, svn에 대해서 선입견을 가지시는 분들이 계실까 올리는 글입니다. 그리고, 저흰 별도의 툴은 거의 사용하지 않고, 대부분 command line에서 작업합니다.

[ 출처 : http://eenn.tistory.com/48 ]

--------------------------------------------------------------

CVS만 아주 약간의 기능을 사용해봤고..
SVN은 사용해본적이 없다..

SVN이 CVS를 대체하기 위해 나왔다고 들었는데..
실제로는 말들이 많은가보다..

뭐.. 위의 글은 참고만 하고~
나중에 SVN에 대해서 내가 사용해보고 그때 판단하도록 하자..
아직은 CVS의 기능조차 제대로 사용하고 있지 못하다고 난...

Posted by 열라착한앙마

댓글을 달아 주세요

  1. 2007.08.17 14:16  댓글주소  수정/삭제  댓글쓰기

    글쿤하

  2. BlogIcon x rated screensaver 2008.03.13 05:54  댓글주소  수정/삭제  댓글쓰기

    이 위치는 유익한뿐 아니라 재미있는다!

2007.08.02 10:51
최근 기자가 속한 카네기멜론 대학과 마이크로소프트(MS)가 새로운 협력 사업을 발표했다. 협력의 구체적 내용은 MS가 150만달러(약 14억여원)를 지원해 ‘컴퓨터 기반의 생각(Computational Thinking)을 연구하는 MS 카네기멜론 센터’를 세운다는 것이다.

일단 MS 같은 회사가 ‘컴퓨터 기반의 생각’이라는, 쉽게 머릿속에 들어오지도 않는 분야의 연구를 지원한다는 사실에 놀랐다. MS가 보도자료에서 밝혔듯 이번 합작 연구소는 MS 산하의 MS 리서치가 대학과 특정 분야 연구를 진행하기 위해 전 세계 8번째로 세운 것일 정도로 흔한 경우는 아니라고 한다. 그런데 연구소에서 추구하는 방향을 좀 더 들여다보니 놀라움은 더욱 커져만 갔다.

카네기멜론 컴퓨터공학 대학 학장인 자네트 윙 박사에 따르면 ‘컴퓨터 기반의 생각’이란 생물학·천문학·경제학을 비롯한 모든 학문 분야와 심지어 일상 생활에서도 컴퓨터의 능력을 활용해 문제를 해결하고 원하는 결과를 얻어내려는 것이다.

다르게 표현하자면 컴퓨터공학을 컴퓨터공학과의 테두리 안에만 가두지 않고 다양한 분야 학문과 연계해서 사회적 문제를 함께 해결해 나가자는 얘기다.

뒤통수를 한 대 맞은 기분이다. ‘공돌이’라는 자조적 표현이 난무하고 포스텍 수석 졸업자가 서울대 의대로 편입하는 우리의 현실을 빗대어 보면 컴퓨터공학을 중심으로 타 학문을 엮어나가려는 카네기멜론 대학의 시도와 이에 호응해 공동 연구소를 설립한 MS의 결정은 문자 그대로 ‘남의 나라 얘기’다.

그러나 부러워만 하기 보다는 카네기멜론과 MS의 협력이 갑자기 막연하게 이루어진 것이 아니라는 사실에 주목해야 한다. 카네기멜론 대학은 산업계에서 경험을 쌓은 사람이 교수로 오거나 그 반대의 경우가 매우 활발하다. 이번 협력 사업을 주도한 MS 리서치의 릭 라시드 부사장은 카네기멜론 대학 교수 출신이며 지난해 문을 연 구글 피츠버그 연구소의 소장 역시 이 대학 교수다. 산업의 생리를 잘 아는 사람들이 대학을 이끌고 있으니 기업체도 그들을 믿고 지원하는 것이다.

반면 우리는 서울대 산업공학과 이면우 교수의 ‘이공계가 아니라 이이계’라는 말처럼 이론의 틀 안에만 머물고 있는 것이 아닌가 싶다. 이공계 위기 타파는 ‘대통령 과학장학생 제도’ 같은 번지르르한 정부 지원만으로는 해결되지 않는다.

[ 출처 : http://www.etnews.co.kr/news/detail.html?id=200704010013 ]

--------------------------------------------------------------------------------

음음... 맞는말이다..

학교에서 배우는 지식만으로는 사회에서 통하지 않는다..
뭔가... 실용적인 학문을 추구해야할 필요가 느껴진다..
우리나라의 이공계의 현실은.. 암울하기만 하구나..
Posted by 열라착한앙마

댓글을 달아 주세요

  1. BlogIcon bare ass paddling 2008.03.13 06:04  댓글주소  수정/삭제  댓글쓰기

    친구는 너의 위치의 현재 팬이 되었다!

2007.04.15 19:36

2007년 4월 13일 쇠의날 늦은 7시 역사적인 날로 기록될지도 모르는 날.. ㅋㅋ
야그의 공개발표회에 참석하게 되었다..


어쩌면 우리는 역사적인 날의 주인공으로 그자리에 참석했을지도 모른다는
이현봉님의 의미심장한 말씀의 인용을 시작으로 아주 간단한 후기를 작성해본다..

참고로.. 카메라 안가져가서 사진은 없다.. ㅡㅡ;;
(나름 사진찍기를 취미생활로 하는데 카메라가 저멀리.. 집에 있는 관계로..
집에는 1주일에 하루정도밖에 안가서뤼 ㅡㅡ;; 아흠 게으른 찍사;;;)


처음은 이현봉님의 Yag의 개발이 시작하게된 배경에 대해서 들었다..

3년여에 걸친 연구와 개발 그 노력이 왜 필요했는지..
뭐.. 그 내용을 요약하기란 너무도 어렵지만..

결국 웹상에 사용자들을 보이도록하여 편의성을 높이고자 함이라..
사용자를 보이도록 하면 온라인상에서도 오프라인에서의 행동과 많이 비슷해진다..
간단한 예로는 사람들이 모여서 무엇인가 보고있다면 궁금함에 나도 근처를 기웃거리게 된다..
야그를 사용하게 되면 이러한 점을 오프라인상에서도 보여줄수있다..(물론 많은 보완이 필요하겠지만..)
나 이외의 사람들에 대해서 볼수있고 무엇을 보고있는지 알수있으며 접근 또한 쉽다..

또 이것은 구글이나 다른 거대 회사들이 하지 못하기 때문에(기술력이 없는것이 아님..)
마이엔진(야그를 개발한 회사) 에서 개발한다는 뭐.. 그런얘기이다..
보충설명한다면..
사실 현재 최고의 검색기술이라 할 수 있는 구글 검색같은 경우는 현재의 이슈가 되는 점을 검색할 수는 없다..
왜냐하면 구글의 검색은 사용자들이 그동안 많이 사용하고(링크등) 본 페이지의 랭크를 높이 평가하는데
새로나온 이슈가 그렇게는 표시될 수 없기 때문이다..
즉, 평소에 정확성 높은 글을 검색하기는 쉬울지 몰라도 현재의 이슈에 대해서 검색하기는 힘들다는 단점이 있다...
이러한 것들을 자신과 같은 회사들을 할수 있다.. 뭐 그런얘기가 되겠다..
이해안되면 패스하자.. 쩝;; (글을 못쓰는 내가 죄인이라 ㅜ.ㅜ)


다음으로는 말로만 듣고 글로만 만나던 김중태님..

야그의 기능적 특성과 이로인한 효과등에 대한 설명이었다..
(원래는 발표 ppt가 있었지만 시간관계상..)

내용을 요약하기는 힘들고 느낌을 쭉 정리해보면..

먼저 웹의 발전 방향은..
지금의 시맨틱웹에서 오프라인의 개념이 추가된 쉬운웹, 밝은웹으로 발전한다..
즉, 온라인도 오프라인과 같은 방식으로 행동하여 학습이 따로 필요치 않도록 하는 방향으로 발전한다는 의미이다.. (비교자료는 panic.com .VS. Yes24, 알라딘 등)

1. 인터넷 + 하이퍼텍스트  ==>  Web
2. Web + GUI  ==>  Web의 대중성 증대
3. Web + GUI + Infrastructure  ==> Web 2.0, SemanticWeb..
4. Web + GUI + Infra + Offline  ==> 쉬운웹, 밝은웹


구글, 유투브의 성공 기반은
분산의 개념을 적용한 것이다.
다른 시각에서 보면 이것은 사용자의 오프라인상의 행동패턴을 온라인에 적용한 것이라는 점이다..
구글은 현재 광고를 분산시켰으며(구글 애드센스) 유투브는 동영상을 퍼가도록 하여 동영상 컨텐츠를 분산시켰다. 즉, 자신들의 페이지에 직접오지 않아도 되도록 한것이며, 이것은 오프라인상의 개념으로 본다면 당연한 것이다.
예를들면, 오프라인에서는 자신이 구매한 음반에 대해서는
자신의 집에서 가져가서 필요할 때 꺼내서 듣는다는 것이 당연하다..
근데 왜 온라인상에서는 자신이 구매한 음반을 그쪽 사이트에 가서 듣는것인가..?
이와같이 필요하면 가져가서 자신이 편한곳에 두어서 듣고 싶을때 꺼내서 들어라는 개념이 바로 유투브의 개념이라는 것이다.

또 panic.com과 같이 사용자가 구매하는 과정이 오프라인과 비슷하도록 하여 사용자가 학습이 필요하지 않도록 하여야 하는데 왜 지금의 페이지들은 불편하기 짝이 없는가..

무슨소리냐고?
구매하는 페이지는 너무 복잡해서 어떻게해야 구매를 해야할지 모르며, 구매버튼을 찾기도 힘들고
또 내가 담아둔 물건들은 어떤것이 있는지 확인하기 힘들고
(장바구니 페이지로 이동해야 확인이 가능하고 구쇼핑하면서는 확인 불가;;)
결국 상품의 구매를 위해서는 사용자가 해당 페이지에 익숙해져야하는 일련의 학습과정이 필요하다는 것
이것이 결국 사용자의 편의성을 저해하는 요소라는 것이다.

결국 웹은 사용자의 편의를 위해서라도 쉬운웹으로 발전할 것이라는 것이다.
즉, 오프라인의 행동을 온라인에서도 가능하도록 하게 해야한다는 것이겠다...
그러한 과정중의 하나로 온라인상에서 사용자의 존재를 나타나게 해주는 것은 여러가지로 큰 의미를 가진다... 이것은 오프라인과 비슷한 환경을 조성해주는 기초적인 과정이기 때문이다.
사용자가 보임으로 인해서 어떠한 행동이나 어디에 있는지 알수 있게되며 이로 인해서 사용자들간의 교류가 가능하다.
머.. 여기서도 대충 예를 들면..(모두다~ 발표회에서 들은 예이지요 ㅎㅎ;;)
쇼핑몰에서 관리자는 현재 접속한 사용자들이 무엇을 보고 있는지 어느 페이지에 있는지를 알수 있게되며
야그와 같은 프로그램에 있는 메신저를 통해서 고객과 대화가 가능하다...
따라서 고객과의 타협도 가능하며 대화를 통해 무엇이 문제이고 무엇이 필요한지를 파악할 수도 있게 되겠다.. (이는 오프라인상의 모습과 비슷함을 알수있지?)
또, 앞에서 말한 것처럼 사람들이 무언가 비슷한 주제를 가지고 얘기하고 있다면 그것을 사회적으로 이슈가 되고 있다는 것을 파악할수도있고(구글이 못하는 점을 보완할 수 있다는 점을 강조하더라.. 뭐.. 지금으로써는 좀 힘들수도 있지만, 어느정도 보완하고 보급만 잘된다면 가능한 얘기겠다..) 또, 그것에 대해서 물어볼수도 있고.. 마치 오프라인상에서 모여있는 사람들의 틈에 껴서 질문하고 정보를 얻고 대화하는 과정과 비슷하다고 할수 있겠다..

이런것 이외에도 생각해보면 많은 점들이 달라질수 있다는 것에 나름대로 동의하며 한마디로 정리해보면
야그는 결국 웹에 사용자의 Visuality를 표현한 방법인 것이다..(이것의 효과는 위에서 간단히 얘기했고..)

아직 보완해야할 것은 많은 것 같다..
가장 중요한 문제는 이것을 사람들에게 배포해야한다는 점.. 많은 사람이 사용하지 않는다면 이것은 실패다!!
따라서 배포가 어떻게든 쉽게 되어야 한다..
또, 현재의 방식대로라면 자신들의 웹페이지 일부를 야그를 위해 내놓아야하는데..
과연 사용자들이 그 자리를 내 놓을수 있을지도 문제이다

다음은 같이간 댕이가 제시한
만약 야그와 같은 프로그램이 또 나온다면 문제가 될 소지가 있다..
그 프로그램들과 호환성이 없다면 결국 이것도 문제이기 때문이다..
그렇다면 이들을 인정고 서로 호환이 가능하도록 미리 개발의 표준안을 제시해야하는 것은 아닌가..


아무튼 이번 발표회를 참석하게 되어서
나름대로 얻은것이 많다..
가장 큰 깨달음은 오프라인이라는 개념이다!!
현재 웹을 공부하는 사람으로써 아직 난 배워야 할 것이 너무도 많다는 것을 알았다..
뒷풀이를 참석하지 못해서 조금더 가깝게(?) 지식을 공유하지 못한 아쉬움이 좀 남는다.. ㅋ
(음.. 시간이 좀;; 다음엔 한 8시경에 뒷풀이가 가능했으면 좋으련만..머.. 핑계입니다 ㅡㅡ;;)
어짜피 약속도 있었기때문에 ㅋㅋ

자세한 프로그램에 대한 설명은 김중태문화원의 글을 참고하여 주시고
야그 홈페이지를 참고해주셔도 좋을 것 같습니다...^^


Follow Your Heart, Stay Foolish!!

Posted by 열라착한앙마

댓글을 달아 주세요

  1. BlogIcon 2007.04.16 10:47 신고  댓글주소  수정/삭제  댓글쓰기

    현재의 이슈에 대해서 검색은 많이 듣던 얘기군... ㅎㅎ
    세미나를 안들어서 그런지 쉬운웹이랑 야그와의 상관관계는 잘모르겠구만..ㅋ

    • BlogIcon 열라착한앙마 2007.04.16 14:16 신고  댓글주소  수정/삭제

      아흠..;;
      나의 부족한 문장실력으로는
      그 2시간을 글로 표현하기가 힘드네 ㅋㅋ
      뭐.. 나중에 기회가 된다면 조금더 정리하던지
      얘기를 해주던지 할께^^
      내가 이렇다우~ ㅋㅋ

2007.04.10 02:16
Head Rush Ajax책의 "자주 묻는 질문중"..

Q: <div>의 텍스트를 읽고 쓰는 더 쉬운 방법은 없나요?
"innerHTML" 이라는 속성을 쓰면 <div>안에 HTML을 집어 넣을 수 있다고 들었는데요. 그렇게 하면 안되나요?

A: innerHTML 속성은 엘리먼트의 내용을 읽고 쓰는데 좋은 방법이 아니예요.
그건 DOM 명세가 아니고 W3C에서 더 이상 쓰지 말라고 한거예요.
앞으로 새로 나오는 브라우저는 지원하지 않을거에요. 게다가 몇몇 브라우저는 지금도 그걸 지원하지 않아요.

DOM은 브라우저만 있으면 언제든, 어떤 플랫폼에서든 사용할 수 있다.

** innerHTML 관련 문서 **
innerHTML 과 createElement의 성능비교
DOM과 innerHTML 방법에 대한 비교 분석

[ 출처 : http://flyburi.com/132?TSSESSION=44c4dc4c26d6dcf9790d076c306d29fa ]

------------------

먼저 버리님의 블로그 글을 허락없이 완전히 퍼온것에 대한 사과를 드립니다
(엮인글은 걸었어요~~^^;;) 
(---> 엮인글을 보낼려고 했습니다만;; 무슨이유인지 안된다고 나오는;; 차후 다시 시도해보겠습니다..)
사용자 삽입 이미지


Head Rush Ajax 책을 읽던 중
innerHTML에 대한 얘기가 위에서 처럼 나오길래 자료를 찾아봤다..

innerHTML과 DOM이라..

난 아무래도 DOM쪽을 그나마 관심있게 봤었고..
더군다나 innerHTML이 W3C에서 지양하라는 방침이 있던터라..
당연 DOM이 더 좋은 성능을 가질줄 알았지만;;
몇가지 시각적인 벤치마크의 결과는 나를 놀라게 했다.. +_+
==> http://www.gloo.ru/blogs/gloom.dhtml_javascript_benchmark._l_en.wiki.aspx
(사실 동작원리를 제대로 이해하지 못한 나로써는 놀랄수밖에...)

표준은 아니라고 하니 지양해야하긴 하겠지만...
성능의 차이가 저리 난다면 좀 심각하게 고려해봐야 하는거 아녀??
일단 왜 innerHTML이 문제가 있는지 좀더 공부해봐야겠다..
(공부해야 할 것은 왜이리도 많은지 원~ 허헛;; 끝도 없는 배움의 길이로군;;)
Posted by 열라착한앙마

댓글을 달아 주세요

  1. BlogIcon 버리 2007.04.10 10:00  댓글주소  수정/삭제  댓글쓰기

    ^^ 방문해주셔서 감사해요~^^
    그냥 말없이 가시는 분도 많으실텐데..
    글 하나하나에 정성이 담겨있는 모습이 엿보여요..^^
    앞으로 자주 들를게요~

    • BlogIcon 열라착한앙마 2007.04.10 12:31 신고  댓글주소  수정/삭제

      아~ 방문해주셔서 감사합니다^^

      버리님 덕분에 좋은정보를 얻었는데
      인사를 안드릴수없죠^^

      제 블로그가 포스팅을 자주 안하고 내용도 잡담위주라
      자주 오셔서 보실것이 있을지;; ㅎㅎㅎ
      저도 버리님 블로그에 자주 들르겠습니다(^^)(__)(^^)

2007.04.09 20:42

김중태 문화원에서 알게된 야그(yag)


그렇지 않아도 우리 연구실 홈페이지를 시맨틱웹 기반의 홈페이지로 개편을 생각하던중에

로그인한 사람들과의 커뮤니티를 활성화하고 싶어서

웹 애플리케이션에서 제공하는 웹 메신저를 생각하고 있었는데..

하하핫~ 벌써 좋은 서비스, 프로그램은 개발이 다 되었구나~ ㅋ

(AJAX를 이용해서 개편도 하고, 연구실 공통 스케줄 관리 플그램 만들고, 가장 맘에 안드는 디자인도 수정하고, 여러가지 편의성이 좀 높은 서비스도 추가해야하고.. 어이쿠 할일이 많네 그려~ 허헛~)


뒤늦게 시맨틱웹에 대해서 공부하고 뒤쫓으려니 여기저기 뒤처지는 느낌이다..

인터넷 소프트웨어 연구실(I-soft Lab.)이라는 이름을 가진 학교 연구실에 있지만

도무지 인터넷에 대해서는 아는게 없는거 같다..

공부를 하면 할수록 뒤처지는 느낌이든다..OTL

이번에 13일 서울에서 야그 3.0의 공개 발표가 있다고 한다..

신청하면 될지는 모르겠지만 참석해서 선배님들의 고견을 들을수 있으면 좋겠다..

내가 가서 정보를 공유할만한 지식은 없지만 하나의 발판이 되는 자리가 되었으면 좋겠다는 생각이다..

앞으로 웹의 발전 방향에 대해서도 좀 배우고~ 크큭~

--------------------------------------------------------------------------------------------

[야그3.0의 주요 기능]
- 방문객이 보고 있는 문서를 보여주고, 방문객을 선택하면 해당 문서로 순간이동하기. 예를 들어 쇼핑몰 방문객이 어떤 상품을 보고 있는지 다 보이게 되며 해당 방문객이 보고 있는 상품이 궁금하면 딸깍 한 번으로 바로 이동할 수 있습니다. 신문사 사이트에 적용한다면 방문객이 함께 보고 있는 뉴스에 대해 이야기 나누거나 다른 사람이 보는 뉴스 페이지로 순간이동하는 시대가 펼쳐집니다.
- 익명인 상태에서 대화방, 쪽지 나누기
- 줄글(LineMemo), 추천, Top10 기능 등
- 이 모든 기능을 위해 사용자 PC에 설치하는 것은 하나도 없습니다.
- 야그에 대한 좀더 자세한 정보는 4월 11일 이후 http://www.yagne.com 을 통해 제공합니다.


** 김중태 문화원 : http://www.dal.co.kr/
** 야그 블로그 : http://www.yagne.com

[ 참조 사이트 : http://www.yagne.com/yag/blog/entry/yag30open ]

Posted by 열라착한앙마

댓글을 달아 주세요

  1. BlogIcon 2007.04.10 10:56 신고  댓글주소  수정/삭제  댓글쓰기

    이름만 들어본듯..
    연구실 홈페이지에 야그 적용하는겨??

    그러고보니 스킨바꼈네..ㅎㅎ

    • BlogIcon 열라착한앙마 2007.04.10 12:28 신고  댓글주소  수정/삭제

      아~ 아니 야그를 적용하는건 아니고~
      만약 된다면 좋겠지^^
      편하게 좋은 기능도 사용할수도 있고~

      스킨이 새로운게 좀 나온거 같길래 분위기 전환으로 ㅋ