@sinbi 좋은 말씀 감사합니다.
디자인은 살짝 네이버를 오마쥬로 하였습니다.
디자인은 화려함보다는 차후의 확장성을 고려하여 심플하게 하였기도 하거니와
디자인에 추가할 인적 비용적 자원과 내부 능력이 부족하여 이렇게 선택하였습니다.
또한 저 같은 경우 헤드 코더로서 프론트, 백, 서버, 데몬 (JS, PHP, Linux, Daemon)
다 신경쓰다 보니 디자인 쪽은 여력이 만만치 않네요.
말씀주셔서 감사합니다!

서비스의 모토가 평화인지라 평화의 상징인 푸른색을
테마로 하는 것으로 내부결정이 났습니다.^^;
저도 블랙 앤 화이트면 유지보수도 좋고 누가 합류하더라도
대응하기 쉽기에 좋은 방법이라고 생각합니다. ㅠㅠ

감사합니다!

넵. 접속자가 생겨나고 콘텐츠가 늘어나면
그에 따라 나열할 디자인거리가 생기겠지요.^^

말씀 감사합니다.

넵. 일단 데스크탑 버전만 완료입니다. 모바일은 아예 막아두었습니다.
그리고 컨텐츠는 번역이 안되는 것이 아니라 번역 영역은 두가지입니다.
인터네페이스와, 말씀하신 컨텐츠로 나누어 집니다.

모바일에서는 아쉬운데로 가로 모드로 해서 보시면 대략 해상도가 좌우
다 보실 수도 있지 않을까 합니다. 물론 디바이스에 따라 다르겠습니다.

그리고 번역은 실시간으로 되는 것입니다.
이 실시간 이라는 것은 클라이언트 단에서 언어를 선택하면 번역을 해서
보여주는 것이 아니라 커뮤니티 기능 그러니까 게시판의 글과 댓글을
작성하면 데몬이 DB내의 스트링을 번역해서 다시 Insert 및 Update 하게
됩니다. 그러니까 결국은 사전에 번역되는 시스템이며 중복번역되지
않습니다.

크롬 브라우저의 페이지 번역과는 다르게 DB 단에서 이미 번역되어
있는 것을 출력해 주는 것입니다.


모바일 마크업 개발이 제일 시급한 문제입니다.
관심 가져주셔서 감사합니다.

기획 단계에서 그누보드와 JQuery 정도를 제외하고는

외부 코드를 최소한으로 줄이고자 하였습니다.

부트스트랩이 좋긴 합니다만 저희 쪽 마크업의 취지는
올드해 보일지라도 심플하고 단순하고 기억에 남을 수
있는 색의 강조이고 리뉴얼의 배제를 염두해두고 시작한
프로젝트이기에 콘텐츠가 늘어나면 이 기조에서 그냥
확장만 해 나간다는 식입니다.

시급히 모바일 웹 페이지를 추가하도록 하겠습니다.

관심 감사합니다!

@프로그래머7 감사합니다! 과찬의 말씀이십니다.

안녕하세요.

곡해하신 듯 싶어 말씀드립니다만 저희 회사의 독자적인 번역 엔진은
아닙니다. 구글에 약간의 소극적인 지원 아래 API를 이용, 자체적으로
개발한 좀 더 진보된 기계 번역 모듈 정도로 생각하시면 되겠습니다.

번역 엔진과 웹프로그램의 분야는 또 개별인지라 그렇게 되었습니다.
2000년 즈음부터 ASP, PHP 등을 거쳐서 웹프로그램을 개발해온 경력이
있긴 합니다만 여러가지 보안 이슈에 대한 대응과 표준 등의 변화로 인한
유동성이 존재하는 웹환경에서는 많은 개발자 분들과의 소통이 가능한
오픈 코드가 적합다고 판단이 되었습니다.

또한 그누보드는 4버전을 거쳐서 5까지 온 현재, 그리고 계속하여 꾸준히
업데이트가 되고 있다는 점. 그리고 이러한 자산을 SIR 자체적으로 뿐만이
아니라 '한국인터넷진흥원' 등의 여러 기관에서도 모니터링을 하고 있는
만큼 제 개인이나 하나의 사업체 차원에서 디버깅 하는 것보다 훨씬 더
효율적이고 안정적인 관리가 가능하다고 판단하였습니다.

제 생각에 그누보드는 단순한 게시판 로직이라고 부르기에는 많은
노하우가 집약된 코드라고 판단됩니다. 글쓰기, 읽기, 페이징하기, 코멘트.
여기 계신 베테랑 분들 대부분께서 쉬이 작성하실 수 있는 코드라고
사료되긴 합니다. 하지만 여기 모인 우리가 기꺼이 그누보드를
선택한 이유는 이러한 간단한 로직 속에서도 다양한 사용자 환경에서의
클라이언트에 의하여 보고되는 이슈와 이로 인한 해결. 공개된 토론을
통한 발전 가능성 등의 이유 때문이 아닐까 합니다.

저는 결코 그누보드가 단순한 게시판 코드 뿐이라고는 생각지 않습니다.
그 어떤 뛰어난 개발자가 존재한다 할지라도 집단지성만 못 하다고
생각합니다. 그리고 저는 훌륭한 개발자도 아니기에 웹 프로그램에서
그누보드의 힘이 필요하였습니다.

말씀 감사합니다.
그누보드가 대단한 것입니다.
저는 그 토양 아래 혜택을 누렸을 뿐입니다.
SIR 에 감사할 따름입니다.

아닙니다. 그럴리가 있겠습니까.
제가 잘못된 단어 선택을 한 것 같습니다.
정확히는 구글의 'Translatoin API'를 사용하였습니다.
다만 구글에서 제공하는 레퍼런스 문서와 코드, 그리고
GitHUB 및 구글 개발자 포럼 등 다양한 개발자 커뮤니티
에서 자료들을 취합해 보았습니다만 원하는 만큼의
결과물을 도출할 수 없어서 API를 이용하는 모듈을
별도로 개발하였습니다.

이 과정에서 구글 캘리포니아, 싱가포르, 서울 등과
다수의 상호 소통도 있었구요.

그러므로 번역의 DB는 구글의 그것에서 파생된 것입니다.
하지만 번역의 결과물은 미묘하게 다릅니다. 간혹가다
구글 번역기에서 삑사리나거나 단락되는 부분을 최소화하여
무결성을 지향하도록 개발하였습니다.
때문에 여러가지 별도의 알고리즘을 거치기 때문에
저희 번역 서버에서 상주하고 있는 데몬 프로세스의 성능은
개선의 여지가 많이 남아 있습니다.

그리고 구글 번역기가 만능은 아니라고 생각됩니다.
특히나 중국어 부분에서는 Bing 번역기가 일부 뛰어난
결과물을 보여주기에 하이브리드로 사용하는 것도 검토 중
입니다.

저 그냥 보통~ 사람입니다. 오해 않으시길 바랍니다.

과찬이십니다.

그리고 현재의 기성 번역 알고리즘이라는 것도
사실 별 것 없습니다. 방대한 정보를 바탕으로
각 언어별 문법체계로 치환되는 것 뿐입니다.

그 방대한 정보를 쌓는 것이 굉장히 많은 비용과
인원, 시간 등이 소모되기 때문에 쉬이 할 수
없는 것이겠지요.

관심 감사합니다!

번역 알고리즘이라는게 사실 업체별로 큰 차이없이
누가 많은 DB를 가지고 있느냐 이고, 차이가 있다면
문법 체계 대응이 얼마나 정교하냐 정도겠지요.
여기서 구글의 신경망 기반 자연어 번역 알고리즘
정도가 요즘의 뜨거운 감자가 되겠습니다.

이렇게 선두 기업들이 발판을 마련해두고 고맙게도
서비스 자체를 오픈해 주니 저같은 평범한 개발자들은
그로부터 파생되는 버그들만 다잡아 주면 되는 것인지라
참으로 좋은 세상인 듯 싶습니다.

감사합니다.

저는 반대라고 생각합니다.
SIR에서 그누보드를 통하여
저희에게 날개를 달아 주셨다고
생각합니다. ^^

해당 게시물은 사실 1년 전 즈음에 API를 돌린 것입니다.
게시물 날짜랑은 좀 상이한 점이 있습니다.

지금 다시 한번 게시물 수정으로 돌려보았습니다.
구글 번역과 동일한 결과물이 나오네요.

그리고 클라이언트가 작성한 원래의 텍스트는 '컨텐츠 언어'
선택 부분에서 '원문'을 선택하셔야 정확히 보실 수 있습니다.

지금 출원 중인 특허건과 관련하여 여러가지 기술이 있어서
상세히 말씀드리긴 힘듭니다만 번역 보정과 관련된 여러가지
알고리즘이 삽입되어 있습니다.

절권도님의 의문 부분은 이렇게 생각하시면 되겠습니다.

구글 번역 DB의 버전이 4.0 일때 번역한 결과물과
구글 번역 DB의 버전이 7.0 일때 번역한 결과물은
상이하다. 라는 데이터 베이스의 발전을 참고하시면 됩니다.

구글과 협업하는 입장에서 이런 말을 하긴 좀 그렇지만
구글의 번역엔진과 이를 비롯한 그들이 현재 내세우고 있는
인공지능 혹은 신경망 AI 등은 사실 방대한 DB를 수집하여
구축한 거대한 노하우의 집약체로 이해하는 쪽이 맞을 듯
합니다. 약인공지능에서 아직 한발짝도 더 나아가지
못 하였다고 보는 쪽이 타당하다고 사료됩니다. MS는
후발 주자가 되겠구요. 우리가 좀 더 유심히 관찰해야할
업체는 IBM 입니다. 그들은 스스로가 무엇을 하고 있는지
조차 정확히 공개하고 있지 않지요. 하지만 다수의
업계인들은 뭔가 심각한 것을 준비하고 있다고
추측 중 입니다.

그동안 게시판이나 SNS 등의 유동적 데이터베이스 상에서의
실시간 번역 서비스가 완벽한 형태로 등장하지 않았던 이유가
절권도님께서 말씀하신 그냥 (API 등을 거쳐서) 번역하면
되지 않는가. 하는 방식의 알고리즘이었기 때문입니다.

이런 식으로 개발된 코드에서는 클라이언트가 게시물을
작성하고 확인 버튼을 누른 후 브라우저를 바로 닫아버리면
데이터가 훼손됩니다. 때문에 데몬 프로세스가 필요하겠지요?^^

CURL 이 간단하지 않을까 하고 생각하실 수 있겠습니다만
다양한 OS에 대응하기 위해서 다수의 플랫폼에서 운용
가능한 별도의 데몬의 개발이 필요하였습니다. CURL 도
호환성 좋고 괜찮긴 합니다만 여러가지 알고리즘에 의한
코드 첨가가 필요하다 보니 별도의 프로세스를 개발하게
되었습니다.

또한 DB 입력 후 데몬을 통하여 선번역 처리하지 않고
그냥 클라이언트가 페이지를 열람할 때 마다 번역처리를
그때 그때 해주게 되면 이는 패킷, 서버 자원 등의 막대한
소모가 필요합니다. 때문에 리얼타임 선번역이 필요한 것
입니다. 양단의 장단점이 존재합니다만 구글이나 MS를
제외하고는 음..., 좀 더 좁혀서 대한민국 내의 그 어떤
업체도 페이지 번역식 커뮤니티 서비스를 개발하고
이 비용을 감당할 사업체는 없다고 말씀드릴 수 있겠습니다.
(N사 조차 말이지요.^^)

현재 4건의 특허를 특허법인에 의뢰하였고 해당 법인에서
검토한 결과, 최종적으로 10 여건의 특허를 출원 중입니다.

많은 궁금증을 가지심에 당히 이해가 갑니다만 여러모로
부연 설명을 나열해 드리기가 힘든 점 이해 부탁드립니다.

단지 저 혼자서 개발한 작업물이라면 모르겠습니다만
그런 것도 아니거니와 더 많은 부분을 말씀드렸다간
저 잘려요...^^;

회사의 경영 대표님은 따로 계십니다.
저는 그냥 기술 대표입니다.
(원래 IT 회사는 아니고 새로운 사업부를 만들면서 제가
참여하게 되었고 첫번째 모델로 금번 서비스가
개발된 것입니다.)

관심 감사합니다!

@절권도

절권도님, 자기전에 중요한 부분을 빠트린 것이 생각나서 다시 첨언합니다.
현재 구글의 번역 API는 크게 두가지로 나뉠 수 있습니다.

일단 우선에 구글 번역기 자체에 대한 설명이 필요합니다.

기존의 구글 번역기가 존재하였으며 이 것이 점 점 더 진화하여
이제는 'Neural Machine Translation System' 이라고 명칭을 붙인
좀 더 정확한 결과를 보여주는 번역 엔진이 제공되는 중입니다.

허나 기존의 구글 번역기에서 100개가 넘는 언어를 지원하던 것이
대폭 축소되어 20개 가량의 언어가 지원이 됩니다. 그러나 다행이도
한국어, 중국어, 일본어, 영어 등 한국에서 필요로 하는 대다수의
언어권을 지원합니다.

그리고 이러한 '신경망 번역'은 일반 구글 번역기 웹페이지에서
이에 해당하는 언어를 번역하고자 할 경우 자동적으로 적용됩니다.

하지만 번역 API의 경우는 다릅니다. 아직 구버전의 번역기가
기본적으로 작동되며 NMT(신경망 번역)는 베타 서비스 중이며
이 서비스는 프리미엄 에디션이라는 명칭으로 일부에게 그리고
작은 자원만 할당하고 있으며 말 그대로 테스트버전 입니다.
따라서 NMT를 커뮤니티에 적용하기에는 키가 부족한 상황입니다.

때문에 현재 구글의 가장 진보된 번역 DB를 공개적으로
사용하기에는 시일이 다소 소요될 예정입니다.

(이 부분을 적용하는 것에는 JSON 요청시 단순히 파라미터 값
하나만 추가하면 됩니다. 때문에 구글측의 NMT API 서비스에
대한 준비가 원활해 질 때 저희도 함께 적용될 것입니다.
현재는 개발자를 위한 베타 서비스에만 참여 중입니다.)