근데 문장을 구성할 때 앞서 이야기한 요소들을 나열하기만 해서는 안된다. 사람들과 이야기할 때에는 일종의 규칙이 있어야 소통 가능하기 때문에, 요소를 나열하는 순서도 있어야 하는 법이다. 기본적으로 우리나라는 주어, 목적어, 동사의 순서로 오는 SOV(Subject-Object-Verb)의 어순을 취하고 있고, 이 사이사이에 적절한 요소들을 끼워넣는 형태로 되어있다. 예를 들어,
나는 철수를 죽였다. (SOV)
나는 짜증이 나서 철수를 죽였다. (SCOV)
어제 나는 짜증이 나서 철수를 죽였다. (AdvSCOV)
어제 나는 짜증이 나서 철수를 목매달아 죽였다. (AdvSCOCV)
나는 짜증이 나서 철수를 죽였다. (SCOV)
어제 나는 짜증이 나서 철수를 죽였다. (AdvSCOV)
어제 나는 짜증이 나서 철수를 목매달아 죽였다. (AdvSCOCV)
정말 블로그 주인장의 졸렬한 사상이 드러나는 예문이 아닐 수 없으나, 어쨌든 기본적으로 SOV를 중심으로 문장이 확장되는게 한국어인 것이다. 그런데, 여기에 각종 재료들을 붙일 때, 다음과 같이 붙이는 사람이 있다.
사실 나는 철수를 죽였다. (○, AdvSOV)
나는 사실 철수를 죽였다. (△, SAdvOV)
나는 철수를 사실 죽였다. (X, SOAdvV)
나는 철수를 죽였다 사실. (X, SOVAdv)
나는 사실 철수를 죽였다. (△, SAdvOV)
나는 철수를 사실 죽였다. (X, SOAdvV)
나는 철수를 죽였다 사실. (X, SOVAdv)
첫번째 문장은 언제든 쓸 수 있고, 두번째 문장은 경우에 따라서는 쓸 수 없을 수도 있다. 세번째나 네번째는 '사실'이라는 부사가 들어갈만한 자리가 아니기 때문에 쓸 수 없다. 그렇지만 세번째나 네번째가 일리가 있는 것은, 사고 방식을 그대로 표출하고 있기 때문이다. 사실 사람들은 SOV에 기반한 부분을 먼저 생각하고, 이후에 저런 살들을 붙여나간다. 세번째나 네번째 문장을 이야기하는 사람은, '내가 철수를 죽였다'는 사실을 강조하고 싶었고, 필요한 살이 뒤따라 생각나는 경향이 있다. 그래서 문어가 아닌 구어로 이야기할 때에는 저런 문제가 발생한다 흔히(?).
실제로 간단한 글을 쓸 때에도 절이나 구, 부사 등을 넣는 위치에 대해 고민할 때가 많다. 영어의 경우에는 교과서에서 배운 공식(?)들이 있기에 고민할 필요가 없을 때가 많다. 심지어는 확신이 서지 않으면 구글로 찾아보아 더 많은 검색수를 가지는 문형으로 써버리면 되니까. 그런데 한국어의 경우에는 주어+목적어+동사 를 중심으로 한 생각의 속도가 훨씬 빨라서인지, 먼저 중심 요소들을 묘사하고 후에 필수 요소들이 생각나는 경우가 많아 참으로 안타깝다.
많은 책에서 제안하는 것은, 일단 단순한 문장으로 쪼개보라는 것이다. 그렇게 해서 문장 하나 당 아이디어 하나만 담게 하면, 문장을 읽는 호흡도 짧아질 뿐더러 오류가 적어진다는 것. 이후에는 문장을 배치하는 것만으로도 하나의 구절(paragraph)이 완성된다는 것이다. 맞는 이야기다. 그렇지만 그렇게 생각해가며 구절을 쓸 만큼 시간이 많지 않은 것 또한 사실이다...
생각해보면 영어 논문을 쓸 때 시간이 걸리는 이유는, 배운 적은 없지만 명문이라고 일컬어지는 문장이나 구절들을 흉내내어 글을 쓰기 때문이 아닌가 싶다. 일단 아이디어는 최대한 많이 모여있고, 이를 적절하게 배치하여 영어 표현상의 오류를 최소화하는게 목적이어서 그런걸까? 거기에 엎친 데 덮친 격으로, 많은 연구자들이 한글로 논문을 먼저 쓴 다음 영어로 옮기는 일을 하고 있어, 그런 사람들은 영어 논문을 쓰는 데에 더 많은 시간이 걸리게 된다. 나도 처음에 논문을 쓸 때에는 그랬다가, 지금은 일단은 틀린 표현이 생기는 위험이 있더라도 영어로 먼저 적기 시작한다. 그래서인지 어순이 점점 SOV에서 SVO로 바뀌고, 각종 구나 절 등이 아무 곳에나 배치되는 문제가 발생하더이다.
컴퓨터 프로그래밍으로 생각하면, 연습장 등에 설계하지 않고 바로 코딩부터 시작하는 위험한 짓거리다. 컴퓨터 프로그램을 짤 때, 최소한 머릿속으로 생각하는 일이라도 하지 않으면, 전반적으로 유지보수하기 곤란해지는 아키텍처가 나타날 수도 있다. 만일 팀 공동 작업이면 이같은 문제는 다른 멤버 및 다른 팀으로까지 확대되어, 나중에는 프로그램 전체를 엎어야 하는 사태가 발생할 것이다. 때문에, 코딩 실력이 뛰어나거나 학업 성적이 좋은 사람보다, 연습장에 설계를 꼼꼼히 하고 매뉴얼대로 따르는 사람을 우선 채용하는 것인지라. 하지만 이렇게 채용된 사람들도 현업에 투여되면 시간 문제로 인해 설계를 게을리 하게 된다. 이러다 보면 설계도 없이 문제도 없이 돌아가는 코드를 작성하는 신기한 능력을 취득하게 된다! ... 대부분 문제가 나타나기 전에 관리직으로 이동하거나 다른 직장으로 이동하기에 별 문제가 없는 것으로 보이지만...
여튼 그렇다. 요즘 블로그 등에 문장을 적을 때, 문장의 마침표 근처에 다가가면 지금까지 넣지 못했던 각종 문장 구성 요소들이 생각나 괴로울 때가 많다. 하지만 어쩌랴. 일단은 틀리더라도 적고 보는 것이 일 아닌가 싶다. 그렇지 않으면 쓰는 시간이 점점 길어질 뿐더러, 이것이 습관화(?)되면 제한 시간 안에 아무것도 생산할 수 없게 되니 말이다. 정말 제한 시간이라는게 참 아쉬운 녀석이다.



2009/12/16 11:20
2009/12/17 22:04
2009/12/17 22:24
저는 그래서 일단 쓰고[1] 다시 본 다음[2], 수정하는[3] 단계를 거쳐서 사용중이랄까요?
그래도 '이게 맞는 말인가?' 하고 갸우뚱댈때도 있지만 말입니다;ㅅ;
그러면서 조금씩 나아진다고 생각하는 자세로 써 나가는거죠.^^
2009/12/18 05:14