기상청, 오픈소스 채용

hey의 이미지

국가 종합기상정보시스템, 오픈 소스가 맡는다라는 기사입니다.

새로운 종합기상 정보시스템인 COMIS-3에 오픈소스를 사용한다는 얘기인데, 별로 자세하게 나와있진 않습니다. 그보다는 Web 2.0 관련한 이슈일지도 모르겠는데요,

Quote:

이 프로그램을 통해 업데이트된 자료는 웹에서도 사용되어 사용자들에게 세밀한 예보 서비스를 할 수 있다. 이 자료는 또한 기상 연구개발에도 사용될 수 있다.

라는 듣기 좋은 소리를 하고 있군요. 두 이슈 다 관심이 있는 내용인지라 퍼와봤습니다. :]

별로 열심히 기사를 보고 있는 건 아니고, GDS 4가 뉴스를 계속 띄워주기 때문에 관심있는 제목만 하루에 한 두개 쯤 열어보는 정도입니다.

keizie의 이미지

http://kz.mpecc.com/moniwiki/wiki.php/%B1%E2%BB%F3%C3%BB 에 제가 겪은 일을 적어뒀습니다.

내부 시스템으로 뭘 쓰는지는, 실제로 느낄 수 있는 기상청의 서비스 수준과는 다른 얘기입니다. 지금도 http://web.kma.go.kr/parti/qna/custom_02.jsp?page=3&num=69&mode=view&field=&text=&order=&dir=&bid=QNA&ses= 같은 걸 보면 (구글에서 xml site:kma.go.kr로 검색해서 나온 내용입니다) 전혀 바뀐 점이 없는 걸 확인할 수 있습니다.

도대체 기상청의 웹을 관리하는 사람은 그 단순한 .htaccess 조차 모르는 건지 의문이 듭니다. 기본이 없이, 파워포인트로 끄적거려 만든 화려한 서비스 구성도는 무의미합니다.

hey의 이미지

그래도 별 한개 주시니 마음이 ... OTL

May the F/OSS be with you..



----------------------------
May the F/OSS be with you..


wish의 이미지

서비스 마인드가 좋지 않다는 것과 내부적으로 오픈 소스를 사용하는 것과는 다른 문제라고 생각합니다만...

"파워포인트 끄적거려서 만든 서비스 구성도" 는 ".htaccess 조차 모르는" 경우엔 무의미 해지는 군요.

간단한 웹 서비스 관리 조차 허술하면서 서비스 구성도만 번지르한 것은 욕먹을 만한 일일 수도 있겠지만

내부적으로 오픈소스 사용하는 것과는 별 개의 문제입니다.

더욱이 웹 서비스 관리랑 서비스 구성도가 화려한 것도 완전히 다른 문제라고 생각합니다.

님께서 나쁜 서비스를 받으신 것은 충분히 이해가 되고, 공론화 할 만한 문제라고 생각합니다만,

당최 서비스 문제와 오픈소스 도입이 무슨 관계가 있는지 궁금합니다.

익명사용자의 이미지

구성원의 마인드가 되어있지 않는데 오픈소스 사용으로 인한 어떤 상승효과 혹은 부수효과를 기대할 수 있을까요?

제가 보기에도 암담하네요.

hey의 이미지

제가 포스트를 올릴 때 두 가지 이슈로 해서 올렸습니다. 하나는 '솔루션에 오픈소스를 채택했다'. 또 다른 하나는 '더 나은 공개된 서비스'입니다. 그런 내용을 적은 이유가 kz님이 소개하신 위키 페이지를 읽고, 이제 바뀌지 않을까? 하는 관심에서 올린 것이었고요, 이 포스트를 최근에 읽기도 해서, 제 따름엔 변화를 감지했다 싶어서 올린 것이었던 거죠.

kz님 반응을 보니 시기상으로 보아 근본적인 변화가 있는 것은 이해 했습니다만..

그런 뒷 이야기가 있다는 얘기였습니다.

May the F/OSS be with you..



----------------------------
May the F/OSS be with you..


noricube의 이미지

http://www.digital.go.kr 가보시면 각지역 예보별로 RSS를 받아보실수 있습니다.
문제는 ActiveX를 설치해야 -_- 지역에 RSS주소를 알수있다는거죠.
처음에 불편함만 감수하시면 그뒤는 편하게 받아보실수 있긴 합니다.

keizie의 이미지

구글에서 site:digital.go.kr rss로 검색하니 두 개가 나오네요. wine으로 ie 띄워서 사는 곳의 url은 알아냈습니다.

주소를 알아내는 방법이 있으면 좋겠군요. 네이버 지도와 연동해서 그 지역의 url을 다른 방법으로 알아낼 수 있을까 모르겠습니다.

RSS를 생성하는 주소를 보니 숫자가 일률적이라, 동 이름과 번호로 찾아봤습니다. http://www.ngic.go.kr/DOWN/OpenDown/dong.txt 이런 게 덜컥 나옵니다. 이로써 row, column, region, locationcode 네 개의 변수 중 하나는 무슨 값인지 알게 됐습니다.

http://www.ngic.go.kr/NGIC3/user/help/UseProcess_3.jsp 여기를 보니 row, column, region이 어떤 값인지 대충 파악은 됩니다. 온전한 rss url에서 값을 바꿔보니 날씨가 다르게 나오더군요. locationcode는 다른 세 변수와 무관한 것 같았습니다. 세 개로 표현되고 동작구 동작동이 125, 60, 1의 값을 가지는 지리정보가 어떤 게 있나요? 울릉군 북면은 129, 127, 31입니다. 지리에 밝으신 분께 설명 좀 부탁드립니다.

Necromancer의 이미지

기상청 작업하는 사람입니다.
서버나 홈페이지 작업은 아니고 홈페이지에 음성들어가는 작업을 하고 있죠.
요새 정부에서 접근성이라고 이야기하는 작업인데
정확히 말하자면 "시각장애인 접근성"입니다.
비 IE 브라우저를 위한 "접근성"은 신경 쓸 리가 없죠.

일단 사람들이 브라우저 하면 "인터넷 익스플로러"밖에 모릅니다.
"갑"에 해당되느 공무원들, 공사직원들은 전부 다 모른다고 보면 됩니다.
공공기관 이곳저곳 다니면서 작업하는 동안 "파폭" 얘기 꺼내는
사람은 충남교육청에 있는 개발자 한분밖에 못봤습니다.

그리고 개발자가 파폭이나 오페라같은 다른 브라우저까지 지원하게 하고 싶어도
일단 위에서 개발시간 자체를 빠듯하게 주면 대책 없습니다.
또 시간 여유 있어도 같이 작업하는 팀원들도 "파폭이 뭐에요?", "그런거 왜신경써요"
설득하기 난감하고요. (회사내에 파폭 쓰는 사람이 저밖에 없음 -_-;)

그리고 말하기는 거시기 하지만 제가 작업하는 거도 물론 IE 전용입니다.
(현재 웹페이지 음성은 다 activex로 받아오기 때문에 이거는 피할 수 없죠.)
언젠간 리눅이에서도 음성 지원되는 모듈 만들여볼려고 생각 하고 있지만 시간이빠듰하니 -_-;

하나 더.
기상청 홈페이지 작업실도 지하 구석에 처박혀 있어요 -_-;

Written By the Black Knight of Destruction

Written By the Black Knight of Destruction

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

시각장애인들은 보통 스크린 리더를 사용할텐데, 그러면 웹페이지에 ActiveX로 삽입한 TTS과 충돌하지 않나요?
http://hyeonseok.com/soojung/web/2006/10/17/296.html

han002의 이미지

시작장애인을 위해서 꼭 파폭용 웹페이지를 만들 필요는 없습니다.
외국꺼는 모르겠는데 국내 스크린리더는 파폭에서는 잘 동작하질 않더라구요.(요즘은 바뀌었나?)

다만 시각장애인용을 따로 만들기 보다는 플래시 메뉴대신 그림메뉴(그림 삽입시 alt로 스크린 리더서 인식가능하게)로 바꾸고 탭키로 이동 가능하게 해주면 이것만으로 꽤 편하게 사용가능합니다.


그러고 보니 액티브액스와 스크린리더 양쪽에서 읽어주면 난감해지는군요..

..

죠커의 이미지

한국의 스크린 리더는 한국의 엉터리 사정에 맞추어서 구현된 부분도 많습니다. 비용의 낭비이죠.

- CN의 낙서장 / HanIRC:#CN

aero의 이미지

기상청뿐만 아니라 국가적 Digital정보를 관장하는 부서들( 기상청,국토지리정보원 등등)을
보면 생산되는 각종 정보를 담은 문서는 hwp,MS office 파일 형태로 게시판에 덕지덕지
올려놔서 체계적 분류도 없고 웹브라우져만으로 충분히 접근가능한 정보를 별도의 reader,
상용프로그램을 사용해서 다시 봐야하는등 접근성이 떨어지게 만들고...

어떤 시스템을 구축한다고 쳐도 자신들이 제공하는 ActiveX혹은 Java applet등의 폐쇄적
인터페이스를 통해서만 정보에 접근 가능하게 해서 접근성을 떨어뜨리고 정보의 손쉬운
2차적 가공을 힘들게합니다.

우리나라의 공공기관들을 보면 아직 정보의 표준화,체계화,집약화에 대한 개념이 없고
그리고 국민의 세금으로 구축되고 서비스되는 정보라면 그 정보는 국민들의 것이고
당연히 그 이득은 국민에게 돌아가야하는것임에도 어떤 기관이 구축한 정보는 무슨 신주단지
모시듯 폐쇄된 인터페이스를 통하지 않고는 접근하지 못하게 하며 그 정보가 자신들의것인냥
다른 사람이 가져가서 사용하는것에 거부감 같은걸 가지고 있는것 같습니다.

정보의 가치는 화려한 인터페이스에서 나오는게 아니라 어떻게 표준적으로 정규화시켜 접근성과
재사용성을 높여 정보의 시너지효과가 창출 될 수 있게하는가에 달려있다는 사실부터 정부기관
관리자들이 깨달아야 할것입니다.

로미의 이미지

여러 댓글을 보니 우리나라와 미국의 자판 표준이 생각 나는 이유가 뭘까요...
미국은 쿼티와 드보락이 국가 표준으로 등록이 되어 있다는데 우리나라는 오직 두벌식만 표준으로 해놓은것은...

머리야 늙어서 유연성과 수용성이 떨어져서 그렇겠구나 하고 넘어가면 되겠지만
을(乙)은 머리를 설득할 수 있는 능력과 유연성, 수용성을 잃지 말아야겠습니다.

국가 종합기상정보시스템이 오픈소스라고 해도 GPL 혹은 유사한 라이센스냐 아니냐에 따라 폐쇄적 오픈소스가 될 가능성도 있겠군요.

Signature:
끝까지 읽어 주셔서 감사합니다.(이봐 로미, 뭐가 감사한거야?!)

혹시 댓글로 싸움을 즐기려는 님!?
당신은 眞性 변퉤 입니다~ :P

이제는 무늬만 백수로 가장한 개발자가 아닌 진정한 개발자가 되어야겠다.
이제는 학생으로 가장한 백수가 아닌 진짜 백수가 되어야겠다.

언제나 newbie의 마음가짐.

jeongsam의 이미지

몇몇 표준은 국가가 주도하기보다는 사용자들에 의해 만들어져왔었습니다.
전자우편이 좋은 예가 될 것 같내요. 7bit에서 시작해서 euc-kr로의 안착...
표준 결정력이 사용자의 손에서 떠났던 적은 마이크로소프트사의 한글코드였죠.
세벌식 자판의 경우 정부의 마인드 문제라기보다는 사용자들의 외면이 더 큰 장애가 아니였을까요?
저도 한 때 주위 모든 사람들의 원성 - 제가 사용한 PC는 자판이 고장 난다는 소문이... - 속에서
1년정도 사용하다가 결국은 두벌식으로 돌아왔습니다. 소수의 사용자를 확보한 기술은 표준이 아니라
매니아들의 그들만의 기술이 되고 마는거죠.

논쟁용 글이 아니라 로마님의 글을 읽다가 불현듯 생각이 나서 몇자 그적거려봅니다. ^^;

죠커의 이미지

적어도 드보락의 사용비중에 비해 세벌식의 사용자는 압도적으로 많습니다. 그리고 드보락이 쿼티 배열에 비해서 특출나게 효과적이지도 않습니다. 제 생각엔 정부의 마인드가 가장 큰 문제입니다. 미국이 한글을 썼다면 드보락 조차 표준이 되었는데 세벌식이 표준이 못되었을 이유가 없을 것입니다.
- CN의 낙서장 /
HanIRC:#CN

로미의 이미지

문제는 그 정부의 마인드를 바꿀수 있는
힘이나 지식이 있는 그런 기구나 사용자 그룹 같은 것이 없다는데에 문제가 있는것 같습니다.
세벌식 사용자 모임같은 데라도 정부의 마인드를 바꿀수가 있을지 의문이네요...

Signature:
끝까지 읽어 주셔서 감사합니다.(이봐 로미, 뭐가 감사한거야?!)

혹시 댓글로 싸움을 즐기려는 님!?
당신은 眞性 변퉤 입니다~ :P

이제는 무늬만 백수로 가장한 개발자가 아닌 진정한 개발자가 되어야겠다.
이제는 학생으로 가장한 백수가 아닌 진짜 백수가 되어야겠다.

언제나 newbie의 마음가짐.

ed.netdiver의 이미지

엄한 걸로 CN님의 말씀에 딴죽거는것처럼 보일까봐 염려스럽습니다만,
드보락이 쿼티에 비해 크게 효과적이지 않다는 말씀은 좀처럼 수긍하기 어렵습니다.
CN님도 당연히 써보고 하신 말씀이겠습니다만, 저도 드보락을 2년 조금 못되게 사용한적이 있습니다.
드보락은 모음이 왼쪽에 몰려있어서, 타이핑하기가 무척 편합니다.
마치 한글의 자음모음순으로 세벌식구성이 되있는것과 매우 유사합니다.
결국 다시 쿼티로 돌아왔으되 세벌식은 사용하고 있습니다만,
(개인차이겠지만), 두벌에서 세벌로 옮겼을때보다, 쿼티에서 드보락으로 옮겼을때의 안락함이 확실히 더 컸습니다.

드보락의 가장 큰 문제는 모든 unix 키조합(명령어, 단축키 등등)이 쿼티기준으로 되어있다보니, 그 편한 ls, cd, 그리고 vi의 hjkl 조합조차도 박살이 나버린다는 점이었습니다.
그러나 영문 작성시에는 드보락이 월등히 우수합니다.

전혀 딴죽걸 의도는 아니며, 제가 적은 글때문에 본문 주제와 다른 길로 글타래가 전진하는것도 원치않습니다.
(적으면서도 괜한 소리하는것같단 생각이 떠나질 않네요^^;)
CN님 이해해 주실거죠?^^;

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

병맛의 이미지

흠 제가 공직에 들어가면 니눅스를 '쪼꼼' 써본 '드문' 꽁뭔이 되려나요? =ㅁ=

(문제는 9급이라 아무 힘도 없다는 거... ;;)