no-param-reassign

원래 버그 수정이라는 게 다 그렇습니다. 잘 풀리면 10초 만에도 풀리지만, 안 풀리면 열흘을 붙잡고 있어도 안 풀리지요. 물론 할 일이 많은 저희가 안 풀리는 버그 수정 하나에 열흘씩 소모하는 것은 옳지 않으므로 그 계획 수립과 실행에 신중해야 함은 두말할 것도 없습니다.

그래서 저는 다크 테마보다도 더 어두운 제 상황을 돌아보며 이런 생각을 했습니다. 만약 소모시간에 대한 올바른 예측, 시급성과 영향도를 고려한 우선순위 결정, 예상과 다른 상황이 벌어졌을 때의 대처가 버그 수정의 진선미라면 제가 하고 있는 것은 예측, 결정, 대처에 모두 실패한 버그 수정의 모범적인 위악추가 아닐까.

실전 프로젝트에서의 버그 수정은 일종의 타워 디펜스와 같은 양상을 보일때가 있습니다. 일정과 상황에 따라서 버그는 천천히 혹은 빠르게 쌓이는데 이렇게 쌓인 버그를 본진이 터지기 전까지 얼마나 빠르게 제거할 수 있느냐에 승패가 걸려있기 때문입니다. 물론 타워 입장에서 타워 디펜스의 좋은 점은 내가 아니더라도 다른 타워들이 있다는 점이었지만 내가 자기 소임을 다하지 못했을 때 그런 이야기를 하면 좀 치사하게 보이겠다는 생각을 했습니다.

수요일에 조준한 버그가 금요일까지 쓰러지지 않았을 때, 슬슬 지쳐서 그냥 포기하고 다른 버그로 넘어갈까라는 생각을 했습니다. 하지만 이미 수요일에 한 번 써먹었던 방법이기에 선뜻 선택하기는 어려운 대처법이었습니다. 그래서 아무래도 어떻게든 이 버그를 수정해내야겠다는 다짐으로 마음을 다잡고 목표를 센터에 놓고 열심히 스위치를 눌렀지만 다짐은 다짐일 뿐 실제로는 별다른 성과가 없었습니다.

저는 커서가 특정한 위치에 있을 때 붙여넣기 동작이 이상하게 동작하는 문제를 해결하고 있었는데, 제가 사용한 오픈소스는 붙여 넣기 동작을 바로 잡는 함수도 제공했고, 커서가 특정 위치에 있을 때를 감지하는 함수도 제공했지만 그 두 가지를 합친 하나의 함수를 제공하지는 않았습니다. 그리고 제가 3일 동안 열심히 검증해본 결과로는 그 두 가지를 하나로 합치는 것도 논리적으로 불가능했습니다.

그래서 오픈소스가 제공하는 함수를 사용하지 않고 문제를 해결하는 방법에 대해 고민해봤는데, 방법이 있기는 있다는 생각을 했습니다. 다만 그 방법이라는게 수에즈 운하가 막혀서 희망봉을 돌아가는 것처럼 끔찍하게 멀리 돌아가는 방법이었다는 게 문제였습니다. 저는 돌아 돌아서 버그를 고치면 얼마나 걸릴지에 대해서 어림짐작해봤다가, 아무래도 버그 하나에 30일은 누구도 용납하지 않을 것 같다는 결론을 내리고는 다시 두 개의 함수에 집중했습니다. 그리고는 곧 아무래도 답이 없다는 생각에 모라토리엄을 선언 하기 직전의 상태가 되었습니다.

재택근무의 장점은 포기 선언을 했을 때 퇴근이 빠르고, 퇴근하다가 번뜩이는 아이디어가 떠올랐을 때 복귀도 빠르다는 것입니다. 그래서 전 뭔가 좋은 아이디어가 떠오르지 않을까 하면서 폐점시간이 얼마남지 않은 집 근처 마트에 걸어가면서 두 개의 함수와 다섯 개의 장을 봐와야 할 품목에 대해서 고민했습니다. handlePaste와 tranformPaste, 그리고 올리브유, 버터, 대파, 비엔나소시지, 우유에 대해서 고민하다가 아무래도 답 안 나오는 앞의 2개 보다는 마트가 폐점하기 전에 빠르게 5개의 품목을 모아서 계산할 수 있는 최단 동선에 대해 고민하는 것이 생산적이라는 생각을 했습니다.

사실 저는 이 동네에 이사온지 그리 오래되지 않아서 마트의 내부 구조에 완전히 익숙해지지 않은 상태였고, 그래서 최적의 동선을 미리 계산하는 것이 좀 어려웠습니다. 하지만 막상 마트에 도착하자 약간의 직관과 다수의 행운이 도와줘서, 여행하는 세일즈맨처럼 매우 효율적인 경로로 5개의 품목을 수집하고는 바로 계산할 수 있었습니다. 하지만 제가 정말 기뻤던 것은 효율적인 경로를 만들어냈다는 사실보다도 마침 올리브유가 다 떨어졌는데 올리브유를 세일하고 있었다는 점이었고, 칼집이 이미 난 비엔나소시지라는 게 세상에 존재한다는 사실을 알아냈고, 대파를 찾으러 가기 전에 올리브유 근처에서 파기름을 완성품으로 팔고 있다는 것을 발견했다는 점이었습니다.

저는 요리를 많이 하는 편이 아니기도 하고, 파는 거의 파기름을 낼 때만 사용했기 때문에 대파는 한단만 사도 다 쓰지 못하고 물러져서 버린 경험이 너무 많았습니다. 그래서 아무래도 파기름을 포기해야겠다는 생각을 했을 때, 저에게 구원처럼 다가온 것이 냉동 슬라이스 대파였습니다. 장기간 보존할 수 있으면서도 이미 손질이 끝난 대파는 제 문제에 대한 완벽한 해결책이자 구원처럼 보였습니다. 실제로는 얼어있는 파 슬라이스를 기름에 바로 던지면 기름 온도 조절이 조금 애매했다는 단점이 있었지만 그래도 그 편의성이 압도적이었습니다.

하지만 냉동 슬라이스 대파에 크게 만족했기에 저는 완성품 파기름이라는 제품을 찾아볼 생각조차 하지 못했습니다. 아마 마트에서 우연히 발견하지 못했다면 영영 몰랐을지도 모르겠습니다. 칼집이 이미 나있는 비엔나소시지도 마찬가지였습니다. 매번 칼집을 내면서 불편하다고 생각은 했지만 칼집을 미리 내서 파는 소시지가 있을 것이라고는 생각도 안 해봤던 것입니다. 제가 아는 범위에서 생각해보면 특별히 없을 이유도 없는데 말이죠.

그렇게 집에 와서 버터를 잘라서 소분하면서 문득 무서운 생각이 들었습니다. 혹시 버터도 이미 소분해서 파는 제품들이 있는데 내가 찾아볼 생각도 하지 않은 것을 아닐까. 그래서 떨리는 마음으로 검색해보니 버터 소분기라는 제품이 있다는 사실을 알고 살짝 당황했고, 소분된 버터는 포션 버터라는 이름으로 매우 다양한 제품들이 존재한다는 사실을 알고 살짝 침울해졌습니다.

아무래도 이게 내 인생 마지막 소분이 될 것 같다는 생각을 하며 버터를 마저 잘라서 냉장고에 넣어두면서 파기름의 인스턴트성에 대해서 조금 고민해봤습니다. 불을 사용하지 않는 요리도 있고, 물을 사용하지 않는 요리도 있지만, 칼을 사용하지 않는 요리를 요리라고 할 수 있을까. 물론 요리라고 할 수는 있겠지만 파기름 조차도 귀찮아서 완제품을 사다 쓰는 것은 요리에 진심인 사람들에게는 조금 불편한 느낌으로 다가오지는 않을까라는 생각이 들었습니다.

저는 미국에 있을때 밀키트를 꽤 많이 써봤는데, 지금 넣고 있는 소스가 무슨 소스 인지도 잘 모르면서 그냥 번호 순서대로 넣는 것이 과연 요리라고 할 수 있을까에 대해서 고민했던 적이 있었습니다. 고민 끝에 내린 제 결론은 이것은 요리보다는 조리에 가깝고, 요리든 조리든 맛만 있으면 되는 거지 그걸 신경 쓰고 있을 필요는 없다는 것이었습니다. 제가 어딘가에서 평가를 받는 요리사도 아니고 그냥 내가 먹을 음식을 만드는거니까요.

사실 고백하자면, 저는 3일 동안 풀리지 않던 버그를 고칠 방법을 이미 첫째날에 발견했었습니다. 다만 그 방법은 사용해서는 안 되는 방법이었기에 좀 더 제대로 된 방법을 찾느라 3일이 걸렸던 것이었습니다. 제가 찾은 방법은 흔히 이 바닥에서 말하는 hack에 해당하는 방법으로 오픈소스의 원작자나 자바스크립트의 개발자들이 봤으면 근처에 있는 키보드로 제 머리를 후려쳐도 무죄가 나올만한 죄의식 가득한 방법이었습니다. 그래서 저는 '아마 이렇게 하면 되기는 되겠다'라고 생각만 하고 실제로는 그 불경스러운 코드를 쳐보지도 않고 다른 방법을 찾아서 떠났던 것입니다.

3일 동안 많은 고난을 겪고 마음속에서 '그냥 확 그 방법으로 고쳐버릴까'라는 생각이 스멀스멀 올라오길래 저는 제가 고쳐지지 않는 버그에 지친나머지 타락해버린 게 아닌가라는 생각을 잠시 했었습니다. 그런데 막상 제가 별로 깊이 고민해보지도 않았으면서 완제품 파기름을 거부하고 다 먹지도 못할 대파를 찾아다니는 것은 아닐까라는 생각이 들었습니다. 금기시 되는 코드가 정말 써서는 안 될 방법인가라는 생각을요. 아직도 어린 개발자이던 시절의 이상론에 사로잡혀서 프로그래밍의 예술성이나 코드의 미학 같은 것에 집착해서 다른 사람들을 힘들게 만드는 건 아닐까라는 생각을요. 파기름을 완성품으로 쓰면 버려지는 파도 줄일 수 있고, 칼과 도마를 설거지할 때 사용될 세제도 아낄 수 있는데 너무 생산적이라는 이유만으로 이유 없이 생겨난 거부감에 외면하는 것이 옳을까라는 생각도요.

다음 날 출근해서 처음에 생각해봤던 금단의 버그 수정 코드를 슬쩍 작성해봤습니다. 익숙하지 않은 방법이었기에 다소 시행착오는 있었지만 역시나 코드는 그럭저럭 원하는대로 동작했고, 버그는 그럭저럭 깨끗하게 제거되었습니다. 그리고 다시 그 코드에 대해서 한참을 고민했습니다. 써서는 안 될 방법을 써서 생길 수 있는 문제가 무엇일까. 하지만 여러 문서들과 여러 소스코드들을 읽어보고, 코드 흐름과 메모리의 변화를 계산해보면서 문제점을 예측해봐도, 별로 문제 될 것은 없겠다는 결론이 여러 번 나왔습니다. 그저 문제가 되는 건 인생에서 처음으로 이런 코드를 작성하고 올려서 반영해야 하는 제 심정이었겠지요.

아시는 분들이 많겠지만 대부분의 언어에는 lint라는 도구가 존재하고, 이 도구는 하지 말아야 할 짓을 한 개발자들에게 준엄한 경고를 내려주는 역할을 합니다. 물론 제가 저질렀던, 함수의 파라메터를 직접 수정하는 행동도 당연히 그 하지 말아야 할 짓에 포함이 되었고 - 아마 거의 모든 언어에 포함된 룰이었을 겁니다 - 제가 코드를 작성하자마자 개발툴은 그 코드에 자비 없이 경고를 발생시켰습니다. 물론 경고는 경고였기 때문에 무시해도 큰 문제는 없었지만, 아무래도 뭔가 찔리는 게 많았던 저는 그 경고를 무시하는 게 너무 힘들었습니다.

사실 GOTO나 JMP 같은 무시무시한 명령어를 쓰면서 프로그래밍을 배웠던 저는, 어느샌가 GOTO를 쓰지 말라는 금기사항이 보편적이라는 사실을 알았을때 당황할 수밖에 없었습니다. GOTO를 쓰지 말고 GOSUB를 쓰라고요? 그게 무슨 차이죠? 아, 그냥 가는 게 아니라 갔다 와야 한다고요? 그래서 그게 무슨 차이인데요? 하지만 왜인지 모르게 세상은 GOTO를 쓰는 사람은 프로그래머로 취급하지 않는 분위기였고 저는 프로그래밍 유망주로 인정받기 위해 다른 방식들에 익숙해져야 했습니다. 그 뒤로 수십 년 동안 계속 새로운 것들을 배우면서 뭔가 하지 말아야 할 금기들과 규칙들이 점점 많아지고 있다는 생각을 하기는 했는데, 그 금기와 규칙들은 대부분 맞는 말이었기에 별로 반항할 생각을 하지는 않았던 것 같습니다. 오히려 내가 뭐를 잘 몰라서 금기를 어기지는 않을까 전전긍긍하면서 살았습니다.

하지만 또 제가 느낀 사실 중 하나는, 뭐가 되었든 일정한 경지에 오르면 금기나 규칙에 얽매이지 않고 더 유연하게 생각할 수도 있다는 점이었습니다. 저는 일을 하면서 뭔가 잘 모르는 사람들이 교과서에서 배운 형식주의에 매몰되어서 그게 무엇을 위한 것인지도 모르는 규제를 남발하는 것을 가끔 목격하고는 했는데, 그로 인한 비효율이 점점 커져서 프로젝트를 잡아먹을 지경이 되더라도 아무도 이의를 제기하거나 처음부터 다시 생각해보려는 움직임을 보이지 않았던 것입니다.

그래서 저는 점점 경력이 쌓여가는 개발팀과 개발자들이 궁극적으로 추구하는 방향은 클래식 음악처럼 엄격하기 보다는 재즈처럼 자유로운 방향이 맞지 않을까라는 생각이 들었습니다. 주어진 규칙과 규정을 자유롭게 지키고 깨면서, 효율적이고 아름다운 방향을 찾아 나가는 그런 방향이요. 프로그래밍에는 인생을 반영하기 어렵기에 궁극적으로 예술이 되기는 어렵겠지만, 거기에서 어떤 미학을 찾을 수 있다면 그건 교과서적인 코드보다는 그 반대편에 있는 코드에서 찾을 가능성이 더 높지 않을까요.

 

그래서 코드를 전송하기 전에 제가 했던 마지막 고민은 이것이었습니다. 그런데 내가 이런 말로 합리화를 시키고 금기를 어길 만큼 자바스크립트를 잘 안다고 할 수 있을까. 아무리 고민해도 그렇게 잘 안다고 말하기는 어렵겠다는 생각이 들었습니다. 하지만 어쨌든 이번에는 내가 맞는 선택을 했다는 생각도 같이 들었습니다. 앞으로도 이런 고민을 계속해봐야 일정한 경지에 올라서 진정 자유로워지지 않을까라는 생각도요. 그래서 저는 10줄 남짓한 코드에 고해성사하듯이 20줄의 주석을 달아놓고는, 조금 더 고민하고, 마지막 주석으로 lint의 경고를 비활성화시킨 뒤 그냥 코드를 올려버렸습니다.