단어 리스트를 기부하고 싶습니다만..
Jiho Han
이렇게 멋진 프로젝트가 있다는 걸 얼마 전에야 알았습니다. 오픈 소스 환경에서 한국어 철자 검사라니 예전에는 그저 꿈만 같이
생각했던 일이었는데 실제로 쓸 수 있게 되었다니 많이 감동했습니다.
워낙 멋진 프로젝트인지라 개인적으로 뭔가 도움될 일이 없나 싶었는데, 보다 보니 몇달 전에 구글에서 크롬과 관련해서
hunspell 에 신규 단어들을 추가한 일이
있더군요.(http://blog.chromium.org/2009/02/spell-check-dictionary-improvements.html)
똑같은 일이 한국어에 대해서도 가능하지 않을까 싶어서 좀 알아봤습니다. 어떻게 여차저차해서 저 작업을 수행했던 구글
translation 팀으로 부터 자주 출현하는 빈도 순으로 정리된 한국어 단어 몇십만개를 가진 리스트를 구할 수 있었습니다.
대략 살펴보니 상위 단어 10만개 정도만 보면 사전에 추가할 만한 단어들을 추려낼 수 있겠더군요.
몇달 전의 선례도 있고, 구글의 기본 정책으로 보아 제가 이 단어 리스트를 이 프로젝트에 라이센스 문제 없이 기부하는 것이
가능해 보입니다. 그리고 그렇게 하려면 사내에서 이와 관련한 절차를 알아보고 적법한 승인을 받아야만 합니다. 이를 진행해 보는
것도 괜찮겠다 싶긴 합니다만, 그 전에 이 것이 과연 가치가 있는 일인지 확실히 확인하고자 메일 드립니다.
일단, 문제는 구글이 사용하는 번역 기술이 형태소 분석이나 구문 분석을 사용하는 것이 아니라 통계적 접근법이라는 점입니다.
결국 여기에 기반해 만들어진 이 단어 리스트도 전문가가 오랜 시간 고생해서 만든 것이 아니라 기계가 통계적으로 수집해 만들어
낸 것이라 분명한 문제점들이 몇개 있습니다.
- 품사 정보가 전혀 없습니다. 명사인지 동사인지 형용사인지 다시 사람이 구분해줘야만 합니다.
- 한국어 특성을 고려하지 않고 명사 + 조사 나 동사/형용사 + 어미 를 한 단어로 취급하는 경우가 많습니다.
- 철자법과 상관없이 자주 쓰이는 단어라면 다 가지고 있습니다. ex) 자장면, 짜장면, 찌게, 찌개..
- 사람 이름 같은 고유 명사가 많이 들어 있습니다. ex) 김태희, 전지현, 김연아..
결국 다시 사람이 몇만개의 단어들을 일일히 보면서 선택과 분류를 다 해줄 수 밖에 없습니다. 메일링 리스트를 보다 보니 다음
커뮤니케이션의 윤석찬님께서도 예전에 거의 동일한 형태의 지원을 말씀하셨던 거 같던데, 아마 이와 비슷한 문제로 진행이 더 많이
되지 못한 게 아닌가 싶더군요. 아니면 이미 뭔가 작업이 진행 중이신데 제가 모르고 있을 수도 있겠다 싶었습니다.
어떻게들 생각하시는 지요? 이 단어 리스트를 기부하도록 하면 프로젝트에 도움이 될까요?
Changwoo Ryu
네 따로 진행되는 작업은 없습니다.
크롬 개발 과정에서 새로 추가했다는 단어 목록도 단순히 인터넷에서 많이 등
장하는 단어를 빈도 순서대로 줄을 세워서 코딩만 해서 추가한 건 아닐 것이
고 수동 확인이 들어갔을 겁니다. hunspell 사전은 어떤 언어이든 (교착어가
아니라면 덜 복잡하겠지만) 단어마다 접사 정보를 기입하게 되어 있고, 올바
르지 않은 단어이거나 파생된 형태인데도 인터넷에서 널리 발견되는 말은 언
어에 관계없이 다 있습니다. 추가한 단어가 1000개라고 쓰여 있으니 그렇게
많은 것도 아니고요.
현재 구글 번역의 품질만 봐도 웹 문서만 갖고 하는 100% 통계적인 방법은 인
터넷의 한글 문서의 수로 볼 때 가능해 보이지 않습니다. 자동화된 방법을 사
용하려면 사람이 확인할 수 있는 후보를 어느 정도까지 줄일 수 있느냐 궁리
해 볼 수 있을 겁니다. 단어 후보를 hunspell -l 명령으로 한번 거르면 없거
나 틀린 단어 목록이 나올 것이고, 이 중에서 사전에 있는 말을 확인하면 명
사 부사는 대략 나오고, 동사 형용사의 경우에는.. 형태소 분석을?
--
Changwoo Ryu <ryu.ch...@gmail.com>
JEONG, MunShik
도움이 될 것 같습니다.
한 100여개 단어를 galwki.appspot.com을 통해서 추가해 보았는데
처음 추가해보자라고 마음을 먹었을 때
가장 큰 걸림돌이 "어떻게 galkwi에 없지만 자주 쓰이는 단어를 알아낼까" 였습니다.
지금은 직지프로젝트에서 글 하나를 sample.txt로 저장하고
cat sample.txt | ./utils/syl2jamo.py | hunspell -d ko | grep '^&'
라고 실행한 결과에서
한 단어씩 사전에서 조회해 본 다음 galkwi에 입력하고 있는데요.
만약에 빈도수로 정렬된 목록을 기부해주시면
상위 1만 단어중에 galkwi에 없는 단어를 골라서
한 단어씩 사전에서 조회해 본 다음 galkwi에 입력을... :-)
Jiho Han
해보는 건 처음이라 시간이 얼마나 걸릴런지는 모르겠네요. 승인이 떨어지는 대로 다시 메일 드리도록 하겠습니다.
아무래도 사람 눈과 손을 안거치고 그 단어 리스트에서 얼마나 쓸만한 단어들을 추려내고 품사별로 분류할 수 있느냐가 관건이겠군요.
"사전에 있는 말을 확인하면" 이란 말씀은 현재 웹 상에 존재하는 각종 사전 서비스에 각 단어들을 던져봐서 그 결과를 확인하자는 말씀이신거죠?
구글에도 아마 국어 사전 서비스가 있던 걸로 기억하는데 그쪽 팀에 이렇게 사용하는 것이 저작권이나 다른 문제는 없는 지 한번 물어봐야 겠군요.
감사합니다.
2009/5/10 Changwoo Ryu <ryu.ch...@gmail.com>:
Jiho Han
네. 그렇게 하면 될 것 같습니다. :)
지원자분 몇분이 단어 리스트를 1만개나 5천개 정도의 단위로 쪼개서 확인 및 입력 작업을 해주시면 많은 단어들을 금방 입력할
수 있지 않을까 싶네요.
다만 그 전에 뭔가 미리 기계로 불필요한 단어들을 어느 정도 걸러내거나, 품사 태깅을 할 수 있는 한도에서는 해주는 방법이
있으면 좋을 것 같습니다.
뭔가 쓸만한 좋은 방법이 없을까요? ^^
JiHui Choi
단순히 단어량이 많아진다고 좋아지는 것은 아니지만, 어떤 룰을 찾아내거나 다른 뱡향으로 발전시키려면
기본적인 자료로서의 단어량이 확보되어야 할텐데, 그 점에서 굉장히 좋은 도움이 될 것 같습니다.
프로그램적으로는 도와드릴 것이 없지만, 노가다 -_-; 라면 일단 손하나 얹어보겠습니다. :)
--
Regards,
JiHui Choi
----------------------------------------------------
http://Mr-Dust.pe.kr
http://GIMP.kr, http://OpenOffice.or.kr, http://Ubuntu.or.kr
Changwoo Ryu
> 별도로 진행되는 작업이 없으시다니 이 한국어 단어 리스트 기부 건을 계속 추진해보도록 하겠습니다. 저도 회사에서 이런 걸
> 해보는 건 처음이라 시간이 얼마나 걸릴런지는 모르겠네요. 승인이 떨어지는 대로 다시 메일 드리도록 하겠습니다.
>
> 아무래도 사람 눈과 손을 안거치고 그 단어 리스트에서 얼마나 쓸만한 단어들을 추려내고 품사별로 분류할 수 있느냐가 관건이겠군요.
> "사전에 있는 말을 확인하면" 이란 말씀은 현재 웹 상에 존재하는 각종 사전 서비스에 각 단어들을 던져봐서 그 결과를 확인하자는 말씀이신거죠?
> 구글에도 아마 국어 사전 서비스가 있던 걸로 기억하는데 그쪽 팀에 이렇게 사용하는 것이 저작권이나 다른 문제는 없는 지 한번 물어봐야 겠군요.
네. 어떤 단어가 있을 때 온라인 사전 서비스에 그 단어를 던져서 그
단어가 존재하는지 여부를 자동으로 확인하는 행위가 되는데요. 이럴 때
그 사전 서비스의 저작권이 들어가는지 저도 모르겠군요.
생각해 보니 좀 꺼림칙하네요. 사전 CP들 때문에 포털들이 open API도
못 만드는 걸 보면 일단 피해가야 하지 않나 싶군요.
구글 사전은 올바른 단어가 들어 있는 사전이 아니라 구글 번역 데이터를
이용한 한영사전으로 보이네요.
http://www.google.co.kr/dictionary?aq=f&langpair=ko|en&q=짜장면&hl=ko
--
Changwoo Ryu <ryu.ch...@gmail.com>
Jiho Han
> 네. 어떤 단어가 있을 때 온라인 사전 서비스에 그 단어를 던져서 그
> 단어가 존재하는지 여부를 자동으로 확인하는 행위가 되는데요. 이럴 때
> 그 사전 서비스의 저작권이 들어가는지 저도 모르겠군요.
>
> 생각해 보니 좀 꺼림칙하네요. 사전 CP들 때문에 포털들이 open API도
> 못 만드는 걸 보면 일단 피해가야 하지 않나 싶군요.
>
>
> 구글 사전은 올바른 단어가 들어 있는 사전이 아니라 구글 번역 데이터를
> 이용한 한영사전으로 보이네요.
>
> http://www.google.co.kr/dictionary?aq=f&langpair=ko|en&q=짜장면&hl=ko
실은 구글에도 국어 사전이 있기는 합니다. 다만...잘 눈에 안띄입니다. -_-;;
http://www.google.co.kr/dictionary?aq=f&langpair=ko%7Cko&q=%EC%A7%9C%EC%9E%A5%EB%A9%B4&hl=ko
아직 법적인 문제는 확인을 못해봤고 관련 엔지니어 분께 여쭤보기만 했습니다만..
아무래도 문제가 될 가능성이 커보이니, 누군가 오프라인 사전 프로그램을 가진 분이 계시면 '눈에 안뜨이게' 거기서 해보는게
어떻겠느냐는 의견을 조심스럽게 주셨습니다. :)
Calvin
Changwoo Ryu
> http://stardict.sourceforge.net/Dictionaries_ko.php
>
>
> 이건 어떤가요? 한국어 사전과 한영 사전을 쓰면 될 것 같아요.
>
>
> 라이센스를 보니깐 GPL 도 있네요.
앗, 절대 쓰지 마세요. GPL은 커녕 불법으로 추출된 사전입니다.
저 불법 사전들 때문에 stardict 개발자들은 계속 욕을 먹고 있는데
얼굴에 철판을 깔았는지 자국에서 (중국) 지재권 소송 가능성이
극히 낮아서인지 오히려 계속 불법 사전을 늘려 나가는 군요.
--
Changwoo Ryu <ryu.ch...@gmail.com>
Sung-Jin Hong
JiHui Choi
> http://stardict.sourceforge.net/Dictionaries_ko.php
> 이건 어떤가요? 한국어 사전과 한영 사전을 쓰면 될 것 같아요.
> 라이센스를 보니깐 GPL 도 있네요.
>
누군가 "이거 공개된 거 아니었어?" 라면서 GPL 로 올린 것 같습니다.
위험한 자료죠. 하지만 없으니 아쉬운대로 또 쓰게 되는..
redneval
>
> 네. 어떤 단어가 있을 때 온라인 사전 서비스에 그 단어를 던져서 그
> 단어가 존재하는지 여부를 자동으로 확인하는 행위가 되는데요. 이럴 때
> 그 사전 서비스의 저작권이 들어가는지 저도 모르겠군요.
>
> 생각해 보니 좀 꺼림칙하네요. 사전 CP들 때문에 포털들이 open API도
> 못 만드는 걸 보면 일단 피해가야 하지 않나 싶군요.
>
저작물로 저작권법의 보호를 받는 것은, `인간의 사상 또는 감정을 표현한 창작물'입니다. (저작권법 제2조 제1항)
그러므로 예를 들어서,
`짜장면이라는 단어가 맞춤법에 맞는지 틀리는지 여부' 그 자체는 저작권법의 보호를 받지 못합니다.
(물론 `자장면은 야채와 고기를 넣고 식용유와 함께 춘장을 넣어 볶은 양념을 밀가루를 반죽하여 늘려 만든 국수에 비벼먹는 한국
식 중화요리이다.'
이라는 문장이 있다면, 이런 `독창적'인 `표현'은 저작권법의 보호를 받습니다.)
그래서 2003년 이전에는 데이터베이스도 독창적인 내용이 없다면 보호를 받지 못했습니다.
하지만 2003년 저작권법 개정에 따라, 데이터베이스의 저작권 보호가 강화되었기 때문에
(일정요건을 갖춘) 데이터베이스를 그대로 복제하거나 비록 일부일지라도 부당하게 이용한다면 불법이 됩니다. (저작권법 제93조)
(참고로, 사전은 종이사전이든 전자적 형태의 사전이든간에, 데이터베이스에 해당됩니다.)
저작권법 제93조를 엄밀하게 적용하면, 사전을 이용해서 또 다른 데이터베이스를 만드는 것은 불법에 해당될 수 있습니다.
하지만 데이터베이스의 보호기간은 5년이므로 (저작권법 제 95조),
2003년 이전에 만들어진 사전은 데이터베이스로서 보호받지는 않습니다. (하지만 여전히 저작물로서 보호를 받습니다.)
그러므로 2003년 이전에 만들어진 오프라인 사전 프로그램이 있다면, 그걸 이용하면 되겠습니다.
-------------------------------------------------------
가입하고 눈팅만 하고 있었는데, 제가 도움이 될만한 부분이다 싶어서 적어봤습니다.
정확한 것은 법률가에 문의해야겠지만, 나름대로 열심히 찾아보고 내린 결론이므로 참조하시기 바랍니다.
이 문제가 해결되어 구글의 데이터를 기부받는다면 본 프로젝트에 큰 발전이 있을 것 같아서 매우 기대되네요. ^^
Changwoo Ryu
제가 여기에서 자주 언급한 이야기이고 README 파일에도 써 있는데요. 저는
그 논란의 여지마저 일으키고 싶지 않습니다.
이 저작권이 없다고 선언한다면 불법 사전들에 들어 있는 데이터를 코딩 몇
줄
해서 변환하면 되겠죠. 하지만 그 자연어처리 데이터베이스를 제한적인
라이선스에 고가에 판매하고 있는 게 사실입니다.
2009-05-12 (화), 03:29 -0700, redneval:
--
Changwoo Ryu <ryu.ch...@gmail.com>
redneval
> "과연 이게 저작권을 주장할 수 있는 독창적인 데이터인가"에 관한 이야기는
> 제가 여기에서 자주 언급한 이야기이고 README 파일에도 써 있는데요. 저는
> 그 논란의 여지마저 일으키고 싶지 않습니다.
>
> 이 저작권이 없다고 선언한다면 불법 사전들에 들어 있는 데이터를 코딩 몇
> 줄
> 해서 변환하면 되겠죠. 하지만 그 자연어처리 데이터베이스를 제한적인
> 라이선스에 고가에 판매하고 있는 게 사실입니다.
전후사정 자세히 설명하지 않고 무턱대고 저작권법이야기를 늘어놓은 점 죄송하게 생각합니다. ^^;
몇몇 부분에 오해가 있는 것 같아서 좀 더 자세히 적어놨으니
귀찮으시더라도 다음 글을 읽어주시면 감사하겠습니다.
--------------------
`저는 그 논란의 여지마저 일으키고 싶지 않습니다. '라고 하셨는데요.
그러면 예를 들어 이런 상황을 생각해보겠습니다.
누군가가 XXX 라는 단어를 추가하기 위해서
2009년판 AAA 사전에 들어있는지 확인하고, XXX 가 맞춤법에 맞는 단어라는 것을 확인하고는
spellcheck-ko 프로젝트에 새로운 XXX 단어를 추가했다고 가정해보겠습니다.
불행히도 이는 저작권 논란이 발생할 소지가 있습니다.
그러므로 논란의 여지를 완전히 없애기 위해서는
사전 협업 프로세스에 참여하는 모든 사람이 다른 어떠한 사전도 보지 않게 해야하는데,
이는 애초부터 불가능합니다.
게다가 편집가이드에 보면,
`표제어 등재 여부는 다른 사전에 들어 있느냐 여부, 널리 사용하고 있느냐 여부에 따라 판단한다.'
라고 되어있는데 다른 사전을 참조하게되는 것만으로도 저작권을 침해할 소지가 있습니다.
그러므로 엄밀히 말하자면, 편집가이드도 약간의 수정이 필요합니다.
그리고 다른 사전을 참조하는 것은 되고, 온라인 사전 서비스에 단어가 존재하는지 파악하는 것은 안된다는 논리는
저로서는 이해하기 어렵습니다.
저작권 문제가 발생하지 않는 데이터를 만드고자하는 뜻에는 저도 공감합니다. 당연히 그래야 하고요.
하지만 그렇게 하기 위해서는, 오히려 저작권법을 완벽히 이해하는 과정이 필요합니다.
모르고 있다가는 아무도 모르는 사이에 저작권법 위반을 할 수 있으니까요.
그리고 저작권 문제가 발생할 여지를 완전히 차단하고 싶으시다면
공개 협업 프로세스란 불가능하고, (공개된 프로젝트에서 리더가 모든 가능성을 통제하기란 불가능하기 때문입니다.)
다른 사전도 전혀 참조할 수 없습니다.
혹시라도 나중에 누군가가 이렇게 물어봤다고 가정해봅시다.
`맞춤법이 맞는지 여부는 어디서 확인하셨습니까? 저작권 문제가 없는지 궁금합니다.'
이런 질문이 들어왔을때 어떻게 대답해야할까요.
죄송한 말씀이지만 지금상태대로라면 제 생각에는 제대로 답변을 못할 것 같습니다.
그냥 `사전에서 확인했습니다.' 라거나
`제가 그냥 맞춤법에 맞는지 판단한 결과물입니다.' 라고 답변한다면,
오히려 저작권에 문제가 있는 것은 아닌지 의심의 여지가 생길 수 있습니다.
(맞춤법에 맞는지는 결국 `어딘가'에서는 확인을 해야하는데
어차피 어딘가에서 확인해야한다면 저작권법에 걸리지 않게 합법적으로 확인해야합니다.)
오히려 저작권법을 제대로 이해하여 `2003년 이전의 사전은 사용하기에 안전하다'라는 사실을 알고 있다면
다음과 같이 답변할 수 있습니다.
`모든 단어는 제가 2003년 이전의 사전을 통해서 최종 확인했기 때문에 저작권 문제는 없습니다.'
예를 들으셨던 `고가로 판매되는 자연어처리 데이터베이스'가 어떤 것인지는 모르겠습니다만
법률적으로 보호할 수 있는 방법은 데이터베이스로서의 저작권법 보호가 아니더라도
특허, 실용신안, 알고리즘의 저작권을 통해 보호할 수도 있고,
손쉬운 방법으로는 EULA를 통해서 복제를 금지할 수도 있습니다. (Changwoo님이 언급하신 바로 그 제한적인 라스선스를 통
해서 말입니다.)
그러므로 `자연어처리 데이터베이스'는 제가 납득할만한 예시가 아닙니다.
그리고 혹시나 모르실까봐 적어보면 (알고 계신다면 죄송합니다. ^^;)
http://kldp.org/node/80530 에 보시면
(5년이 지난) 창작성이 없는 데이터베이스는 저작권 보호를 받을 수 없기 때문에
국립국어원 사전 표제어 목록의 데이터를 코딩 몇 줄로 변환해서
오픈소스인 libhangul 의 한자목록을 개선하는데 사용되었습니다.
Changwoo Ryu 님의 반응이 너무 지나치신 것은 아닌가 하는 생각을 감히 해봅니다.
다만, 불법 사전들에 들어 있는 데이터를 이용하는 것은 저도 반대합니다.
불법으로 생성된 자료를 이용하는 것은 또다른 불법이 되니까요.
조금 전에 위에서 제가 작성했었던 글은
"어떤 단어가 있을 때 온라인 사전 서비스에 그 단어를 던져서 그
단어가 존재하는지 여부를 자동으로 확인하는 행위가 되는데요. 이럴 때
그 사전 서비스의 저작권이 들어가는지 저도 모르겠군요."
라는 말씀을 하셨길래 제가 아는 대로 적은 것 뿐입니다.
"과연 이게 저작권을 주장할 수 있는 독창적인 데이터인가"에 대한 이야기가 아니었습니다.
애초부터 `어떤 단어가 맞춤법에 맞는지 여부'는 독창적인 데이터가 절대로 될 수 없기 때문입니다.
그 점을 지적하고 싶었습니다.
쓰다보니 꽤 긴 글을 작성했네요.
제가 쓴 글이 괜한 논란을 불러일으키는 것으로 보이거나 불쾌하셨다면 죄송하게 생각합니다.
혹시라도 그렇게 생각하셨다면 제 글은 무시하셔도 좋습니다.
(어쨌거나 여기서는 프로젝트 관리자님이 하자는 대로 따라야 하는 법이니까요 ^^)
하지만 본 프로젝트를 위한 마음으로 작성하는 글이라는 점은 이해해주실 것으로 믿습니다.
여기까지 긴 글 읽어주셔서 감사합니다.
------------------------------------
긴 글 읽기 귀찮은 분들을 위해 핵심 요약 (이 부분만큼은 꼭 읽어주시면 고맙겠습니다.)
1. 나중을 위해서라도, 저작권법은 우리가 정확히 알고 짚고 넘어가야할 문제입니다.
논란을 일으키자는 것이 아닙니다. 이번 기회에 확실히 정리하고 넘어갔으면 좋겠습니다.
2. `2004년 이후의 사전은 절대 보지 맙시다. 불법의 여지가 있습니다.' 라는 내용을 편집가이드에 추가해야합니다.
3. 불법 사전들에 들어 있는 데이터를 사용하는 것은 불법입니다.
4. libhangul 처럼 받아들일 것은 받아들이면 안될까요.
`라이선스 의심이 가는 어떠한 외부 자료도 받아들이지 않는다'는 정책은 당연합니다.
하지만 저작권 문제가 없는 자료까지 외면해서는 안되지 않나 생각합니다.
Jiho Han
> 그리고 혹시나 모르실까봐 적어보면 (알고 계신다면 죄송합니다. ^^;)
> http://kldp.org/node/80530 에 보시면
> (5년이 지난) 창작성이 없는 데이터베이스는 저작권 보호를 받을 수 없기 때문에
> 국립국어원 사전 표제어 목록의 데이터를 코딩 몇 줄로 변환해서
> 오픈소스인 libhangul 의 한자목록을 개선하는데 사용되었습니다.
> Changwoo Ryu 님의 반응이 너무 지나치신 것은 아닌가 하는 생각을 감히 해봅니다.
> 다만, 불법 사전들에 들어 있는 데이터를 이용하는 것은 저도 반대합니다.
> 불법으로 생성된 자료를 이용하는 것은 또다른 불법이 되니까요.
다른 부분은 제가 코멘트할 수 있는 부분이 아닌거 같고요. ^^;;
만약 국립국어원의 표제어 리스트나 또는 2003년 이전에 작성된 오프라인 사전의 단어 정보를 저작권 문제 없이 이용할 수 있다면,
어쩌면 제가 제공하려던 단어 리스트보다는 그쪽이 훨씬 더 낫겠는 걸요. :)
이쪽 단어들이야 기계로 자주 출현하는 단어를 아무 형태소 분석없이 모아 놓은 거라 처음 메일에서 썼었던 몇가지 문제가 있는지라...
사실 작업할 일이 좀 막막하기는 합니다. ^^;;
저작권 문제가 확실한 자료라면 활용할 수 있었으면 좋겠군요.
Dohyun Kim
2번에 동의할 수 없습니다.
사전을 참조하는 게 그 사전의 내용을 베끼거나 개작하거나 배포하는 행위가 아닐진대
어째서 저작권 침해가 일어날 수 있는지 이해할 수 없네요. 만약 이런 것도
저작권 침해라면 소설가가 사전을 참조하면서 쓴 소설은 사전의 저작권을 침해한
2차적 저작물을 구성하는 결과가 되어 도저히 받아들일 수 없습니다.
4번에 관해서는 일단 동의는 합니다만 류창우님의 생각도 존중합니다.
사실 기존 사전에서 표제어만 뽑아내서 사용하는 것은 저작권 침해가 되지 않습니다.
표제어는 사상이나 감정의 표현이 아닌, 단지 이름에 불과하죠. 그것도 가나다 순 배열인...
따라서 혹시 데이터베이스가 될 수는 있겠지만 저작물이라고는 할 수 없습니다.
그런데 현실적으로 볼 때 저작권 관련해서 법적으로 확실한 게 별로 없지 않나 합니다.
합법적인 행위를 해도 유치장에 갇히는 경험을 해야하는 세상합니다.
제대로 된 판례가 충분히 축적되어 있지 않은 컴퓨터프로그램 영역이나 인터넷 영역
사례라면 더욱더 모든 것이 불확실합니다. 만의 하나 안전을 대비해서
일말의 의심의 여지도 없게 한다는 정책은 충분히 공감합니다.
따라서 정말 안전하다는 생각되는 경우에만 받아들이는 쪽이 합리적이라고 봅니다.
Changwoo Ryu
그렇게 해서 제가 습득한 단어와 품사 정보가 저작권 정보라고 생각하지는 않
습니다. 하지만 프로그램을 통해서 수 만 개의 단어에 대해 자동으로 사전 기
재 여부와 품사를 확인해서 목록을 뽑아내거나 프로그램에 따라 자동으로 변
환하는 행위는 또 다른 얘기입니다. 네, 물론 논리적으로는 다를 게 없죠. 이
야기를 하다 보면 하늘 아래 새로운 게 없는데 표절 아닌 창작품이 뭐가 있나
삼천포에 빠지겠지만 너무 식상한 얘기니까 생략하고..
지금은 어떻게 확인할 거냐고 물으셨는데, "협업프로세스"인가 문서에 써 있
듯이, 만약 참여자가 자동 입력으로 의심되는 행위가 발견된다면 언제라도 그
참여자는 차단당하고 문제 데이터는 모두 삭제할 것입니다. 길게 보면 그 단
어들은 다시 보충되겠지요.
맞춤법 검사를 위한 데이터는 단어/품사/활용정보같은 일반적인 사실만 담겨
있고 독창적인 데이터는 하나도 없습니다. 그러므로 저작권을 주장할 수 없다
는 해석대로라면 어떠한 외부 데이터든 가져와도 사용자가 범죄를 저지를지언
정 데이터는 문제가 없어야 되는데요. 저는 그렇게 확신하지 못하겠습니다.
자세히 답을 달면 한도 끝도 없겠지만, 저는 이런 논란의 여지도 남겨두고 싶
지 않습니다.
libhangul 한자 사전은 어떻게 만들어졌는지 몰랐었는데요. 데비안 패키지에
서는 삭제를 고려해야겠습니다.
2009-05-12 (화), 07:22 -0700, redneval:
--
Changwoo Ryu <ryu.ch...@gmail.com>
JiHui Choi
같습니다. 즉, 기존의 데이터를 단순 참조용으로 사용한 것이냐, 아니면 기존의 데이
터를 기초 자료로 이용하여 그 안에서 필요한 데이터를 추출해 냈느냐라는 것입니다.
redneval 님의 말씀대로 "법이 규정하는 내에서" 기존의 데이터베이스를 이용할 경우
법적인 문제가 "발생하지 않을 수도" 있지만, 법적인 문제가 "발생할 수도" 있습니다.
왜냐하면 법은 해석하기 나름이니까요. 그런데 문제는, 그런 문제가 발생하였을 경우
우리측의 입장을 얼마나 명확하게 입증할 것이며 누가 할 것이냐인 것 같습니다. 과연
그럴 수 있을까요? 만약 그러지 못한다면 "우리는 억울해 할지 몰라도" 피해를 고스란
히 입어야 할 수도 있습니다.(전 이 시나리오가 더 가능성 있어 보입니다.)
다른 이야기. 다른 관점.
구글의 데이터나 다른 기존 데이터를 이용하면 분명 많은 단어들을 손쉽게 얻을 수
있고, 맞춤법 검사기 개발에 큰 도움이 될 수도 있을 것입니다. 하지만 꼭 그래야 할
까요? 좋고 훌륭한 맞춤법 검사기를 만드는 것도 중요하지만, 시간이 조금 걸리더라도
많은 분들의 손을 거쳐 하나씩하나씩 만들어가는 것도 큰 의미를 갖을 것입니다. 특히
맞춤법 검사기라는 것이 단지 단어들만 모아놓은 것이 아님을 상기하면 전자나 후자나
들여야 되는 노력의 양이 크게 다를 것 같지도 않습니다.
개인적으로 이렇게 토론이 이루어지고 많은 분들이 관심을 갖어 주시는 것이 얼마나
고마운지 모릅니다. 제가 시작한 프로젝트도 아니고, 아직 기여한 것은 없지만, 창우
님 혼자 애쓰시는 것이 안타까웠거든요. 그런데 소스 부분에서 남형님을 비롯해 한분,
두분 참여를 해주시고, 갈퀴에도 직접 참여해 주시는 분이 나타나시고, 데이터 부분에
서도 그러하고..
어찌보면 그냥 사무실에서, 또는 연구실에서 몇 명이 짧은 시간 내에 뚝딱 만들어낼
수도 있었을지도 모르는 이것을, 답답할 정도로 느릴지도 모르겠지만 많은 분들의 관
심과 참여 속에 이렇게 진행시켜 나가는 것. 여기서 공개 맞춤법 검사기 또는 사전의
미래를 본다면 지나친 비약일까요?
정리하자면, 조금 천천히 가보는 것은 어떨까요?
기존 데이터 사용에 관한 문제도 그러하고, 전체적인 방향도 그러하고..
다만 꾸준히 관심을 갖고 많은 분들이 함께 하는 쪽으로.. :)
JEONG, MunShik
>
> 만약 국립국어원의 표제어 리스트나 또는 2003년 이전에 작성된 오프라인 사전의 단어 정보를 저작권 문제 없이 이용할 수 있다면,
> 어쩌면 제가 제공하려던 단어 리스트보다는 그쪽이 훨씬 더 낫겠는 걸요. :)
> 이쪽 단어들이야 기계로 자주 출현하는 단어를 아무 형태소 분석없이 모아 놓은 거라 처음 메일에서 썼었던 몇가지 문제가 있는지라...
> 사실 작업할 일이 좀 막막하기는 합니다. ^^;;
>
작업할 일이 좀 막막하기는 하지만
리스트를 기부해주시면
그 리스트가 아주 좋은 품질을 가지고 있지 않더라도
단어 추가작업이 훨씬 보람찰 것 같습니다.
가끔 단어를 입력하면서
언젠가는 끝나겠지만
얼마나 지나야 False Positive가 5%이내로 줄까
궁금해지곤 합니다.
빈도로 정렬된 리스트가 있다고 하면
제가 별다른 기준없이 고른 단어들을 추가하는 것보다
그 언젠가가 10배는 빨리 오지 않을까 싶습니다. (초큼 과장을~)
----
> 저작권 문제가 확실한 자료라면 활용할 수 있었으면 좋겠군요.
'표제어 리스트'를 사용하는 것이
'사전을 참조'하는 것이
법률적인 문제가 있는지 없는지에 대해서 여러 의견이 있습니다.
정답이 딱 하나 있다고 보기힘든
법률 해석의 특성이지 않을까 싶은데요.
단어목록의 소유자가 '마음대로 써도 좋다'고 선언해 주면
법률해석 자체가 필요없어지니 더 좋지요.
'국립국어원'에서 그렇게 선언해 주면 좋지만
메일을 봐서는 '다음' 이나 '구글'에서 기부하는 것이 더 빠를 듯 합니다.
redneval
법적논란에 휘말려들만한 작은 소지도 남겨두어서는 안된다는 Changwoo님의 생각에 깊이 공감하고 있습니다.
생각을 정리하여 다시금 꽤 긴 글을 작성하였습니다.
요점만 정리해서 말씀드리면,
1. 2004년 이후의 사전을 보는 것은 안됩니다.
2. Changwoo님의 뜻에 따라,
프로그램을 이용하여 자동변환하는 것과 관련된 이야기는 더이상 저도 언급하지 않겠습니다.
3. 협력 프로세스에 대해서 다시 한 번 생각해봤으면 합니다.
4. 구글에서 데이터 기부는 받지 않는 것이 좋을 것 같습니다.
자세한 내용은 아래 부분을 참조하시기 바랍니다.
---------------------------------------------------------
밑에 부분은 Dohyn Kim님의 글에 대한 답변입니다.
(요약 : 1. 2004년 이후의 사전을 보는 것은 안됩니다.)
2번에 대해서는 저작권법 제93조와 관련이 있습니다.
[제93조2항]"데이터베이스의 개별 소재는 제1항의 규정에 따른 당해 데이터베이스의 상당한 부분으로 간주되지 아니한다.
다만, 데이터베이스의 개별 소재 또는 그 상당한 부분에 이르지 못하는 부분의 복제등이라 하더라도 반복적이거나
특정한 목적을 위하여 체계적으로 함으로써 당해 데이터베이스의 통상적인 이용과 충돌하거나
데이터베이스제작자의 이익을 부당하게 해치는 경우에는 당해 데이터베이스의 상당한 부분의 복제등으로 본다."
라고 되어있습니다.
소설가가 소설을 쓰기위해서 사전을 참조하는 행위는
`당해 데이터베이스의 통상적인 이용과 충돌'하지도 않고 `데이터베이스제작자의 이익을 부당하게 해치지'도 않기에
합법적인 행위입니다. 사전은 그런 용도로 사용하도록 만들어졌기 때문입니다.
하지만 맞춤법검사기를 만드는데 사전을 참조하는 행위는
사전의 통상적인 이용이 아니라고 `사전 제작자'가 주장할 수도 있습니다.
`사전 제작자'가 그렇게 생각한다면, 법적대응을 하는 것도 가능할 것입니다.
불법인지 여부는 법원에서 판단할 것이지만, 우리는 이러한 작은 가능성도 무시해서는 안됩니다.
다른 분들의 추가 반론이 없다면, `2004년 이후의 사전은 보지 않는 것'을 방침으로 정했으면 좋겠습니다.
(요약 : 2. 프로그램을 이용하여 자동변환하는 것과 관련된 이야기는 더이상 저도 언급하지 않겠습니다.)
4번에 대해서는
> 합법적인 행위를 해도 유치장에 갇히는 경험을 해야하는 세상합니다.
> 만의 하나 안전을 대비해서 일말의 의심의 여지도 없게 한다는 정책은 충분히 공감합니다.
> 따라서 정말 안전하다는 생각되는 경우에만 받아들이는 쪽이 합리적이라고 봅니다.
라는 글을 보고 상황파악이 됐습니다.
4번 내용은 제가 괜한 말을 꺼낸 듯 싶습니다. ^^;
이 부분은 제가 주제 넘게 나선 것 같아서 죄송하게 생각합니다.
---------------------------------------------------------
다음 부분은 Changwoo Ryu님의 글에 대한 답변입니다.
> 단어를 입력하면서 직접 일일이 단일 단어에 대해 사전을 참고하는 일이라면,
> 그렇게 해서 제가 습득한 단어와 품사 정보가 저작권 정보라고 생각하지는 않
> 습니다.
그렇지 않습니다. 위에 Dohyn Kim님의 글에 대한 답변에 적어놓았듯이
데이터베이스(사전)을 통상적인 이용방법과는 다르게,
`맞춤법검사기를 만드는데 사용'한다면 논란의 소지가 있습니다.
다만, 제가 확실하게 말씀드릴 수 있는 것은,
2003년 이전의 사전만을 사용하신다면 이 논란의 소지 또한 완벽하게 없앨 수 있습니다.
(요약 : 3. 협력 프로세스에 대해서 다시 한 번 생각해봤으면 합니다.)
> 지금은 어떻게 확인할 거냐고 물으셨는데, "협업프로세스"인가 문서에 써 있
> 듯이, 만약 참여자가 자동 입력으로 의심되는 행위가 발견된다면 언제라도 그
> 참여자는 차단당하고 문제 데이터는 모두 삭제할 것입니다
죄송한 말씀지만 그런 방법은 제가 납득하기 어렵습니다.
그런 정책을 유지하는 경우에 발생될 수 있는 문제점을 제시해보겠습니다.
spellcheck-ko 프로젝트가 성공적으로 발전하여 여러 곳에 배포되었다고 가정하겠습니다.
그러고 한참 뒤에 `참여자의 불법이 의심되는 행위가 발견'된다면,
참여자를 차단하고 문제 데이터는 모두 삭제하는 것으로 모든 문제가 해결될 것이라고 보지는 않습니다.
일단 기존에 배포된 데이터는 모두 회수하는 것은 불가능하기 때문입니다.
그리고 `기존에 배포된 데이터'에 대해서 발생한 피해에 대해
누군가가 법적대응을 한다면 본 프로젝트는 힘든 상황을 맞이하게 됩니다.
제가 말씀드리고 싶은 것은
문제가 발생하고 나서 수습하기 보다는, 사전에 차단하는 방법을 강구해야한다는 의미입니다.
솔직히 말씀드리면, 어떤 면에서는 Changwoo님보다 더 철저하게 논란의 여지를 피하는 방법을 선호합니다.
그런 면에서 볼 때, 저는 중앙집중식 프로세스로 진행돼야한다고 봅니다.
`참여자의 불법이 있을지도 모르는 협력 프로세스'보다는
오히려 `프로젝트 관리자의 통제하에 소수 인원의 중앙집중식 프로세스'가 더 (법적으로) 안전하다고 저는 믿습니다.
Changwoo님께서는 프로젝트 관리자 없이도 알아서 잘 돌아가는 `협력 프로세스'를 구축하고 싶은 심정은 동감합니다.
하지만, Changwoo님의 헌신적인 노력에 찬물을 끼얹는 것 같아서 굉장히 죄송스러운 말씀이지만,
제 관점으로는, 지금의 협력 프로세스는 불안해보입니다.
위에서 이미 언급했지만, 예를 들어서, 협력 프로세스에 참여한 누군가가 2009년판 XXX 사전을 보는 것만으로도 불법의 소지
가 있으니까요.
협력 프로세스에 참여한 모든 사람들을 2004년 이후의 사전을 보지 못하게 만드는 것이 가능할 것이라고 생각하지는 않습니다.
저작권 문제에 민감하게 반응하시는 Changwoo님이,
`협력 프로세스'와 `2004년 이후의 사전'에 대해서는 낙관적으로 바라보시는 이유는 무엇인지 설명을 해주셨으면 좋겠습니다.
이 문제는, 저뿐만이 아니라 spellcheck-ko 프로젝트를 지켜보는 모든 사람들이 관심있어할만한 내용이므로 꼭 답변해주셨으
면 좋겠습니다.
> 맞춤법 검사를 위한 데이터는 단어/품사/활용정보같은 일반적인 사실만 담겨
> 있고 독창적인 데이터는 하나도 없습니다. 그러므로 저작권을 주장할 수 없다
> 는 해석대로라면 어떠한 외부 데이터든 가져와도 사용자가 범죄를 저지를지언
> 정 데이터는 문제가 없어야 되는데요.
절대로 그렇지 않습니다. 합법적으로 데이터를 가져왔을 때에 한해서, 데이터가 문제가 없습니다.
예를들어서, 불법으로 추출된 데이터를 이용하는 것은 불법입니다.
그리고 EULA(제한적인 라이선스)를 위반하면서 가져온 데이터를 사용하는 것도 불법입니다.
범죄를 통해 획득한 데이터를 사용하는 것도 불법입니다.
단어/품사/활용정보가 일반적인 저작물에 있던 자료라면 그냥 가져와도 됩니다만
(5년 이내의) 데이터베이스(사전)에서 가져오는 것은 불법의 소지가 있습니다.
데이터베이스는 일반적인 저작물보다 더 강하게 보호되기 때문입니다.
---------------------------------------------------------
다음 부분은 Jiho Han님의 글에 대한 답변입니다.
(요약 : 4. 구글에서 데이터 기부는 받지 않는 것이 좋을 것 같습니다.)
곰곰히 생각해본 결과,
구글에서 데이터 기부는 받지 않는 것이 좋지 않을까 개인적으로 생각하고 있습니다.
구글에서의 데이터는 물론 법적인 문제는 없다고 저는 생각합니다만,
법적인 논란을 완전히 없애기 위해서는 좀 더 신중해야 할 것 같습니다.
미국에서의 법과 한국에서의 법이 다릅니다.
미국에서는 창작성이 없는 데이터베이스는 저작권보호받지 못하는 것으로 알고 있습니다.
그래서 구글의 영어단어데이터 기부는 법적으로 아무런 문제가 없다고 100% 확신할 수 있습니다.
(적어도 미국내에서는 말입니다.)
하지만 한국에서는 창작성이 없는 데이터베이스도 또한 보호받을 수 있기 때문에
구글코리아의 한국단어데이터 기부는
적어도 2003년 이전의 사전에 쿼리를 보내는 것보다는, 불법의 소지가 아주 미약하게나마 있을 수 있습니다.
(예를 들어, 구글에서 인터넷상의 네이버, 다음, 야후 등의 국어사전을 참조하지 않았음을 완전히 증명할 수는 없을 것입니다.)
(구글코리아가 아닌 구글본사에서 기부한다면 또 얘기는 달라지겠지만,
법률적인 이야기를 늘어놓는 것은 Changwoo님이 별로 안좋아하실 것 같아서 ^^; 여기까지만 적습니다.)
만에하나 문제의 소지가 있는 데이터라고 하더라도 구글코리아 내부에서 사용하는 것은 문제가 되지 않습니다.
`구글본사에서 받았습니다'라고 하면 됩니다. 구글본사는 한국법의 적용을 받지 않기 때문입니다.
게다가 아무도 모르게 사용하면 그만입니다. 누군가 귀찮게 물어본다면 `영업비밀입니다.'라고 해버리면 끝나는 문제입니다.
하지만 오픈소스 프로젝트에 기부하는 것은 또 다른 차원의 문제입니다.
오픈소스 프로젝트에 영업비밀이 있을리는 없습니다.
모든 것은 투명하게 공개돼야하므로, 일반 사기업에 비해서 더 높은 수준의 도덕적 행동과 준법책임이 요구됩니다.
`오픈소스 프로젝트'를 곱지 않게 바라보는 시각이 있을 수 있으며, 사소한 걸로 시비를 걸 수 있고,
Changwoo님과 여기 계신 분들 모두 그런 논란에 휘말리기를 원치않을 것이기 때문입니다.
---------------------------------------------------------
다음 부분은 JiHui Choi님의 글에 대한 답변입니다.
> 제 생각에는 이 주제의 요점은 "사람의 손으로 한 것이냐? 기계가 한 것이냐?" 인 것
> 같습니다. 즉, 기존의 데이터를 단순 참조용으로 사용한 것이냐, 아니면 기존의 데이
> 터를 기초 자료로 이용하여 그 안에서 필요한 데이터를 추출해 냈느냐라는 것입니다.
"사람의 손으로 한 것이냐? 기계가 한 것이냐?"여부를
Changwoo님이 중요하게 생각하시는 것 같습니다.
저는 그것은 아무런 문제가 되지 않는다고 생각하기는 하지만,
Changwoo님의 생각대로 무조건 따르기로 하겠습니다.
정말 이 이후로는 저도 더 이상 이 문제에 대해 언급하지 않겠습니다.
> redneval 님의 말씀대로 "법이 규정하는 내에서" 기존의 데이터베이스를 이용할 경우
> 법적인 문제가 "발생하지 않을 수도" 있지만, 법적인 문제가 "발생할 수도" 있습니다.
> 왜냐하면 법은 해석하기 나름이니까요. 그런데 문제는, 그런 문제가 발생하였을 경우
> 우리측의 입장을 얼마나 명확하게 입증할 것이며 누가 할 것이냐인 것 같습니다. 과연
> 그럴 수 있을까요? 만약 그러지 못한다면 "우리는 억울해 할지 몰라도" 피해를 고스란
> 히 입어야 할 수도 있습니다.(전 이 시나리오가 더 가능성 있어 보입니다.)
JiHui님이 어떤 의도로 말씀하신지는 잘 이해하지는 모르겠습니다만,
`우리측의 입장을 얼마나 명확하게 입증할 것'인가에 대한 중요성은 저도 동감합니다.
그리고, 현재의 협력 프로세스로는 `우리측의 입장을 명확하게 입증'하기 힘들지는 않을지 저는 걱정이 됩니다.
---------------------------------------------------------
부족하나마 제 글을 읽고 저작권문제에 대해 다시 생각해보는 계기가 되었다면,
그것만으로도 제 글이 의미가 있지 않나 주제넘게 생각해봅니다. ^^;
여기까지 긴 글 읽어주셔서 감사합니다. (__)
Changwoo Ryu
그 쪽이 뒤집어 쓰겠지요. :P)
하지만 "이런 데이터는 저작권을 주장할 수 없다"라는 해석에 따라 가져다
쓰는 일은 동의하지 않습니다. 예를 들어 눈앞에 두산동아 사장이 보는 앞에서
동아 새국어사전을 프로그램으로 돌려서 데이터를 만들고 "이 데이터는 저작권이
없어요. 맞춤법 데이터는 MPL/GPL/LGPL에 따라 영리로도 자유롭게 활용할
수 있어요"라고 말했을 때 분쟁이 일어나지 않는다고 자신할 수 있습니까?
이렇게 할 수만 있으면 저도 편하고 모두가 편하겠죠.
2009/5/13 JEONG, MunShik <rus...@gmail.com>:
Changwoo Ryu
피곤하군요. 모두의 시간 낭비를 줄이기 위해 redneval님을 차단합니다.
2009/5/13 redneval <rednev...@gmail.com>:
Jiho Han
일단 프로젝트에 단어 리스트를 올리는데 대해 허가를 받았습니다. 사내 오픈 소스 관련 규정에 따라 오픈 소스 프로젝트에 보낼
패치를 만들고 이를 심사 받는 형식을 따랐습니다.
사소한 제약이 있었습니다만 큰 문제는 없었네요.
심사를 위해 프로젝트에 대해 패치를 만들어야 하다보니 git을 사용해서 뜬금없이 source code랑 같은 디렉토리에
ko_words1.txt, ko_words2.txt, ko_words3.txt 를 두는 change를 만들었는데요, 이대로
이걸 그냥 commit 할 수는 없지 않나 하는 생각이 드는군요. 잘은 모르지만 당연히 제게 commit 할 권한도 없을 듯
하고요. 어떻게 올리면 좋을 지 알려주십시오.
파일을 3개로 나눈 이유는, 결국 원래의 단어 리스트가 문서 상의 출현 빈도 순으로 한국어 단어를 나열한 것인데 가급적 정확한
순서를 노출하지 않기를 요청 받았기 때문입니다. 그래서,
1. 전체 단어들 중 현재 이미 갈퀴에 등재된 단어들을 제거하고,
2. 남은 것들 중 상위 15만개를 출현 빈도 순으로 5만개씩 3등분한 다음에,
3. 각각 가나다 순으로 소팅했습니다.
ko_words1.txt는 1 ~ 50000 번째까지의 단어를, ko_word2.txt는 50001 ~ 100000,
ko_words3.txt 는 100001 ~ 150000 번째 까지입니다. 상대적으로 ko_words1.txt에 쓸만한
단어들이 많이 보이고, ko_words3.txt에는 드뭅니다.
총 15만개의 단어가 있습니다만, 실제로 사전에 등재할만한 단어가 그렇게 많이 포함되어 있지는 않습니다. 갈퀴에 이미 포함된
단어를 제거한 탓에 더욱 그렇습니다. 일단은 다음에 추가해야할 만한 단어들을 쉽게 찾아내는데에는 도움이 될 것 같군요. 무언가
더 나은 활용방도가 있으면 좋겠습니다.
감사합니다.
2009/5/13 Changwoo Ryu <ryu.ch...@gmail.com>:
JEONG, MunShik
> 심사를 위해 프로젝트에 대해 패치를 만들어야 하다보니 git을 사용해서 뜬금없이 source code랑 같은 디렉토리에
> ko_words1.txt, ko_words2.txt, ko_words3.txt 를 두는 change를 만들었는데요, 이대로
> 이걸 그냥 commit 할 수는 없지 않나 하는 생각이 드는군요. 잘은 모르지만 당연히 제게 commit 할 권한도 없을 듯
> 하고요. 어떻게 올리면 좋을 지 알려주십시오.
>
git://git.kernel.org/pub/scm/git/git.git에서 쓰는 html 브랜치 처럼 만들어 넣어두면 어떨까요?
git 프로젝트에서는 설명서들 html 포맷으로 자동생성해서 html 브랜치에 넣는데요.
이 html 브랜치는 소스코드와 같은 리포지토리에 들어 있지만
master 브랜치와 완전히 별개 브랜지입니다.
git 프로젝트의 설명서 html도 hunspell-dict-ko의 기부받은 데이터도
원래 프로젝트와 성격은 다르지만
따로 리포지토리를 만들기에는 또 너무 가까워 보이는데요.
같은 리포지토리에 집어 넣으면서 전혀 다른 브랜치로 만들면
google에서 받은 단어목록의 이력과
hunspell-dict-ko의 python 소스코드 이력
따로 관리되어 좋고, 또 clone 한번에 모든 정보를 다 가져올 수 있어서 좋습니다~
아래처럼 해주시면 아예 다른 브랜치를 만들어 올리게 됩니다.
* github.com에 가입
* http://github.com/changwoo/hunspell-dict-ko/tree/master 로 이동
* fork 버튼을 누름
http://github.com/ruseel/hunspell-dict-ko/tree/master 로 자동으로 이동합니다.
* 화면의 Your Clone URL: g...@github.com:ruseel/hunspell-dict-ko.git 을 메모.
* 새 git repository를 하나 만듭니다.
$ mkdir google_words
$ cd google_words/
$ cat <<EOF > ko_words1.txt
> 루비쿡북
> 파이썬
$ git init
Initialized empty Git repository in /Users/thpark/Projects/google_words/.git/
$ git add ko_words1.txt
$ git commit -m "initial import"
[master (root-commit)]: created adfd617: "initial import"
1 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 ko_words1.txt
* github.com의 hunspell-dict-ko를 remote repository로 추가하고 push
$ git remote add ruseel g...@github.com:ruseel/hunspell-dict-ko.git
$ git checkout -b google_words
Switched to a new branch "google_words"
$ git push ruseel google_words
Counting objects: 3, done.
Writing objects: 100% (3/3), 251 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To g...@github.com:ruseel/hunspell-dict-ko.git
* [new branch] google_words -> google_words
JEONG, MunShik
관료주의는 구글과는 관련없는 단어인가봐요. :-)
jiho님께서 신경을 많이 써주셨으니 가능한 일이겠지만 그래도 참 부럽네요.
2009/5/13 Jiho Han <han...@gmail.com>:
Jiho Han
막막했었는데 덕분에 금방 끝낸거 같습니다.
시키신 대로 해서 그럭저럭 잘 만들어진 걸로 판단됩니다. 관련 URL은 여기입니다.
http://github.com/hanjiho/hunspell-dict-ko/tree/google_words
제대로 되었는지 한번 살펴봐 주시겠습니까? 워낙에 쓸모 없는 부분도 많이 포함이 된 데이타라 큰 도움이 안되는게 아닐까 약간 걱정도 되는군요.
2009/5/13 JEONG, MunShik <rus...@gmail.com>:
Changwoo Ryu
틀린 말 말고도 인명, 상호명, 브랜드, 빌딩 이름같은 자질구레한 고유명사가
상당 부분을 차지하고 잘못 수집된 것처럼 보이는 ("떠오르", "똑똑해지") 말
도 있습니다.
이대로는 상위 5만개 수준에서 확인해 보는 일도 너무 비효율적으로 보이는데
요. 혹시 빈도에 따로 좀 더 세분화할 수는 없을까요? 상위 1, 2만 정도에서
는 노이즈 비율이 좀 줄어들지도.
2009-05-13 (수), 22:27 +0900, Jiho Han:
--
Changwoo Ryu <ryu.ch...@gmail.com>
JEONG, MunShik
$ grep '나무$' *.txt
ko_words1.txt:가시나무
ko_words1.txt:감나무
ko_words1.txt:꽃나무
ko_words1.txt:느릅나무
...
...
$ grep '히$' *.txt
ko_words1.txt:가지런히
ko_words1.txt:가히
ko_words1.txt:간곡히
ko_words1.txt:간략히
ko_words1.txt:건강히
...
...
'고이고이' 처럼 4글자인데 2글자가 반복되는 패턴도 한 30개쯤...
2009/5/14 Changwoo Ryu <ryu.ch...@gmail.com>:
JEONG, MunShik
2557
2402
2296
Jiho Han
> 국어사전을 참조하지 않은 건 분명하군요. 틀린 단어가 너무 많아요. :)
네. 아무래도 내용이 좀 그런 측면이 있습니다. :)
사람 손을 전혀 안타고 기계가 만들어낸 녀석들이니까요. 게다가 기존 갈퀴에 등록된 단어들을 제거해버렸더니 쓸만한 단어들이 많이
날라가버렸죠. ^^
일단 상위 1만개 단어만 다시 만들어 ko_words0.txt라는 이름으로 올렸습니다. 어차피 상위권에는 갈퀴에 등록된 단어가
많았던 탓에 눈에 띄이게 좋아 보이지는 않네요.
명확한 노이즈 단어들을 쉽게 제거할 방법이 있으면 좋겠는데 딱히 좋은 방법이 떠오르질 않는군요.
Changwoo Ryu
혹시 등록된 단어들을 제거하셨다는 게 직접 xml에 들어 있는 기본형과 같은 단어만 제거하신 것 아닌가요?
2009/5/14 Jiho Han <han...@gmail.com>:
Jiho Han
> hunspell -l 옵션으로 걸러내면 5만개 중에 35000개만 남아서 걸러내지 않은 단어인 줄 알았는데요.
>
> 혹시 등록된 단어들을 제거하셨다는 게 직접 xml에 들어 있는 기본형과 같은 단어만 제거하신 것 아닌가요?
앗! 맞습니다. XML에 들어있는 단어랑 일치하는 단어들만 제거했습니다.
저도 hunspell -l 로 다시 돌려봐야 겠군요.
Jiho Han
감사합니다.
2009/5/14 Jiho Han <han...@gmail.com>:
Changwoo Ryu
대략 단어 1개에 대해 상식과 사전 찾기로 검증하는 시간이 약
30초라면 상위 1만개는 83 시간이(man-hour) 걸리고, 순서대로
하나씩 하기에는 꽤 많은데, 최근 입력하신 "~나무"처럼 특정한
맞는 패턴이나 특정한 틀린 패턴을 어느 정도 걸러내는 게 좋을
것 같습니다. (어미 중간에 잘린 경우 등)
좋은 생각 있으신 분? 어떤 방법으로 하든 중복 작업을 피하도록
추가한 단어나, 틀린 단어는 표시해서 기록을 남기고 넘어갔으면
좋겠습니다.
Hodong Kim
스크립트 등의 프로그램을 이용하여 구글 한국어 사전에 자동 접속해서 검사
하는 것은 어떨까요? 좀.. 위험하겠죠?
방법2 : 사람이 검사
협업해서 검사할 수 있도록 위키 문서로 올리는 것이 좋을 것 같습니다.
구글 docs 라는 것도 있는데.. 협업에 적합한지 아직 검토해 보지 않았습니
다.
우선 먼저, 방법1과 방법2 둘 중 하나로 결정하면 좋겠습니다.
방법1의 경우, 어떤 법적 문제가 있는지는 저는 모릅니다.(참 무책임하죠;;;)
Hodong Kim
import, export 가능합니다.
방법1에 대해서 잠깐 고려해봤는데
제가 알기로는 법적인 최종 판단은 법원이 하는 것으로 알고 있습니다.
그래서 방법1은 반대입니다.
Kim Jae ju
저작권자들에게도 '표제어와 품사만을 이용한다는 조건' 같은 걸 달아서 요청해 본다던가요.
못 먹는 감 찔러나 본다고 혹시 긍정적인 반응이 돌아올지 모르죠.
질러서 갈 수 있는 길이 있다면 그 편이 낫다고 생각합니다.
09. 5. 18, Hodong Kim <hodo...@gmail.com>님이 작성:
Hodong Kim
검색 조건: 내용
검색어 : 표제어만 추출
답변 작성일: 2007.10.09.
-------------------------------------------------
2. 표준국어대사전 DB는 (주)0000와 계약이 체결되어 있어 현재는 표제어 목
록 등을 제공하고 있지 않습니다. 따라서 웹 스크립트 코드 등도 제공하기 어
렵습니다.
-------------------------------------------------
Jiho Han
> 방법1 : 기계가 검사
> 스크립트 등의 프로그램을 이용하여 구글 한국어 사전에 자동 접속해서 검사
> 하는 것은 어떨까요? 좀.. 위험하겠죠?
구글 사전 데이타를 계약하신 분께 여쭤봤는데 아무래도 문제가 될 수 있을 것 같으니 그렇게 안했으면 좋겠다고 하시더군요.
사람이 직접 검사하는 방법이 너무 힘들다던가 해서 정 다른 방법이 없는 것 같으면 사전 데이타 원 소유주에게 직접 한번 문의해
보도록 추진해 보겠습니다.
> 방법2 : 사람이 검사
> 협업해서 검사할 수 있도록 위키 문서로 올리는 것이 좋을 것 같습니다.
> 구글 docs 라는 것도 있는데.. 협업에 적합한지 아직 검토해 보지 않았습니
> 다.
간단하게 처음 1만 단어를 로딩해서 구글 문서를 만들어봤습니다.
http://spreadsheets.google.com/ccc?key=rhW_LpvS5Ackqs8LViJ_ZHg
아무나 편집할 수 있고 동시에 여러명이 한 문서를 보는 것처럼 같이 작업하는 것도 가능합니다.
나중에 CSV로 export 할 수 있으니, 완성된 후에 갈퀴 데이타로 한꺼번에 집어 넣는 것도 가능할 것 같네요.
직접 한번 보시고 판단하시죠. 작업하기 어떨까요?
p.s. 그나저나 한국어 메일을 쓰는데 그 와중에 철자법 검사가 척척 되어주니 참으로 감동이군요. :)
p.s.2 그런데 아직 '철자법'은 사전에 안 들어가 있네요. ^^;;
JiHui Choi
> 간단하게 처음 1만 단어를 로딩해서 구글 문서를 만들어봤습니다.
> http://spreadsheets.google.com/ccc?key=rhW_LpvS5Ackqs8LViJ_ZHg
>
2009/5/18 Changwoo Ryu <ryu.ch...@gmail.com>:
> 감사합니다. 이제 노가다를 할 시간인가요? :>
>
> 대략 단어 1개에 대해 상식과 사전 찾기로 검증하는 시간이 약
> 30초라면 상위 1만개는 83 시간이(man-hour) 걸리고, 순서대로
>
뭐 언젠가는 되겠죠? ㅋ
JEONG, MunShik
> 추가한 단어나, 틀린 단어는 표시해서 기록을 남기고 넘어갔으면
> 좋겠습니다.
galkwi에 웹인터페이스를 하나 더 추가하는데
화면에 google_words 브랜치의 단어 하나만 보이고
일단 '명사인지, 아닌지'만 묻고
명사라면 끝
명사가 아니라면 '사전에 등재하기 적당한지, 아닌지'만
상식선에서 여러 사람이 중복해서
확인할 수 있게 하면 어떨까요?
이렇게 해서 데이터베이스에 google_words 브랜치의 단어들이
'명사인지, 아닌지'
'사전에 등재하기 적당한지, 아닌지'
만 상식선에서 (사전을 점검하지 않고) 2회쯤 검사가 되게 하면
괜찮을 듯 싶은데요.
구현은 별개문제로.. ^^;;;
Hodong Kim
구글 1만개 단어 검토 며칠내로 끝날 것 같습니다.
그리고 구글 스프레드 시트에 2번째 column 에서
o 는 검토한 것이지만, 잘못된 것이 있을 수도 있습니다.
? 는 검토해야 하는 것입니다.
x 는 없습니다. 속도 때문에 명백히 잘못된 표제어는 바로 삭제할 겁니다.
규칙 기능을 적용했습니다.
2번째 clumn 에서
o 을 입력하면 연두색, ? 을 입력하면 노란색으로 자동으로 표시됩니다.
품사 column에서
형용사, 동사를 입력하면 배경색이 붉은 계열의 색깔로 자동으로 표시됩니다.
** 주의 **
구글 docs가 베타 버전입니다. data corruption 가능성을 100% 배제할 수는
없을 것 같습니다. 어차피 revert 기능도 있고 원본이 있는 만큼 별 상관은
없습니다.
간혹, 색깔 변하는 규칙을 적용할 때, 엄청난 메모리를 소모하면서 엄청난 시
간이 소비되는 경우 있습니다. 메인 메모리 4GB가 바닥나고 swap 을 1GB 를
사용하기도 하더군요...
그냥 웹브라우저 죽였는데...
데이터가 소실이 안 되는 점으로 보아 당황할 필요 없습니다.
(웹브라우저의 문제일 수도 있고,... 아니면 링크되는 라이브러리 문제일 수
도 있고... 구글 스프레드 시트의 문제일 수도 있고...
일단, 제가 debian testing, unstable 버전을 사용하고 있습니다.)
Hodong Kim
리스트
http://spreadsheets.google.com/ccc?key=rhW_LpvS5Ackqs8LViJ_ZHg
정리가 완료된 후에 어떻게 할지, 어떻게 해야 되는지 의견 좀 주세요.
예를 들자면,
* 최종 승인 APPROVE, REJECT 방법?, 절차?
* 중복제거 : 단어리스트 - 칼퀴 DB
* 칼퀴 DB <--- 입력 방법? --- 승인된 최종 리스트
* 총대 맬 사람?? 누가 총대를 메는가?
On May 19, 1:04 am, JiHui Choi <jihui.c...@gmail.com> wrote:
> 2009/5/18 Jiho Han <hanj...@gmail.com>:> 간단하게 처음 1만 단어를 로딩해서 구글 문서를 만들어봤습니다.
> > http://spreadsheets.google.com/ccc?key=rhW_LpvS5Ackqs8LViJ_ZHg
>
> 여기 표를 보면서 체크 안된 것을 체크해두면 되는 것인가요?
>
> 2009/5/18 Changwoo Ryu <ryu.chang...@gmail.com>:> 감사합니다. 이제 노가다를 할 시간인가요? :>
>
> > 대략 단어 1개에 대해 상식과 사전 찾기로 검증하는 시간이 약
> > 30초라면 상위 1만개는 83 시간이(man-hour) 걸리고, 순서대로
>
> 뭐 언젠가는 되겠죠? ㅋ
>
> --
> Regards,
> JiHui Choi
> ----------------------------------------------------http://Mr-Dust.pe.krhttp://GIMP.kr, http://OpenOffice.or.kr, http://Ubuntu.or.kr
Jiho Han
보니까 원래의 1만 단어에서 대략 4천개 정도 추려내신 거 같군요. 맞나요?
아직 품사 태그를 주는 작업이 아직 남아 있는 거 같던데 나눠서 하시는 건 어떻겠습니까?
그러면 좀 더 빨리 끝낼 수 있지 않을까 싶은데요.
Sheet를 하나 더 만들고 본인이 작업하고 싶은 단어 영역을 기입한 후에 시작하면 다른 분과 작업이 안 겹치면서 진행할 수
있지 않을까 싶네요.
2009/5/20 Hodong Kim <hodo...@gmail.com>:
Hodong Kim
1만개에서 약 4천개로 추린 것입니다.
제가 작업한 과정은
수작업으로 했으며, 비슷하게 재연할 수 있으며 도의적인 문제, 법적인 문제
전혀 없습니다.
> 아직 품사 태그를 주는 작업이 아직 남아 있는 거 같던데 나눠서 하시는 건 어떻겠습니까?
>
> 그러면 좀 더 빨리 끝낼 수 있지 않을까 싶은데요.
>
> Sheet를 하나 더 만들고 본인이 작업하고 싶은 단어 영역을 기입한 후에 시작하면 다른 분과 작업이 안 겹치면서 진행할 수
> 있지 않을까 싶네요.
그렇게 하고는 싶은데... 구글이 속도가 느립니다.
1000개씩 4개 시트로 나누고 싶은 마음이 굴뚝 같습니다.
단어리스트 파일은 jiho 님이 소유자이시니
1000개씩 4개 시트로 나누어 주시면 좋겠습니다.
제가 나누어보려고 몇 번 시도했었는데...
잘 안 되더군요.
그리고 대부분의 단어가 명사이기 때문에,
마음먹고 달려들면 하루만에도 끝날 수가 있습니다.
단어리스트는 시간이 흐를수록 효용성이 떨어집니다.
정리 후에 어떻게 하면 좋을 지에 대하여
칼퀴 DB 에 관련된 분들의 빠른 의견 제시를 부탁드립니다.
만약 완료 시점까지 후 처리에 대한 아무 의견이 없을시..
완료된 단어리스트를 칼퀴에 제안 단어로 입력한다면...
제안 단어가 약...4000개... 대략난감 사태가 벌어집니다^^;;.
Changwoo Ryu
중복 제거는 이번 주말에 새로 릴리스를 하면 소스에 포함된
dict-ko-galkwi.xml 파일을 기준으로 삼아도 될 것 같습니다. 릴리스와 데이
터 입력 중간에 며칠 사이에 입력된 단어 때문에 겹칠 수도 있겠지만 있어봤
자 얼마 안 되고 나중에 다시 찾아서 제거할 수 있으니까요.
입력이 문제인데, 지금 갈퀴 시스템은.. 대량 입력을 일부러 하려고 해도 앱
엔진의 여러가지 제한때문에 하기 좀 많이 껄끄러운데요. (처음 데이터
import할 때 얼마나 많은 삽질을 했는지..) csv로 만들어서 주시면 제가 수동
으로 하겠습니다.
그리고 기록 목적도 있고 구글에 대한 credit을 남기는 게 좋을 것 같은데,
주석에 한 줄 추가해야 겠네요 추가하면 합니다. "(google.co.kr
ko_words.00)" 이러면 될까요.
2009-05-20 (수), 04:17 -0700, Hodong Kim:
--
Changwoo Ryu <ryu.ch...@gmail.com>
Changwoo Ryu
> 처음에 예측한 대로 83시간을 쏟으신 것인지.
>
> 중복 제거는 이번 주말에 새로 릴리스를 하면 소스에 포함된
> dict-ko-galkwi.xml 파일을 기준으로 삼아도 될 것 같습니다. 릴리스와 데이
> 터 입력 중간에 며칠 사이에 입력된 단어 때문에 겹칠 수도 있겠지만 있어봤
> 자 얼마 안 되고 나중에 다시 찾아서 제거할 수 있으니까요.
>
> 입력이 문제인데, 지금 갈퀴 시스템은.. 대량 입력을 일부러 하려고 해도 앱
> 엔진의 여러가지 제한때문에 하기 좀 많이 껄끄러운데요. (처음 데이터
> import할 때 얼마나 많은 삽질을 했는지..) csv로 만들어서 주시면 제가 수동
> 으로 하겠습니다.
>
> 그리고 기록 목적도 있고 구글에 대한 credit을 남기는 게 좋을 것 같은데,
> 주석에 한 줄 추가해야 겠네요 추가하면 합니다. "(google.co.kr
> ko_words.00)" 이러면 될까요.
보내기 단축키를 눌러서 오타가 났네요. 빠진 얘기가..
갈퀴에 지금 들어 있는 전체 단어 수가 19200 단어 정도인데, 아마 여기서
4000개를 추가해도 체감하는 빨간 줄 개수는 비슷하지 않을까 싶습니다. :>
그래도 많은 수가 늘어나는 셈이니 믿고 입력하기 전에 최소 다른 한 분이 확
인하고 넘어갔으면 좋겠습니다. 입력하기보다 나중에 삭제할 틀린 단어를 확
인하는 일이 더 어렵습니다.
음 데이터가 많으니 구글 doc은 어려움이 있네요. 찾기 기능 없나요..
--
Changwoo Ryu <ryu.ch...@gmail.com>
Jiho Han
> 그렇게 하고는 싶은데... 구글이 속도가 느립니다.
> 1000개씩 4개 시트로 나누고 싶은 마음이 굴뚝 같습니다.
> 단어리스트 파일은 jiho 님이 소유자이시니
> 1000개씩 4개 시트로 나누어 주시면 좋겠습니다.
네. 일단 4개로 나눠봤습니다. 방법을 몰라서 원래 sheet를 duplicate 한 다음에 각자 필요 없는 줄을 지워서 만들었네요.
그다지 안정적으로 화면이 보이지 않아서 몇번이나 리로드를 해야 하더군요.
다음 ko_words.01 1만개를 작업할 때에는 미리 2천개씩 나눠서 하는 편이 좋을 것 같습니다.
> 잘 안 되더군요.
>
> 그리고 대부분의 단어가 명사이기 때문에,
> 마음먹고 달려들면 하루만에도 끝날 수가 있습니다.
아, 한가지 궁금한 점이 있습니다. 명사 중에는 '~하다'와 '~되다'가 붙어서 동사로 쓰일 수 있는 경우가 많은데요,
이럴 경우에 동사형도 같이 만들어서 넣어 줘야 하는 거죠? 지금 보니, 제일 앞부분만 해도 '가용'이라던가 '가출', '각색'
등등의 명사들이 보입니다.
Jiho Han
> 갈퀴에 지금 들어 있는 전체 단어 수가 19200 단어 정도인데, 아마 여기서
> 4000개를 추가해도 체감하는 빨간 줄 개수는 비슷하지 않을까 싶습니다. :>
그래도 상대적으로 출현 빈도 수가 높은 단어들이라 (최소한 구글 번역팀이 그렇게 판단한)
그럭저럭 숫자에 비해서는 나름 효과가 괜찮지 않을까 싶습니다. :)
아직 필터링을 기다리고 있는 14만개 단어가 더 있군요. 이걸 연내에 다 처리할 수만 있다면, 1~2만개 정도는 더 추가할 수 있겠죠.
> 그래도 많은 수가 늘어나는 셈이니 믿고 입력하기 전에 최소 다른 한 분이 확
> 인하고 넘어갔으면 좋겠습니다. 입력하기보다 나중에 삭제할 틀린 단어를 확
> 인하는 일이 더 어렵습니다.
크로스 체크를 하도록 할까요? 호동님이 추려내신 4천개 단어들을 4 부분으로 나눴으니 4분이 지원해서 작업해주시면 좋을 것 같은데요.
4분이 각자 자기 담당 부분의 품사 및 속성 기입을 해주시고, 작업이 끝난 후에 각자 다른 분의 작업 결과를 크로스 체크해주시면 어떨까요?
Hodong Kim
날밤 새면서 엄청난 시간을 쏟았습니다.
구글 스프레드 시트상에서 추리는 것이 가능하지만,
속도가 느린 것이 단점입니다.
(여러가지 이유 때문에, row 1개 삭제하는 데에 약 ** 10초 ** 걸립니다.)
(* 여러가지 이유
손으로 마우스 이동 시간 포함, 웹브라우저 오류 포함, 스크롤 시간 포함 등)
그래서 제 컴퓨터에서 걸러서 올린 것입니다. 제 컴퓨터 RAM 이 4기가입니다.
예를 들어, 100MB 문서 파일도 문제없이 읽어서 swapping 없이 작업할 정도로
환경이 좋습니다.
1만개 리스트의 법적 문제 여부는 제가 알 바 아니고,
일단, 제가 4천여개로 추리는 것(과정)에 문제가 없음을 입증할 수 있습니다.
추후 어느 누군가(개인, 법인, 회사, 기관 등)가 문제를 제기한다면...
제가 수작업으로 날밤 새면서 작업한 것이기 때문에...
재연 비용을 주시면 수작업으로 재연할 수 있습니다.
다들 아시겠지만,,,
혹시라도 잘모르고 추후(5년 후, 10년 후) 문제 제기 하실 분을 위해 설명해
드리겠습니다.
vi의 기능 중에 찾기, 치환 등 강력한 기능이 있습니다.
정규식 표현 적용 가능합니다.
예를 들겠습니다.
* 한문자로 된 단어 검색
* 끝글자 검색
* 형용사, 동사로 추측
-다\n
-하다\n
-한\n
-인\n
-스럽-
-스러-
(..생략..)
* 짤린 문자열로 추측되는 것
-으로
-니까
-긴
-와
(...생략...)
수작업으로 1만개를 작업하다 보니...
맞춤법 규칙이 읽혀졌습니다.
만약, 수만개를 수작업으로 처리한다면
품사 분류 알고리즘도 만들 수 있을 것 같습니다.
그 정도로 제가 처리한 과정(1만개에서 4천개 가량으로 추리는 작업)에는 도
의적, 법적 문제가 전혀 없습니다.
(리스트의 품질을 보증한다는 의미가 아닙니다. 약 4천개 리스트 내에 잘못된
것들이 있습니다. 잘 찾아보면 멀쩡한 것이 제거된 것을 발견할 지도 모릅니
다. 찾는 시간이면 칼퀴에 수작업으로 입력하는 것이 빠르겠지요. 경제성을
고려해서 마구 삭제했습니다.^^;;;;;;)
-------------------------------------------
류창우님, 추리는 과정에 대해서는 걱정 안 하셔도 됩니다. 저는 리눅스를 10
년 이상 사용한 사람이라, 리눅스에 기본 탑재되려면 라이선스 등의 법적 문
제가 전혀 없어야 된다는 사실을 잘 알고 있습니다.
그리고 또한 과거에 개인적으로 맞춤법 검사기를 만들려고 시도만 하다가 포
기했었습니다. 그 열정 때문에 날밤 새면서 작업을 했습니다.
류창우님이 총대메고 검사기를 만들어 주셔서 정말 감사할 따름입니다.
JiHui Choi
>> 처음에 예측한 대로 83시간을 쏟으신 것인지.
>
> 날밤 새면서 엄청난 시간을 쏟았습니다.
> 구글 스프레드 시트상에서 추리는 것이 가능하지만,
> 속도가 느린 것이 단점입니다.
>
요즘 다른 일때문에 도움이 못 되어 드리고 있는데, 이 내용은 "과정상의 투명성
확보" 뿐만 아니라, 저처럼 리눅스를 잘 다루지 못하는 사람들이 쉽게 참여하는데
큰 도움이 될 것 같습니다. 좋은 내용 감사합니다. :)
--
Regards,
JiHui Choi
----------------------------------------------------
http://Mr-Dust.pe.kr
Hodong Kim
On Thu, 2009-05-21 at 02:00 +0900, Jiho Han wrote:
> 2009/5/21 Changwoo Ryu <ryu.ch...@gmail.com>:
> > 갈퀴에 지금 들어 있는 전체 단어 수가 19200 단어 정도인데, 아마 여기서
> > 4000개를 추가해도 체감하는 빨간 줄 개수는 비슷하지 않을까 싶습니다. :>
>
> 그래도 상대적으로 출현 빈도 수가 높은 단어들이라 (최소한 구글 번역팀이 그렇게 판단한)
> 그럭저럭 숫자에 비해서는 나름 효과가 괜찮지 않을까 싶습니다. :)
>
> 아직 필터링을 기다리고 있는 14만개 단어가 더 있군요. 이걸 연내에 다 처리할 수만 있다면, 1~2만개 정도는 더 추가할 수 있겠죠.
>
이거(14만 단어)는 효율이 안 나올 것 같네요. 단시간(24시간 내)에 추리려면
단순한 text 를 가지고, 알고리즘을 고안해서 해결해야 되는데...
고안한 알고리즘이 특허 등록되어 있는 알고리즘일 수도 있으니...
단시간(약 24시간 내)에 추리는(필터링) 작업은 매우 위험할 것 같습니다.
혹시 오해가 있을까봐 내용 추가하는데...
4천개 추리는 과정에는 고등학교 문법책에 있는 규칙이 사용되었습니다.
뭐 그냥...vi와 gedit 로 찾아서 지우고, 외래어 조금 순화한 것 밖엔 ....(
외래어 정말 많더군요)
(고등학교 문법 교과서는 0000회사 홈페이지에서 pdf 파일로 다운받을 수 있
습니다.)
> > 그래도 많은 수가 늘어나는 셈이니 믿고 입력하기 전에 최소 다른 한 분이 확
> > 인하고 넘어갔으면 좋겠습니다. 입력하기보다 나중에 삭제할 틀린 단어를 확
> > 인하는 일이 더 어렵습니다.
>
> 크로스 체크를 하도록 할까요? 호동님이 추려내신 4천개 단어들을 4 부분으로 나눴으니 4분이 지원해서 작업해주시면 좋을 것 같은데요.
> 4분이 각자 자기 담당 부분의 품사 및 속성 기입을 해주시고, 작업이 끝난 후에 각자 다른 분의 작업 결과를 크로스 체크해주시면 어떨까요?
>
jiho 님 의견에
저는 동의합니다. 너무 무리해서 좀 쉬다가;;;
토요일과 일요일에 집중적으로 작업할 생각입니다.
---------------------------
여담이지만,,,,
과거에 심리학책에 언어 처리에 관하여 나온 부분이 생각이 납니다.
(아마 언어학책에는 더 자세히 나와 있을 수도 있겠군요.)
사람이 단어를 계층화하여 이해한다는 것이 기억이 납니다.
식물 - 과일 - 사과 - 빨간 사과 등등..
사과 관련하여 적용되는 행위 - 먹다, 보다 등등등...
완전 객체지향입니다.
이러한 것을 OODBMS 를 응용하면 세계최강의 맞춤법 검사기, 번역기, 언어 표
현 기계, 언어 이해 기계 등이 나올 수 있다는 생각이 듭니다.
촘스키 언어학 이론이 대단하기는 참 대단합니다.
제가 뒷북치는 걸지도 모르겠군요;;;
> >
Hodong Kim
hunspell-ko 최신 버전을 설치하고
빨간줄 나오는 것을
수작업으로 바로 칼퀴에 제안 단어로 입력할 것을 제안합니다.
** 대충 사용할 만한 단어 예측 **
14만 단어 * 0.4 = 56000개
56000 - 20000(칼퀴) = *** 36000단어 ***
** 갈퀴 수작업 입력, 총작업 시간 예측 **
단어 1개 = 30초
56000개 * 30초 = 28000분 = 약 467시간 = 총작업 시간, 약 19일 * 24시간
********** 제안 **********
* 한지호님께
1만개 * 14개의 파일을 tar.bz2 로 묶어서
구글 그룹 등 적절한 곳에 올려 주시기를 제안합니다.
* 1만개 파일 입력자분들께
* 작업시에 항상 최신 버전 hunspell-ko 설치
해당 스레드에 보고 : x번 파일을 맡아서 갈퀴에 수작업 입력합니다.
해당 스레드에 보고 : x번 파일 갈퀴에 수작업 입력 끝났습니다.
* 류창우님께
만약, 가능하다면,,,
hunspell-ko 비공식 버전이라도 매주 또는 매달 **평일**에 한번 가량 업데이트 해주시면 좋겠습니다.
(개인 사정 상 어렵다면 편하실 때 미리 작업해 놓고 평일을 골라서 hunspell-ko-몇월며칠버전 제작)
제안 단어가 대량화(하루 제안 수백개~1000개) 될 것에 대비하여 검토자를 확보해 주시면 좋겠습니다.
**또는**
칼퀴에서 검색할 때 ** 현재 제안 중인 것까지 검색 결과 출력 ** 되면 매우 좋겠습니다.
* 사족
{ 1만개 자료 검토 입력자 != 검토자 } 이었으면 좋겠습니다.
** 소요 시간 예측 **
10000개 * 0.4 = 쓸만한 단어 4000개 = 2000분 = 33시간
1만개 = 1개월이라 가정했을 때
14명 달려들면 1개월에 끝나고
3명 달려들면 5개월이면 끝납니다.
***************************
위의 제안처럼 한다면 단어 부족 문제는 금방(수개월 내, 빠르면 한달) 해결이 되지 않을까...합니다.
단어가 많아지면 문법 규칙 만드는 것이 조금이라도 수월해지지 않을까...생각합니다.
이후 느긋하게 품질 향상에 초점을 맞출 수 있을 것 같습니다.
단어가 부족할 경우,,,
단어와 맞춤법 검사 품질을 동시에 신경쓴다는 것이 *모순*이라고 추측합니다.
14만 단어리스트 제공에 각종 법적 문제가 없다면..
제 생각엔 협업을 고려했을 때, 이게 제일 안전하고 빠를 거 같습니다.
개인적인 의견을 검토해 주세요.......
On May 21, 2:00 am, Jiho Han <hanj...@gmail.com> wrote:
> 2009/5/21 Changwoo Ryu <ryu.chang...@gmail.com>:
JiHui Choi
> vi의 기능 중에 찾기, 치환 등 강력한 기능이 있습니다.
> 정규식 표현 적용 가능합니다.
>
막상 해보니 좋은 아이디어가 떠오르지 않네요.
일단은 csv 로 export 한 다음에, 검색을 하여 치환을 해봤는데, 딱히 효율적이지가
않은 것 같아서요..
예) '점' 을 검색하여(gedit 에서 해서 정규식 미적용)
하나씩 단어를 보면서 '점'으로 끝나면서 명사인 경우
'점,,명사'로 변환.
(실제로는 바꾸기 대화상자를 띄워놓고 '찾기' 버튼을 눌러 보고 맞으면 바꾸기 버튼,
아니면 찾기 버튼.. 그렇게 해봤습니다.)
--
Regards,
JiHui Choi
----------------------------------------------------
http://Mr-Dust.pe.kr
Changwoo Ryu
로 문서화하지는 않았는데요. hunspell-dict-ko 소스 안에 갈퀴 데이터를 새
로 가져올 수 있는 스크립트가 있습니다. 당장 2,3일 내에 업데이트된 단어를
쓰고 싶으시다면 직접 받으셔도 될 듯.
전부 받으려면,
$ python utils/dumpgalkwi.py -a dict-ko-galkwi-new.xml
(성공하면)
$ mv dict-ko-galkwi-new.xml dict-ko-galkwi.xml
$ make
(하면 새로 aff/dic 파일 생성)
문제는 받는 과정이 안정적이지가 않아서 쉽게 timeout을 넘어가서 다시 처음
부터 받기도 하는 이상한 동작을 합니다. urllib 애러 체크하기 귀찮고 재현
도 쉽지 않고 해서 남겨뒀는데 보통 성공합니다.
2009-05-20 (수), 12:38 -0700, Hodong Kim:
--
Changwoo Ryu <ryu.ch...@gmail.com>
Hodong Kim
On Thu, 2009-05-21 at 09:20 +0900, JiHui Choi wrote:
> 2009/5/21 Hodong Kim <hodo...@gmail.com>:
> > vi의 기능 중에 찾기, 치환 등 강력한 기능이 있습니다.
> > 정규식 표현 적용 가능합니다.
> >
vi로는 정규식으로 해당 부분을 찾고 치환(바꾸기)을 했습니다.
1만개에서 찾기하면 수천개 나옵니다. 그걸 일일이 눈으로 보고 1초 이내에
판단하고 1초 이내에 치환 또는 라인을 삭제한 겁니다.
> 죄송한데, 실제로 어떻게 작업하신지 알려주실 수 있으신지요?
> 막상 해보니 좋은 아이디어가 떠오르지 않네요.
>
1만개 정도는 수작업으로 하는게 나을 것 같다는 개인적인 판단,
10만개 이상은 스크립트 또는 프로그램을 만들어서 처리하는 것이 나을 것 같
다는 개인적인 판단.
제가 능력이 부족해서 단순한 스크립트 또는 단순한 프로그램을 만들려면 단
순하더라도 10시간 이상이 걸립니다. 그래서 철저히 수작업으로 했습니다.(저
는 프로그래머가 아니랍니다.)
4천개로 추리는데 소요된 시간은 연속 10시간 + 연속 10시간시간 가량입니다.
합 20시간 소요된 것 같습니다.
> 일단은 csv 로 export 한 다음에, 검색을 하여 치환을 해봤는데, 딱히 효율적이지가
> 않은 것 같아서요..
>
> 예) '점' 을 검색하여(gedit 에서 해서 정규식 미적용)
> 하나씩 단어를 보면서 '점'으로 끝나면서 명사인 경우
> '점,,명사'로 변환.
> (실제로는 바꾸기 대화상자를 띄워놓고 '찾기' 버튼을 눌러 보고 맞으면 바꾸기 버튼,
> 아니면 찾기 버튼.. 그렇게 해봤습니다.)
일단, 1000개 * 4개 파일까지는 그냥 무식하게 수작업으로 하면 좋을 것 같습
니다. csv 파일로 vi 만을 이용하여 정규식으로 품사를 입력하려면 무척 골치
아픕니다. grep, |, > 등을 적절히 이용하면 될 것 같기도 한데, 정확하게 품
사를 자동 분류해내지 못하니까 스트립트 만드는 것이 힘듭니다. 수시간을 소
비하여 만들었다 해도 결과물이 안 좋을 가능성도 있고요. 어차피 또 수작업
으로 확인을 해야 되니까. 품사 분류는 제 능력으로는 못 합니다.
일단, 명사가 제일 많으니까... ods 파일로 export 해서 품사 부분을 명사로
도배하는 것은 어떨까요.
의견이 나와서 하는 이야기인데...14만개 작업할 때에는 작업 전에 스크립트
또는 단순 허접한 자바 프로그램이라도 만들어서 선처리할 것을 검토*만* 해
보겠습니다. 예상 외로 투명한 절차와 투명한 처리로 더 빠르게, 더 안전하게
작업이 완료될 지도 모르겠군요. 14만개에서 필터링 하는 작업은 한 달이 걸
릴 지도 모릅니다. 일단 *검토만*이라도 해보겠습니다.(저는 프로그래머 아니
니까...허접하다고 놀리시면 안되요^^)
김남형
일단, 1000개 * 4개 파일까지는 그냥 무식하게 수작업으로 하면 좋을 것 같습
니다. csv 파일로 vi 만을 이용하여 정규식으로 품사를 입력하려면 무척 골치
아픕니다. grep, |, > 등을 적절히 이용하면 될 것 같기도 한데, 정확하게 품
사를 자동 분류해내지 못하니까 스트립트 만드는 것이 힘듭니다. 수시간을 소
비하여 만들었다 해도 결과물이 안 좋을 가능성도 있고요. 어차피 또 수작업
으로 확인을 해야 되니까. 품사 분류는 제 능력으로는 못 합니다.
일단, 명사가 제일 많으니까... ods 파일로 export 해서 품사 부분을 명사로
도배하는 것은 어떨까요.
--
Regards,
Namhyung Kim
Jiho Han
지금 든 생각입니다만, 다음 1만 단어들부터는 필요한 작업들을 작게 분할해서 공장제 분업! 처리하면 어떨까 싶은데요.
한 사람이 많은 양의 원 소스 단어들을 처음부터 끝까지 일괄적으로 처리하는 일은 아무래도 보통 힘든 일이 아닌거 같습니다.
일단, 현재 1만개씩 묶여있는 소스 단어들을 200개씩으로 나눠서 50분할하는 겁니다. 기존 파일이
ko_words_00.txt 였다면, ko_words_00_00.txt ... ko_words_00_49.txt 이렇게
50개로 나누는 거죠.
그리고 각 조각들을 다음의 4개의 파이프 라인을 거치도록 하는 겁니다. 각 파이프 라인 작업은 각각 다른 분이 맡아서
분업하는게 좋겠습니다. 총 50 개 단어 묶음 x 4 파이프 라인 = 200 개의 처리해야할 작업 조각이 생기게 됩니다.
1. 단어 삭제 및 단어 확장 단계
- 이미 갈퀴에 추가된 단어들을 제거합니다.
- 명백히 추가될 수 없는 단어들에 대해 앞에 'X' 자를 붙여 제거 표시를 해둡니다.
- 명사 -> 동사 등의 확장이 가능한 경우 이를 추가합니다.
2. 1번 단계 결과물 검토
- 1번 단계에서 표시해둔 내용을 다시 확인하고 검토합니다.
- 검토된 불필요한 단어들을 제거합니다.
3. 품사 및 속성 태그 추가
- 2번 단계 결과물에 대해서 각각 품사와 속성 정보를 기입합니다.
4. 품사 및 속성 태그 검토 및 CSV 작성
- 3번 단계의 결과물의 내용을 검토해서 확정한 후
- 이를 CSV 로 변환하여 창우님께 전달합니다.
그후 최종 결정권자 창우님이 내용을 한번 쓰윽-_-훑어 보시고 문제 없다고 생각되면 갈퀴에 확! 추가하시는 겁니다.
단어를 200개씩 쪼개서 작업하면 하나의 작업 단위가 그렇게 크지 않기 때문에 금방 금방 더 쉽게 성취감을 느끼면서 단어
추가를 할 수 있지 않을까 싶습니다.
분업을 위해 다음과 같이 50 x 4 크기 표를 만들어서 작업 분담을 하죠. 시작하기 전에 각자 작업을 하고 싶은 부분에 본인
이름을 적어서 중복 작업이 없도록 합니다. 완료가 되면 그 부분의 배경색을 녹색으로 변경합니다. 이렇게 하면 다른 분이 그
다음 파이프 라인 작업을 시작할 수 있다는 걸 쉽게 알 수가 있고 전체적인 작업 진행 상황도 쉽게 파악이 가능합니다. 많은
분들이 참여하기도 쉽죠.
http://spreadsheets.google.com/ccc?key=rpsytD4rNMBACrxaA_FEjXw
단어 목록 파일들을 git으로 공유하고 디렉토리별로 각 파이프 라인의 중간 산출물들을 공유하도록 하면 될 것 같습니다.
pipeline_00/ pipeline_01/ pipeline_02/ pipeline_03/ pipeline_final/
그런데 git으로 공유하면 엔지니어가 아니신 분들이 작업에 같이 참여하시기 좀 어렵지 않을까 싶은데요. 더 나은 방법이
있을까요? 기존처럼 구글 Docs로 만드는 것도 방법이긴 합니다만..
아니면 중간 산출물들을 그냥 업로드 공간에 두고 업로드 다운로드로 작업해도 될 것 같습니다. 그쪽이 많은 분들이 접근하기 더
쉬울 것 같습니다. 구글 Docs도 CSV import/export가 되니 그렇게 해도 되고요.
어떻습니까? :)
JiHui Choi
> 1. 단어 삭제 및 단어 확장 단계
> - 이미 갈퀴에 추가된 단어들을 제거합니다.
> - 명백히 추가될 수 없는 단어들에 대해 앞에 'X' 자를 붙여 제거 표시를 해둡니다.
> - 명사 -> 동사 등의 확장이 가능한 경우 이를 추가합니다.
>
Jiho Han
생각해보니 아무래도 좀 복잡한 작업이 되겠군요. 최종 단계에서 갈퀴에 업로드할 때 걸러질 수 있으니까
일단은 그대로 두는게 어떨까 싶습니다.
2009/5/21 JiHui Choi <jihui...@gmail.com>:
Hodong Kim
On Thu, 2009-05-21 at 17:52 +0900, Jiho Han wrote:
> 처음에는 CSV 형식으로 내려 받은 다음에 hunspell -l 을 쓰고 diff를 돌려서 파악하면 어떨까 했는데,
> 생각해보니 아무래도 좀 복잡한 작업이 되겠군요. 최종 단계에서 갈퀴에 업로드할 때 걸러질 수 있으니까
> 일단은 그대로 두는게 어떨까 싶습니다.
최종 업로드할 때 아래의 방법으로 걸러낼 수 있습니다.
> 2009/5/21 JiHui Choi <jihui...@gmail.com>:
> > 2009/5/21 Jiho Han <han...@gmail.com>:
> >> 1. 단어 삭제 및 단어 확장 단계
> >> - 이미 갈퀴에 추가된 단어들을 제거합니다.
> >> - 명백히 추가될 수 없는 단어들에 대해 앞에 'X' 자를 붙여 제거 표시를 해둡니다.
> >> - 명사 -> 동사 등의 확장이 가능한 경우 이를 추가합니다.
> >>
> > 갈퀴에 있는지 여부는 어떻게 확인하는지요?
> >
칼퀴 데이터를 아직 꺼내보지 않아서 확신할 수는 없지만,
만약,
xml 로 되어 있고, 표제어 부분이 <tag>표제어</tag>로 되어있다면,
중복 제거 작업에는 별로 문제가 없습니다.
* vi 를 사용하여
<tag>표제어</tag> 중에서
<tag></tag> 만 제거할 수 있습니다.(정규식 사용)
과거에 모사이트에서 남이 만들어 놓은 정규식을 발견하여 사용했던 기억이
납니다. 사이트 찾기가 어렵고, 정규식 만드는게 어려우면
vi 설명서 보고 만들어도 되고요.
** 두번째 방법으로는
(제가 스크립트를 거의 못합니다.)
java 프로그램 간단하게 만들어서
<tag>표제어</tag>에서 표제어만 끌어올 수 있고,
*** 아...세번째 방법....
그냥 grep 로 검색하면 되겠네요.
단순 무식하게 예를 들면
(아래처럼 그대로하면 작동 당연히 안되고요)
while(!EOF)
{
read_line 표제어 in csv파일
if ( (grep 표제어 갈퀴DB파일) = true )
cat 표제어 > 갈퀴중복제거파일
}
1,2,3 중에 소스코드 만들기 제일 편한걸로..;;;
하면 될 거 같네요.
(옛날에 그냥 취미로 프로그래밍 조금해서 기억이 가물가물하네요)
(놀리기 없기에요^^ , 저를 전문가라고 착각하여 저를 대략난감한 상황에 만
들기 없기입니다.)
JiHui Choi
> 1,2,3 중에 소스코드 만들기 제일 편한걸로..;;;
> 하면 될 거 같네요.
> (옛날에 그냥 취미로 프로그래밍 조금해서 기억이 가물가물하네요)
> (놀리기 없기에요^^ , 저를 전문가라고 착각하여 저를 대략난감한 상황에 만
> 들기 없기입니다.)
>
일전에 전문가 논란이 있긴 했습니다만, 최소한 저에게 있어서는..
제가 알아 들을 수 없는 말을 하는 사람은 죄다 전문가입니다. ㅋㅋㅋ
Changwoo Ryu
> 아, 한가지 궁금한 점이 있습니다. 명사 중에는 '~하다'와 '~되다'가 붙어서 동사로 쓰일 수 있는 경우가 많은데요,
> 이럴 경우에 동사형도 같이 만들어서 넣어 줘야 하는 거죠? 지금 보니, 제일 앞부분만 해도 '가용'이라던가 '가출', '각색'
> 등등의 명사들이 보입니다.
네 별도 동사로 만듭니다.
--
Changwoo Ryu <ryu.ch...@gmail.com>
Hodong Kim
4천개 만큼은 월요일까지 어떻게든 해보려고 했는데...
도저히 일이 손에 잡히지 않습니다.
저는 당분간 쉬겠습니다. 죄송합니다.
On May 21, 10:15 am, Hodong Kim <hodong...@gmail.com> wrote:
> 안녕하세요.
>
> On Thu, 2009-05-21 at 09:20 +0900, JiHui Choi wrote:
> > 2009/5/21 Hodong Kim <hodong...@gmail.com>:
Jiho Han
> 저의 정신적 지주가 세상을 떠나셔서
> 4천개 만큼은 월요일까지 어떻게든 해보려고 했는데...
> 도저히 일이 손에 잡히지 않습니다.
> 저는 당분간 쉬겠습니다. 죄송합니다.
저도 주말 내내 일을 하나도 하지 못했네요.
저 개인적으로 작업 속도를 좀 늦출 수 밖에 없겠습니다.
이번 여름은 참 뜨거운 계절이 될 것 같습니다.
Changwoo Ryu
> >
> > 그리고 기록 목적도 있고 구글에 대한 credit을 남기는 게 좋을 것 같은데,
> > 주석에 한 줄 추가해야 겠네요 추가하면 합니다. "(google.co.kr
> > ko_words.00)" 이러면 될까요.
특정 패턴의 단어를 입력하신 ruseel님의 연속 입력 단어들에 (2009 Google
Korea 제공) 문구를 추가했습니다.
"~나무"
"~히"
"~록"
--
Changwoo Ryu <ryu.ch...@gmail.com>