소프트웨어 개발을 하다보면 누구나 시행착오를 겪는다. 시행착오의 종류는 다양하다. 예를 들자면
- 프로그램에 발생한 논리적인 오류, 에러를 내뿜으며 올바르게 동작하지 않는 종류의 오류
- 오류를 나타내지 않지만 내 마음에 들게 동작하지 않는 프로그램
- 열심히 만들었지만 사실은 이미 누군가가 만들어둬서, 아니면 만들고 나니 생각보다 기대하던 효과나 가치를 내지 못하는 프로그램
이런 것들이 대표적인 시행착오인 것 같다.
데이터를 분석하고, 딥러닝 소프트웨어를 개발하는 나에게는 이런 시행착오의 문제는 굉장히 비용적으로 비효율적으로 다가온다. 좋은 딥러닝 소프트웨어를 개발하기 위해선 일주일이 걸릴수도 있고, 한 달이 걸릴수도 있고, 1년이 걸릴수도 있다는 사실을 배웠다. 시간도 시간이지만, 돈도 돈이다. 기업에서 일하는 입장에서 무한정의 그래픽카드 연산량을 끌어다 쓸 수도 없거니와, 이런 것들이 결국 전기세로, 클라우드 이용료로, 장비값으로 이어진다. 개인의 입장에서는 이런 시행착오가 길어질수록 경험의 폭은 줄어들고, 다양한 연구나 소프트웨어를 접할 기회도 점점 줄어들어서 커리어 또한 제한된다는 생각이 든다. 이제는 무작정 뭐든지 몸으로 부딪히며 비용들을 감수하지 않고 그러면서도 고민을 끝내고 결단력있게 좋은 소프트웨어를 만들기 위한 방법을 고민하고 있다. 아래의 내용은 내가 경험적으로 이해하는 그 방법들이다.
소프트웨어, 연구 / 개발의 목표를 일정 주기로 산정하기
딥러닝 소프트웨어라면 개발의 목표는 크게 3~4가지 정도로 정리된다. 예를 들면
- 구동 속도가 얼마나 빨라야 하는지
- 배포할 환경은 어떤 환경인지
- 어느 정도의 성능(정확성 등)을 목표로 하는지
- 소프트웨어로써 어떤 기능을 가져야 하는지
되도록이면 모두가 이해할 수 있는 언어로 이런 목표를 정하고, 개선이 필요한 경우 지속적으로 개선하려고 한다. 목표를 팀원들과 공유하고 서로에게 검증받고 조절하는 과정을 거쳤을 때 개발이 훨씬 수월해지고, 해보고 싶은 것들이 너무 많은 와중에도 헤매이지 않을 수 있는 것 같다.
구현의 방법, 선행연구 조사하기
각각의 연구 / 개발목표가 산정된 이후라면 선행연구도 그 방향에 맞게 적절하게 찾을 수 있는 것 같다. 예를 들어 정확성이 좋은 소프트웨어를 만드는 게 제일 큰 목표라면 그걸 달성한 딥러닝 모델이나 다른 소프트웨어를 참고해서 그로부터 기준을 잡는다. 이 소프트웨어보다 나아야하는지 동급이라도 괜찮은지를 정량적으로든 정성적으로든 산정하고 이를 검증하는 데에서부터 개발을 시작하면 굉장히 빠르게 나아갈 수 있는 것 같다.
나는 딥러닝 모델의 기준점을 잡기 위해 paperswithcode를 사용한다. 가장 최신의 연구, 가장 좋으면서도 검증된 연구들을 제일 먼저 참고해서 왜 좋은지, 진짜 좋은지를 빠르게 빠르게 검증하고 비즈니스나 연구의 제약사항과 목표에 가장 어울리는 기준점을 찾을 수 있다.
또 구현의 방법에는 사용하는 프레임워크, 결과물의 형식이나 배포되는 플랫폼 등 엔지니어링 적인 측면도 많이 고려해야 하는 것 같다. 이 부분을 잘 정하기 위해서는 함께 일하는 실무자나 관리자와 열심히 대화해서 적절한 지점을 찾는 게 제일 중요한 것 같다.
열심히 개발하다 막히면 질문하기, 도와주기, 소통하기
나는 혼자서 모든 걸 이해할 수 있고 인터넷을 찾지 않고도 코딩할 수 있는 천재 개발자가 아니기 때문에 (그리고 그런 종류의 개발자는 아마 존재하지 않기 때문에) 언제나 소통이 필요하다. 이 소통은 개발 목표를 현실적인 가능성에 맞추어 수정하는 것일수도 있고, 다른 실무자에게 개발의 방향성이나 오류, 방법에 대해 묻고 알아가는 과정이기도 한 것 같다. 이 소통은 비단 같은 공간에 있는 사람들에게 한정될 것이 아니라, 사용하는 오픈소스 소프트웨어의 개발자들에게도 이어지면 더 좋은 것 같다. 소통의 결과를 코드로 남기고, pull-request를 보내 더 좋은 소프트웨어에 보탤 수 있다면 그것은 더 좋은 일인 것 같다. 어떤 분야를 제일 잘 아는 개발자도 나와 같은 사람이라서 때로는 친절을 베풀어 남을 도와주곤 한다. 물론 친절은 완전 공짜인 것은 아니고, 그만한 간절함을 내비추고 도와주는 사람이 상황을 이해할 수 있는 자료들을 충분히 제공하는 게 방법이라면 방법인 것 같다. 당연하게도 도움은 받기만 하면 안되고, 나에게 무언가를 물어보는 사람이 생길 때는 기쁜 마음으로 도와주는 것도 중요한 일 같다. 내가 도와줄 수 없는데 나를 도와줄 사람이 어디 있을까. GitHub이나 오픈소스 커뮤니티에서는 공유하는 것이 힙하고 도와주는 것이 성취다. 나에게 이런 문화나 태도를 정말 잘 가르쳐준 것 같아서 항상 고맙다.
잘 소통하기 위해서는 내가 더 잘 알아야 해서 더 공부하게 된다. 스스로 더 잘 이해할 때 남에게 더 잘 설명할 수 있고, 남에게 더 잘 설명할 때 나와 남의 시간도 많이 절약되고 원하는 것도 얻어낼 수 있고 자신감도 붙는 것 같다.
일을 시작할 때의 나는 일과 사람이 다르고 일과 삶이 다르다고 생각하곤 했다. 하지만 요즘에는 그리 다르지 않다고 생각하게 되었다. 생각보다 일하는 나와 일 밖의 나는 완전히 분리되지 않더라. 좋고 나쁨이 나뉘어 있어서 어떤 사람이 되는 것이 꼭 좋은 건 아니고 주어진 환경이나 여건상에서의 최선은 언제나 다르지만, 만약에 열려 있는 개발자가 되려고 하면 열려있는 사람이 되어야 하고, 계획을 잘 세우는 개발자가 되고 싶으면 계획을 잘 세우는 사람이 되어야 하는 것 같다. 엔지니어에게 인문학적 소양이라는 이야기가 필요하단 말들이 고리타분하게 느껴진 적도 있었지만, 지금은 그 말을 이해하고 있는 것 같다. 나중엔 다시 잊어버릴지도 모르겠지만 말이다.