1. 언제나 반드시 의심하고 테스트하라.

    겨우 소스 한 줄 추가했을 뿐인데 이상이 있겠어? 라는 생각이 가장 위험하다. 그럴 수록 테스트해봐야 한다. 테스트 없는 소스는 가장 위험한 소스이다. 그러니 아무리 뻔하더라도 테스트해야 한다. 테스트는 귀찮은 일이지만, 그것을 간과해서 발생하는 비용은 만만치 않다. 저녁이 있는 삶, 불금을 즐기고 싶다면, 아무리 사소한 수정이라도 반드시 테스트해라. 본인이 만든 로직을 끊임없이 의심하고 테스트해라. 그 의심이 나를 지켜줄 것이다. 그리고 테스트 할 경우에는 여러 테스트 케이스를 적용하고 검증하라. 테스트 케이스가 많아질수록 더 안전한 코드가 만들어지고, 그만큼 자유로워 지게 된다.

  2. 개발자의 1차 고객은 개발자이다.

    백엔드 개발자라면 자신이 만든 라이브러리, API등은 다른 개발자에게 제공되어 진다. 그런데 버그가 반복되거나, 문제가 발생하면 사용하는 개발자는 이만 저만 스트레스를 받을 것이다. 대부분 이런 경우는 충분히 테스트 하지 않았기 때문이다. 다양한 상황을 만들어보고 테스트 해야 한다. 한 두어번 성공했다고 해서 방심하지 말고 여러 번 다양한 상황에서 테스트해야 한다. 그리고 구체적인 에러메시지를 제공해야 한다. 에러가 발생했습니다 라고 끝내서는 안된다. 구체적인 에러 메시지를 제공해야 한다. 간혹 타 시스템과 연동시 불충분한 에러 메시지로 시간을 많이 낭비하는 경우가 많다. 반면교사로 삼아야 한다. validation 체크만 해주어도 많은 대응 시간을 줄일 수 있다. 마지막으로 좋은 문서와 좋은 태도를 제공해야 한다. 불명확한 문서나 태도는 좋은 개발자의 모습이 아니다. 친절한 문서와 친절한 태도를 잃지 마라. 단, 여기서 친절함은 상냥함을 의미하는 것이 아니다. 정확하고 명확한 피드백을 의미한다.

  3. 방어 코드는 백신이다.

    백엔드 개발자는 프론트 개발자에게 API를 제공하고 약속된 데이터가 올 것이라고 믿는다. 하지만 그렇지 않은 경우가 생긴다. 프론트에 버그 일수도 있고, 사용자의 실수일 수도 있다. 문제는 그로 인해 잘못된 데이터가 저장되는 것은 결국 백엔드의 문제인 것이다. 그러므로 충분한 방어 코드를 작성해야 한다. 아무리 validation을 프론트에서 했어도, 백엔드도 역시 촘촘하게 방어코드를 작성하여 side effect에 대비해야 한다. 결국 데이터 문제가 생기면 그것을 복원하는 것은 본인의 문제 인 것이다.

  4. 좋은 로그는 문제 해결의 지름길이다.

    로그 작성에 정말 신경을 잘 써야 한다. 적절한 로그는 문제는 해결하는데 시간을 많이 단축한다. 로직이 제대로 수행되는지 체크가 되고, 문제가 발생시 원인을 빨리 찾게 된다. 로그만 잘 작성해도 야근이 줄어들 것이다. 특히 타 시스템과 연동시 연동 전후에 대한 꼼꼼한 로그가 필수이다. 이러한 로그를 봄으로써 문제의 원인이 어디인지 빠르게 찾을 수가 있다. 명심해라. 로그는 퇴근의 지름길이다. 참고로 로그 작성에 대한 https://jojoldu.tistory.com/712 글을 추천한다. 그동안 정말 생각 없이 로그를 남겼었구나 라는 자책감이 들었다.

  5. 주석은 개발자의 얼굴이다.

    주석은 나와 타인을 위한 배려이다. 주석이 잘 짜여져 있다면, 타인에게 인수인계도 쉬어지고, 시간이 지난 후에 자신이 다시 볼 때 쉽게 파악하게 해준다. 그러니 주석을 잘 작성하도록 해야 한다. 주석을 잘 작성함으로써 내가 짠 코드도 다시 보게 된다. 그러므로 좋은 개발자는 좋은 소스와 함께 좋은 주석을 작성한다.

  6. 나부터 의심해라.

    무언가 정상적으로 수행되지 않는 연동 문제가 있다면, 일단 본인의 소스부터 의심해라. 내가 넘겨주거나 처리해주는 로직에 문제가 있는지 자신부터 먼저 돌아보라. 오타는 없는지, validation은 잘 체크되어 있는지, 약속된 방식으로 처리하고 있는지. 그것부터 먼저 체크해라. 간혹 자신 보다는 상대방의 문제부터 찾다가 결국 자신의 문제라는 것을 알게 되는 뻘쭘함을 겪게 된다. 이런 상황이 반복되면 신뢰를 잃기 십상이다. 그러니, 확신하지 말고, 일단 본인의 문제가 아닌지 먼저 점검해라.

  7. 미리 미리 대비하라.

    프로젝트를 시작하기 전에는 늘 여유가 있다. 아직 연동 문제나, 구체적인 업무 협의가 나오지 않은 경우이다. 이 기간이 짦으면 괜찮은데, 때로는 길 수가 있다. 이때가 가장 위험한 때이다. 미리 대비하지 않으면 나중에 그만큼 대가를 치르게 될 것이다. 그러므로 평화로울 때 미리 준비해야 한다. 업무 결정이 안나왔다면 미리 프로젝트에서 도입되는 기술을 사전 검토해보거나, 아직 연동 방안이 안 나왔지만, 대략 예측하고 연동 코드를 작성할 수 있다. 간혹 A가 안되서 B를 못했어요. 라고 말하는 상황이 많은데, A가 있다치고 B를 먼저해보는 것이 큰 도움이 된다. 물론 예측은 늘 틀린다. 그렇다고 당장 할 것이 없다고 해서 멍때리거나, 인터넷만 기웃거리다가는 결국 나중에 호되게 당하게 된다. 경험상 미리 준비할 수록 반드시 효과를 본다. 좋은 프로젝트 개발은 끝이 갈수록 여유가 생기는 것이다. 지금 프로젝트 초반인데 평화로운가? 그럼 진짜 위기가 온다. 프로젝트 막바지인데 위기인가? 초반을 여유롭게 보낸 탓이다.

  8. 안되요를 말하기 전에 확인해보겠다고 말해라.

    덮어놓고 안된다고 말하거나, 기술적으로 안될 것 같아서 말하지만, 조금만 생각해보고 고민해보면 가능한 것이 많다. 그러니 무조건 방어적인 자세로 안된다고 먼저 말하는 것보다, 일단 한번 확인해보겠다고 말하는 것이 먼저이다. 물론 정말 딱 들어도 안되는 것도 있지만, 대부분 그렇지 않다. 그러니 정말 안되는 것인지 확인해보면 된다. 충분히 확인했는데 정말 안되는 것은 그때 말하는 것이 훨씬 신뢰가 깊어진다. 그러므로 순간 짜증이 날 지라도 일단 확인해볼게요 라고 먼저 내 뱉어라. 면전에서 거부하는 것은 불쾌감만 줄 것이다. 그리고 제삼자가 그 방법을 찾는 것도 창피한 일이기도 하다. 찾아보라. 안될 것 같은 것들의 방법을 찾아가는 것이 바로 노하우이고 경험이다.

어려운 일을 하려면 그것이 쉬울 때 해야 하고, 큰 일을 하려면 그것이 작을 때 해야 합니다. 세상에서 제일 어려운 일도 반드시 쉬운 일에서 시작되고, 세상에서 제일 큰 일도 반드시 작은 일에서 시작되기 때문입니다.

그러므로 성인은 끝에 가서 큰 일을 하지 않습니다. 그래서 큰일을 이루는 것입니다.

노자 - 도덕경 중에서