Dependency란 무엇인가?

[Toby Lee]

이전의 DI 용어 번역 논의에서 한 부분을 차지했던 dependency에 대해서 좀 더 생각해보고 싶습니다.

Dependency Injection이라는 용어를 처음 만들어서 제안했던 사람은 Martin Fowler입니다. 스프링이 사용한 방식을 IoC라는 너무 느슨하고 일반적인 용어로 부르는 것보다는 그 특성을 잘 나타낸 구체적인 용어를 사용하는 것이 좋겠다고 생각해서 제안한 것이죠.

그의 IoC/DI 소개 글은 매우 유명합니다. 스프링 레퍼런스 문서에서도 IoC개념을 위해서 1.0 문서 때부터 이 문서를 읽도록 권장하고 있습니다.

http://www.martinfowler.com/articles/injection.html

이 글에 나타난 dependency에 대한 설명을 좀 살펴볼 필요가 있습니다.

I'm going to start by talking about the various forms of dependency injection, but I'll point out now that that's not the only way of removing the dependency from the application class to the plugin implementation

이 글에 나타난 dependency에 대한 설명을 좀 살펴볼 필요가 있습니다. DI에 대해서 먼저 설명한다고 하면서 그것이 애플리케이션 클래스에서 dependency를 제거하는 유일한 방법은 아니다라고 이야하기 하고 있습니다.  DL(service locator)도 있다는 설명을 위한 것인데, 아무튼 여기서 관건은 DI란 application class에서 dependency를 제거하는 방법의 일종이라는 것입니다.

좀 더 구체적인 설명을 보죠.

The key benefit of a Dependency Injector is that it removes the dependency that the MovieLister class has on the concrete MovieFinder implementation

예제에 나온 MovieLister -> MovieFinder(interface) -> MovieFinderImpl 관계를 가지고 설명하기를 DI의 장점은 dependency를 제거하는 것인데, dependency란 MovieList클래스가 MovieFinderImpl 클래스에 대해서 가지고 있는 것이라고 되어 있습니다.

내용은 쉽습니다. MovieList가 MovieFinder라는 인터페이스에만 의존하고 있어야지, MovieFinderImpl에 의존하고 있으면 안된다는 것이고, 그 것을 완벽하게 제거하기 위해서는 인터페이스를 도입할 뿐더러, 그 DI를 통해서 외부에서 dependency를 주입해주도록 해야 한다는 것입니다. 

자 그럼 여기서 제거 된다는 dependency란 무엇일까요? 그것은 MovieLister안에 가지고 있는 구체적인 클래스에 대한 모든 정보를 말합니다. 그 정보를 가지고 있기 때문에 발생하는 모델링 타임의 의존관계(dependency relationship) 또는 의존하고 있는 성질(?)이라고 추상적으로 말할 수 있는 의존성(dependency)입니다.

적어도 여기서 볼때 dependency란 런타임시에 컨테이너가 집어넣어주는 dependent object가 아님을 분명히 알 수 있습니다.

오히려 그것은 모델링 타임시 코드레벨에서 가지고 있을 수 있는 의존관계(UML에서 쓰는 용어이죠)를 가리킨다는 것이라고 볼 수 있습니다.

코드에서는 제거해주고 대신 IoC/DI컨테이너가 대신 부여(주입)해준다는 것이죠.

즉, MovieLister 코드에 나타날 수 있는 특정 클래스에 대한 의존관계(또는 의존성)을 외부로 제거하는 것이 DI라는 설명입니다. 

물론 나중에 DI 방식의 컨테이너가 해주는 일은 구체적로 런타임시 의존객체를 전달해주어서 그것과 런타임 의존관계를 만들어주는 것입니다. 구현 메카니즘으로 보면 dependent object injection이라고 할 수 있지만, 그 개념을 보자면 코드레벨에서 구체클래스에 의존관계를 가지지 않도록 해주는 것이 DI 라는 것입니다. 

그래서 DI라는 용어를 처음 고안한 Martin Fowler의 아이디어에 따르면

DI에서 dependency를 의존객체라고 보는 것은 적절치 않습니다.

대신 코드 레벨에서 제거했지만, 런타임시에 가지게 해주는 의존관계 또는 의존성으로 보는 것이 타당하다는 것입니다.

http://publib.boulder.ibm.com/infocenter/radhelp/v6r0m1/index.jsp?topic=/com.ibm.xtools.viz.java.doc/topics/cdependency.html

에서 볼 수 있 듯이, 한쪽 클래스가 다른 클래스에 의존하고 있는 것을 UML에서는 dependnecy relationship이라고 표현합니다.

위의 설명에서 제거한다는 dependency란 바로 그것을 말하고 있고(have dependency on a class), 그런면에서 의존관계라고 이해하는 것이 DI 개념을 가장 잘 설명한 dependency의 해석이라고 봅니다.

물론 DI에서 dependency의 뜻이 그렇다는 것이지, 그래서 용어번역도 그래야 맞다고 주장할 생각은 없습니다.

번역이란 또 다른 이유와 목적을 위해서 원개념과 다른 대안번역어를 가질 수 있기 때문이니까요.

그래도 의존객체는 쫌 그렇네요. 상위 개념을 너무 노우레벨의 실현방법으로 대치시켜버린 듯한 느낌이

[박성철]

아주 깔끔하게 잘 정리해주셔서 감사합니다.
이런 글은 groups에 남기기 아깝네요. ksug blog로 옮기거나 해야 할 듯... ^^

* 마틴 파울러의 글 링크를 오랜만에 봐서 레퍼런스에서 빠졌나 했더니 아직 첫장에 남아 있네요. 그 만큼 레퍼런스를 잘 안 본다
는 뜻인가봐요. ㅎㅎ

On 6월9일, 오후1시37분, Toby Lee <tobyi...@gmail.com> wrote:
> 이전의 DI 용어 번역 논의에서 한 부분을 차지했던 dependency에 대해서 좀 더 생각해보고 싶습니다.
> Dependency Injection이라는 용어를 처음 만들어서 제안했던 사람은 Martin Fowler입니다. 스프링이 사용한 방식을
> IoC라는 너무 느슨하고 일반적인 용어로 부르는 것보다는 그 특성을 잘 나타낸 구체적인 용어를 사용하는 것이 좋겠다고 생각해서 제안한
> 것이죠.
>
> 그의 IoC/DI 소개 글은 매우 유명합니다. 스프링 레퍼런스 문서에서도 IoC개념을 위해서 1.0 문서 때부터 이 문서를 읽도록

> 권장하고 있습니다.http://www.martinfowler.com/articles/injection.html

>
> 이 글에 나타난 dependency에 대한 설명을 좀 살펴볼 필요가 있습니다.
>
> I'm going to start by talking about the various forms of dependency
>

> > injection, but I'll point out now that *that's not the only way of
> > removing the dependency from the application class* to the plugin

> > implementation
>
> 이 글에 나타난 dependency에 대한 설명을 좀 살펴볼 필요가 있습니다. DI에 대해서 먼저 설명한다고 하면서 그것이 애플리케이션
> 클래스에서 dependency를 제거하는 유일한 방법은 아니다라고 이야하기 하고 있습니다. DL(service locator)도 있다는

> 설명을 위한 것인데, 아무튼 여기서 관건은 *DI란 application class에서 dependency를 제거하는 방법의 일종*이라는

> 것입니다.
>
> 좀 더 구체적인 설명을 보죠.
>

> The key benefit of a Dependency Injector is that it removes* the dependency
>
> > that the **MovieLister** class has on the concrete **MovieFinder**
> > implementation*

>
> 예제에 나온 MovieLister -> MovieFinder(interface) -> MovieFinderImpl 관계를 가지고

> 설명하기를 DI의 장점은 dependency를 제거하는 것인데, *dependency란 MovieList클래스가
> MovieFinderImpl 클래스에 대해서 가지고 있는 것*이라고 되어 있습니다.

>
> 내용은 쉽습니다. MovieList가 MovieFinder라는 인터페이스에만 의존하고 있어야지, MovieFinderImpl에 의존하고
> 있으면 안된다는 것이고, 그 것을 완벽하게 제거하기 위해서는 인터페이스를 도입할 뿐더러, 그 DI를 통해서 외부에서 dependency를
> 주입해주도록 해야 한다는 것입니다.
>
> 자 그럼 여기서 제거 된다는 dependency란 무엇일까요? 그것은 MovieLister안에 가지고 있는 구체적인 클래스에 대한 모든
> 정보를 말합니다. 그 정보를 가지고 있기 때문에 발생하는 모델링 타임의 의존관계(dependency relationship) 또는
> 의존하고 있는 성질(?)이라고 추상적으로 말할 수 있는 의존성(dependency)입니다.
>
> 적어도 여기서 볼때 dependency란 런타임시에 컨테이너가 집어넣어주는 dependent object가 아님을 분명히 알 수
> 있습니다.
> 오히려 그것은 모델링 타임시 코드레벨에서 가지고 있을 수 있는 의존관계(UML에서 쓰는 용어이죠)를 가리킨다는 것이라고 볼 수 있습니다.
> 코드에서는 제거해주고 대신 IoC/DI컨테이너가 대신 부여(주입)해준다는 것이죠.
>
> 즉, MovieLister 코드에 나타날 수 있는 특정 클래스에 대한 의존관계(또는 의존성)을 외부로 제거하는 것이 DI라는
> 설명입니다.
>
> 물론 나중에 DI 방식의 컨테이너가 해주는 일은 구체적로 런타임시 의존객체를 전달해주어서 그것과 런타임 의존관계를 만들어주는 것입니다.
> 구현 메카니즘으로 보면 dependent object injection이라고 할 수 있지만, 그 개념을 보자면 코드레벨에서 구체클래스에
> 의존관계를 가지지 않도록 해주는 것이 DI 라는 것입니다.
>
> 그래서 DI라는 용어를 처음 고안한 Martin Fowler의 아이디어에 따르면
>

> *DI에서 dependency를 의존객체라고 보는 것은 적절치 않습니다.*
> *대신 코드 레벨에서 제거했지만, 런타임시에 가지게 해주는 의존관계 또는 의존성으로 보는 것이 타당하다는 것입니다.*
>
> http://publib.boulder.ibm.com/infocenter/radhelp/v6r0m1/index.jsp?top...

> 에서 볼 수 있 듯이, 한쪽 클래스가 다른 클래스에 의존하고 있는 것을 UML에서는 dependnecy relationship이라고
> 표현합니다.
> 위의 설명에서 제거한다는 dependency란 바로 그것을 말하고 있고(have dependency on a class), 그런면에서
> 의존관계라고 이해하는 것이 DI 개념을 가장 잘 설명한 dependency의 해석이라고 봅니다.
>

> *물론 DI에서 dependency의 뜻이 그렇다는 것이지, 그래서 용어번역도 그래야 맞다고 주장할 생각은 없습니다.*
> *번역이란 또 다른 이유와 목적을 위해서 원개념과 다른 대안번역어를 가질 수 있기 때문이니까요.*

[안영회]

무게감 있는 내용에서 모호한 부분을 뚜렷히 하기 위해 첨언을 합니다.

자 그럼 여기서 제거 된다는 dependency란 무엇일까요? 그것은 MovieLister안에 가지고 있는 구체적인 클래스에 대한 모든 정보를 말합니다. 그 정보를 가지고 있기 때문에 발생하는 모델링 타임의 의존관계(dependency relationship) 또는 의존하고 있는 성질(?)이라고 추상적으로 말할 수 있는 의존성(dependency)입니다.

...

DI에서 dependency를 의존객체라고 보는 것은 적절치 않습니다.

대신 코드 레벨에서 제거했지만, 런타임시에 가지게 해주는 의존관계 또는 의존성으로 보는 것이 타당하다는 것입니다.

...

물론 DI에서 dependency의 뜻이 그렇다는 것이지, 그래서 용어번역도 그래야 맞다고 주장할 생각은 없습니다.

번역이란 또 다른 이유와 목적을 위해서 원개념과 다른 대안번역어를 가질 수 있기 때문이니까요.

Toby님 글에 따르면 dependency는 '구체적인 클래스에 대한 모든 정보', '모델링 타임의 의존관계또는 의존하고 있는 성질(?)', '의존성' 등으로 표현했습니다. 앞선 번역에 대한 논의에서 dependency와 injection을 번역 출발어라고 하죠. 출발에에 대해서 1:1로 도착어를 정의하지 않았습니다. 사실 이 글에 드러나듯 Dependency와 DI는 긴 설명이 필요한 개념입니다.

'의존성 주입'이나 '종속객체 주입'이나 어구로 볼 때, Dependency Injection에 대한 도착어로 우위를 점하기 힘들다고 봅니다. 다른 내용을 인용하면서, 이야기를 조금만 덧붙여보죠.

물론 나중에 DI 방식의 컨테이너가 해주는 일은 구체적로 런타임시 의존객체를 전달해주어서 그것과 런타임 의존관계를 만들어주는 것입니다. 구현 메카니즘으로 보면 dependent object injection이라고 할 수 있지만, 그 개념을 보자면 코드레벨에서 구체클래스에 의존관계를 가지지 않도록 해주는 것이 DI 라는 것입니다. 

위 내용에서 '런타임 의존관계를 만들어주는 것'은 없던 내용을 생성하는 의미는 아닙니다. 앞에 인용한 글에도 나타나지만 모델타입 혹은 개발할 때 이미 관계는 정의합니다. 인터페이스 혹은 Contract 수준에서만 정의했던 의존 관계의 인스턴스(instance)가 만들어집니다. UML 표현으로는 Link 생성인데요.

이 때, Dependency Injection을 Dependency Lookup과 구분지어주는 특징이 바로 Dependency를 스스로 확보하느냐 외부에서 주입해주느냐라 생각합니다. 이러한 메커니즘 이해가 dependency 개념 표현보다 중요하다고 보면 '종속객체 주입'이라는 표현도 그리 나쁘지는 않다 생각합니다.

[Toby Lee]

. 이러한 메커니즘 이해가 dependency 개념 표현보다 중요하다고 보면 '종속객체 주입'이라는 표현도 그리 나쁘지는 않다 생각합니다.

이번에 쓴 글은 번역어를 선정하기 위함이 아니라 DI를 선정한 사람이 가졌던 dependency에 대한 아이디어를 살펴보기 위한 것이었습니다. 

세 가지만 살펴봅니다.

1. 

DI를 의도를 가지고 번역할 때 "의존객체 주입"은 충분히 가능성 있고, 의미가 있는 시도라고 봅니다.

그럼에도 다만 자꾸 의존객체와 자꾸 섞여서 등장하는 "종속객체"이라는 말은 이해가 안되는군요. 

UML정의에서도 dependency는 association보다 조금 느슨한, 주로 "사용"이라는 방식으로 관계를 형성하는 경우를 말한다고 되어있습니다. 그럼에도 DI에서 dependency를 "종속"이라는 매우 제한적이고 긴밀한 관계로 표현하는 이유에 알 수 없습니다.

물론 영어에서 dependent하면.. 부양가족과 같은 경우에 사용해서 그야 말로 딸려있는 상태를 말하기도 합니다. 

하지만 설령 다른 분야에서 dependency를 "종속"이라는 단어로 번역해 쓰는 경우가 있다고 해도, DI에서 dependency를 종속되었다는 의미로 해석할 수 있다는 데에는 동의할 수 없습니다.  

2.

실제 DI 작업 때 일어나는 일부 프로세스를 기준으로 추상적인 개념어인 의존성 주입이나 의존관계 주입으로 하는 것보다 "의존객체 주입"이라고 하는 것이 낫다고 볼 수도 있습니다. 

그 낫다는 볼 수 있는 근거는 "객체"가 만들어지는 시점(즉 런타임시에)에서 의존이 결정된다는 컨셉을 설명하기가 쉽기 때문입니다. 그것은 의존이라는 말때문이 아니라 "객체"라는 말이 명시적으로 나타나 있기 때문입니다. 즉, 클래스 설계 타임이 아니고 객체가 만들어지는 타임에 관한 무엇이라는 것을 명확히 해주기 때문이죠. 하지만 이는 이미 DI의 동작원리와 개념을 충분히 이해하는 사람들에게 좀 더 의미를 명확하게 해주고, 설명가능성을 조금 높여줄 뿐입니다.

반대로 이 표현은 오해의 가능성도 있습니다.

DI의 dependency를 구체적인 클래스와의 의존관계가 결정되는 것이라고 볼 때, 의존객체 주입은 그 의존이 결정되는 시점에 대해서는 전혀 아이디어를 주지 못한다는 것입니다. 의존객체의 대상클래스는 이미 결정되어있지만, 단지 그것을 직접 만들지 않고 외부에서 만들어서 넘겨받는다는 의미로도 충분히 해석가능하기 때문입니다.

예를 들어, 의존성(구체적인 클래스와의 의존관계)은 이미 결정되어있어도 의존객체는 외부에서 런타임시에 주입되는 형태로 동작할 수 있습니다. 예를 들어 클래스 A->B관계에서 이미 A가 B를 다 알고 있어서, 그 의존관계가 미리 정의되어있다고 해도, B라는 클래스의 객체를 만들어서 A에게 던져주는 것을 외부에다 위임하면 그것도 "의존객체 주입"입니다.

즉, 메카니즘을 표현한 "의존객체"라는 것은 그 자체에서 의존대상이 언제 결정되느냐를 설명하는 개념을 가지고 만든 단어인 DI 제안자의 의도를 충분히 반영하지 못하고 있다는 것입니다.

물론 이어서 충분히 주절주절 설명하면 되죠.

그렇게 치면 뭐 의존성 주입이든, 의존관계 외부설정이든, 의존삽입이든 뭐든 못쓸게 없습니다. 설명하면 되죠. 이름도 길~게 만들고.

DI를 자주 설명해야 했던 경험으로 볼 때 "의존객체가 주입된다"라는 표현은 설명하는 사람 입장에서 좋습니다. 컨테이너가 의존객체 만들어서 setter를 불러줘..라고 하면 되죠. 하지만 거기에서 듣는 사람이 이 의존객체가 만들어져서 setter로 전달되어지는 방식의 필요한 진정한 "이유"를 파악못하면 여전히 개념 못잡고 혼란스럽긴 마찬가지입니다.

그런면에서 원래 전체 DI 프로세스와 전제조건 중에서 가장 로우레벨인 "의존객체 주입"이라는 것을 대표적인 용어로 쓰는데는 조금 불만이 있습니다. 뭐 한가지 가능성으로 볼 수는 있지만, 그것이 의존성과 같은 표현보다 더 우월하다거나, dependency란 결국 의존객체다라고 설명한다는 것은 이상합니다.

3.

과연 의존객체란 무엇인가를 한번 또 생각해볼 필요가 있죠. 

그게 과연 개발자가 만든 인터페이스를 구현한 클래스의 인스턴스의 하나인가? 라고 생각했을 때, 스프링의 DI는 사실 그보다 훨씬 복잡합니다.

전략패턴을 적용해서 구체 클래스를 여러개 만들어서 필요에 따라서 바꿔서 쓰게 하겠다는게 DI의 기본이라고 보면, DI의 절정은 AOP입니다. 스프링은 ProxyFactoryBean을 DI에 도입해서 AOP로 사용하게 합니다. 스프링 AOP는 결국 DI에 기반을 둔거죠. 

그런 경우 과연 주입되는 것은 무엇일까요? 물론 ProxyFactoryBean도 객체니까 의존객체라고 할 수도 있겠죠. 하지만 개발자가 원래 만든 어떤 클래스의 "객체" 자체는 아니죠. 그 이상의 어떤 DI 메카니즘을 이용한 서비스가 주입되는 것입니다. 필요에 따라 심지어는 의존객체를 제끼고 AOP의 proxy가 그 자리를 차지하기도 한다는 것이죠.

AOP 말고도 request scope 같은 경우를 생각해도 마찬가지 입니다. request scope는 싱글톤에 하나의 객체가 주입되는 것처럼 보이지만, 각 request thread마다 그때마다 다른 실제 객체가 호출되도록 그 사이에서 복잡한 다이나믹 라우팅이 일어나고 있습니다. prototype처럼 매번 다른 객체를 가져오는 것이 아니고, 처음에 DI해서 한번 주입했음에도 각 스코프 마다 다른 객체가 최종적으로 불립니다.

이런 경우 주입된 의존객체란 과연 무엇일까요? 엄밀히 말하면 특정 객체가 주입된 것이 아니죠. 

매우 고도로 복잡하고 세밀한 방식으로 스프링이 다이나믹하게 의존대상을 바꾸어주는 어떤 기능이 적용이 된 것입니다. 구지 말하자면 "특별한 의존성" 또는 "특별한 의존관계 설정 방식"이 주입된거죠.

이렇게 스프링의 DI의 다양성을 고려해보면, 단지 전략패턴에서 말하는 식으로 특정 클래스의 구현객체를 만들어서 그것을 의존객체로 주입해준다는 것은  "런타임시 사용하게 될 의존대상과의 관계를 스프링이 총체적으로 결정하고 그 결정된 의존특징을 런타임시 부여한다"라는 DI의 넓은 컨셉을 충분히 설명하지 못하고 있습니다.

아무튼,

그럼에도 "의존객체 주입"을 DI의 번역어로 사용하는 것은 조금 무책임하지만 뭐 크게 잘못되었다고 보지는 않습니다. 외냐면 좀 더 개념을 잘 담고 있는 "의존성 주입" 등으로 해봤자, 그럼 도대체 그 의존성이 무엇이냐라는 설명이 역시 필요한 것이고, 그것은 사실 영어의 Dependency Injection도 마찬가지 이기 때문입니다.  객체지향을 일부 사람들이 주장하는 것처럼 개체지향이라고 한다고 해서 뭐 OO를 이해하는데 더 나을까요? 

번역을 안해본 입장이라 그렇게 말하는지 모르겠지만요.. :)

사실 이해하기 힘든 용어는 오해하지 않도록 쉽고 편한 용어보다는 이해가 안되서 그게 도대체 뭔가 하고 호기심을 가지게 만들게 어렵게 번역하는게 더 낫다고 봅니다. 어색한 번역은 있을 지언정 엉뚱한 오해가 있으면 안되겠죠. 이왕이면 짧고 부르기 편하면 좋고..

개인적으로는 "의존주입"을 가장 선호합니다. 짧고 명료하고, 직역이지만 오해를 불러일으키지 않고, 그리고 의존이 먼지, 그게 왜 주입된다고 하는지는 따로 설명해주면 되고.

용어번역과 상관없이 dependency injection의 dependency란 무엇이고, DI의 개념과 원리, 목적이 무엇인지에 대해서는 한번쯤 깊이 생각해보는게 좋을 것 같습니다.

2009/6/9 안영회 <ahnyo...@gmail.com>

[안영회]

용어를 선정함에 있어 단어-대-단어 번역을 할 수 있겠죠. 하지만, 용어 번역 따로고, 'dependency란 무엇이고, DI의 개념과 원리, 목적이 무엇인지 깊이 생각하는' 행위가 완전히 다른 일은 아니죠.

DI에 대한 우리말 표현을 찾아가는 여정은 단순히 책 학 권 번역하는 행위에서 완성할 순 없습니다. 그 정도로 쉽게 우리말 표현을 찾을 수 있는 문제라면 KSUG에서 꼬리에 꼬리를 묻 글을 볼 수는 없었겠죠. 여정이라는 단어를 일부러 사용해보았는데요. 성철님이 용어 선정을 논의를 꺼낸 취지는 단지 여기서 답을 찾으려는 시도는 아닙니다.

토비님 말대로 말을 만들어낸 곳에서조차 Dependency Injection이 낯익은 표현을 아닙니다. 하물며 우리나라에서야 어떻겠습니까? 그런 상황에서 바로 답을 찾으려는 시도는 무모한 일이죠. 다만, spring reference 번역을 시도하며 여정을 시작하려 합니다.

굳이 우리가 마무리를 지을 수 없다고 해도 타성에 젖은 단순 용어 선정보다는 한 발만 더 나아갈 생각입니다. 다른 토양에서 자라난 어휘와 개념이 우리 문화에도 그대로 자라날 수 있을지는 의문입니다.

현장에서의 시간을 돌이켜보면 Framework, Use Case니 하는 용어도 원어 그대로 쓰이면서 개념조차 모르면서 용어를 남발하는 일이 꽤 길었습니다. 피부로 느끼는 바대로 생각해보면 기술 용어를 밥 먹듯이 쓰는 사람 중에서 꽤 많은 숫자가(적어도 과반은 넘는) 해당 개념이 필요한 이유조차 모릅니다. 또한, 우리는 외래 기술 수용 주기가 매우 빠릅니다. 이를 고려하면, 개념을 모르는 사람 사이의 오해를 조금이라도 줄일 수 있는 표현을 찾아 고민하는 일은 매우 가치있는 일입니다.

이실직고하면 2, 3년 전만 해도 번역 자체가 부질 없는 일이라고 생각했습니다. 뾰족한 사건이 있지도 않았는데 생각이 확 바뀌었습니다. 갑자기 떠오른 생각인데, '세종대왕께서 우리말을 만든 뜻'이 내 몸 어딘가에 새겨져 있지 않나 하는 엉뚱한 생각을 합니다. :)

* 혹시 훈민정음 창제 이유를 모르시면 구글링하세요.. 아니면.. K한글UC에 가보시거나.. ㅡㅡ;

[Toby Lee]

세종대왕께서 우리말을 만든 뜻

세종대왕은 우리 글자를 만들었겠죠. 우리 말은 조상들이 대대로 만들고 발전시켜 온 것이고요.

대체로 서민계층의 삶에서 발전해온 일상적인 표현과 어휘와 달리, 전문용어나 어려운 말들은 역사적으로 볼때도 소수의 엘리트 계층에 의해서 일방적으로 만들어지고 외국에서 들여왔죠(한자어,일본어,요즘은 영어)

그걸 돌이켜본다면 지금의 소수의 번역자, 전문가들이 거의 일방적으로 정해서 던져주는 번역용어들이나 표현들이 만들어지는 방식은 그 때나 다를바 없는 것 같습니다.

소수의 폐쇄적인 작업으로가 아니라  과정이 투명하게 공개되고, 많은 사람들이 참여하고 또는 피드백을 통해서 기여할 수 있는 그런 번역 또는 용어선정이라는 것이 가능할지 궁금하군요.

2009/6/10 안영회 <ahnyo...@gmail.com>

[Gir Won Lee]

빙고.. ㅎㅎ

말과 글을 자주 혼용?혼동?해서 사용해서..

학교에 있을때, 어느 한 교수님으로부터

수업시간의 반에 해당하는 시간을 말과 글에 대해서 강의받았다는... ^^;;;;

 

왜 물리전공인데 6개국어를 하시는지....;;;;

-랩실에 있었던 몽골학생을 위해 몽골어를 배우셨다는..;;

 

 

소수의 폐쇄적인 작업으로가 아니라  과정이 투명하게 공개되고, 많은 사람들이 참여하고 또는 피드백을 통해서 기여할 수 있는 그런 번역 또는 용어선정이라는 것이 가능할지 궁금하군요

 

번역이나 용어와 관련해서 맞는지는 모르겠지만, 프랑스가 매년 새로운 용어나 단어들을

채택하기위해(사전 등재를 위해서였나??), 소설가나 다양한 분야의 사람들을 모아놓고 회의를 한다는데..

우리나라도 언젠가는 가능하지 않을까요?? ^^

 

 

2009년 6월 10일 (수) 오전 6:56, Toby Lee <toby...@gmail.com>님의 말:

--
In the midst of the street of it, and on either side of the river, was there the tree of life,
which bare twelve manner of fruits, and yielded her fruit every month: and the leaves of the tree were for the healing of the nations.


Gir won Lee

Dept. of Bioinformatics, Bioneer Corporation
URL: http://www.bioneer.co.kr
http://www.thegreatgoodplace.com
E-mail: leegw700@{bioneer.co.kr|ssu.ac.kr|gmail.com}
Tel: 82-42-930-8755
Phone: 82-10-3323-0868

[안영회]

가능한지 여부는 알 수 없지만, 과정을 공개조차 하지 않으면 아예 알 길이 없으니까요.
공론에 부치는 일은 가치 있는 일이라 생각합니다.