개요

벌써 2주차 보고서... 이번주도 너무 빨리 지나갔다. 알고리즘과 CS 지식이 전혀 없던 나에게 가장 힘든 시간이 아닌가 싶다. 이번주도 너무 많은 일이 있어서 기록하고자 작성했다.

목차

• 의장님과 티타임
• 퀴즈와 코테(코드 리뷰)

의장님과 티타임

갑자기 의장님과 티타임을 진행하게 되었는데, 해주셨던 말씀들을 듣고 생각을 한번 정리해 보면서 나를 되돌아 보려고 한다.

협업과 소통

• 의견 수용과 길 수용의 중요성
  • 타인의 의견을 경청하고 그 의미를 판단하는 것이 중요하며, 자신의 장점을 발견하고 의미 있는 일을 해야 한다.
• 협업에서의 커뮤니케이션
  • 협업 시 커뮤니케이션과 일의 분배가 중요하며, 기본 실력을 쌓기 위해 매주 점검 과정이 필요하다.

사실, 지금 2주차 WIL을 작성하는 이유는 '매주 점검 과정이 필요하다'라는 의장님 말씀을 보게 되어서다. TIL과 WIL을 적는 것을 미뤘던 이유는 정리를 따로 조금씩 하긴 했지만, 가끔은 이해하기도 바빠 정리조차 못할 때가 많았기 때문이다. 또한, 이해했던 내용들을 정리하다 보면 공부보다 정리에 더 많은 시간을 소비하게 되는 경우가 종종 발생했고, 해당 내용을 Velog에 올리려고 다듬는 과정에서 시간이 너무 많이 소요되어 하지 않았었다.

하지만 '기본 실력을 쌓기 위해 매주 점검 과정이 필요하다'는 말씀을 듣고 지난 3주를 돌아보니 점검의 필요성에 동의하게 되었다.

점검 과정의 중요성

이제는 정리와 점검 과정을 학습의 필수 요소로 받아들이고 있다. 매주 WIL을 작성함으로써 내가 무엇을 이해했고, 어떤 부분에서 어려움을 겪었는지 명확히 파악할 수 있고 이렇게 하면 앞으로의 학습 방향을 설정하는 데 큰 도움이 될 것이라는걸 조금씩 느끼고있다. Velog에 올리는 포스팅은 누군가에게 정확한 정보를 제공해야하는 정보 제공용도로만 사용되야한다 라는 착각을 했었다. 물론 정보를 제공하려는 목적의 글이면 당연히 정확한 정보를 제공해야하지만 WIL은 보다 성장한 내일을 위해 나의 상태를 점검하고 기록하는 목적이기에 잘못된 것이 아니라는 생각이 들었다.

기술과 인공지능

• 인공지능 모델의 이해
  • 인공지능을 공부하기 전에 기초적인 뿌리를 이해해야 하며, 프로젝트 참여 시 시간 분배와 경험의 중요성을 고려해야 한다.
• 기계와 인간의 역할
  • 기계가 발전하지만, 애매모호한 상황에서 인간의 역할이 중요하다.

두 가지 이야기를 하나로 묶어서 이야기해보려 한다. 나는 데이터 분석과 DL/ML로 코딩을 입문하였다. 계기는 당시 소방관에 관심이 있었던 나에게 코딩으로도 누군가에게 도움을 줄 수 있다는 말 한마디 때문에 시작하였다. 그 후 무작정 신청했던 인턴을 드라마에서 나올 것 같은 스펙을 지닌 사람들과 짧은 시간이지만 했었고 그 경험을 기반으로 첫 인공지능 프로젝트를 진행하였다. 하지만 기본기가 없기에 커스텀이 불가능했고, 있는 모델들을 가지고 활용만 할 뿐이었다. 그때부터 지금까지 계속 느끼고 있었다. "기본기의 중요성을"

단지 누가 만든 걸 쓰는 게 전부인 전문성이 없는 개발자라면 월 20$를 주고 GPT를 쓰는 게 더 낫지 않은가? 지금같이 인간보다 생산성이 좋은 인공지능이 계속 발전하는 상황에 인공지능보다 생산성도 안 좋고 전문성도 떨어진다면 회사 입장에서는 나를 고용해야 할 이유가 없기에 현재는 전문성을 위한 기본기가 중요하다는 말에 공감이 되었다.

경험의 중요성

• 기계와의 경쟁에서 경험의 중요성

이전에 친구에게 기능 구현 문제에 막힌 부분이 있어서 해결 방법을 GPT에게 물어보고 이해하지 못한 부분을 친구에게 물어보았던 적이 있었다.

??? : 그거 그렇게 안 해도 더 쉽게 할 수 있어

많은 사람들이 이러한 경험이 있을 것이다. GPT가 평균 이상의 코드를 짜주는 것, 빠르게 정보를 제공해 주는 것 등 유용한 작업을 해주는 것은 사실이지만, 모두가 정확한 것은 아니고 그 정보를 검증하려면 해당 정보에 대한 지식이(경험) 있어야 한다.

아는 만큼 보인다.

공부를 하면 할수록 이 문구의 의미를 뼈저리게 느낀다. 개발자로서 경험이 부족하면, 주어진 정보나 도구가 얼마나 좋은지, 얼마나 효과적인지 제대로 이해할 수 없다. 알고 있는 만큼 보이고, 보이는 만큼 제대로 활용할 수 있는 것이다.

이 생각이 들고부터는 최대한 많은 것을 접하고 경험해보려고 노력하는 중이다. 다양한 문제를 직접 해결해보면서 경험을 쌓고, 그 경험을 바탕으로 더 나은 해결책을 찾아내는 능력을 키우고자 한다. 이를 통해 GPT와 같은 도구를 더욱 효과적으로 사용하고, 개발자로서의 역량을 높여 기계와의 경쟁에서 우위를 점할 수 있을 것이라고 생각한다.

경험이 많은 개발자는 다양한 상황에서 적절한 판단을 내릴 수 있을 거고, 어떤 문제가 발생했을 때, 그 문제를 해결할 수 있는 여러 가지 방법을 알고 있고, 그중 최선의 방법을 선택할 수 있다. 이는 결국 더 효율적이고 효과적인 개발이 가능할 것이다. 그래서 나는 다양한 경험을 쌓고, 그 경험을 통해 성장하는 것도 중요하지만, 그 경험을 찾아 나서는 것 또한 매우 중요하다고 생각한다.

퀴즈와 코테 그리고 코드 리뷰

퀴즈와 코테는 나의 부족한 점을 성적을 통해서 느꼈기에 넘어가겠다. 사실 의장님과 티타임 내용이 이번 주 가장 큰 이슈였다면, 두 번째는 코드 리뷰가 아닌가 싶다.

효과적인 코드 리뷰를 위한 리뷰어의 자세 - kakao Tech - 카카오

지난날의 리뷰들을 효과적인 코드 리뷰를 위한 리뷰어의 자세라는 글을 보면서 회고를 진행할 예정이다. 참고할 자료는 Kakao Tech의 한 포스팅이다.

코드 리뷰란

본인이 발견하지 못한 실수를 다른 사람이 발견하여 코드의 부작용(Side effect)과 오류를 조기에 대응할 수 있으며, 개발 내 정해진 컨벤션 규칙을 유지하고 기술 부채를 줄일 수 있습니다. 또한 여러 명의 개발자가 참여함으로써 문제 해결을 위한 기술 구현 방법론에 대해 공유하기도 하는 것입니다.

리뷰의 5가지 규칙

1. 왜 개선이 필요한지 이유를 충분히 설명해 주세요.
2. 답을 알려주기보다는 스스로 고민하고 개선 방법을 선택할 수 있게 해 주세요.
3. 코드를 클린하게 유지하고, 일관되게 구현하도록 안내해 주세요.
4. 리뷰 과정이 숙제 검사가 아닌 학습 과정으로 느낄 수 있게 리뷰해 주세요.
5. 리뷰를 위한 리뷰를 하지 마세요. 피드백할 게 없으면 칭찬해 주세요.

지난날의 과오 돌아보기

이전의 리뷰를 가져와 보겠다.

이전 프로젝트에서 작성했던 리뷰 중 하나이다. 부족한 부분은 무엇일까를 혼자 고민하며 작성해 보았다.

개선 제안에 대한 구체적인 이유가 명시되지 않음

왜 API 모킹이 필요하며, API 모킹이 무엇인지 등의 충분한 설명을 통해 리뷰어가 개선의 필요성을 느낄 수 있도록 작성해 주어야 하는데 그러지 못하였다.

사용법이 구체적이지 않고 설명과 섞여있어 떨어지는 가독성

지금 보니 정확히 어떤 식으로 데이터를 넣거나 등록하는지 설명을 애매하게 작성하여 개선의 필요성을 유도하기에는 많이 힘들어 보인다. 조금만 정갈하게 정리했으면 어땠을까라는 후회가 많이 남았다.

스스로 고민하며 개선을 할 수 없게 해버림

위 글에서 나와있듯이 리뷰는 스스로 고민하도록 리뷰를 작성하여 리뷰어가 스스로 고민할 수 있도록 리뷰를 작성했으면 어땠을까 라는 후회가 들었다. 당시에는 정보 전달에 급급하여 이런 부분을 신경 쓰지 못하였다.

반성 및 개선해보기

지난 리뷰를 보다 좋게 작성해보면 어떨까라는 생각에 리뷰를 조금만 수정하여 다시 작성해보았다.
이러한 수정을 보면서 사실 사소한 부분이지만, 리뷰를 내가 받는다는 생각으로 리뷰를 작성해 나가면 보다 좋은 리뷰를 작성할 수 있지 않을까라는 생각이 들었다.

정글에서 첫 코드 리뷰

아래 사진은 정글에서 첫 코드 리뷰였다. 먼저 리뷰 내용을 봐보자

사실 리뷰를 작성하면서 알고리즘 풀이에 사소한 부분을 리뷰를 작성하는게 맞을까? 알고리즘 코드 리뷰에 객체 지향 설계 원칙을 예로 들며 피드백을 준 것이 너무 과한 느낌이 있지 않나? 라는 생각도 했었다. 리뷰를 보내기 이전에 많은 고민을 하였다.

그 고민은 만약 이 코드가 내 코드라면? 이라는 생각이 들자 고민이 끝났다. queue라는 단어 하나를 que로 축약한 것은 사소할 수 있지만, 지난날의 나를 되돌아보면 이런 작은 것 하나가 습관이 되어 후회한 경험이 많았고, 몇 번 지적받은 적도 많았고 지금도 끊임없이 신경 쓰고 있는 부분이기에 리뷰를 작성하였다.

정글에서의 코드 리뷰 시 나만의 원칙

현재는 알고리즘 주차라 알고리즘 문제풀이를 기준으로 코드 리뷰 시 나만의 원칙을 정했다. 이 원칙은 지속적으로 수정될 예정이다.

나만의 원칙

• 내가 풀지 못한 문제는 리뷰 작성하지 않기, 풀지 못했다면 인상적인 부분을 진심으로 칭찬하기
• 내가 풀었더라도 누군가에게 설명할 수 있고 해당 로직이 왜 더 효과적인지 명확한 근거를 제시하며 설명할 수 없다면 작성하지 않기
• 나의 경험을 토대로 제안하되 제안 전 3번 더 고민하고 피드백하기
• 리뷰가 같이 성장하는 트리거가 될 수 있도록 의문을 던져보기
• 답을 알려주기보다 스스로 고민하고 개선 방법을 선택할 수 있게 작성하기

마치며

알고리즘과 CS에대한 회고는 저번주 회고에서도 말했듯이 작성하지 않았다. 누군가에게 보여주기위해 설명하면서 작성하고 다듬는 과정에서 너무 많은 시간을 소요할까봐 나만의 공간에 작성하고있다. 성장을 위한 기록이 오히려 성장을 방해하게 될까봐 이렇게 진행중이고 알고리즘 주차가 끝나면 한번에 적을 예정이다.