프로그래밍을 배우기 시작한지 딱 1년 정도가 지났다. 42Ecole의 교육 과정이 한국에서도 진행된다고 했을 때, 지금이 기회라고 생각했다. 더 늦기 전에 내가 하고 싶은 것을 하기 위해 잘 다니고 있던 회사도 고민없이 그만두었다. 피신 시작 기간에 맞춰 퇴사했지만, 코로나로 인해 계속 지연되는 피신으로 인해 살짝 불안하기도 했었다. 다행히 5월에 피신을 시작할 수 있었고, 한 달 간 코딩, 밥, 잠 이외에는 아무것도 하지 않았다고 해도 과언이 아닐 정도로 몰두했다. 그 결과 본 과정에 합격했고, 여러 과제를 진행하면서 현재까지 무사히 잘 살아남아 있다.
피신을 시작하기 전엔 피신을 하면서 다 배울 수 있다고 해서 정말 아무런 준비도 하지 않고 피신을 시작했다. 첫 날에는 C언어가 아닌 난생 처음 만져보는 shell에 당황했다. 처음엔 이런 것도 배워야 하나? 라고 생각했는데, 지금 돌아보면 정말 좋은 출발이었던 것 같다. 오히려 지금은 GUI보다 CLI가 더 편할 때도 있다.
두 개의 shell 과제가 끝나고 C언어 과제를 시작했을 때 역시 당황하지 않을 수 없었다. "라이브러리를 쓸 수 없다고...? 그럼 어떻게 하라는 거지? 출력하는 다른 방법이 있나?" 한참을 고민하고 있을 때, 슬랙에 글 하나가 올라왔다. "Linux에서는 fd라는게 있는데 ~~~" 아직도 잊혀지지 않는 그 글의 내용은 바로 file descripter에 관한 내용이었다. 아마 이것이 내가 피신에서 배운 가장 첫 컴퓨터공학 지식이었던 것 같다. 그 이후로도 슬랙엔 피신을 진행하면서 많은 정보들이 공유되었고, 모르는 것은 직접 그 글을 올린 사람을 찾아가 물어보기도 했다.
피신에서 가장 좋았던 점은 지식과 정보의 나눔이었던 것 같다. 내가 모르는 건 가서 물어보고, 내가 아는 건 알려주는 그 과정이 너무 좋았다. 누군가 과제에 대해 고민하고 있으면 그 과제를 해결한 사람들이 너 나 할 것 없이 몰려가서 알려주곤 했다. 같은 과제를 하고 있는 사람이면 지금 어떤 방법으로 문제를 해결하고 있는지, 어떤 방법이 더 좋은지, 그런 얘기들을 나누며 과제를 하나씩 해결해나갔다. 뿐만 아니라, 내가 아직 진행하지 않은 과제에 대한 설명을 듣기 위해 일부러 평가를 진행한 경우도 자주 있었다.
개인적인 감상으로는 1기 2차 피시너들간의 교류가 유독 활발했던 것 같다. 처음에 피신 예정 인원은 150명 정도였는데, 코로나로 인하여 3개월 정도 연기되면서 약 90명 정도 밖에 남지 않았고, 따라서 거의 모든 피시너들을 알 수 있을 정도였다. 그래서 남은 소수 인원들 끼리 같이 잘해보자라는 마인드로 피신에 임해서 그랬던 것 같다.
올해 초 까지만 해도 본과정을 진행하면서 과연 내가 제대로 학습하고 있는 게 맞는지 의문이 들 때가 많았다. 그러나 최근에 기초를 공부하기 위해 운영체제 강의를 보면서 지금까지 학습했던 개념들이 나오는 것을 보고 잘 하고 있다는 확신이 들었다. 과제를 진행하면서 겪었던 각종 에러나 문제를 해결하는 과정들이 전부 컴퓨터공학 지식을 학습하는 과정이었던 것이다. 이 사실을 깨닫고 나서는 동료평가를 하는 기준이 조금 달라진 것 같다.
이전까지의 동료평가는 단순히 코드를 얼마나 깔끔하게 짰는지, 과제에서 요구하는 사항을 잘 만족하는지 그저 주어진 조건에만 맞게 평가를 진행했었다. 그러나 과제를 해결하는 과정이 컴퓨터공학 지식을 학습하는 과정이라는 것을 깨달은 이후에는 그 과제가 어떤 지식을 학습시키길 원하는가를 생각해보게 되었다. 예를 들어, 가장 첫 과제인 libft같은 경우는 그냥 단순히 라이브러리 함수를 똑같이 구현하는 과제가 아닌, 함수의 동작이 어떻게 이루어지고, 각각의 파라미터나 변수들이 어떤 것을 의미하는지 생각해보는 과제라고 생각한다.
예를 들어, libft를 평가하면서 항상 하는 질문은 다음과 같다.
#include <stdio.h>
int main()
{
char *str;
str = NULL;
printf("%d\n", ft_strlen(str));
return 0;
}
테스터를 모두 통과해도 위 코드를 실행시키면 segfault가 발생한다. 평가를 받는 사람은 자신의 코드가 잘못된 줄 알고 당황한다. 그러나 코드는 잘못되지 않았다. 그렇다면 왜 segfault가 발생하는가? 답은 간단하다. 라이브러리의 strlen 함수도 마찬가지로 segfault가 발생한다. 그냥 strlen 함수가 그렇게 만들어져있기 때문이다. str이 null pointer일 때의 동작이 정의되지 않아서 에러가 발생하는 것이다. 지금까지 평가를 진행하면서 이 질문에 대한 답변을 제대로 들은 경우는 많지 않았다. 아마 직접 테스트 해보지 않고 단순히 테스터에만 의존하여 과제를 해결했기 때문이 아닐까 생각한다.
테스터가 나쁘다는 것은 아니다. 테스터가 많은 부분에서 이점을 주는 것은 사실이다. 30분이라는 제한된 시간 동안 모든 함수가 제대로 동작하는지 각종 테스트케이스를 넣어보면서 확인하긴 어렵기 때문에 테스터를 사용하는 것은 큰 도움이 된다. 다만 테스터는 어디까지나 보조수단일 뿐, 테스터를 너무 맹신하지 않는 것이 좋다고 생각한다. 물론 나도 과거에는 이러한 부분들을 반성하고 있고, 지금은 테스터 결과와는 상관 없이 그 사람이 얼마나 과제를 이해하고 코드를 짰는지를 더 중점적으로 보는 편이다.
이전에 코로나로 클러스터 출입이 불가하여 원격으로 ft_server 과제를 평가했던 적이 있었다. 평가를 받으시는 분은 VNC 화면을 공유하여 평가를 진행하는데, 자꾸 알트탭으로 창을 전환하며 어딘가에 적혀진 글을 보면서 명령어를 입력하는 것이 보였다. 그래서 피평가자분께 혹시라도 치팅으로 의심될 수 있으니 해당 글을 보지 말고 평가를 진행하기를 요청드렸더니 명령어를 모른다고 하셔서 더 이상 평가를 진행할 수 없었다. 과제 평가 기준에는 부합하지만 내가 생각했을 때 Docker 명령어도 모르고 이 과제를 했다는 것은 이 과제에서 요구하는 바를 만족시키지 못했다고 설명하고 Fail을 드렸다. 평가가 끝난 후 피평가자분께서 "안일한 생각으로 과제 평가표만 넘길 정도로 과제를 진행한 자신에 대해 부끄럽고 죄송하다"며 DM을 보내주셨고, 잘 마무리 되었다.
그러나 항상 이렇게 훈훈한 평가만 있는 것은 아니었다. 과제 관련 내용을 질문했을 때, 해당 내용은 평가 기준이랑 관계 없지 않냐며 짜증을 내는 사람 뿐만 아니라 평가 기준을 다 만족하는데 왜 Fail 이냐고 따지는 피평가자도 일부 있었다. 해당 내용이 왜 평가랑 관계가 있는지, 설명한 후에 Fail을 드리고 나면 평가 Feedback 점수를 0점으로 테러하는 사람도 있었다. 어쩌면 다른 사람에게 평가받았으면 통과했을지도 모르지만, 과제가 요구하는 바를 깨달아버린 이상 어쩔 수 없다. 운도 실력이라고 하지 않았는가!
회고를 쓰다 보니 잠시 딴 길로 샜는데, 어쨌든 요점은 평가를 통과하기 위한 과제 진행은 지양하는 것이 바람직하다고 생각한다. 1년쯤 하고 보니 42는 정말 내가 노력하는 만큼 알게되고, 내가 아는 만큼 더 많은 것을 보고 배울 수 있다는 것을 느꼈다. 지금도 평가를 진행하면서 이미 지나온 과제이지만 나도 간과하고 넘어간 부분이 있기 때문에 끝난 과제에서도 배우는 것이 많다.
김수보 멘토님의 글에서도 알 수 있다시피, 우리는 기술을 배우는 것이 아니다. 문제를 풀고, 협력하고, 스스로를 가르치고, 창의적이고, 비판적 사고를 가지기 위한 수용능력을 개발하는 것이다. 그러기 위해서 라이브러리를 쓰지 않고 과제를 해결하는 것이고, 과제를 해결하는 것이 곧 문제를 해결하는 능력을 기르는 것이라고 생각한다. 나는 이 사실을 깨닫는데 1년이라는 시간이 걸린 것 같다.
1년이라는 시간이 생각보다 빠른 것 같다. 1년동안 그토록 좋아하던 게임을 거의 안했는데, 코딩하고 공부하는 게 재밌었기 때문에 게임 생각이 안 나서 참 다행인 것 같다. 최근에는 AIFFEL이라는 인공지능 관련 교육을 듣느라 42과정을 잠시 미뤄두긴 했지만, 다시 42과정에 집중할 생각이다. 이제 사람도 많아진 만큼 나보다 과제를 앞선 사람들도 많아졌으므로 내가 부족한 부분을 잘 찝어줄 것이라 생각한다. 얼른 cpp 해야지.
