GNL이라는 과제를 맨 처음 접하고 나서는 그저 멘붕에 지나지 않았다. 생각보다 더 불친절한 Subject와 인공지능번역기인 파파고의 낮은 번역수준에 과제를 등록한 뒤, 몇일 간 그냥 과제가 무엇을 의미하는지.. 과제안에 어떤 함수를 써야하는지.. 어떤 식으로 접근해야하는지 고민에 고민을 거듭했던 시간속의 연속이었다.
고민끝에 여러 프로토타입(6~7버전)이 나왔었는데 최종적으로 어떠한 것도 발탁되지 못하였다. 문제를 완벽하게 이해를 끝내지 못하고 코드를 작성하니 당연한 결과였고, 그리 효율적이지도 못하였다. 마지막 7번 버전에서는 파일을 읽어오고 한 줄 씩 받아내어 연결하는데 까지는 성공하였지만, gnl내부에서 접하는 오만가지의 코드오류(seg fault, mem leaks, 등등)를 만나게 되었다. 하지만 그보다 더 중요한 문제는 따로 있었는데, 짜여진 코드가 구조적으로 절대 효율적인 로직이 아니라고 생각되었고, 사족이 너무 많은 코드가 되어버렸다. 어찌저찌 잘 돌아간다고해도 이런식의 코드구성은 앞으로 과제를 해나감에 있어서 절대로 빠르고 명확한 성장이 기대될리는 만무하였다.
그래서 현재 구성하던 코드는 잠시 미뤄둔 채, 다른 여러 구성된 코드를 참고하고, 비교하여 효율적인 코드를 차용하고 나만의 코드구성으로 간결하게 만들어 효율이 높고 좀 더 여러 접근법을 학습하는 방식을 택하였다.
앞서 구현된 여러 코드들을 읽어보고 하나하나 분석하면서 따져나가니 어떤것이 좋은 코드고 어떤 것이 나쁜 코드인지에 대한 기준도 생기고, 오류가 분명히 있음에도 통과한 코드들이 있다는 것도 알 수 있을 정도로 과제에 대한 이해도가 높아졌다. 십 수개의 코드를 분석하고 난 뒤, 지금까지 작성했던 내 코드를 바라보니 내 코드는 눈이 있어야할 위치에 코가 있고, 귀가 있어야할 위치에 입이 있는 요상한 작업물이었다는게 더 확실해졌다.
그렇게 하나하나 내가 작성했던 코드들을 순서에 맞게 수정하고, 간결하고 효율적이게 짜나갔다. 물론, 코드를 다시 구성함에 있어서도 여러 의문점들과 난관이 많았었다. 이 부분에 대해서는 뒤에 Question에 정리를 하려고 한다.
마침내 코드 작성이 끝난 뒤, 내가 스스로 이해할 수 있고, 언제 다시 코드를 보더라도 명확하게 설명할 수 있도록 코드를 구성할 수 있게 되었다. 하지만, 이렇게 까지 구성하였음에도 불구하고 여러 사람들에게 코드를 보여주고 평가받을 때, 미처 생각치 못했던 부분들이 드러났다. 다행히도 로직에는 큰 문제가 없어서 물리넷에서는 운좋게(?) 통과하였지만 평가가 끝난 후, 성공과는 상관없이 이런 오류들을 수정하고나서야 이제야 진짜로 GNL과제가 끝난 것을 실감할 수 있었다.