※ 이 글은 The Codist 블로그의 「Lessons From A Lifetime Of Being A Programmer」를 번역한 글입니다.
내가 30년 넘게 개발자로 살면서 몇 가지 배운 것이 있다. 여기에 몇 가지를 적어두었는데, 아마 앞으로 더 많이 배울 수 있다고 생각한다.
고객은 결과물을 본 후에야 자신이 뭘 원했는지 안다.
이건 첫 직장에서 배웠다. 고객은 직접 만들어서 보여주기 전까지는 자기가 실제로 필요한 게 무엇이었는지 깨닫지 못한다. 구구절절한 말보다는 실제 동작하는 프로토타입이 백번 낫다.
시간이 충분하다면 보안은 반드시 실패한다.
오늘날의 보안은 제대로 하기가 굉장히 어렵다. 개발자는 언제나 완벽해야 하지만, 해커는 단 한 번만 이기면 된다.
보안은 반드시 실패하지만, 결과는 그 상황에 대해 미리 계획을 세워두었는지에 따라 달라진다.
공격자가 결국 당신의 방어를 뚫을 거라고 생각했다면 그 순간에 대한 대비를 해두어야 한다. 데이터베이스의 내용을 판독할 수 없게 만들거나 각 서버를 격리해두는 등의 적절한 보안 조치를 미리 해둔 덕분에 침입자가 훔쳐간 정보를 사용하지 못하게 할 수 있다면 신문에 당신의 이름이 오르내릴 가능성도 줄일 수 있다. 언제나 엉성한 조치보다는 철두철미한 방어가 낫다.
좋은 보안은 지출이 아닌 전략 자원이다. 나쁜 보안은 비싼 대가를 치른다.
나는 사람들이 올바르게 보안을 하려면 얼마나 복잡한지 혹은 얼마나 비싼지 불평하는 말을 많이 들었다. 보안이 실패하면 수백억 이상을 손해 볼 수도 있는 건데 말이다. 돈 몇 푼 아끼자고 회사를 무너뜨리는 우를 범하지 말라.
복잡한 걸 간단해 보이게 만드는 건 어렵지만 복잡한 걸 더 복잡해 보이게 만드는 건 쉽다.
이는 프로그래밍, 디자인 그 밖의 거의 모든 창조적인 활동에 있어 진실이다. 나는 늘 다른 사람이나 내가 이해하기 쉽게 코드를 가능한 한 단순하게 작성하려고 노력한다.
코드가 너무 복잡하거나 너무 대단해 보인다면 그 코드는 제대로 동작할 가능성이 작다. 당연한 말이지만 굉장한 노력을 들여서 이해하기 어렵게 작성한 코드는 수도 없이 봐왔다.
성공은 실수를 통해 배운 것에서 비롯된다. 실패는 실수가 정상적이며 그 정도는 용인할 수 있다고 착각하는 데서 비롯된다.
프로그래밍은 어려우므로 끊임없이 실수하는 게 당연하고 형편없는 소프트웨어는 필연적이라고 주장하는 사람들이 많다. 이 같은 소리를 계속 듣다 보니 결함을 용인해버리는 경우도 있다.
하지만 개발자라면 이런 걸 받아들여선 안 되며 어떤 실수든 한 번에서 그치도록 노력해야 한다. 실수를 한 번씩 겪다 보면 결국 당신이 만든 결과물은 개떡 같지는 않은 소프트웨어가 될 것이다. 언제나 완벽할 수 있는 사람은 없다. 하지만 적어도 완벽해지려고 노력은 해야 한다.
유일하게 변하지 않는 건 변화 그 자체이며, 우리는 변화를 거부할 수 없다.
내일도 오늘과 같을 것으로 생각하고 계획을 세우는 건 매우 멍청한 짓이다. 특히 프로그래밍 세계에서 영원한 건 없다. 변화를 막으려는 신기술 반대주의 같은 태도는 실패할 것이다.
끊임없이 학습하라. 기술이라는 스팀 롤러는 바로 뒤에 붙어서 당신이 멈출 때만 기다리고 있다.
내가 가장 좋아하는 비유는 커다란 롤러가 꽁무니에 따라붙어서 당신을 쫓고 있는 상황이다. 오랫동안 개발자로 일할 수 있는 유일한 방법은 멈추지 않고 끊임없이 앞을 향해 가는 것이다. 잠시라도 주저앉아 쉰다면 잘 다져진 도로의 일부가 되고 말 것이다.
소프트웨어 산업은 어림짐작을 기반으로 한다.
주변 사람들은 일이 작든 크든 그 일이 얼마나 걸릴 것인지 예측해야 한다고 주장했는데, 그 예측이 맞았던 적은 한 번도 없었다. 과거 잘못된 예언을 한 예언자들은 돌팔매질을 당했다. 오늘날에는 그저 다음 스프린트에 투입될 뿐이다.
당신에게 좋았다고 다른 사람에게도 좋을 거란 보장은 없다.
어떤 소프트웨어 프로젝트에서든 개발자가 할 수 있는 선택은 셀 수 없을 만큼 많다. 일부는 훌륭하고, 일부는 그럭저럭 괜찮겠지만, 대부분은 엉망진창일 것이다. 하지만 어떤 이와 그의 상황에는 적용할 수 있던 것들이 다른 이에게는 전혀 맞지 않을 수 있다.
다른 사람들이 어떻게 하고 있는지 경청하는 건 좋지만 마치 그것이 유일한 진리인 양 말하는 건 항상 마음에 안 들었다.
끊임없이 변하는 세상에서 가장 중요한 기술은 안목이다.
누구에게나 옳은 말은 아닐 것이다. 하지만 새로운 것을 알아보는 능력, 다른 이의 작업을 알아보는 능력 또는 어떤 일을 할 수 있는 여러 방법을 비교하고 당신, 팀, 프로젝트, 조직에 가장 적합한 것을 고를 수 있는 능력은 어마어마하게 소중하다. 내가 아는 이 대부분은 이에 능하지 못했고, 내가 아는 대부분의 리더는 이 부분에선 정말 엉망이었다.
누군가 당신에게 이걸 해야 한다고 말하는 일이나 블로그에서 읽은 것 또는 모두가 하는 걸 그대로 해내는 건 쉽다. 목적과 모든 면을 고려하여 살펴보고 자신에게 가장 잘 맞는 최적의 선택을 하는 게 훨씬 어렵다. 누구나 선택을 해야 하지만, 어떤 이들은 평가 자체를 두려워하여 아무거나 골라버리거나 남들이 하는 대로 따라가는 일도 흔하다.
목적을 달성하는 방법엔 여러 가지가 있지만, 고객 입장에선 뭐든 상관없다.
고객은 개발자가 겪는 문제가 뭔지 관심 없다. 그저 결과물인 소프트웨어가 자신이 원하는 작업을 해결해주길 바랄 뿐이다.
시스템에 문제가 생기고 예외가 발생하든 개발 장비에 문제가 생겼든 다른 개발자가 진상이거나 해커가 침입했든, 사용자에게는 별로 중요한 문제가 아니다. 문제가 생겼을 때 정직해지는 건 좋다. 그게 가끔이라면 말이다. 하지만 고객이 보기 전에 문제가 오래가지 않도록 해두는 편이 더 좋다.
품질은 고객이 제일 잘 평가한다.
당신이 어떤 기준을 가지고 있든, 완료됐다고 확인한 체크리스트가 몇 개든, 코드 리뷰를 몇 번이나 했든 테스트를 몇 개나 작성했든 상관없다. 고객이 생각할 때 당신이 만든 소프트웨어가 해야 할 일은 제대로 하고, 하지 말아야 할 일은 하지 않는다면 앞서 말한 기준 중 그 어느 것도 중요하지 않다. 궁극적으로는 당신의 코드 품질, 성능, 디자인, 사용성에 관한 고객의 의견만이 유일한 품질 측정 기준이다.
로그를 남기지 않아 몰랐던 것이 큰 문제가 될 수 있다.
오늘날에도 소프트웨어가 어떻게 동작하는지 알기 위해 로그나 크래시 리포트, 사용 정보를 충분히 수집하지 않는 걸 보면서 놀라곤 한다. 이러한 정보를 수집하지 않는 사람들은 품질을 과신한다.
측정하고 기록하지 않으면 고객은 당연히 알게 될 문제를 개발자는 알 수 없다. 어떤 문제든 발생하는 즉시 알 수 있도록 나는 늘 세밀하고 유용한 로그, 크래시 추적, 리뷰와 코멘트 등 수집할 수 있는 건 모조리 해야 한다고 주장해왔다. 물론 아직도 이런 것들이 개발자가 되는데 전혀 필요 없다고 생각하는 사람들도 있지만 말이다.
언제나 더 나은 길은 있을 테지만 시간은 기다려주지 않는다.
할 일을 정할 때 균형 잡기 가장 어려운 부분은 시간과의 타협이다. 더 나은 방법에 대한 미련이 남을 수도 있지만, 더 나은 방법을 찾는데 시간이 너무 많이 걸린다면 대신 지금 당장 뭐든 하는 게 좋다. 올바른 선택이 아닐지도 모른다. 하지만 때로는 덜 좋은 오늘의 선택이 더 좋은 내년의 선택보다는 낫다.
원문: 코드쓰는사람
