• How I Work: Yahoo!’s Doug Crockford On JavaScript

  • 나는 어떻게 일하는가: Yahoo! 더글라스 크록포드의 Javascript

  • note icon
    역자주: 더글라스 크록포드는 오랫동안 야후에서 JavaScript 구루로서 일해오다가 얼마 전(2012년 5월) Paypal 로 자리를 옮겼습니다.
  • Welcome to the first in a new series of interviews called “How I Work”. These interviews revolve around how thinkers and creators in the Web world design, code, and create. The goal is not to get into the specific nuances of their craft (as that information already exists online), but rather step back and learn a bit about their habits, philosophies, and workflow for producing great work.
  • "나는 어떻게 일하는가" 시리즈의 첫번째 글을 읽게되신 것을 환영합니다. 이 인터뷰는 웹세상의 사상가들과 창조자들이 어떻게 디자인하고 코딩하고 창조작업을 하는지에 대해 알아보려고 합니다. 이 글의 목표는 그들의 특별한 기술을 알아보는게 있는 것이 아니라 (그런 글을은 이미 온라인에 많이 있으니까요), 한발짝 물러서서 그들이 위대한 결과물들을 생성하기까지의 버릇, 철학 그리고 그들의 작업의 방법(workflow)에 대해서 배워보려고 합니다
  • Meet Doug Crockford

  • 더글라스 크록포드를 만나다

  • First up is Douglas Crockford who believes JavaScript might just be the most elegant language ever. Learn why he thinks you should study the history of computer science, the value of reading your code in front of other people, and that jQuery really is a good thing.
  • 더글라스 크록포드는 JavaScript가 가장 우아한 언어일지 모른다고 믿습니다. 컴퓨터 과학의 역사를 공부해야하는 이유와, 자신의 코드를 다른 사람들에게 내보이는 것의 가치, 그리고 jOuery가 얼마나 훌륭한지에 대한 그의 생각을 들어봅니다.
  • Douglas Crockford is known as The JavaScript Guy. He’s famous not only for his O’Reilly bookJavaScript: The Good Parts but even more so as the visionary behind the JSON data format as well as the JSLint tool. He was featured in the book Coders at Work for his contributions and philosophies on what JavaScript got right, and what it didn’t.
  • 더글라스 크록포드는 JavaScript 구루로 알려져 있습니다. 그는 O'Reilly에서 나온 JavaScript 관련 저서인 "The Good Part"뿐만이 아니라 (그가 만든) JSLint툴과 JSON 데이터 포맷을 통해서 많이 알려져있습니다. 그는 "Coders at Work"라는 책에서도 JavaScript가 가진 좋은 것과 그렇지 못한 것에 대한 그의 의견과 철학들을 피력하기도 했습니다.
  • As a native of Southern California, Doug has the build of a surfer; lean and tall with white hair and a beard. A veteran of Silicon Valley, he’s worked at Atari Labs, founded and worked at numerous software start-ups, was head of technology at Lucas Films and now has the enviable job of being a JavaScript evangelist at Yahoo!.
  • 더글라서는 전형적인 남부 캘리포니아 사람으로서 백발의 머리와 수염, 마르고 키가 큰 서퍼 체구였습니다. 실리콘 밸리의 베테랑으로 아타리랩에서 근무했으며 수많은 신생 소프트웨어 벤처를 설립하고 일했습니다. 또한 루카스필름의 수석연구원이었으며 지금은 야후에서 남들이 부러워할만한 JavaScript 전도사로 일하고 있습니다.
Image of 1259 article
  • Image credits go to Eric Miraglia.
  • 이미지 저작권: Eric Miraglia
  • Self-taught (as many of the greats are), he says his goal is simply to get more people coding in JavaScript, or any language for that matter. While his day job may be as a JavaScript evangelist, speaking with Doug you get the sense he really is an evangelist for programming in general.
  • 많은 대단한 사람들이 그렇듯이 그는 혼자서 많은것을 깨우친 사람입니다. 그는 그의 목표가 더 많은 사람들이 문제를 해결하기위해서 JavaScript 뿐만아니라 어떤 언어로든간에 코딩을 하게 되는 것이 그의 목표라고 말합니다. 그의 직업은 JavaScript 에반젤리스트 이지만 더글라스와 이야기 하다보면 당신은 그가 정말 프로그래밍 전반에 대한 전도사라는 것을 느낄 수 있습니다.
  • Below is a conversation that took place in Bozeman, Montana prior to a talk at Montana State University. Doug freely shared his thoughts on great programmers, user empathy, and how JSON restored his faith in humanity.
  • 아래 대화는 몬타나 대학교의 대담에 앞서 몬타나 보즈맨에서 나눈 이야기입니다. 이 자리에서 더글라스는 훌륭한 프로그래머들에 대한 이야기와, 유저공감대 그리고 JSON이 어떻게 인간에 대한 신념을 되살려 놨는지에 대해서 자유롭게 이야기하였습니다.
  • WHY DO YOU FEEL PROGRAMMERS SHOULD STUDY THE HISTORY OF COMPUTER SCIENCE?

  • 왜 프로그래머들이 컴퓨터 과학의 역사를 익혀야 한다고 생각하시나요?

  • Well, first semester of physics is a history class. You study Galileo and Newton and all their contributions to the field and that gives us the overall view of physics. It’s a really nice place to start.
  • 물리학에서 첫 학기는 역사클래스로 시작됩니다. 당신은 갈리레오나 뉴턴 그리고 총체적인 물리학의 관점을 우리에게 물려준 공헌자들에 대해 배웁니다. 그리고 그것은 정말 멋진 첫 걸음입니다.
  • I wish CS would do that. It doesn’t seem to have enough value in its history and it’s a really amazing history that’s completely neglected. It’s rarely that the best idea won. So, we’ve taken different paths over the years and maybe haven’t realized why.
  • 나는 컴퓨터 과학도 그럴거라고 생각합니다. 역사안에 모든 것이 있지 않지만 우리가 지나쳐버린 것 속에 놀라운 역사가 있습니다. 그리고 그때문에 우리는 수년동안 잘못된 길을 왔거나 혹은 아직도 왜 잘못된 길임을 깨닫지 못하고 있을지도 모릅니다.
  • Ironically, despite the rate of change in technology, we see in the story of software that it takes a generation to retire or die off before we have a critical mass of bright young minds to embrace new ideas.
  • 아이러니하게도, 기술 변화의 속도에도 불구하고, 새 아이디어가 받아들여질 만큼 새로운 분위기가 정착이 되기까지 한 세대 정도의 시간이 필요하다는 것을 소프트웨어 역사를 통해 보아왔습니다
  • I think if people were more aware of their history, they could see these patterns more easily.
  • 나는 사람들이 역사를 조금 더 주의깊게 본다면 이러한 패턴을 쉽게 발견할 수 있을거라고 생각합니다.
  • WHAT WERE THE TRAITS OF THE WEAK PROGRAMMERS YOU’VE SEEN OVER YOUR CAREER?

  • 능력이 부족한 프로그래머의 특징은 무엇이라고 생각하시나요?

  • That’s an easy one—lack of curiosity. They were so satisfied with the work that they were doing was good enough (without an understanding of what ‘good’ was) that they didn’t push themselves.
  • 쉽게 볼 수 있습니다. 그것은 바로 호기심의 부족입니다. 호기심이 부족한 사람들은 자신이 충분히 잘하기 때문에(잘한다는 것에 대한 이해도 없이) 자신 일에 만족하고 스스로를 몰아붙이지 않습니다.
  • I’m much more impressed with people that are always learning. The brilliant programmers I’ve been around are always learning.
  • 나는 항상 공부하는 사람들을 볼때마다 무척감명을 받습니다. 내가 만나본 훌륭한 개발자들은 항상 배웁니다.
  • You see so many people get into one language and spend their entire career in that language, and as a result aren’t that great as programmers.
  • 당신은 많은 사람들이 하나의 언어에 빠져 그안에서 일생을 보내고 결국 훌륭한 개발자가 되지 못하는 것을 볼 수 있습니다.
  • DO YOU FEEL THAT THE PAIN A PROGRAMMER GOES THROUGH IN LEARNING A LANGUAGE CONTRIBUTES TO THIS UNHEALTHY ATTACHMENT TO USING ONLY ONE LANGUAGE?

  • 개발자에게 언어를 학습하는데에 따르는 어려움이 한가지 언어만 사용하게 되는 부작용을 나았다고 생각하십니까?

  • My advice to programmers to avoid this trap is to learn lots of different languages. We’re in sort of a language renaissance right now and there are a ton of brilliant languages to learn from.
  • 개발자들이 많은 언어를 익혀야 한다는 굴레에서 벗어나야 한다고 말해주고 싶습니다. 우리는 지금 개발언어의 르네상스속에 살고 있고 그것으로부터 우리가 배워햐 하는 것들은 수만가지가 있습니다.
  • To learn new languages takes nights and weekends outside of work, and that’s a commitment. The great programmers are the people that are constantly picking a project and diving into it, learning a language that way.
  • 새로운 언어를 배우기 위해서는 며칠씩 걸리기도 하고 그것은 하나의 책무이기도 합니다. 훌륭한 개발자는 항상 프로젝트를 고르고 그것에 뛰어들어 새로운 것을 배웁니다.
  • IN CODERS AT WORK, YOU STRESS THE IMPORTANCE OF DOING CODE READINGS WITH TEAMS. WHY DO YOU FEEL IT’S IMPORTANT TO PRESENT YOUR CODE IN FRONT OF OTHER PEOPLE?

  • 당신은 "CODERS AT WORK"에서 팀에서 함께 코드를 해석하는 것에 대한 중요성을 역설했습니다. 다른 사람앞에서 당신의 코드를 시연하는 것이 중요하다고 생각하나요?

  • Well, over the years I noticed that there are some terrific programmers out there that are completely content to sit in their cave all day long writing brilliant code. But they don’t interact much with their team, which means it’s a lost opportunity for mentoring other members.
  • 음, 오랜시간동안 나는 훌륭한 개발자들이 그들의 동굴에 앉아 오랜 시간동안 짠 훌륭한 코드를 보았지만, 그들은 다른 팀과 소통하지 않았습니다. 그것은 다른 사람들이 그들이 짠 훌륭한 코드를 배울 좋은 기회를 가지지 못했다는 것을 의미합니다.
  • As you know, a lot of coders aren’t the most socially adept animals either.
  • 당신도 아는것 처럼 많은 개발자들이 사회적으로 능숙하지 못합니다.
  • So, my idea with code reading sessions is to provide a forum where people can come together and read for each other to get them out of their caves. The masters read for the beginners, and vice versa, as a team-building exercise.
  • 그래서 나는 그들이 혼자만의 동굴에서 나와 서로서로 모여서 함께 읽을 수 있는 포럼을 제공하려고 합니다. 팀빌딩 학습으로 마스터가 초보와 함께 할 수도 있고 반대로 초보자도 마스터와 함께 할 수 있습니다.
  • The trick for success is to set up rules ahead of time so that nobody is going to get spanked and everyone is respectful in their feedback. It has to be a good learning experience for everyone. You have to be careful with a dysfunctional team, because it can quickly tear apart the group. But I always call the game before it gets that far.
  • 성공의 열쇠는 누구도 튀지않도록 미리 규칙을 정하는 일입니다. 그 규칙안에서 모두는 피드백을 받으면서 서로를 존중할 수 있도록 해야합니다. 이 경험에서 모두가 배울 수 있습니다. 각 팀의 기능과 역량이 잘 분산되도록 해야합니다. 그렇지않으면 그 팀이 조직을 망칠 수 있기 때문입니다. 보통 그런 문제가 생기기 전에 조취를 취하도록 하는것이 제 역할이기도 합니다.
  • The rules are that it’s about improving the quality of the code that we’re all responsible for, improving the quality of our team, and improving our individual capabilities.
  • 그 규칙으로 인해 우리모두가 잘 만들어야할 소스코드의 품질이 올라가고 팀도 향상되고 또 구성원 각자의 능력도 향상시킬 수 있습니다.
  • Some people see this as a terrible time sink. Yet, I’ve found by doing this exercise, bugs are caught way ahead of time and you can prevent a team member from going off the tracks. But again, that’s not the goal, it’s about team building.
  • 어떤 사람은 이런 것들을 형편없는 시간낭비라고 생각합니다. 하지만 경험으로 인해 제가 알아낸 것은, 버그는 미리 잡을 수 있고 팀에 문제가 생기는 것도 방지할 수 있다는 것입니다. 다시말하면, 규칙을 세우는것이 목적이 아니라 팀의 운영이 핵심입니다
  • Over time the masters help pull up the beginners and the overall output from the team gets better.
  • 오랫동안 마스터 들은 초보 개발자들의 능력을 키우고 팀을 잘 관리함으로서 좋은 결과물을 만들어왔습니다.
  • ARE PROGRAMMERS GETTING BETTER AT USER EMPATHY?

  • 사용자를 이해하면 프로그래머들이 더 잘 일하게 될까?

  • The best experience I had with empathy was working in marketing support. There were times I would go out into the field and hold hands with the customers and see the consequences firsthand of some of the crap we were delivering to them.
  • 사용자와의 공감을 통해 얻은 가장 소중한 경험은 내가 마케팅지원 업무를 할 때였습니다. 심지어 고객들의 손을 붙잡고 우리가 그들에게 만들어준 시스템의 문제점을 직접 보여주고싶을 때도 있었습니다.
  • I was shocked when I moved into systems programming and how the programmers actually held the customer in contempt.
  • 시스템 프로그래밍을 하러 들어가서는 프로그래머들이 고객을 얼마나 업신여기는지를 보고 충격을 받았습니다.
  • I think every programmer should work in customer support for the product they’re delivering.
  • 모든 프로그래머들은 그들이 만드는 제품의 고객을 위해서 일해야 한다고 생각합니다..
  • It’s another case of over-specialization. “I just write the code,” is the response you get and the programmers don’t see it as a chance to improve peoples’ lives.
  • 또다른 자기일만 생각하는 예로, "나는 그저 개발만 한다"라고하고 프로그래밍을 사람들의 삶을 변화시키는 일로 보지 않는 경우도있습니다.
  • HOW MUCH OF A LANGUAGE DO YOU NEED TO KNOW?

  • 언어를 얼마나 깊게 알아야 하는가?

  • Virtually every programming language is too big. Language standards have difficulty removing unnecessary features but as users we can choose not to use it.
  • 사실 모든 프로그래밍 언어는 너무 거대 합니다. 프로그래밍 언어 표준은 불필요한 기능을 빼버리기 어렵게 하지만, 사용자인 우리는 그런 불필요한 기능을 쓰지 않으면 됩니다.
  • I would say you can do 100% with knowing 50% of the language.
  • 어떤 언어에 대한 50%의 지식 만으로, 100% 사용할수 있다고 말할수 있을것 같습니다.
  • The language that taught me that lesson the most was JavaScript, because it has more bad parts than good parts. It gave me a very strong motivation for figuring out what are the good parts and what are the bad parts, and what the criteria is for deciding what’s in or out.
  • 이 교훈을 나에게 가장 잘 가르쳐준 언어는 JavaScript 입니다. 왜냐하면 JavaScript는 좋은부분 보다는 나쁜 부분이 더 많은 언어이기 때문이죠. 어떤 부분이 좋고 어떤 부분이 나쁜지 그리고 무엇이 좋고 나쁜지 결정하는 기준이 무엇인지 알아내고 싶은 강한 충동을 느끼게 해주었습니다.
  • And the good parts are just so good. Be sure to watch Doug’s Google Tech talk titled “JavaScript: The Good Parts.”
  • 그리고 좋은 부분은 정말 좋습니다. 더그의 구글 테크 토크 (JavaScript의 장점)을 꼭 보세요.
  • note icon
    이 비디오가 아래 임베드 되어있습니다.
  • WHAT APPROACHES WOULD YOU SAY A MASTER HAS VERSUS A BEGINNER?

  • 마스터에 비해 초보자가 갖지 못한것은 무엇일까?

  • When I was a journeyman, I was a maximilist. I tried to use the whole language. While I don’t know if I would call myself a master now, I’m certainly a minimalist. I’ve tried to get good at using as little of the language as possible.
  • '도제' 시절 나는 극대주의자(maximilist) 였습니다. 언어의 모든 부분을 사용하려고 했어요. 지금 내가 '장인' 이라고 할수 있는지는 잘 모르겠지만, 지금은 분명 미니멀리스트 입니다. 언어의 가능한 적은부분만 사용하는데 능숙해 지려고 노력합니다.
  • I place a lot of value in simplicity and minimalism.
  • 단순함과 미니멀리즘에 굉장히 많은 가치를 둡니다.
  • WHAT ARE YOUR THOUGHTS ON JQUERY? SOME JS ENTHUSIASTS FEEL LIKE IT’S LETTING PEOPLE OFF THE HOOK FROM TRULY LEARNING JS.

  • jQuery에 대한 당신의 생각은 어떻습니까? 몇몇 JS 마니아들은 jQuery가 JavaScript 언어 자체를 배울수 있는 기회를 없애고있다고 합니다.

  • There is some really clever stuff in jQuery and I think John Resig did some very good work there.
  • jQuery에 어떤 현명한 방법이 있으며, John Resig이 했던 것이 매우 좋은 작업이라고 생각합니다.
  • I do have a problem with anybody doing anything without understanding what they’re doing. I’m not going to fault jQuery for attracting those sorts of people.
  • 하지만, 사용자들이 자신이 왜 그렇게 코딩 해야하는지도 이해하지 못하고 사용하는 것이 문제입니다. jQuery가 그런 사람들에게도 매력적이라는 것을 비판하지는 않겠습니다.
  • But I do think there are some other AJAX libraries that maybe doing a better job that aren’t quite as accessible. However, I think there is a place for all of these things.
  • 그러나 보다 나은 작업을 할 수 있는 다른 AJAX 라이브러리들이 많다고 생각하지 않습니다. 그러나, 이런 여지가 있다는 생각은 합니다.
  • WHEN YOU WERE DEVELOPING JSON WAS IT TOUGH TO PULL BACK AND NOT PUT TOO MUCH INTO IT?

  • JSON을 개발할 때, 어떤 것은 장애가 되고, 어떤 것은 장애가 되지 않습니까?

  • My design criteria were three things: minimal, contextual, and a subset of JavaScript.
  • 내 디자인 범주는 세 가지입니다: 미니멀, 컨텍추얼, 그리고 JavaScript의 서브셋.
  • The last constraint was to keep us from going off the rails and inventing new stuff. We had to only use stuff that was in JavaScript, which meant that our unicode handling wasn’t quite right because JS isn’t quite right, which was disappointing. We don’t have proper support for dates because JS didn’t have it. But we can work around both of these.
  • 가장 최근의 제약사항은 큰방향에서 벗어나지 않고, 새로운 기능을 추가하는 것이었습니다. JavaScript가 우리가 사용할 수 있는 유일한 것이었는데, JavaScript가 유니코드를 적절하게 다루지 못한다는 점이 실망스러운 부분이었습니다. 또한 날짜처리에 대한 지원도 JavaScript 의 제약으로서 잘 지원할 수 없었습니다. 하지만 그런 문제들을 모두 피해갈수 있습니다.
  • But it also meant that when somebody proposed, “Hey we should do this crazy thing” we could be like “Nope”. So, we had a really easy criteria for stopping extra features from being added.
  • 이는 누군가가 "이 기능은 꼭 넣어야한다" 라고 했을때, 우리는 단호하게 "노"라고 말할 것이라는 것을 뜻합니다. 우리는 너무 많은 기능이 추가되지 않도록하는 표준을 가지고 있었습니다.
  • One interesting story about leaving things out: as we got closer to releasing JSON I decided to take out the ability to do comments. When translating JSON into other languages, often times the commenting piece was the most complicated part. By taking the commenting out we reduced the complexity of the parsers by half—everything else was just too simple.
  • 이를 잘 말해주는 재미있는 이야기가 있습니다: JSON 릴리즈가 보다 가까워지면서 주석(comments)을 남기는 기능을 없애기로 결정했습니다. JSON을 다른 언어에서 사용할 때, 종종 주석 기능이 가장 복잡한 부분이었습니다. 주석기능을 제거함 으로서 파서들의 복잡도를 절반으로 줄였습니다.
  • One of the best features of JSON is that it’s stable. If your program works now, it will work forever, and that is an attractive thing.
  • JSON의 가장 좋은 특징 중 하나는 안정성입니다. 지금 프로그램이 동작한다면, 앞으로도 영원히 동작할 것입니다. 이점은 매우 매력적인 부분입니다.
  • I still get notes from people saying they’ve got great ideas for the next version. But there isn’t going to be a next version. I always say you’re free to invent a new standard and promote it as much as you like.
  • 여전히 다음 버전을 위한 좋은 아이디어를 가지고 있다고 계속 연락이 오고있습니다. 그러나 다음 버전은 아직 계획이 없습니다. 보통 나는 그들에게 당신이 새로운 표준을 발명하고, 그것을 널리 퍼지게할 수 있는 자유를 가지고있다고 조언합니다.
  • HOW DID JSON GET ADOPTED?

  • JSON이 어떻게 널리사용되게 되었는가?

  • You know, the adoption of JSON sort of restored my faith in humanity because it was a good idea that won out, only because it was a good idea.
  • 알다시피, JOSN은 생각할 수 있는 가장 좋은 아이디어라는 일종의 인간적인 신뢰로 인해 채택했습니다.
  • It was a case where there were no slick marketing campaigns. In 2001, I started working on it as a way to tie the browsers to the server. At the time, everyone thought XML had to be used or they’d say “that’s a great idea but JSON isn’t a standard”. So, I bought json.org, made a logo, threw up a Web page and it sat out on the Web for three years.
  • 당시에, 엄청난 마케팅 캠페인을 한것은 아닙니다. 2001년, 브라우저와 서버를 연동하는 방법에 대해 작업하기 시작했습니다. 그때, 모든이들이 XML을 써야 한다고 하거나, 훌륭하긴 하지만 "JSON은 표준이 아니잖아"라고 했습니다. 그래서 json.org를 샀고, 로고를 붙이고, 웹페이지를 만들어서 3년 동안 내보냈습니다.
  • In the meantime, AJAX happened and when it became the way for writing applications JSON was there. There was counter promotion from the XML community, of course.
  • 그 당시, AJAX가 생겼고, JSON은 애플리케이션의 한 수단이 되었습니다. 물론, XML 커뮤니티에서도 이에 대응하기위한 프로모션이 있었습니다.
  • But when I arrived at Yahoo! some kids at the company started thinking it was okay to start shipping JSON API’s through Web services. And developers found the apps got faster and were easier to write.
  • 그러나, 내가 야후에 왔을 때, 드디어 몇몇 이들이 JSON API를 웹 서비스로 제공하는 걸 시작하는 게 좋다고 생각하기 시작했습니다.그리고 개발자들은 JSON을 사용하면 어플리케이션이 빨라지고 또한 사용하기 편하다는 걸 알았습니다.
  • It sort of took off from there—no slick campaigns. So a good idea based on simplicity won out for once.
  • 자연스럽게 시작한 움직입이었습니다. 결국은 단순함에 기초한 아이디어가 승리했다고 할 수 있습니다.
  • Watch Doug Crockford At Google Speaking On “JavaScript: The Good Parts”

  • Doug Crockford의 구글 연설 동영상
    "JavaScript: The Good Parts"

  • In this presentation from Google Tech Talks, Doug goes over the ideas behind his landmark book, JavaScript: The Good Parts, and dives into the areas of what JavaScript got right and what it didn’t. Learn about the history and common roadblocks programmers run into when developing with this language.
  • 구글 연설에서 한 프리젠테이션에서, 더글라스는 그의 저명한 저서 JavaScript: The Good Parts 에서 하지 못한 이야기들을 이야기해 주었습니다. 가장 중요 부분은, JavaScript가 어떤 부분을 작했고 어떤부분을 잘 하지 못했는지에 대해 깊이 다룹니다. 이 언어를 가지고 프로그래머들이 개발할 때 어떤 장애물에 부딪히는지에 대해 알 수 있습니다.
  • Learn About The JSON Saga

  • JSON Saga에 대한 소개

  • In this video, Doug tells the interesting tale of how JSON was discovered, and sheds some light on how it became a major standard for describing data in an interesting turn of events.
  • 이 비디오에서는, 더글라스가 JSON을 발견한 재미있는 이야기를 알려줍니다, 그리고 데이터를 표현하기위한 주요 표준이 되기까지의 재미있는 사건들에대해서도 설명하고 있습니다.
6 Comments
ohyecloudy

ohyecloudy • May 22nd, 2012

덕분에 잘 읽었습니다. 눈꼽만큼 보탰습니다.
  • umteeh • May 22nd, 2012

    수정 감사드려요~

junuki

junuki • May 22nd, 2012

좋은 글 번역해주셔서 감사합니다! 저도 이분 존경하게 되었습니다.. 주변의 개발자 분들이 디게 좋아하시더라고요..
umteeh

umteeh • May 20th, 2012

저도 몇줄 얹어봤습니다. ^^
  • isyoon • May 22nd, 2012

    @tebica 번역가분들이 정확하게 정수로 번역된게 아니라서 반올림해서 처리하다 보니까.. 1%가 없어져버렸네요;; 도망간 1% 찾아오도록 하겠습니다.

  • tebica • May 21st, 2012

    감사합니다-
    이제 리뷰를 하려고 하는데,
    번역을 다한거같은데 아직도 번역율이 99%네요.. 숨은 1%는 어디에있을까요?