6/23 ~ 7/4 까지 진행한 네이버 부스트캠프 베이직 과정에 대한 회고를 작성해보려고 한다.
지원 배경
개발자가 되기로 다짐하고 관련 프로젝트와 활동을 시작한지 어느덧 1년 반이 지났다. 2학년 1년 동안을 아무 의미 없이 그냥 흘려보냈다는 자책감과 뭐라도 하지 않으면 안된다는 조급함으로 1년 반동안 여러 프로젝트를 병행하며 나름 열심히 보내려고 한것 같다. 1년 반 내내 20학점을 들으며 적게는 1~2개에서 많게는 4~5개의 프로젝트를 병행하다보니 웬만한 기능들은 뚝딱 만들 수 있을 정도의 실력은 됐다.
하지만 단기간 내에 수행해야 하는 프로젝트(축제 웹앱, 한 달 해커톤 등)가 대부분이었기에 마감 기한을 맞추기 위해 확장성과 유지보수 측면은 고려하지 않고 그저 프로젝트를 쳐내기에 바빴다. 그렇게 내가 이 기술을 왜(Why) 써야하는지, 이 기술은 무엇(What) 인지에 대한 고민 없이 그저 내가 그동안 짜온 코드들을 답습하기에 바빴다.
개발을 시작함과 동시에 AI가 빠르게 발전한 것 또한 개발 실력 저하에 한 몫 했다. AI의 편안함에 길들여지다보니, 점점 AI와의 대화 형태가 "고민하며 AI와 질문을 주고받는 형식"이 아닌 (생각하기 귀찮으니까 그냥 ) 해줘 형태로 바뀌기 시작했다.
개발 생산성은 훨씬 좋아졌지만, 딱 그만큼 개발의 깊이와 사고력은 퇴화했다.
마지막으로 CS 관련 지식이 사실상 전무했다. ICT융합학부라는 컴퓨터 관련 전공 학부를 나오기는 했지만, 학부 설립 취지 자체가 컴퓨터 지식을 베이스로 기획, 디자인, 게임 등 다양한 융합형 인재를 양성하는 것이었기에 전공 수업을 통해 들을 수 있는 CS 지식은 C 언어, 자료구조, 알고리즘이 전부였다.
단순히 프로젝트 양이 많고, 1일 1커밋을 하며 깃허브를 잘 관리하는 나를 보고 대단하다, 개발 잘한다..며 칭찬해주는 지인들도 많았지만 내 스스로는 알고 있었다. 그저 껍데기 밖에 없다는 것을.
이외에도 문서화 능력, 특정 기술에 대한 딥다이브 경험 전무 등 다양한 이유들로 내가 해나가고 있는 개발에 대한 의구심을 떨쳐낼 수 없었다. 그저 프로젝트만 쳐내며 어느 순간 내가 주체가 되는 개발이 아닌 그저 AI에게 뇌를 의탁하여 개발을 해나가고 있는 나를 보게 됐다.
그렇게 그동안 진행해오던 프로젝트들이 어느 정도 정리되었을 때 (물론 아직 진행 중인 것도 많지만)
잠시 멈추고 나 스스로를 돌아보게 됐다.
"나는 스스로 문제를 정의하고 해결할 수 있는 개발자가 맞나?"
"앞으로 무한히 발전해나갈 AI에 의해 대체되지 않을 수 있을까?"
이 두 가지 질문에 대한 지금 나의 답은 No다.
그리고 이 질문을 Yes로 바꾸기 위해, 내가 남긴 의문에 대한 문제의 원인을 한 단어로 표현하면
기본기 부족 이다.
이러한 나의 문제점과 갈증을 채워줄 수 있는 가장 적합한 것이 네이버부스트캠프라고 생각했다.
베이직을 시작하기 전 알아봤을 때 프로그램 전반에 걸쳐 CS 지식 학습을 강조하는 점이 마음에 들었고, 이를 동료들과 함께 혹은 스스로 문제를 정의하고 해결해나간다는 부분에서 도움을 많이 얻을 수 있을거라 생각했다.
배우게 된 것
문제 정의 및 설계
매일 미션이 하나씩 주어진다. 문제에 대한 자세한 내용은 적을 수 없지만 CS를 바탕으로 한 구현 문제, 설계 문제 등이 있었다.
조건이 자세히 주어지는 문제도 있었지만 대략적인 키워드만 주워지고 스스로 학습 범위를 정해야 하는 문제도 있었다.
대부분의 문제가 간단히 생각해서 풀수 있는 문제가 아니었기에 문제를 풀기 전 문제 정의와 설계에 시간을 많이 사용한 것 같다.
미션마다 조금씩 다르지만, 내가 세웠던 문제풀이 전략은 다음과 같다.
-
문제 요구사항 분석
문제의 조건을 이해하고 내가 쉽게 이해할 수 있도록 가공하여 정리한다. -
사전 학습
문제를 풀기 위해 필요한 사전 지식을 구글링을 통해 학습한다. -
문제 설계
- 앞의 내용을 바탕으로 문제를 어떻게 풀어야할 것인지에 대한 플로우를 구상한다.
- 조건이 복잡하거나 감이 잘 오지 않는 경우는 대략적인 큰 그림만 그려놓고, 문제를 직접 구현하며 작은 단위로 설계를 지속적으로 수행한다.
문제를 스스로 정의하고 설계하는 것 은 베이직 OT에서부터 강조하던 내용이다. 이 과정에서 의도한 방향대로 내가 수행한 것인지에 대한 확신은 없다. 하지만 정답은 없고, 무슨 방법이든 이전과 달리 문제를 대하는 태도에 대해서는 확실히 배우게 됐다. 어떤 것을 구현할때 별 생각 없이 무작정 달려들었던 이전과는 달리 조금은 더 큰 시야에서 문제를 바라볼 수 있게 됐다.
문제가 원하는 바를 파악하고 이것을 해결하기 위한 큰 플로우를 구상하며 이렇게 나눠진 각 단계의 문제를 각개 격파하는 식으로 모든 미션을 수행했다. 특히 구현 문제에서는 이렇게 쪼개진 문제들이 자연스럽게 하나의 독립적인 함수로 분리되었고, 단일 책임 원칙에 의해 함수를 설계하는 연습 또한 많이 해볼 수 있었다.
문서화
베이직 과정에서는 코드로 구현 후 문서화할 것을 요구했다.
문서화에 대한 중요성은 이전에도 알고 있었다. 단지 당장 해치워야 할 프로젝트가 많다는 핑계로 등한시하고 있었을 뿐.
내가 개발한 내용, 트러블 슈팅 내용 등을 기록해보려고 몇 번 시도를 해봤지만 실패했다. 가장 큰 이유는 개발 못지 않게 에너지가 너무 많이 든다는 것이다. 무엇보다 남이 본다고 생각하고 작성할 때는 그 힘이 배로 든다.
그렇지만 어차피 해야할 것이라면 지금부터 습관을 들여야겠다고 생각했다. 문서화에 대한 거부감을 낮추는 것이 가장 큰 목표였다.
README.md 문서화 템플릿
요구사항 분석 - 사전 학습 내용 (있을 시) - 해결과정 - 트러블 슈팅 (있을 시) - 회고
문서화에 대한 양식은 주어지지 않았기에 GPT에 물어본 템플릿에서 조금 다듬어 사용했다.
코드를 짜는 시간 못지 않게 문서화하는 시간도 많이 들어서 2~3일차 까지는 조금 힘들었던 것 같다. 무엇보다 평소에 독서와 글을 읽는 습관도 없고 유튜브 쇼츠 등 짧은 컨텐츠를 소비하는 습관 때문인지 문장을 작성하는 것 자체가 힘이 들었다.
코드를 짜면서 나름 주석도 열심히 달아두기는 했지만, 문서화 시에 이걸 다른 사람들이 읽는다고 생각했을 때 어느 정도 수준까지 작성을 해야하는지도 감이 잘 안왔다.
또한 내 생각의 흐름과 코드에 대한 판단 근거 등을 담으려고 했지만, 작성하다보니 그저 코드 주석 달아놓은 내용을 조금 더 보충하는 수준으로 작성하고 있는 것 같아 내가 맞게 하고 있는지에 대한 의문도 많이 들었다.
하지만 이것도 매일 하다보니 어느 순간 자연스러워졌고,
베이직의 마지막 과정에 가까워져서는 오히려 문서화 없이 코드만 짠다고 했을 때
코드의 실체가 없이 허전한 것 같다는 생각까지 들었다.
문서화를 해야하는 이유
이는 단순한 기록을 넘어 나의 개발 의도와 히스토리를 설명해줄 문서이다.
- 내가 구현한 코드를 나만의 언어로 다시 정리하고, 판단 근거 또한 남겨두는 것
- 또 다른 사람들이 내 코드를 볼때 도움을 주는 것
개발자는 다른 개발자만이 아닌 기획자 디자이너들과 소통하며 일을 해야하기에 잘 정리된 언어로 소통할 수 있는 능력 또한 매우 중요하다.
아직은 많이 미약하지만 표현 방식이나 전달력 부분에 대해서는 앞으로도 많이 기록해두면서 나아질 것이라고 생각한다. 다른 사람들의 글도 많이 읽고 써보며 계속해서 늘려나가야겠다.
학습법 (feat. AI 활용)
AI 시대의 흐름은 거역할 수 없다. 이 흐름의 직격탄을 제대로 맞은 개발자는 두말 할 것도 없다.
AI에 의존할 것이 아니라 내가 주체가 되어 이를 잘 활용할 수 있다면 이 흐름에 올라타 대체불가능한 개발자가 될수 있다. 하지만 뇌를 빼고 그저 그 흐름에 몸을 맡기기만 한다면 휩쓸리는 거다.
그저 프로젝트만 쳐내며 어느 순간 내가 주체가 되는 개발이 아닌 그저 AI에게 뇌를 의탁하여 개발을 해나가고 있는 나를 보게 됐다.
주객전도되어 우선 AI에게 80퍼센트의 개발을 맡기고, 이 코드를 내 프로젝트 내의 맥락에 맞게 수정하여 붙여넣는 것. 앞에서 말했던 그동안의 나의 개발 행태다.
베이직의 미션을 수행하면서는 그동안 해왔던 학습 방식을 버리고 나만의 기준을 지키며 AI를 활용하려고 노력했다.
80%의 구현 및 설계는 내가 주체가 되어 수행하고, AI에게는 개선점 수정, 아이디어 제공, 빠른 단순 정보성 검색을 제공하는 도구로써 잘 활용했다고 생각한다.
회고
매 미션마다 회고를 수행한다.
내 코드 제출 후 다른 사람의 코드를 보고 느낀 점에 대한 회고와 오늘 미션에 대한 회고를 진행한다.
처음에는 구현 외에도 요구하는 사항 (피어 피드백, 회고..)이 많아 귀찮기도 했지만,
계속 하다보니 왜 시키는지 알게 되었다.
하나의 미션을 마치고 오늘 미션에 대한 회고를 그저 아무 생각 없이 or 생각만 하고 넘기는 것과
글로 내 생각과 느낀 점을 한자 한자 적어가며 되돌아보는 것은 정말 다르다.
매 미션에 대해 내가 부족했던 부분과 잘한 점 개선해야 할 부분을 짚고 넘어감으로써
나를 다시 돌아보고 점검하며 방향성을 다시 설정해나갈 수 있는 것이다.
개발자가 아니더라도 삶을 살아가며 꼭 가져가야 할 중요한 습관이지 않나 싶다.
그동안 미뤄뒀던 일기를 다시 쓰기 시작해야겠다.
아쉬운 점
피어 피드백
어쩌다보니 미션을 하루씩 늦게 수행하게 됐다.
미션이 열리고 먼저 코드를 제출한 순서대로 (다른 사람들의 코드를 보고 피드백을 남기는) 피어 피드백 링크가 쌓이는데, 사람 심리상 대부분 제일 위부터 코드를 보기에 항상 하루씩 늦게 낸 내 링크는 비교적 중간 쯤에 위치하여 다른 분들의 눈에 잘 띄지 않았던 것 같다.
그래서 베이직 기간 동안 내 코드에 피드백이 3개밖에 안달렸다.
하나의 미션 수행 후 마무리 회고까지 수행하는데 짧게는 3~4시간 길게는 5~6시간까지 걸렸던 것 같은데, 미션을 구현하고 문서화하여 제대로 소화하는 데에 시간과 에너지를 더 쓸수 밖에 없다보니 다른 사람들의 코드를 주의 깊게 보지 못했다.
내 코드 구현 후, 다른 사람의 코드를 하나하나 읽고 이해하며 거기에 제대로 된 피드백까지 달 에너지까지는 없었기에 리드미를 읽으며 이 사람의 설계 방식과 핵심 아이디어 정도만 얻어와서 이후 미션에서 개선해보려는 노력 정도만 했던 것 같다.
하지만 조금 여유로웠던 미션이나, 갈피를 잘 못잡았던 미션 중 몇몇은 다른 분들의 코드를 깊이있게 분석해봤었는데 확실히 사고의 틀이 넓어지는 것을 느꼈고 이후 코드 작성할 때 있어서도 도움을 많이 받았다. 똑같은 문제이지만 사람마다 생각하는 게 이렇게 다르구나에 대해 많이 느꼈고, 이를 나에게 적용해 보는 과정에서 얻어가는 것도 있었다.
만약 챌린지에 입과하게 된다면 무엇보다 피어 피드백에 더 집중해볼 생각이다.
하는만큼 얻어갈 수 있다
위의 피어 피드백 내용과도 이어지는 내용이다. 미션만 주어지고 스스로 모든 걸 결정하고 수행해야 하는 이 과정에서는 정말 본인이 하는만큼 얻어갈 수 있다. 하지만 시간은 제한되어 있기에 모든 것을 얻으려다 아무 것도 제대로 못얻을 수도 있다. 그래서 본인의 수준을 잘 판단하여 얻어갈 수 있는 것도 스스로 결정해야 한다.
그러한 점에서 스스로를 돌아봤을 때 아쉬운 점도 많지만 본격적인 학습을 위한 기초적인 토대 정도는 확실히 닦았다고 생각한다. 생각보다는 힘들었지만, 기대보다는 더 많은 것을 얻어갈 수 있어서 좋았다.
챌린지를 너무 가고 싶지만, 문제 해결력 테스트를 못본 것 같아 큰 기대는 하지 않고 있다.
챌린지까지 가지 못하더라도 베이직에서의 경험을 토대로 앞으로 나아갈 방향성은 명확히 얻은 것 같아 이걸로 만족한다.
