Netty 프로젝트를 만드신 이희승님의 이야기가 담긴 “꾸준히, 자유롭게, 즐겁게’란 책을 우연히 접하게 되어 구매해서 읽게 되었다. 모르고 샀는데 2013년에 출판된 오래된 책이었다. 책을 읽으며 인상적인 내용들을 기록해 본다.
점진적 vs 단번에 개선하기
대부분 프로젝트를 점진적으로 발전해 와서 결정적으로 중요했다고 느끼는 것이 없다는 답변이 인상적이다. 뒤 이어서 어떤 문제는 점진적으로 해결하는 것이 불가능하여 전체를 새로 작성하여 단번에 문제를 해결한 경험도 있다고 했다.
좋은 개발자의 공통된 특징
훌륭한 개발자들을 보면 자주 “사용자의 압장에서” 라는 말을 듣는다. API를 만들 때 내부 구조를 이렇게 저렇게 해서 어떤 모습을 만들거다가 아니라 사용자가 맞닿는 API 모습 부터 구상해서 내부 구현을 이어 가는 방식을 사용한다고 하셨다.
사용자가 피드백을 줄 수 있도록
기본적인 편의성을 갖춘 서비스를 먼저 갖추어 놓으면 사소한 문제(함수의 반환 타입이 어떠면 좋겠다와 같은)는 사용자들이 쉽게 피드백을 주지만 근본적인 문제는 사용자들이 잘 짚어내지 못한다고 말한 부분도 인상깊었다.
스트레스
커밋 권한을 준 사람이 마음에 들지 않는 코드를 커밋했을 때, 재단에 소속되어 일을 하는데 별다른 진척 없이 말만 오갈 때 스트레스를 받는일도 있다고 한다.
유닉스적 철학
프로젝트 규모가 커지면 여러 사람의 분업이 필요하고 의사소통 비용이 생기게 마련인데 그게 발생하지 않도록 작은 프로젝트들로 쪼개고 그 프로젝트들을 조합해서 더 큰 프로젝트가 되는 유닉스적 철학으로 접근하면 좋겠다는 말도 인상깊다.
두 가지 입장을 고려한 성공
직접 쓰려고 만든 오픈소스 프로젝트 소프트웨어는 성공 확률이 높다고 한다. 이유로는 개발자가 사용자이기도 해서 두 입장을 다 고려해 개발해서 사용자 친화적으로 개발할 가능성이 높아지기 때문이라고 한다. 그리고 오픈 소스 프로젝트를 공개할 뿐 아니라 지속적으로 유지보수 할 수 있는지도 고려해야 한다고 했다.
프로젝트의 가치에 대한 믿음 그리고 끈기
프로젝트의 가치에 대한 믿음이 있다면 당장 프로젝트가 유명해지지 않더라도 끈기 있게 일을 진행해 나갈 수 있다고 했다.
가치있는 사용자의 피드백
프로젝트가 어느 정도 궤도에 오르면 피드백이 오게 되는데 자신이 생각하지 못한 좋은 아이디어가 꽤 많아서 프로젝트에 대한 열정만 있다면 프로젝트가 자연스럽게 술술 굴러가게 되는 것 같다고 했다.
끝으로
해결하고 싶은 문제가 있을 때까지는 계속 개발을 하고 싶고 나이가 들어도 계속 변화를 받아들여 나아갈 수 있는 모습이면 좋겠다고 하셨다. 그때 당시에 한 애플리케이션의 확장성을 높이는 스케일업을 넘어 스케일아웃 하는 기법에 대해서도 익혀나가야 겠다고 인터뷰한 내용이 있는데 10년 전 언급하신 그것이 지금의 Armeria 프로젝트가 아닌가 생각하며 시간 여행을 다녀온 느낌이 든다.
나에게 질문하기
끝으로 나는 내가 사용하기 위해 만들고 싶은 오픈소스 프로젝트가 있는지 질문하게 된다. 그리고 어떤 걸 가치있다고 믿고 있는지, 처음부터 끝까지 한 번 만들어 볼 수 있겠는지, 세상에 내 놓을 뿐 아니라 계속 유지보수 해 나갈 수 있는 것이 있는지 질문해 본다.
