프로그래밍 적성에 관한 고민과 해결을 위한 Tool 5가지

사실 작년 7,8월에 개발공부 접해보고 제대로 공부하기 위해 투잡을 뛰며 2월까지 정신없게 돈을벌고 2월부터 삭발을 하며 9월까지 공부했을 때 이 공부를 하며 적성이 맞지 않다 란 생각을 한번도 안해본건 아니었다.

나는 뭔가 어려운 문제나 해결해야 하는 문제가 있을 때 생각하는것을 힘들어하며 뭔가 에러가 생겼을 때 누군가 해결해 주기를 바랬었다. 그리고 그것을 '빠른 피드백'이라고 '자기 합리화'를 하며 문제를 피해왔던 것 같다. 공부를 그런 방식으로 했었고 지금 이해가 안되는건 당연한거야 다음번에 볼땐 괜찮을거야 라고 생각하며 코드가 구현이 안되는 상황이 있을 때마다 구글링을 하거나 해답지를 보고 이해를 하는 방식으로 공부방식을 진행하였다.

그러나 그 방식은 이과에서 수학이 싫어 문과로 간 나에게 더 생각하는 힘을 기를 시간을 갖지 못하게 하였고, 그 결과 간단한 함수의 코드 한 줄 구현하지 못하는 사람이 되었다.

근 며칠간 많은 검색을 해본 결과 함수를 구현하고 코드를 짜며 알고리즘을 생각하여 구현한다는 과정은 문제를 면밀하게 읽고 파악을 한후 내 머릿속에서 그 과정을 풀어 생각을 정리한 후 그 나의 언어로 정리한 생각을 순서대로 배치하여 그 순서에 따라 내 언어를 컴퓨터의 언어로 바꾸는 과정이었다. 그리고 나의 회고팀의 '수학과'를 나오신 형님은 이 과정이 굉장히 익숙해보였고 응용과정을 잘 해냈다.

나는 남의 코드를 따라하고 구현하는 클론코딩, 구글링 들을 통해 해답을 빨리 얻는 과정으로 이 내 머릿속에서 논리력과 문제해결능력을 기르는 과정 자체가 삭제되었다고 무방하다. 그렇다 보니 남들은 알고리즘을 이해하고 구현하여 발표를 할 동안에도 책과 강의를 보며 2시간동안을 이해하지 못하였다.

벽에 부딪힌 느낌이었고 이 벽을 뚫고 나갈 자신이 없었다. 벽을 뚫으면 또 벽이 있다고 하고 사실 나는 내 인생에서 이렇다할 성취를 이뤄보지 못한 사람으로써 더욱 자신감이 없었다.

나와 같이 하는 백엔드스쿨 수강생들은 대개 자신감이 넘치고 이 프로그래밍 공부를 즐기고 있는것처럼 보였다. 그리고 최소한 '재밌다'라는 말은 다들 나왔었던 것 같다. 그리고 그 단어는 내 입에서 단 한번도 나오지 않은 말이다. 여기서 박탈감을 많이 느꼈고, 내가 악으로 깡으로 머리 밀어가며 한 것은 의무감에 한 것이었지 단 한번도 흥미와 적성을 찾아 해본것이 아니었구나란 생각이 들었다.

지난 몇주간 이 고민에 대해 강사님과 현업 멘토님들 수많은 컴공과 친구와 현업에 종사하는 지인들에게 상담을 요청하였고 많은 얘기를 들을 수 있었다. 사실 거기서 긍정적인 얘기를 듣고싶었다기 보다 오히려 이 분야는 적성도 많이 타고 진입이 쉬운만큼 사람도 많이나가 그걸 인정하고 넌 할만큼 했으니까 그만하는게 괜찮을거 같아 란 말을 듣고싶었던것 같다. 왜냐하면 너무 질려버렸으니까

사실 블로그를 운영하며 남의 게시글을 따라치고 책에 있는 내용을 그대로 타이핑 했던 과거들을 보며 나는 참 '새로운 가치를 생산하는 것'과는 동떨어진 행동을 하는 사람이었다는 것을 떠올렸고 내가 바래왔던 '대체되지 않는 인재'와는 거리가 먼 인재상이란걸 느낄 수 있었다. 그만큼 나는 남들보다 배우는게 더딘 사람이고 공부를 업으로 삼기에는 남들보다 2배는 더 노력해야 되는 사람이다.

 

그렇지만 이 벽을 뚫지못하면 분명 나는 후회할 것이고 이 시간은 다시 돌아오지 못할 것이다. 나는 자율적인 삶을 살 수 없고 내가 싫어하는 반복적이고 따분한 것들을 하며 커리어는 커리어대로 쌓지못하고 남한테는 직업을 말하지 못하는 떳떳하지 못한 삶을 살것이 너무 상상되었기 때문에 놓을 수 없었다.
그리고 이 분야에 종사하는 사람을 볼때 너무 자신이 못났다고 생각하고 당당하지 못할 것 같다. 그래서 이왕 주어진 이 시간들 최대한 열심히 살아보려 한다. 그치만 이 기대감이 다시 떨어질때는 어떻게 견뎌야 할지 그것까진 미쳐 생각하지 못하였다. 그만큼 업에 관한 고민은 끝없고 돈을 번다는 것은 '프로페셔널'이 가감되어야 하는 절대 쉽지 않은 일이니까.

원래 상담을 해주시던 멘토님이 당근마켓 입사면접을 보셨다고 하셨는데 통과를 하셨는지 이번에 새로운 여자 멘토님께서 오셨다. 나는 그리고 지난 나의 과정들을 설명드렸고 여기서 뜻밖에 엄청난 도움을 받을 수 있었다.
나에게 이때까지 공부했던 지식의 깊이가 얕은것 같다고 말씀해주셨고 원서를 보거나 많이 찾아보며 내가 쓰는 기술들의 정확한 이유와 원리까지 알아야 된다고 하셨다.
공부하셨던 방식은 같은 내용에 대해서 '반복 학습'을 자주하며 멘토님 또한 '응용 부분'이 많이 약하여 같은 내용을 볼 때마다 코딩하고, 해당 내용을 '기술블로그'에 남기며 그 부분을 본인이 상시 기억할 수 있도록 하셨다고 한다. 또한 '프로젝트'를 진행하면서 오픈소스나 이전에 공부한 내용들을 많이 참고하셨다고 한다. 결코 자신이 알고 있는 지식으로만 진행하지 않으셨으며 찾아보는것에 대해 죄책감을 느끼지 말라는 말씀이신 것 같다.
그 분은 나에게 생각이 익숙치 않으니 문제해결능력과 논리적으로 생각하기 위한 강제성 있는 tool들과 강의들을 소개시켜 주셨고 이렇게까지 디테일하게 해결하기 위한 방안을 제시해준분은 처음이었다.

백엔드 스쿨에 들어온것 자체가 나에게 소중한 기회이니 만큼 행동으로 보이며 궁극적으로 개발을 업으로 삼기 위해 노력하라고 하셨다.

 

멘토님의 말씀에 따르면 그 생각하는 힘을 위한 tool들의 목록은 다음과 같다.

< 1. pseudo-code(의사 코드) 작성 >

'의사 코드'란 프로그램 코드를 작성할 때 사용하기 위해, 프로그램의 진행과정을 단계별로 기록해 놓은 것이다.
'가짜의(pseudo)' 코드로써, 알고리즘이 수행될 내용을 인간의 언어로 간략히 설명해놓은 것을 말한다.

사용 이유
-> 나중에 그 프로그램 코드를 읽고 '디버깅'을 하거나 내용을 수정해야 하는 개발자에게 도움을 줄 수도 있음
-> 컴퓨터 프로그램 알고리즘이 어떻게 실행되어야 할지, 또는 어떻게 실행될 수 있을지 보여줄 수 있음
-> 나중에 코드입력, 테스트, 디버그 수정단계에서 작업하는 것보다 '의사코드 설계단계'에서 미리 오류를 수정하는 것이 훨씬 경제적
-> 프로그램의 문제를 해결하기 위한 도구로, 또는 다른 사람들과 프로그램의 흐름에 대해 소통하기 위한 방법으로 활용

effort = 노력

규칙 
-> 반드시 따라야 하는 규칙같은 것은 없지만 다른 개발자들이 쉽게 이해할 수 있는 형식을 사용해야 함
-> 본인이 쓰려고 작성하는 경우 생각을 정리하고 계획한 것을 만드는데 도움이 되어야 한다.
-> 다른사람에게 설명이 되도록

다음 3가지를 통해 의사코드 작성을 작성할 수 있다.

순차적 명령문

반복문

조건문

의사코드 수정하기

-> 의사코드를 작성하는 것의 장점은 어려운 부분을 추후에 채워넣을 수 있다는 것이다. 위 예제에서 단어를 어떻게 찾고 지우고 바꿀 것인지에 대한 내용을 추가해보자.
-> 의사코드를 통해 기능을 추가해보자
-> 의사코드는 '알고리즘 문제'를 어떻게 접근해야 할지 생각하는데 도움이 된다. 따라서 복잡한 프로그래밍 문제를 단순하게 표현할 수 있다.

 

의사코드 작성의 표준

1. 한줄에 한 명령만

-> 의사코드의 한 줄은 한 가지 행동만 표현한다. 할 일 목록을 의사코드로 바꿔보자.

2. 영어로 의사코드를 작성중이라면 각 명령문의 첫 단어를 대문자로 작성해준다. 아래는 자주 쓰이는 의사코드 영어 단어이다.

3. 어떻게 코드로 표현할지 적지 말고, 하고 싶은 이야기가 뭔지 기록한다.

-> 어떤 개발자들은 "if a % 2 == 1then"과 같이 실제 프로그램 코드처럼 의사코드를 작성한다. 이러면 그것을 읽는 개발자들은 a,%,== 같은 기호들의 의미를 추측해야 한다.
-> 그대신 "숫자가 홀수라면(if an odd then)"은 어떨까. 좀 더 쉽고 명확하게 의미를 파악할 수 있을 것이다.

4. 프로세스에 필요한 모든 것을 빠짐없이 기록한다.

-> 의사코드는 '단순한 구조의 문장'으로 작성하며, 대개 변수가 사용되지 않지만 계정 번호, 이름, 거래 횟수 같은 현실에서 사용되는 단어를 이용해 프로그램이 해야 할 일을 설명한다.

5. 블록으로 코드의 구조를 정리해준다. 대개 들여 쓰기를 이용해서 각 명령문 간의 관계를 보여준다. 블록을 만드는 방법은 2가지가 있다.

1. 중괄호 사용하기 {...}
2. 빈칸 사용하기

블록 안에 블록이 들어간다면, '들여 쓰기'는 더 깊어져야 한다.

-> 다음과 같이 의사코드를 작성하지 않고 위와 같은 과정을 코딩하는 것은 끔찍할것.

 

< 2. 플로우 차트 - 순서도, 흐름도(고민의 시각화) >

'순서도'는 어떠한 일을 처리하는 과정을 순서대로 간단한 기호와 도형으로 '도식화'한 것을 의미한다.
미리 정의된 기호와 연결선으로 '알고리즘'이나 '프로그램의 논리' 혹은 흐름을 그림으로 표현하는 방법이다.
프로세스나 문제의 분석, 기획, 디자인, 설계나 관리, 문서 작성 등 폭넓게 활용되고 있다.

즉, 어떤 일을 처리하는 과정을 간단한 기호와 화살표로 도식화 한 그림을 말하는데 주로 컴퓨터 프로그래밍에서 프로그램이 돌아가는 과정을 그림으로 나타낼 때 사용한다. 프로세스의 처리순서를 포함한 단계간의 상호관계를 알기 쉽게 나타낸 그림이다.
이 순서도는 실행, 판단, 연결 등 특별히 형태가 약속된 몇 가지 요소로 되어있다.
-> 일의 순서를 '흐름선'으로 연결하며, 각 도형에 정해진 의미에 따라 처리를 하게 된다.

"플로우 차트의 흐름은 코딩의 순서와 같다" , "코딩 전 순서도 작성을 습관화하는 것이 좋다"

장점

1. 프로그램의 흐름을 단순화하여 분석이 명료해짐
2. 논리적인 오류를 쉽게 파악할 수 있음
3. 도식화된 기호를 이용하므로 다른 사람이 쉽게 이해할 수 있음
4. 원시 프로그램의 작성을 용이하게 하여 코딩 작업이 간단해짐

플로우 차트의 일반적인 규칙

1. 약속된 표준 기호를 사용한다.
2. 기호의 내부에는 처리해야 할 내용이 들어가야 한다.
-> 처리내용은 기호 내부에 간단명료하게 서술하고, 필요하면 외부의 주석기호에 추가기록 하도록 한다.

3. 기호의 모형은 잘 구분할 수 있어야 한다.
4. 비교/판단 기호 사용시 입/출력은 반드시 하나여야 하며, 결과는 Yes or No이어야 한다.
5. 동일한 처리의 중복을 피한다.

프로그램 순서도

-> 프로그램 순서도는 작업을 어떤 식으로 하는지 표시해주는 순서도로 처리 단위 하나하나 단위로 작성하게 된다. 선명의 세밀도에 따라 개략순서도와 상세순서도로 나뉜다.

상세 순서도

-> 프로그램 내부를 상세히 나타내는 순서도로 컴퓨터의 모든 조작과 자료의 이동과정을 순서대로 나타내 그대로 코딩할 수 있도록 상세하게 작성한 순서도이다.

 

< 3. 30분 강제 타이머 맞추기 >

생각하는 힘이 약해 빠르게 해답을 찾는 나에게는 그것을 강제하는 타이머를 통해 의식적으로 생각하는 시간을 늘려나가는 작업을 해야한다고 말씀하셨다.

< 4. 종이와 펜 >

위에 설명한 플로우차트나 수도코드를 임의적으로 수행하기 위해 종이에 그림을 그려 나의 생각을 꺼내보는 연습을 많이 하라고 하셨다. 이 부분은 자바의 정석 저자 남궁성도 말했던 방법이니 만큼 유용할 것으로 기대된다.

< 5. 로직 손 코딩 >

실제 우리가 하는 코딩의 에러들은 인텔리제이 IDE가 바로잡아 주는 경우가 많고 오타나 변수의 설정까지 다 고쳐주어 실제로 코딩을 하는 힘이 늘지 않는 경우가 있다고 한다. 그래서 일부러 Eclipse를 사용하는 사람이 있을만큼.
기업에 입사할 때 보는 면접에서는 면접관 앞에서 손 코딩을 하는 경우가 꽤 있다고 들었다. 그런 만큼 평소에 연습을 해두면 좋을 것이다.

< 6. 코딩관련 영단어 외우기 - 수능 4등급 수준의 영어 실력 > 

StackOverflow를 보며 필요한 기능을 찾고 영어로 된 자료를 보기 위해서는 무엇보다 그 문장들을 해석할 수 있는 영어 실력이 뒷받침 된다면 아주 좋을것이다. 구글에서 코딩관련 영단어를 검색하니 많은 자료가 나왔다. 나는 이 영단어들을 하루에 10개씩 외우는것을 목표로 실행할 생각이다.

< 7. java, spring 관련 원서 보기 >