개발하는 제품이 서비스를 제공하는 소프트웨어인 경우와 하드웨어 제품에 탑재되는 소프트웨어일 경우에는 제품이라는 개념이 다르다. 나의 경우에는 완성된 어떤 물리적인 제품이 존재할 때 그 하드웨어 제품을 만드는데 기여했다는 마음이 컸다.
규모가 큰 소프트웨어를 혼자서 모두 개발하지 않았더라도 해당 소프트웨어 개발자라고 표현하는 것처럼 말이다.
도메인 감옥
당연한 이야기지만 업무의 도메인에 따라 해당 구성원의 관심사도 참 다르다. 그나마 개발자라는 직군 내에서는 세부 직군 차이가 있더라도 IT에 관심이 많은 사람의 비율이 높은 것 같다. 다만 IT의 분야도 워낙 넓기 때문에 또 그 안에서 세부적인 차이가 있다.
그 차이에 큰 영향을 주는 것 중 하나가 업무 도메인이다. 특정 서비스 도메인을 개발한다면 비슷한 서비스와 관련된 도메인 지식을 자연스럽게 더 많이 알게 된다. 경쟁사의 정책 등에 대해서 더 자주 이야기 나눌지도 모른다.
본인이 큰 관심이 없는 도메인이라도 일단 자신의 업이라면 알게 모르게 더 듣게 되는 정보가 있고 자신도 모르게 좀 더 관심을 가지게 된다.
좋아하는 도메인
만약 자신이 좋아하는 도메인이라면 아주 즐거울 것이다. 나는 전자제품을 좋아하는데 특히 한때는 스마트폰에 아주 관심이 많았다. 6개월~1년 단위로 스마트폰을 교체했고 짧게는 4개월 만에 바꾼 적도 있다. 이런 내가 스마트폰을 개발할 때는 참 재미있었다. 주변 동료도 같은 도메인을 개발하니 스마트폰의 여러 가지 기능에 대해서 이야기를 나눌 수도 있었다. 타사의 신제품에 대해 이야기하기도 했다. MWC, CES 등의 행사에 대한 소식도 사내에 공유되기 때문에 스마트폰을 넘어선 다른 기술의 정보 습득과 잡담에도 용이했다.
나야 좋아했지만 누군가에게는 관심이 없는 일이었을 것이다. 하지만 해당 도메인 개발자라면 업계의 트렌드를 파악하는 것도 필요하다고 생각했다. 그 점에서 난 다행이라고 여겼다. 그게 업무적으로 도움이 되고 말고는 차치하고서 말이다.
다만 여러 가지 기술에 대해 접하다 보면 새로운 아이디어가 떠오르기도 하고 어떻게 구현했을지 상상해 보게 된다. 어떤 센서 개발에 전혀 관여하지 않았더라도 해당 센서의 존재에 대해 아는 것만으로도 새로운 아이디어의 밑거름이 되기도 한다.
현재는 소프트웨어 개발 교육이라는 도메인에 있다 보니 더 좋은 코드를 작성하는 방법에 많은 포커스가 맞춰져 있다. 여기서 두 가치관이 충돌한다.
좋은 제품과 좋은 코드
좋은 제품을 만드는 것과 좋은 코드를 작성하는 것은 관계가 없다. 여기서 오해하지 말아야 할 것은 좋은 제품을 만드는 사람은 좋은 코드를 작성하지 못한다는 식의 서로 반대 개념이 아니라는 것이다. 좋은 제품을 만드는 사람이나 좋은 코드를 작성하는 사람이 도메인에 관심이 없다는 말은 더더욱 아니다. 오히려 관심이 많고 더 잘 알고 있을 것이다. 말 그대로 좋은 제품과 좋은 코드는 서로 상관이 없다는 것이다.
좋은 코드를 작성하는 것은 사실 '개발자만의 리그'다. 개발자들끼리 신나는 영역이다. 좋은 코드를 작성한다는 것이 곧 좋은 개발자라는 말은 아니겠지만 동치로 가정하자. 개발자 중에서 좋은 코드를 작성하지 못하고 단순히 주어진 요구 사항을 돌아가게 만드는 정도의 작업만 할 줄 아는 개발자를 구분하여 지칭하기 위해서 '코더'라는 말을 쓰기도 한다. 사실상 비하의 의미를 담고 있다.
읽기 좋은 코드나 유지보수하기 좋은 아키텍처 등과 같은 기술적 고민을 해야 개발자라고 할 수 있다는 일종의 선민의식에서 비롯된 것이 아닐까 싶다.
누가 코더인가?
사실 코드가 어떻게 작성되었는지 사용자에겐 중요하지 않다. 아무리 멋지게 기술적 고민을 하여 좋은 코드로 작성된 프로그램이라고 하더라도 결국 사용자에게 유용한 가치를 주지 못한다면 일종의 예쁜 쓰레기나 다름없다. 사람들은 영양학적으로 완벽히 균형 잡힌 맛없는 음식보단 영양은 조금 부족해도 맛있는 음식에 더 매력을 느끼는 법이다.
자 그럼 이제 누가 코더인가? 사용자의 니즈나 그들에게 제공할 유용한 가치를 만들지 못하고 기술적 가치에 입각한 작업만 할 줄 아는 개발자는 코더가 아닌가?
무슨 소리를 하느냐. 세계적인 탑티어 IT 기업들이 얼마나 좋은 코드를 중요하게 생각하고 좋은 개발자를 뽑으려고 노력하는지 모르냐고 반문할 수도 있겠다. 당연히 좋은 코드가 유저에게 좋은 영향을 주는 면도 많다.
그렇지만 아마 성공한 많은 IT 기업의 초기 제품은 그렇게까지 좋은 코드는 아니었을 것이다. 그들의 제품이 성장함에 따라 코드도 함께 성장하게 되었을 것이다. 급격히 늘어난 사용자에 따른 트래픽이 감당되지 않는다거나 투자로 인해 재정적 여유가 생겼다거나 하는 이유로 말이다. 그렇게 좋은 코드가 투입되고 제품은 더 성장하게 되는 식의 선순환 구조가 만들어졌을 것이다. 그러면 결과적으로 어떻게 되는가?
탑티어 IT 기업들이 얼마나 좋은 코드를 중요하게 생각하는지 아느냐는 말이 나오게 된다. 좋은 코드였기에 탑티어 기업이 된 것인지 탑티어 기업이 되었기에 좋은 코드 작성을 할 수 있게 된 것인지 생각해 볼 문제다.
상황이 이렇다 보니 좋은 기업에 들어가는 요건으로 좋은 코드를 작성하는 것이 필요하게 되었다. 결국 좋은 코드 작성은 좋은 개발자의 미덕이 된 것이다. 맞는 말이다.
좋은 코드에 대해 고민하면서 수백만 명에게 서비스하는 제품을 개발하고 있는 사람도 있을 것이다. 그런데 회사를 자신과 동일시하지 말라는 말이 있다. 이것은 소속된 회사의 제품 사용자가 수백만 명이라고 하여 그것이 본인의 좋은 코드 때문이라고 생각하지 말라는 말도 된다. 만약 초창기 멤버가 아니라면 이미 성공한 제품에 투입된 것일 뿐이다. 하지만 분명히 필요한 포지션이다. 중요한 역할을 하고 있다. 덕분에 서비스는 더욱 고도화될 것이고 안정화될 것이다. 요구 사항의 반영 속도가 빨라질 것이고 이슈가 적어지고 대응 속도도 개선될 것이다.
만약 자신이 성공적인 제품을 개발하지 못한 것이 기획 등에 관련된 의사결정권자 때문이라고 탓하고 싶다면 성공적인 제품 개발에 참여했을 때의 공 역시 본인에게는 하나도 없다고 인정해야 한다.
How에서 What으로
좋은 코드를 작성하는 것은 여전히 중요하고 앞으로도 중요할 것이다. 다만 좋은 개발자의 기준은 변할 수 있다고 생각한다. 가까운 미래에는 제품을 만드는 방법은 AI가 많은 부분을 대체할 수 있을지도 모른다. 이제 어떻게 만들지 보다는 무엇을 만들지에 대한 고민이 필요하지 않을까?
이미 좋은 코드라고 불리는 영역 중 많은 부분은 빠르게 AI가 대체하고 있다. 아직까지 완전하진 않지만 정형화된 좋은 패턴과 같은 부분은 오히려 AI가 빠르게 작성해 준다. 그러면 개발자라고 자부하던 것이 순식간에 코더로 전락하게 될지도 모른다. 따라서 좋은 코드에 대한 고민만큼 좋은 제품에 대한 고민도 필요한 시대가 되지 않았나 싶다.
