brunch

You can make anything
by writing

C.S.Lewis

by 유자 Jul 15. 2022

08. 영문법으로 접근하자

영어를 사용하는 문화권에서 발전했기에.

코딩을 배우다 보면 다들 한결같이 영어를 공부해야 한다고 말한다.

영어를 못해서, 영어를  몰라서, 영어가 힘들어서 코딩을 배우는  어렵다고 한다. 처음에는 그냥 '영어' 자체가 부담스러워서 그런가 보다 하고 동의를 했지만, 시간이 지나고 보니 사실 '영어'자체만의 문제는 아니라는 생각이 들기 시작했다.  



'영어' 공부하는 것도 다양한 목적과 그에 따른 적절한 방법이 있지 않는가. 우리가 수능이나 토익 시험을  치기 위한 기초 문법, 다양한 단어, 빠른 시간 내에 맥락을 파악하여 원어민과 같은 대화를 하고자 공부를 하는 것이 아니다. 물론   있다면야 좋겠지만 그렇게 수준 높은 언어 공부를 하기엔 시간이 빠듯하다. 그리고 단순 영어 능력이 개발 능력과 정비례한다면 영어를 전공한 사람을 뽑으면  일이다. 개발자가 하고자 하는 영어 공부는 주로 영어권에서 개발되고 업데이트되는 개발 문서를 읽고 학습한  개발 능력을 키우기 위함이다.


겨우 일여 년뿐이지만 초보자가 프로그래밍 분야에서 경험하는 어려움은 크게 세 가지다.


0. 똑같이 따라 해도 오류가 발생하는 비과학적인 요소.

1. 가르치는 교수법과 실제 일하는 현장 차이.

2. 영어로 포장되어 있는 영어 문화권 언어 이해 방식.


분명히 시키는 대로 똑같은 코드를 입력해도 아니 그걸 그대로 복사 붙여 넣기를 해도 사람마다 다른 에러가 발생한다. IT기업 유명 개발자들은 학원이나 대학에서 암기식으로 배운 사람은 뽑기 싫다대기업 총수 같은 발언을 한다. 게다가 프로그래밍 언어 자체를 쳐다보고 있으면 코드는  이따구로 생겼는지 이해하기 난해하다.


매일같이 새로운 것이 탄생하는 거대한 우주의 한 토막을 배우는 인간으로서의 나는 위 세 가지가 힘들었고, 이 어려운 점을 해결할 방법들을 생각해보았다.


컴퓨터와 의사소통할  있는가?            -> 아니다

프로그래밍 언어를 잘하는가?               -> 아니다

영어를 잘 하는가?                              -> 아니

 

망했다. 처음부터 다시 생각을 해보자.





똑같이 따라해도 오류가 발생하는 비과학적인 요소.


프로그래밍은 지독히 과학적이면서 사용자때문에 비과학적으로 느껴지는 부분이 많다. 초보자에게 코딩을 가르친다하는 학원이나 유튜브 강의를 보면 일단은 무조건 교수자가 말하는대로 똑같이 따라 설정하고 타이핑 치는 방법이다. 문제는 그렇게 했는데오류가 발생하는 것이다. 물론 완전 똑같지 않아서 그렇겠지만은 처음 배우는 사람이 그걸 어찌 알겠는다. 그저 검은 화면의 빨간 에러 메시지가 보기 싫어서 코딩을 포기하는 사람이 많다.


처음 리액트를 시작할 때에도 윈도우 환경에서 설정을 하는데 무슨 에러가 이렇게 많이 뜨는지 모르겠다. 에러를 해결하겠다고  에러 코드를 구글에 검색한다? 그럼  사람마다 해결 방법이 다르다. 게다가 해결한 사람의 절반은 그게  해결됐는지 모른다. 일단 자기는 그렇게 해서 해결이 됐다고 적어둔다. 이게 원숭이가 얼음 속에 들은 바나나를 꺼내 먹는 100가지 방법을 연구하는 거랑 똑같지 뭔가 싶다. 물론 나는 바나나 껍질도  만져보고 침만 흘리고 옆 사람이 먹는 거나 쳐다보는 똥멍청이 원숭이지만 말이다.


'과학'이라 함은 일정한 규칙이 존재하고 연구 방법이 동일하다면 연구의 결과 역시 동일하게 나오는 재현성이 중요한 요소 중의 하나인데, 이놈의 프로그래밍은 연구 방법을 동일하게 맞추는 과정을 생략하는 경우가 많아서 결과가 동일하게 나오지 않고 맨날 따라하는 사람을 함정에 빠뜨린다. 그리고 오류가 발생한 뒤 찾아보면 버전이 맞지 않는다던가 뭐 암튼 이러저러한 요소를 알려준다.


똑같은 계산기로 1+1을 해도 10진수로 하면 2가 나오겠고, 2진수로 하면 10이 나오지 않겠는가. 과학의 기본이다.


무울론. 이런 어려움 때문에  울트라 어썸한 선구자 개발자들이 '도커'라는 시스템을 만드신  같지만 결국 이것 또한 배워야한다... 혼자서 독학으로 배우는 것이 어렵다. 그래서 다들 국비지원이든 자비든 친절하게 알려줄 사람이 있는 학원을 찾아가게 된다.


참, 그래서 내가 경험했던 윈도우 에러는 그냥 회사에서 맥을 지급받아 쓰는 걸로 해결했다. 나는 아직도 윈도우에서 발생한 그 에러를 어떻게 해결해야하는지 모르고 살아갈 것이다.





가르치는 교수법과 실제 일하는 현장 차이.



신입 개발자에게 취업에 대한 조언을 해 주는 현직 개발자들의 유튜브를 몇몇 보다가 기분이 팍 상한 적이 있다. 자신들이 사람을 뽑을 때 이러한 사람을 절대 뽑지 않을 거라고 하면서 주로 나오는 이야기는

학원에서 찍어내 듯이 배운 것을 포트폴리오로 제출한 사람을 뽑지 않을 것이라면서 면박을 준다.



하하. 세상에. 본인들은 태어날 때부터 응애 대신 Hello, world 를 외치면서 태어난 줄 알겠다.


, 그래. 물론. 학원에서 만든 것을 별다른 기능 추가도 없이 포트폴리오를 제출한  성의의 문제이긴 하지만 그렇게까지 신입을 무시하는 발언은 도를 지나쳤다고 생각한다. 위에서 이야기했듯 코딩을 똑같이 따라서 하는 것도 어려운 판국에 현업에서 일하는 경력자와 동일한 생각과 깊이의 포트폴리오를 요구하는 것은 생각을 다시  보셔야 하지 않을까. 최근 신입 채용공고를 보면 요구하는 리스트들이 장난이 아니다. 이력서와 포트폴리오와 깃허브는 기본이며 어썸하고 창의성이 넘치고 디자인도 훌륭한 토이 프로젝트로 눈길을 사로 잡아야하며 서류 통과를  사람에게는 현업에서 쓰지도 않을 어려운 알고리즘으로 풀어야 하는 코딩 테스트도 주어지며, 면접에서는 각종 전문 지식을 물어본다. 에헤이. 신입을 경력처럼 뽑으시면  되지. 만의 확률로 그렇게 통과한 혜성같은 신입이 온다 한들 일반 회사에서 그렇게 멋지고 복잡한 알고리즘으로 최근 나온 신식 기술이 적용된 프로젝트가 있겠냐구요. 다들 업데이트 안 된 세기말 코드들 가지고 어영부영 작동시키고 있을텐데. 양심 챙기십쇼.


요즘 시대모든 학습이  영상 또는 학원을 통해 효율적으로 배우는 것을 추구한다. 초등학생들에겐 주산학원과 프로그래밍 학원이 유행하 , 직장인들에게는 자기개발이라며 코딩 기초교육을 은근히 강요하는 분위기까지 유행하고 있다. 같이 협업하는 디자이너가 로고 하나 만들어주는데 이건 레이어에 어떤 효과를 주었고, 보여지는 것이 화면인지 출력물인지에 따라서 CMYK인지 RGB인지 설정을 변경했고, 이러저러한 디자인 적인 요소를 살려서 작업을 하느라 몇 시간이 더 소요될 예정인데, 1픽셀의 차이가 맘에 들지 않아서 고민을 하고 있다. 라고 설명을 하면 어떨 거 같은가. 사무직에게도 개발자가 사용하는 전문용어를 이해하라는 광고는 무슨 자신감인지 모르겠다. 모든 세상과 직군이 개발자를 중심으로 돌아간다는 개발자동설을 외치는 사람들을 보면 세상 참 편히 산다는 생각까지 든다.


자고로 신입은 회사에 와서 메일 쓰는 , 전화 받는 법부터 가르쳐 줘야 한다. 숨 쉬고 화장실 가는 것도 어색해하는 애기다. 하물며 코딩을 같이 해야 하는 신입 개발자를 뽑는다면 개발팀에서 코딩을 하는 법을 알려주는 것이 당연하다고 생각한다. 어디서 배웠는지 출신이 뭐가 중요하나. 개발자가 학력과 대학을 따져서 뭐에 쓸거냐. 점점 공무원과 기득권 대기업처럼 거드름피우는 분위기가 조성되어가고 있다고 생각된다. 이미 개발자가 되기 위해서 부트캠프 업체에 몇 백씩 내고 공부 다니는 사람들이 수두룩하지 않는가. 현재 존재하는 직업군 중에서 가장 최단 기간 내에 취업을 위한 고액 학원과 시험 제도가 생긴 업종이지 않을까 싶다. 개발자가 근무하는 모든 기업들이 네배라 뭐시기들처럼 경력자를 신입으로 후려쳐서 뽑는 현장의 분위기가 점점 심해지면, 신입의 유입을 힘들게 하는 요인밖에 되지 않는다.   


게다가 대부분의 회사는 상위 티어만큼 연봉도 못 주지 않는가. 구직자가 타협을 하면 회사와 실무자들도 타협을 해야지. 있는 사람을 갈아넣지 말고, 들어올 사람을 엄격한 잣대로 재단하지 말자.





영어로 포장되어 있는 영어 문화권 언어 이해방식.



지금은 아마 거의 쓰지 않겠지만, 학교에서도 교과서 외 부교재로 채택해서 수업을 할 정도로 인기가 있던 성문 기본영어 책이다. 이 시대의 영문법 책을 가장 먼저 펼치면 나오는 챕터는 '문법의 형식'이다.

1형식부터 5형식까지 쭉 듣다보면 이미 여기서 영어를 포기하는 사람들이 속출하게 된다. 그게 바로 나였다.



영어와 한국어의 가장 큰 차이점은 주어와 동사의 위치가 다르다는 것이다. 사실 코딩은 영어다. 그래서 영어를 그대로 직번역한 듯한 자료때문에 공부가 더 막힌다. 글자가 읽히고 이해가 되야하는데 대부분의 문장이 머리 속에 들어오질 않는다. 도대체 저걸 보고 이해한 사람들은 뭔가 싶다. 다들 그 똑같은 문장을 개발 블로그에 다 복붙해놓는다. 심지어 다른 블로그에 있는 글을 똑같이 가져다 놓는 사람들도 있었다. 이게 무슨 git fork 도 아니고.


영문법 이야기를 하게 된 것은 프로그래밍도 결국은 하나의 의사소통 표현 방식이기 때문이다. 컴퓨터에게 명렁어를 입력하는 것을 단순하게 한 두줄로 끝내는 게 아니라, 여러 가지 조건값을 제시하여 상황에 맞는 반응이 나오도록 하는 것. 그러기 위해서는 영어로 글쓰기를 해야하는데, 그 글쓰기의 조건이 일반적인 영문법에 맞춘 에세이 쓰기와 판이하게 다르다는 것이다. 



나는 회사에 간다. 나는 밥을 먹으러 간다. 나는 집에 간다.



라고 글을 쓰라고 하면 프로그래머는 생각한다.


'중복되는 것을 없애자'


그래서 1페이지에 열심히 단어를 정리한다.



(1) 나

(2) 는

(3) 에

(4) 간다

(5) .



그리고 다시 문장을 바꿔치기 한다.



(1)(2) 회사(3) (4)(5) (1)(2) 밥을 먹으러 (4)(5) (1)(2) 집(3) (4)(5)



그리고 좀 더 줄이고 싶어한다.

1, 2, 4, 5가 반복이 되니까 말이다.



(1)(2)

(1번째 문장에서는 회사, 2번째 문장에서는 밥을 먹으러, 3번째 문장에서는 집)

(1번째 문장과 3번째 문장에서 (3), 2번째 문장은 null)

(4)(5)



이게 개발자가 프로그래밍으로 코딩하고 리팩토링 하는 과정이다. 일반적인 사람으로서는 이해하기가 쉽지 않다....... 정말로... 



글쓰기라고 하면 암묵적으로 합의가 된 적당한 형태가 있다. 서론, 본론, 결론으로 나눌 수도 있고 가장 중요한 주제는 서두에 붙이거나 말미에 요약해서 강조한다던가 하는 것 말이다. 프로그래밍도 비슷하게 볼 수는 있다. 그게 언어마다 다르고 그 언어에서 주도권을 잡고 있는 디자인 패턴이라고 하는 것으로 언급되는 느낌이다. 기능상의 차이가 날 수도 있고, 개인/팀 단위 취향의 문제일 수도 있다. 다만 통일한 느낌보다는 각 언어와 기능 구현을 위해서는 암묵적으로 '당연히 이렇게 구현해야지' 하고 넘어가는 요소들이 개발 공부를 어렵게 하고 있다. 어느 정도 경험이 쌓이면 기반 지식들이 자연스럽게 구축이 되어서 설명을 생략하게 되는 거겠지. 그렇게 생각하고 있다. 




통계분석을 처음 시작한 것은 spss였는데 얘는 유료다 보니 사용하기 쉽지 않았다. 그래서 자연스레 R을 배우게 되었는데 얘는 그래도 수학 기반의 프로그램이었다.


 

이렇게 수학식을 한 줄 한 줄 풀어나가는 느낌으로 적어주면 어지간한 건 다 해결이 되었는데 문제는 파이썬으로 넘어오면서부터다.


R에서는


삼색, 치즈, 고등어 = 고양이

코기, 사모예드, 리트리버 = 강아지

고양이, 강아지 = 포유류


가 성립된다면 파이썬에서는


고양이 = 삼색, 치즈, 고등어

강아지 = 코기, 사모예드, 리트리버

포유류 = 고양이, 강아지


요 느낌이다. 주어와 서술어가 완전히 뒤바뀌는. 3형식을 4형식으로 바꿔버리는 것 같지 않는가


게다가 JS에서 비구조 할당이라는 건 근의 공식 같은 놈이다.

x(a+b)=xa + xb 같은 방식으로 중복해서 타이핑하는 것을 최소화시키고 있다.


const {a, b} = x


x.a와 x.b를 축약해서 굳이 조금이라도 타이핑을 덜쓰겠다는 그 의지는 정말... 이해하기 힘든 개발문화이다.


기술의 발전은 그 기반이 되는 문화와 인간의 영향을 많이 받게 되는데 프로그래밍 역시 마찬가지이다. 그 언어를 개발한 사람과 계속 발전시키고 있는 단체 그리고 주로 사용하는 개발자 커뮤니티의 분위기가 기술을 가장 잘 설명할 것이다.


얼마 전에는 개발에서 숫자의 시작을  0부터 하는지를 우연히 읽었는데 나름 타당성이 있는 이야기 같았다. 코드만 보다가 지칠 때는 잠시 머리를 비울 겸 관련된 발전 역사를 찾아보는 것은 어떠할까. 사실 그냥 멍 때리는 게 제일 좋기는 하지만 말이다.



여담이지만 내년 오월쯤엔 정말 이직을 노려봐야갰다.




작가의 이전글 07. 이 기능은 며칠 작업 분량일까
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari