42의 동료 평가, 그리고 시행착오

42의 동료평가, 그리고 시행착오

42에서는 멘토가 학생들을 평가하는 것이 아니라 학생끼리 서로의 프로젝트를 평가한다. 이 때 평가자는 피평가자의 프로젝트에 대한 지식이 있을 수도, 없을 수도 있다. 어느 경우던 간에, 평가자는 주어진 평가 기준 ("프로그램이 오작동을 하지 않는가?", "프로그램에 Memory Leak이 존재하는가?" 등의 기준)에 따라서 프로젝트를 평가하게 된다. 동료평가는 학생이 공부를 제대로 했는지 판단하는 시간이기 때문에 매우 중요하다고 할 수 있다. 전체적인 동료평가의 질에 따라서 42가 갖는 가치가 달라질 것이라고 생각한다.

 

peer review

 

학생이 평가하는 것의 장점은 우선 지속성과 다양성에 있다고 생각한다. 지속성이란 우리는 학생이 많은 만큼, 소수의 사람만 평가할 경우 지속이 불가능할 것이다. 또, 다양성이란 사람이 많은 만큼 서로 다른 생각을 가진 사람들에게 평가를 받을 수 있을 것이다.

 

단점은 누구든 평가를 할 수 있기 때문에 평가자의 역량에 따라서 평가의 퀄리티가 크게 달라진다는 점이다. 이게 왜 중요할까. 아래에는 내가 직접 평가를 주고, 받으면서 느낀 시행착오를 적어보았다. 이게 정답이라고, 꼭 이렇게 해야한다고 생각하지는 않지만 누군가 이 글을 보면 시행착오를 줄이는 데 도움이 되지 않을까, 생각해본다.

 

공부를 했어도 프로젝트를 제대로 이해하지 못할 수 있다.

printf, cub3d처럼 복잡한 프로젝트는 인터넷에서 이런저런 코드를 참고하면서 프로젝트를 진행하는 사람들이 많은데, 이럴 때 실제로 이해를 한 것인지, 이해한 느낌만 나는지를 확인하기가 어렵다. 마치 수학 시간에 선생님이 문제를 풀어주실 때, 내가 푼 것 같은 느낌이 드는 것과 같다. ㅠㅠ 이걸 확인하려면 다른 사람들에게 설명을 해봐야 하는데, 이게 평가 단계에서 이루어지지 않으면 피평가자에게 부정적일 수 있다. 그리고 가끔은 평가자가 프로젝트를 진행하지 않아서 이해하지 못하는 경우가 있는데, 물론 평가자가 최대한 노력해야겠지만 노력해봐도 평가자가 이해하지 못한 경우에는 Fail을 주어야 한다고 생각한다. (이해하지 못한 프로젝트를 통과시키는 건 너무 위험한 짓이다. 양쪽 모두에게 좋지 않은 것 같다.)

 

cheating?

그리고 얼마 전에 슬랙에서 치팅을 어떻게 아느냐?로 이야기를 한 적이 있다. 사람마다 기준은 다르겠지만 나는 "이 프로젝트를 얼마나 이해하고 있는가?"인 것 같다. 이건 "넌 치팅을 했어. 이건 잘못이야!"라는 생각으로 치팅을 검열하려는 게 아니라, "프로젝트에 대한 이해가 없이 프로젝트를 끝내는 게" 피평가자에게 도움이 안 되기 때문이다. 그리고 프로젝트에 대한 이해도를 이야기하기 위해선 코드 리뷰가 어느 정도 필요하다고 생각한다. 그리고 평가를 하면서 다른 사람들의 코드를 많이 보는게 평가자에게도 도움이 된다고 생각한다.

 

예를 들어서 다음의 상황에는 치팅을 줄 수 있다고 생각한다.

- netwhat 평가를 할 때 계산기는 분명히 풀이에 도움이 되지만 계산기가 없을 때 아예 풀 수 없는 경우

- cub3d에서 자신이 사용한 알고리즘에 대한 설명을 못 하는 경우

프로그램의 안정성

내가 생각하는 안정적인 프로그램이란 "프로그램이 예상하지 못한 방법으로 동작하지 않아야 한다"이다. 예를 들어서 Segmentation Fault, C++에서 처리되지 않은 exception, Memory Leak 등의 상황을 말한다. 또는 로직 상에 논리적 오류가 존재해서 비정상적으로 동작한 경우도 해당한다. 나는 프로그램이 구동되면서 발생할 수 있는 위험을 개발자가 충분히 이해하고, 이를 컨트롤할 수 있어야 한다고 생각한다. 이게 중요한 이유는 프로그램의 안정성이 중요하기 때문이다. 예를 들어서 카톡에서 메시지를 엄청 길게 보냈더니 버퍼 오버플로가 발생해서 채팅 서버가 Segmentation Fault로뻗었다고 해보자. 엄청난 경제적 손실이 있을 것이다. 실제로 로켓 Ariane 5가 오버플로우 버그로 궤도를 잘못 계산해 폭발시킨 사례가 있다. (무려 70억 달러를 날렸다.) (링크) 이런 것들을 생각해봤을 때 "물리넷이 printf 메모리 릭 검사 안 하는데 그냥 넘어가주세요"라는 말을 들으면 마음이 좀 아프다.

 

그래서 나는 평가에 있어서 프로그램의 안정성 테스트를 하는 것을 매우 중요하게 생각한다. 이게 정말 어렵긴 하다. 현재 상용 목적으로 사용되는 프로그램들도 계속 버그를 고치는데, 우리가 작성하는 프로그램은 어떻겠는가 ㅠㅠ 다만 내 능력 안에서 최대한 버그를 찾으려고 노력하고 있다. 그리고 이걸 하려면 반드시 코드 리뷰가 필요하다. 코드 리뷰를 해야 이 사람이 위험한 코드를 짜는지, 가독성은 어떤지를 적절히 평가를 할 수 있다.

 

결론

시행착오는 어쩔 수 없는 것 같다. 위에 적은 것도 몇 번씩 실수를 하고 고민을 했던 내용이고, 앞으로도 고민은 계속 할 것이다. 다만 이런 고민의 내용을 공유하는 게 도움이 된다고 생각한다. 그리고 언젠가 길드에서 오리엔테이션을 한다면 평가 뿐만 아니라 이런 시행착오했던 내용들을 꼭 공유하고 싶다.