코딩하는 건축가 : 18일
좋은 개발자가 되는 법
어떤 지점에 이르면 책을 읽어본다. 책에는 이미 누군가가 해보 지혜가 담겨있다고 믿는 편이다. 오늘은 움베르토 에코의 <논문 잘 쓰는 방법>을 읽은 내용 중 일부를 가지고 개발 잘하는 방법을 이야기해보려 한다. 미리 얘기하자면 나의 개똥철학에서 나온 말이기 때문에 일종의 개인의 의견이라고 생각해 주시길 바란다.
나쁜 개발은 남에게 외주를 주거나 베껴오는 것이다
책에서는 승진을 위해 논문을 단기간, 구체적으로는 1개월 안에 써야 하는 경우를 언급한다. 이는 현실적으로 불가능하며 만약 그러한 경우라면 두 가지 현실적인 방안을 제시한다. 첫째는 자신을 대신해 써줄 사람을 고용하는 것이고, 둘째는 남의 논문을 베껴오는 것이다. 후자의 경우를 좀 더 구체적으로 이야기하자면 논문 등의 결과물이 전산화되기 이전 시대에는 타 지역에서 발간한 논문을 베껴서 발표하더라도 큰 문제가 되지 않은 모양이다. 왜냐하면 그런 주제가 발표됐다는 것을 알기 어렵기 때문이다.
이를 개발로 치환해서 나쁜 개발에 대해 이야기하면 다음과 같다. 첫째는 자신의 조직 또는 본인이 해야 하는 작업을 외주 주는 것이다. 자신이 할 수 있음에도 외주를 준다는 것은 가치가 상대적으로 떨어지는 타인에게 맡기고 자신이 좀 더 가치 있는 일을 할 수 있는 발판이 될 것이다. 하지만 자신이 해당 문제를 해결할 수 없는 실력에서 외주를 준다면 개발자로서 본인도 성장하지 못하고, 야수 같은 외주개발 현장에서 뒤통수 맞기 상당히 좋은 상황이 될 것이다.
타인의 코드를 베껴오는 것은 당면한 문제를 빠르게 해결해 주긴 할 것이다. 이것이 오픈소스를 통해 프로그래밍이 발전하게 된 원동력이 되었음을 부정하려는 생각도 없다. 하지만 어떤 개념이나 지식이 본인의 것이 되기 위해선 본인의 언어로 표현할 수 있어야 한다. 나도 프로그래밍을 하다 보면 베껴오는 경우가 많지만, 이를 이해하지 못하면 내 것이 되질 못한다. 거기다가 거의 유사한 러닝타임과 메모리 컴플랙시티를 가지는 코드여도 본인의 스타일을 완성하지 못하면 결코 좋은 개발자가 될 수 없으리라고 생각한다. 그런 점에서 튜토리얼로 시작해서 최종에는 공식 문서를 가지고 개발할 수 있어야 한다고 생각한다. 사실문제를 응용해야 하다 보면 공식문서를 뚫어지게 쳐다볼 수밖에 없어지긴 한다.
사이드 프로젝트는 6개월 이상 ~ 3년 이하로 완성해야 한다
나는 아직 사이드프로젝트를 진행한 적은 없다. 사이드 프로젝트보다는 관련 지식을 쌓는데 좀 더 중점을 두고 있기는 하다. 아무튼 책에서는 논문을 쓸 때는 6개월 이상 ~ 3년 이하의 기간을 강권한다. 저자는 기간과 논문의 퀄리티가 비례할 것이라고 어느 정도 가정하고 있지만 반드시 그렇지는 않다고 이야기한다.
6개월은 짧지만 훌륭한 결과를 만들 수 있다
책에서는 6개월의 결과가 좋기 위한 단서조항을 달고 있다. 1. 주제가 한정적일 것 2. 가능하면 최근에 나온 것과 관련된 것을 할 것 3. 자료를 찾기 쉬울 것 이 세 가지를 들고 있다.
위 1,2,3을 개발에 적용해 보면 이렇게 얘기할 수 있을 것 같다. 요즘 AI를 예로 들어보자. "건축을 위한 AI"라고 말한다면 사실 어마어마하게 큰 개념이다. 건축에 당면한 문제는 무엇이 있는가. 현장 안전, 도면 자동화, 법규 체크, 3D 스캔 데이터 최적화 등등 수많은 문제들이 있을 것이다. 여기서 1을 적용해 줄여보면 이렇게 써볼 수 있다. "콘셉트 도면 생성 자동화를 위한 AI" 이 정도면 좀 더 와닿는 개념이라고 생각한다.
그 후 현재 연구 동향을 찾아볼 필요가 있다. 내가 알기로 최근 도면 생성을 위한 AI 프레임워크는 GAN이나 GNN을 사용하고 있다. 그럼 이를 적용해 보면 제목을 이렇게 바꿔볼 수 있을 것이다. "GNN 기반 콘셉트 도면 생성 자동화 프로그램 개발". 이 단계도 아직은 좀 더 크기는 하다. 이 정도까지 정했으면 이제 자료의 가용성, 즉 내가 기반을 둘 코드 또는 데이터셋이 있는지 살펴봐야 한다. 예를 들어 김수근 건축가의 도면 등이 존재한다면 이렇게 제목을 써볼 수 있다. "김수근 도면을 이용한 GNN 기반 콘셉트 도면 생성 자동화 프로그램 개발". 사실 이 정도면 석사 논문으로는 충분한 범위라고 생각한다.
아 맞다. 프로그래밍을 논하기로 했지. 그래도 프로그래밍은 좀 더 일반화가 필요하기 때문에 앞의 김수근 도면을 빼고 "GNN 기반 콘셉트 도면 생성 자동화 프로그램 개발" 정도가 괜찮을 것 같다. 사실 사람들은 어떤 기술을 썼는지 크게 관심을 가지지 않고, 몇몇 사람들은 의도적으로 본인이 쓴 기술을 감추기도 하기 때문에 오히려 기술은 안 쓰는 게 맞을지도 모르겠다.
3년이 넘어간다면 이미 본인의 능력을 벗어난 일인 것이다
짧은 개발을 이야기했으니 긴 시간 개발을 이야기할 때가 되었다. 3년 이상을 하지 말라고 하는 이유는 3가지다. 1. 3년 이상이 걸린다는 것은 이미 본인의 능력을 벗어난 것이다. 2. 너무 넓은 범위를 설정한 것이다 3. 논문 노이로제에 걸린 것이다. 번역투로 되어있지만 핵심은 본인이 다룰 수 없는 범위의 일을 하고 있기 때문에 그 기간으로 인해 스스로를 좀먹기 시작한다고 생각하면 되겠다. 마치 고시를 n 년 이상 하게 되면 본인의 자존감이 바닥을 치고 이도저도 안 되는 그런 상태와 비슷하다고 보면 될 것 같다.
나머지 부분은 아직 읽지를 못해 깊은 이야기를 할 수 없다. 그런데 문득 이렇게 써놓고 보니, 만약 한 분야에서 3년 일했는데 뭔가 보이지 않는다면 나와 안 맞는 것을 하고 있는 게 아닐까? 아주 뜬금없지만 그런 생각이 불현듯 들었다.
