가입: 2001년 7월 25일 올린 글: 3413 소속: GPGstudy 타 사이트 ID(?): docbook.kr::류광
[강좌초안] 프로그래밍과 영어 (1)
올려짐: 2002-05-16 16:25
AI Wisdoms 번역 시작하기 전에 뭔가 한 번 써보고 싶었습니다...
그러나 결국 완성 하지 못하고 번역을 시작하게 되었네요. 원래 계획은 동사, 부사 거쳐서 이름짓기, 문장 구성 까지 나아가는 것이었는데... 그 부분은 이번 달 안에는 힘들 듯... 그러나 언젠가는(적어도 GPG3 시작하기 전에) 완성시킬 것입니다.
GPT(현재는 TiGP)에 넣어달라고 부탁할까도 생각했으나 시간 상 책에 실을 정도의 완성도를 달성할 수는 없을 것 같았습니다..
어쨌든 시작.
프로그래밍과 영어
류광
한국의 프로그래머들이 흔히 듣는 조언 가운데, ‘영어는 필수입니다’라는 것이 있다. 영어가 필수인 이유로 흔히 말하는 것은 외국 책이나 자료를 빨리 제대로 읽을 수 있어야 한다는 것이다. 그러나 프로그래머가 영어를 잘해야 하는 또 다른, 그리고 좀 더 중요한 이유는, 코딩 자체가 일종의 영작문이라고 할 수 있다는 점이다.
거의 대부분의 프로그래밍 언어들은 영어를 기반으로 하고 있다. 특히 고수준 언어로 올라갈수록 자연 언어로서의 영어와 가까와지는 경향이 보인다. 또한 설계가 잘 된 코드일수록 마치 영어로 쓰여진 문서를 읽는 느낌이 드는데, 이는 프로그래밍 방법론의 발전과도 맞닿아 있다. 절차적 언어 시절에는 프로그램 소스 코드라는 것을 컴퓨터를 위한 작업 지시서로 생각하는 경향이 있었으나, 소프트웨어의 설계 및 유지·보수에 대한 문제의식이 대두되고 객체지향적 패러다임이 대세를 이루면서 프로그램 소스 코드는 기본적으로 사람을 위한 것이며 프로그래밍 언어는 사람의 생각을 좀 더 직접적으로 나타낼 수 있어야 한다는 생각이 널리 퍼진 것 같다. 객체 지향이라는 것, 특히 ‘모든 것은 객체이다’라는 말은 결국 우리가 다뤄야 할 문제에 관련된 사물들과 개념들을 그대로 소스 코드로 옮길 수 있어야 한다는 말과 일맥상통한다는 점에서, 소스 코드가 곧 하나의 문서(일상정 의미에서의)이며 프로그래머는 곧 작가 또는 저술가라는 점을 항상 염두에 두어야 할 것이다.
앞에서도 말했듯이 프로그램 소스 코드는 컴퓨터를 위한 작업 지시서가 아니라 프로그래머 스스로가 컴퓨터를 통해서 무엇을 어떻게 하고자 하는지를 적어놓은 것이다. 따라서 코딩은 프로그래머 스스로를 위한 서술 과정이기도 하다. 그러나 불행하게도 우리는 우리의 한글로 우리의 생각을 적을 수가 없다. 물론 C# 같은 일부 언어에서는 변수나 클래스, 함수 이름 같은 식별자들에 한글, 엄밀히 말하면 유니코드의 ‘글자(letter)’에 속하는 범위의 한글 글자들을 사용할 수 있으나, 어순 자체는 여전히 프로그래밍 언어의 정의에 따르며, 그 정의라는 것은 대부분 영문법을 따른다. 애초에 한글 언어를 목표로 만들어진 프로그래밍 언어들도 있으나 대부분 기존 언어에서 흔히 보이는 핵심 키워드들을 한글화한 것일 뿐 우리말글의 어순을 따르지는 않는다. 차후에 우리말글의 어순을 따르며 우리말글을 사용하는 사람의 생각을 그대로 자연스럽게 표현할 수 있는 언어가 나오기를 바라나, 어쨌든 지금은 영어에 익숙해질 수밖에 없다.
이 글에서는 영어에 관련해서 프로그래머가 좀 더 나은 소스 코드를 작성하는 데 도움이 될만한 몇 가지 주제들을 이야기하겠다.
그 전에 한가지 강조하고 싶은 것이 있다. 많은 프로그래머들이 고교 과정때까지 배운 수학과 물리학을 전혀 활용하지 못하고 모든 것들을 다시 시작하는 모습을 많이 보는데 무척 안타까운 일이다. 예를 들어 수학 시간에 배운 다각형과 프로그래밍 책에 나오는 폴리곤을 다른 것으로 생각하는(이는 저자나 번역가의 잘못이 크다) 사람은 그 수학 시간만큼의 시간을 낭비하는 것이다. 그와 마찬가지로, 고교 과정까지 배운 영어만으로도 커다란 재산이며, 프로그래머의 코딩 실력에 커다란 뒷받침이 된다. 품사니 태, 법, 3형식 4형식 같은 것들을 자꾸 떠올려보면서 이 글을 읽었으면 한다.
0. 주석
흔히 하는 이야기로, 주석은 없어서도 안 되지만 필요 이상으로 많아서도 안된다. Martin Fowler의 책 Refactoring 을 보면, ‘주석을 쓸 필요가 있다고 느낀다면, 먼저 주석이 불필요해질 때까지 코드를 리팩토링해보라’라는 말이 나올 정도이다. 이는, 역시 흔히 하는 이야기로 ‘잘 쓴 코드는 그 자체가 주석이다’라는 말과 일맥상통하는 말이다. 예를 들어, Refactoring의 Extract Method 항목을 보면 이런 예가 나온다.
이 예는 코드의 블럭에 주석을 붙여서 설명을 하는 대신, 블럭이 하는 일을 직접 알 수 있는 이름의 메서드를 추가함으로써 주석 자체가 필요없게 만든 것이다.
그러나, 주석에 관련된 이러한 지침들과 조언들은 대부분 프로그래머가 영어에 익숙하다는 전제를 깔고 있다. 아주 극단적인 예로, 다음 두 코드 조각들을 비교해보자.
코드:
1.
void printOwing(double amount)
{
printBanner();
printDetails(amount);
}
2.
// 고객의 미지불 정보를 출력. a는 미지불 총액
void print1(double a)
{
// 배너를 출력한다
print2();
// 미지불 정보를 출력한다.
print3(a);
}
영어에 익숙한 사람이라면 당연히 1번 예가 더 낫다고 생각할 것이며, 주석을 달 필요를 전혀 못느낄 것이다. 그러나 만일 owing이나 banner, amount 같은 단어를 모르는 사람이라면 1번은 주석이 전혀 없는 난해한 코드, 2번은 친절한 주석이 달린 알기 쉬운 코드라고 생각할 수 있다.
이 이야기의 교훈은 간단하다. 깔끔한 코드를 원한다면 영어에 더 익숙해져야 하며, 그게 싫으면 주석이라도 많이 집어넣으라는 것. 물론 선택은 여러분의 몫이다.
1. 객체 지향 언어의 표기법과 영어
객체 지향 언어들의 표기 방식에서 영어보다는 한글 어순에 가까운 용법들이 보인다는 점을 지적하는 사람들이 있다. 예를 들어 어떤 문을 연다고 하자. 절차적, 즉 함수와 자료구조 중심의 프로그래밍 언어라면,
open(theDoor);
이런 형태로 표기하게 될 것이다. 이는 영어의 명령문 어순(서술어-목적어)과 거의 일치한다.
Open the door.
반면 객체 지향적 프로그래밍 언어라면,
theDoor.open();
이는 차라리 한글 어순에 더 맞는 듯 보인다.
그 문(the door)을 열어라(open).
그러나 이는 단지 우연일 뿐인 것 같다. theDoor.open()을 일상 영어로 표시하자면 다음에 가까울 것이다.
Door, open yourself!
(yourself는 그냥 붙인 것이 아니다. 실제로, c++에서는 open()이 호출될 때 암묵적으로 this 포인터가 전달된다. this가 바로 yourself에 해당한다).
절차에서 객체로 오면서, 바뀐 것은 어순이 아니라 명령의 대상일 뿐이다. 즉 open(theDoor)는 컴퓨터 자체에게 문을 열라고 명령하는 것이라면, theDoor.open()은 ‘문’이라는 객체에게 명령을 내리는 것(객체 지향 세계의 용어로 말한다면 객체에 메시지를 전달)이다.
어쨌거나 중요한 것은, 객체 지향 언어를 만드는 사람들은 스스로 자각했든 그렇지 않든 여전히 영어를 염두에 두면서 언어를 설계했다는 점 - 객체 지향에서도 영어는 여전히, 아니 더욱더 중요하다.
2. 명사
영문법의 명사는 프로그램 소스 코드의 변수나 상수, 클래스 등의 이름에 해당한다. 명사는 행위의 주체(주어) 또는 행위의 대상(목적어)으로 쓰이곤 한다.
코딩 스타일 표준에 따라서는 변수 이름을 소문자로 시작할 수도 있고 대문자로 시작할 수도 있다. 물론 접두어가 붙는 경우 접두어는 소문자로 쓰는 것이 일반적인 관례이나, 변수의 의미를 알려주는 주된 단어 자체는 대문자로 하는 것이 바람직할 것 같다.
변수를 대문자로 시작하는 것이 좋은 첫 번째 이유는, 변수를 일종의 고유 명사로 볼 수 있기 때문이다. 알다시피 영어에서 고유 명사는 항상 대문자로 시작한다. 두 번째로, 특히 객체 지향적 언어에서는 문장 제일 처음에 나오는 단어가 변수(객체)인 경우가 많다. 절차적 언어에서는 배정문이나 기타 제어문이 아닌 나머지는 모두 함수 호출이며, 따라서 항상 동사가 문장 처음에 나오는 셈이 된다. 그러나 객체 지향 언어에서는 어떠한 동작을 수행할 때 우선 객체 변수가 나오고 그 다음에 그 객체의 메서드가 나오는 식이며, 따라서 문장 처음에 변수 즉 명사가 나오게 된다. 역시 알다시피 영어에서 문장 첫 단어는 대문자로 쓴다.
3. 관사
변수 이름에는 접두어가 붙기도 한다. C 중심 API에서는 흔히 변수의 자료형을 의미하는 접두어를 붙이곤 했으나, 엄격한 형검사를 수행하는 C++ 같은 언어에서는 굳이 변수의 이름에 자료형 정보를 추가할 필요는 없다고 생각한다. 굳이 접두어를 붙여야 한다면 자료형보다는 변수의 범위에 대한 정보를 제공하는 접두어가 더 유용할 것이다.
영어 문장에 좀 더 가까운 코드를 만들기 위해서라면, 변수의 범위를 ‘관사’로 표현하는 것이 바람직할 것이다. 예를 들어 함수의 지역 변수나 매개 변수에는 a(an)를, 전역 변수나 멤버 변수에는 the를 붙이는 식이다. 이는 일상 영어에서 a와 the의 일반적인 의미를 반영한 것이다. 예를 들어 an apple은 불특정한 하나의 사과를 뜻하나, the apple은 해당 맥락에서 이미 존재하고 있던 또는 화자들이 익히 알고 있는 특정한 사과를 뜻한다. 지역 변수는 해당 범위에 진입할 때 초기화되고 범위를 벗어나면서 사라진다는 점에서 a(an)를 붙이는 것이 의미가 있으며, 전역 변수는 전역 아래의 개별 범위들에서도 이미 존재하며 언제라도 접근할 수 있다는 점에서 the를 붙이는 것이 의미가 있다.
명사에는 형용사가 붙기도 한다. 형용사는 명사에 대한 추가적인 정보를 제공한다. 영어의 경우 형용사는 명사 앞에 붙는다. 예를 들어 a red apple. 그렇다면 프로그래밍에서 형용사는 어떻게 표현될까?
형용사는 명사에 대한 추가적인 정보를 제공하기 위한 것이라는 점을 생각하면, 형용사는 객체의 상태를 의미하는 멤버 변수 또는 속성에 해당한다고 할 수 있다. 예를 들어 a red apple을 프로그래밍적으로 표현한다면,
코드:
class Apple
{
private:
Color theColor;
public:
void setColor(Color aColor) { theColor = aColor; }
};
...
Apple aApple;
aApple.setColor( Color("Red") );
이는 결국, 뭔가를 코드로 표현하고자 할 때 어떤 형용사를 사용하려고 한다면, 그 형용사 하나만 추가할 수는 없다는 뜻이 된다. 형용사를 사용하려고 하면, 사용하고자 하는 형용사들의 범주를 의미하는 ‘명사’를 정하고 그 범주를 명사에 속하는 하나의 멤버로 만들어야 한다는 뜻이 된다. 위의 예에서 red라는 형용사를 사용하기 위해서는 color라는 일반화된 ‘명사’를 생각해 낼 수 있어야 한다 - 사실 이는 객체 지향적 모델링의 기본이라 할 수 있다. 주어진 대상에서 중요한 명사들을 뽑아내는 것은 가장 기본적인 객체 식별 방법이기 때문이다.
예를 들어 a apple은 불특정한 하나의 사과를 뜻하나, the apple은 해당 맥락에서 이미 존재하고 있던 또는 화자들이 익히 알고 있는 특정한 사과를 뜻한다. 지역 변수는 해당 범위에 진입할 때 초기화되고 범위를 벗어나면서 사라진다는 점에서 a를 붙이는 것이 의미가 있으며, 전역 변수는 전역 아래의 개별 범위들에서도 이미 존재하며 언제라도 접근할 수 있다는 점에서 the를 붙이는 것이 의미가 있다.
..
뭐.. 굳이 따지겠다는 건 아니고.. 옥의 티랄까요..^^;
a apple 이 아니고 an apple 이 되어야할 것 같습니다. 관사를 쓴다면 말이지요.. ^^;;
가입: 2001년 7월 25일 올린 글: 3413 소속: GPGstudy 타 사이트 ID(?): docbook.kr::류광
조금 수정했습니다..
올려짐: 2002-05-17 16:14
와 호응이 좋아서 기쁩니다..
파연님 지적하신 것처럼 .. 자바 코딩 표준을 언급한 부분이 근거가 미약하네요...
인용:
많은 코딩 스타일 표준들은 변수 이름을 대문자로 시작하라고 권장한다. 특히 자바 진영의 코딩 스타일 표준들은 거의 예외없이 변수 이름을 대문자로 시작하라고 한다. 물론 접두어가 붙는 경우도 있으나, 어쨌든 변수의 의미를 알려주는 주된 단어 자체는 대문자로 시작하는 경우가 대다수이다. 그에 비해 함수는 소문자로 시작하라는 것이 일반적이다. 반면 Win32 API의 경우에는 함수는 대문자, 변수는 소문자로 시작하는 경우가 많다.
그래서 다음처럼 두루뭉실하게 고쳤습니다...(번역가의 필살기 중 하나 - "애매한 것이 틀린 것보다 낫다" -.-)
인용:
코딩 스타일 표준에 따라서는 변수 이름을 소문자로 시작할 수도 있고 대문자로 시작할 수도 있다. 물론 접두어가 붙는 경우 접두어는 소문자로 쓰는 것이 일반적인 관례이나, 변수의 의미를 알려주는 주된 단어 자체는 대문자로 하는 것이 바람직할 것 같다.
a apple도 an apple로 고쳤습니다. 파연님 감사...
GPT 관련해서는... 위와 같은 오류들에서도 알 수 있듯이.... 현재 일정에서 단행본에 실릴만한 완성도(제 나름대로의 기준에 의거한...)를 보장하기 힘들 것이라고 판단했습니다.. 분량 채우기도 만만치 않구요..
다음 글에서는 동사와 부사를 간단하게 짚고, 변수와 함수 이름 짓기에 관해서 좀 더 구체적인 예들을 많이 집어 넣어서 설명할 생각입니다. 특히 함수 이름 짓기에서는 흔히 쓰이는 동사들을 나열하고 비슷하지만 약간 다른 동사들.. 예를 들어 get/retrieve/acquire/fetch 같은 것들의 용례를 구분해 볼까 합니다..
하지만, 과연 굳이 모음으로 시작되는 단어에 a가 아닌 an을 사용해야 하는지에 대해선 좀 애매합니다. 예를 들어 M으로 시작하는 단어라고 하더라도 "엠"이라고 읽히는 경우 (뭐 MSX, MBA, MS 등등..) 영어에서는 an 을 사용하고요, 이런 식으로 약간 혼돈을 줄 수 있는 여지가 있고요,
게다가 furniture나 water와 같은 uncountable noun 의 경우에는 아예 부정관사를 사용할 수 없게 되어있는 것이 영어입니다.
그래서 관사에 완전히 의존적인 코딩은 힘들지 않을까 생각합니다.
전역변수, 클래스의 멤버변수, 지역변수 등은 각각 g_, m_, (없슴)을 붙여주는 것이 좀 더 명확하지 않을까.. 하는 것이 제 소견입니다.
가입: 2001년 7월 25일 올린 글: 3413 소속: GPGstudy 타 사이트 ID(?): docbook.kr::류광
올려짐: 2002-05-19 19:07
파연님:
코드 안의 aApple 부분은 그냥 애교로 남겨두죠 뭐.... 사실 그 부분은.. 문서로서의 소스 코드라는 개념을 어느 정도까지 철저하게 밀고 나갈 것인가에 대한 문제 제기일 수도 있습니다.. (어떻게 바라볼 것인 가가 중요하긴 하지만 결국 코드는 코드일 뿐이니까요... )
그리고 코딩 표준에 대해서는 이 글과 개별적인 주제로 한 번 토론을 해봤으면 좋겠습니다. 재미있을 것 같아요...
karaguru 님:
Wrox 책 안하기로 했었는데... 국내 번역서 시장에서 Wrox가 차지하는 비중을 무시할 수가 없다는 결론과... 올해 들어서 Wrox 책들이 다시 예전 수준의 품질로 올라가고 있는 것 같다는 이야기 때문에 아마 올해 안에 적어도 한 권 정도 할 것 같습니다. .NET C# 쪽이 될 것이구요.
그리고... 시간이 좀 나면 제가 알고 있는 출간 예정 번역서들을 정리해서 올릴께요..
open(&theDoor)는 별 차이를 못 느끼겠는데 자세히 설명을 좀....
그리고.. 가입하신 분들도 왜 guest로 글을 쓰셨는지??? 혹시 로그인에 문제가 있었나요.. 버그 보고 바랍니다.. (저번에 ezBoard에서 phpBB로 바꿀 때에도 그랬지만... 시스템 바꾸면서 로그인, 접속 유지, 개인 정보 변경 부분이 잘 안되는 경우가 많았습니다..)
소스 코드가 단순히 일련의 작업의 나열이 아니라
일종의 문서와도 같다는 개념에 찬성하는 바입니다.
요새들어, 기본적으로 'Language'라 함은 사람(프로그래머)를 위한 것이라는 생각이 들어서 말이죠... ^^
결국 사람이 쓰기 좋고, 읽기 좋고, 관리하기 좋은 코드/언어 가 좋은 코드/언어 이지 않나...하는 생각이 듭니다.
하지만 몇가지 개인적인 의견을 더 이야기 하자면,
코드가 영문장처럼 느껴지고 읽혀진다는 것은
그만큼 코드의 흐름이 부드럽게 이어지고 있다는 뜻이지
코드의 형식이나 문법 등이 영문장의 그것과 동일한 형태를 띤다는 것은 아니라고 생각합니다.
즉, 코드의 흐름이 얼마나 자연스러운가가
코드가 얼마나 영문장과 닮아 있느냐 보다 중요하다고 생각합니다.
영어를 잘하는 사람이라도 C를 전혀 모른다면, C 코드를 이해하기 어려운 것이
다소간은 당연한 일이 아닐까요? ^^
따라서 형식적인 측면에서는
해당 언어의 관례를 따르는 것이
일단은 무난하다고 생각합니다.
영어에는 영어의 문법이 있고, 한글에는 한글의 문법이 있고, C에는 C의 문법이 있는 거겠죠.
그리고 그것이 다른 프로그래머에 대한 일종의 배려라는 생각도 듭니다.
(물론, 저 같은 경우에는 제 맘에 안드는 관례는 '거의' 철저하게 무시합니다만..... ㅡㅡ
p.s: 음... 류광님께서 '코딩 표준'에 관한 이야기는 개별적으로 이야기해봤으면 좋겠다고 말씀하셨는데...
제가 보기에는 이 글에도 '코딩 표준'에 관한 내용이 포함?되는 것 같은데요?
제가 잘못 이해하고 있는 건가요?
가입: 2001년 7월 25일 올린 글: 3413 소속: GPGstudy 타 사이트 ID(?): docbook.kr::류광
올려짐: 2002-05-21 00:15
kane 님 의견에 동감합니다. 코드는 코드일 뿐이죠... 게다가 프로그래밍 언어는 일상 언어에 비해 문법이 매우 엄격하고, 또한 타이핑 효율성이라는 것도 있고.. 등등.
지금 생각하면 정말로 하고 싶었던 말은... 많은 사람들이 몇 년을 공부했든... 항상 프로그래밍에서 뭔가 커다란 벽을 느끼게 되는 것이... 자신의 개인적인 부족함 때문만은 아니라는 것.... 크게는 변두리 국민의 한계일 뿐이라는 점... 인 것 같기도 합니다(인문학도들이 느끼는 좌절감에 비한다면 적겠지만요).
어쨌든 영어는 벽이지만 일단 넘으면 디딤돌입니다..
그리고 코딩 표준을 따로 이야기하자는 것은... 게시판 특성 상 구체적인 주제들을 개별적인 스레드로 이야기하는 게 효율적일 것 같기 때문입니다. 예를 들어 접두어, 중괄호, 명명 관례 등등... 이들은 그 자체만으로도 상당히 긴 논의가 될 수 있을 것 같습니다.
그리고 많은 사람들이 간과하는(... 라기 보다는 누구도 잘 가르쳐주지 않는) 소스 파일 조직화(헤더 파일 분리 등등) 같은 것도 이야기해보고 싶구요..
그런 것들이 이후의 강좌(라고 하긴 부끄럽지만)에서도 언급되겠지만, 주로는 영어라는 관점에서 접근될 것이구요. 다른 관점과 경험들로 다양하게 접근하려면 개별적인 주제로 만드는 게 나을 것입니다.
누구 운을 떼실 분??
p.s Guest가 그런 이유였군요.... 손님도 이름을 남길 수 있게 하기 위한 기능이 다른 식으로 효과를 발휘했네요...
FAQ
검색
멤버리스트
사용자 그룹
이미지 자료실
사용자 등록하기
개인 정보
쪽지(개인 메시지)를 확인하려면 로그인하십시오
로그인
[?]
