🤜 Engineering : 복잡함과의 대결 그리고, 서비스 개발자로서의 생각 🤜 개발을 하다보면, Webpack, Babel 등의 솔루션 이름을 듣습니다. 모두, 사용자들이 만든 High L

🤜 Engineering : 복잡함과의 대결 그리고, 서비스 개발자로서의 생각 🤜 개발을 하다보면, Webpack, Babel 등의 솔루션 이름을 듣습니다. 모두, 사용자들이 만든 High Level Code를 브라우저가 알아듣도록 변환 하는 솔루션을 의미합니다. 🤜 8월 12일 Ruby's on Rail 의 개발자는 ES6, HTTP2 그리고 Ruby에서 제공하는 Map 기능을 언급하면서 이런 변환 솔루션들이 더이상 필요 없을 수 있을 것이라고 내다 보았습니다. 🤜 Engineer의 이미지를 떠올리면, 어려운 말을 하고, 그런 어려운 말을 통과하지 못하면 "모자란" 것처럼 처우하는 때가 있는 것 같습니다. 하지만, 이런 "어려움"을 만든 것을 Engineer들은 부끄러워해야 한다고 생각합니다. 최대한 사람들이 알아들을 수 있도록 하는 것이 좋다고 생각하기 때문입니다. 🤜 Legacy 서비스(기존 서비스)을 이전 사람들로부터 인계 받은 적이 있습니다. 2011년 때 만든 시스템이었는데, "Elastic search, Kafka" 그리고 다양한 이름의 노드들 … 이중에 시간이 지나면서 사용하는 서비스는 30% 정도였습니다. 그 30%로 겨우겨우 서비스를 해나가고 있었습니다. 이 원인을 "복잡함" 그리고 "Engineer들의 잘난 척" 때문이라고 생각합니다. 🤜 최근 우수한 외국계 업체 분이랑 이야기를 할 기회가 있었습니다. 그 분과 이런저런 기술 이야기를 나누었습니다. 어려웠던 것이 기억납니다. 어려웠던 저를 반성하는 부분도 있었지만, 그 업체 분은 그런 정보를 알아낼 수 있도록 하는 "Feed back" 체계를 갖추지 못하고 있었음을 느꼈습니다. 복잡하고 생각해야할 지식이 많다고 하면 Sound 한, (건전한) 지식을 찾을 수 있는 경로는 제공해야하지 않을까 생각도 되고, 어렵게 기술을 풀어나가는 그 "잘난 척"이 불쾌했던 기억이 납니다. 🤜 서비스 기획자로서 접하는 IT 지식이 어렵다고 주눅들기보다는 Ruby의 기술자처럼 쉽게 지식들을 풀어나가는 실마리를 제공하는 것도 참 좋을 것 같다고 생각됩니다.