많은 사람에게 핼러윈은 다양한 복장을 차려 입고 우리를 괴롭히는 것들을 오히려 즐길 수 있는 기회를 주는 날입니다. 이러한 핼러윈 축제의 정신에 따라, Google for Developers는 등골이 오싹할 정도로 소프트웨어 개발자와 엔지니어를 놀라게 했던 문제에 뛰어들었습니다. 숨어 있던 위협을 발견해 극복하고 이겨내기 위한 비법이 궁금하다면 계속 읽어보세요.
복원력 있는 코드는 정기적인 업데이트가 필요하고, 버그 해결의 측면에서는 코드 줄 수가 적을 때 버그를 훨씬 쉽게 찾을 수 있습니다. 레거시 코드나 긴 코드를 다루어야 할 때는 더 쉽게 관리할 수 있도록 코드를 단순화하고 새로 고쳐 보세요. 케케묵거나 지나치게 복잡한 코드베이스를 좋아할 사람은 아무도 없으니까요. 몇 가지 모범 사례를 소개하겠습니다.
작게 시작하기: 전체 코드베이스를 한 번에 업데이트하려고 하지 마세요. 대신, 새로운 버그가 발생할 위험을 최소화할 수 있게 코드베이스의 격리된 작은 부분을 업데이트하는 것부터 시작해 보세요.
버전 제어 시스템 사용하기: 변경 사항을 추적하고 필요한 경우 이전 버전으로 쉽게 되돌릴 수 있습니다.
리팩터링 도구 고려하기: 코드를 손상시키지 않고 변경하는 데 도움이 될 수 있는 도구입니다.
철저히 테스트하기: 프로덕션 환경에 배포하기 전에 변경 사항을 철저히 테스트해야 합니다. 여기에는 변경 사항을 격리하여 테스트하는 것은 물론이고 코드베이스의 나머지 부분과 함께 테스트하는 것이 포함됩니다. 테스트 동기에 대한 자세한 도움말은 아래에서 확인하세요.
변경 사항 문서화하기: 자신이 한 작업과 그 이유를 다른 개발자도 쉽게 이해할 수 있도록 새로운 도구, 업데이트된 API, 모든 변경 사항을 포함하여 문서화하세요.
신속히 개발하여 배포하고 싶을 때, 단기적으로는 코드 테스트로 인해 진행 속도가 느려질 수 있어 테스트를 작성을 피하고 싶은 유혹에 빠지게 됩니다. 그러나 제대로 테스트하지 않은 코드는 결국 골치 아픈 문제가 되어 여러분을 괴롭힐 것입니다. 철저한 테스트는 장기적인 관점에서 시간, 비용, 불안감을 줄일 수 있는 최선의 방법입니다. 테스트를 꼭 실행해야 한다는 걸 안다고 해서 테스트를 하고 싶다는 의미는 아닐 겁니다. 다음 팁을 활용해 테스트 코드를 더 수월하게 작성해 보세요.
테스트를 게임화하기: 테스트 작성을 게임처럼 만들어 보세요. 동료와 게임하듯이 누가 먼저 테스트 코드로 전체 코드 적용 범위에 걸쳐 테스트를 마치는지 경쟁해 보세요.
함께 프로그래밍하기: 동료와 함께 테스트를 작성해 보세요. 마치 운동 친구를 사귀면 혼자 운동하는 것보다 훨씬 재미있고 동기 부여도 되는 이치와 같습니다.
테스트 자동화 설정하기: 가능한 곳은 어디든 테스트를 자동화하세요. 더 효율적이고 더 나은 방법입니다.
제품에 관해서라면 많은 개발자가 저마다 강력히 선호하는 제품이 있지만, 때로는 레거시 기술이나 조직의 요구로 인해 선택의 폭이 제한될 수 있습니다. 특히 최신 도구를 사용하지 못하는 상황이라면 더욱 힘이 빠질 수 있습니다. 이와 비슷한 상황에 직면했다면 팀에 여러분의 추천 제품을 소개해 보는 것이 좋습니다. 그 방법은 다음과 같습니다.
변화를 위한 로비: 현재 기술 스택이 제대로 작동하지 않는다면 변화해야 한다고 주장하세요. 이를 위해서는 일련의 이벤트에 대한 증빙 자료가 필요할 수도 있지만 그런 자료는 주장의 근거가 될 수 있습니다.
혜택 알리기: 자신이 선호하는 기술에 대한 정보를 공유할 준비가 되었다면 최적화된 코드가 어떻게 성능을 향상시키는지와 마찬가지로 선택한 기술 스택이 프로젝트에 어떻게 도움이 되는지 설명하세요.
전문성 보여주기: 개념 증명이든 프레젠테이션이든, 효과적인 방법으로 자신이 선호하는 기술 스택에 대한 깊은 지식을 입증해 보여주세요.
역량 강화: 익숙하지 않은 하향식 기술 스택을 깊이 파고들어야 할 경우에는 좋은 학습 기회라고 생각하세요. 새로운 코딩 언어를 탐구하는 것과 같습니다.
타협이 관건: 먼저, 위의 모든 요점은 목표로 삼을 만한 가치가 충분히 있지만 때로는 타협해야 한다는 점을 알아두시기 바랍니다. 레거시 코드로 작업하는 것이라 생각한다면 비록 이상적인 상황은 아니지만 할 수는 있는 일이니까요. 따라서 여러분이 원하는 방향으로 영향력을 행사하지 못하더라도 실망하지 마세요.
주말을 앞두고 코드에서 버그가 발생하는 바람에 주말에도 코드를 수정해야 하는 것도 짜증 나는데, 특별한 주말 계획이라도 있었다면 더욱 사기가 저하될 것입니다. 주중에 비해 문제에 대응할 시간도 짧고 개인 시간을 바쳐야 하는 데다 문제 해결을 도와줄 사람도 적은 와중에, 도움을 줄 만한 적절한 리소스가 없을 때 코드를 배포하는 건 위험한 일입니다. 더 나은 일정을 수립하고 토요일과 일요일의 공포를 피하는 데 도움이 될 몇 가지 모범 사례를 소개합니다.
업무 시간과 사용자 영향 고려: 피크 시간대를 지나 영향을 받는 사용자가 줄어드는 시간대에 배포를 예약하세요. B2B 기업의 경우 금요일 오후에 배포하면 고객의 업무 중단을 최소화할 수 있지만, 소규모 기업의 경우 금요일에 배포 일정을 잡으면 중요한 문제를 해결하느라 주말 내내 씨름할 수도 있습니다. 자신에게 맞는 일정을 선택하세요.
테스트 자동화: 문제를 조기에 파악할 수 있도록 개발 프로세스에서 자동화된 테스트를 구현하세요.
스테이징 환경이 올바른지 확인: 프로덕션 환경을 반영하는 스테이징 환경에서 변경 사항을 철저히 테스트하세요.
롤백 준비: 문제가 발생할 경우 신속하게 되돌릴 수 있도록 롤백 계획을 준비하세요.
모니터링 및 알림: 연중무휴 하루 24시간 내내 빈틈없이 문제를 파악할 수 있도록 모니터링 및 알림을 설정하세요.
의사소통: 배포 일정과 절차에 관해 팀원들 간 의사소통이 명확하게 이루어지도록 하세요.
예약된 배포: 주말에 정기적으로 배포하지 않는 팀이라면 금요일에 코드를 읽기 전용으로 설정하는 방안을 고려해 보세요. 또는 필요하다면 금요일 배포 작업의 시간대를 오전이나 이른 오후로 예약하세요.
주말 비상 대기: 주말 사이에 발생하는 중대한 문제를 해결할 수 있도록 주말 비상 대기조를 편성하거나 당직 근무 제도를 고려해 보세요.
배포 후 검토: 프로세스 개선을 위해 각 배포의 해결 과제를 분석하고 교훈을 얻으세요.
철저한 계획 수립: 배포 프로세스를 잘 문서화하고 팀과 이해관계자 간에 명확한 의사소통이 이루어지도록 하세요.
위험 평가: 잠재적인 비즈니스 및 사용자 영향을 평가하여 배포 빈도와 시기를 결정하세요.
해킹 당했음을 깨닫는 것은 심장이 철렁할 사건이지만, 기술에 가장 정통한 개발자조차도 공격에는 취약합니다. 실제로 해킹당하기 전에 다음 모범 사례를 꼭 구현하세요.
시스템과 소프트웨어를 최신 상태로 유지: 코드의 취약점에 패치를 적용하는 것이라고 생각하세요.
강력한 비밀번호 사용: 강력한 암호화와 마찬가지로, 강력한 비밀번호를 사용하세요.
2단계 인증 사용: 항상 두 번째 보안 계층을 추가하세요.
피싱 사기 주의: 미끼를 덥석 물지 마세요. 테스트하지 않은 코드와 마찬가지로 의심스러운 이메일에 주의하세요.
보안 감사 수행: 코드 검토를 실행하듯 사이버 보안을 위해 시스템을 정기적으로 감사하여 취약점이 있는지 살펴보세요.
백업 계획: 버전 제어와 마찬가지로 백업을 유지 관리하세요. 상황이 공포 영화처럼 변할 경우를 대비한 안전망입니다.
데이터 유출은 분명 개발자의 안위를 위협하는 가장 공포스럽고도 현실화할 가능성이 큰 중대한 사안입니다. 사용할 서비스 또는 API를 선택한 개발자는 차치하고라도, 어떤 회사도 이러한 위협과 얽히고 싶어 하지 않습니다. 이러한 상황을 피할 수 있도록 타사 벤더와 관련된 문제를 최소화하는 몇 가지 팁을 소개합니다.
타사 벤더에 대한 실사 수행: 타사 벤더와 함께 일하기 전에 해당 업체의 보안 관행과 정책을 주의 깊게 검토하세요. 보안 인증, 취약점 관리 방법, 사고 대응 계획에 대해 물어보세요.
벤더가 보안 요구 사항을 준수하도록 요구: 벤더가 충족해야 하는 보안 요구 사항을 명시하여, 각 타사 벤더와 체결하는 서면 계약서에 필요한 사항을 작성하거나 추가하세요. 해당 계약에는 데이터 암호화, 액세스 제어, 이슈 보고에 대한 요구 사항이 포함되어야 합니다.
벤더 활동 모니터링: 감사 로그 검토와 보안 평가를 통해 벤더가 계약서에 명시된 보안 요구 사항을 준수하는지 확인하세요. 벤더가 요구 사항을 제대로 지키지 못할 경우 데이터 유출의 영향을 최소화하기 위해 벤더가 직무를 수행하는 데 필요한 데이터에만 액세스할 수 있도록 하세요.
강력한 보안 제어 구현: 자체 시스템 내에서 방화벽, 침입 감지 시스템, 데이터 암호화를 통해 데이터를 무단 액세스로부터 보호하세요.
타사 API에 주의: 모든 보안 위험을 점검하세요. API 문서를 주의 깊게 검토하여 필요한 권한을 이해하고 API가 강력한 보안 관행을 사용하는지 확인하세요.
안전한 코딩 방법 사용: 입력 유효성 검사, 출력 이스케이핑, 강력한 암호화를 사용하세요.
소프트웨어를 최신 상태로 유지: 알려진 취약점으로부터 보호하기 위해 항상 최신 보안 패치로 업데이트하세요.
무엇이 잘못될 수 있는지 알면 쉽게 두려울 수 있습니다. 하지만 이러한 모범 사례를 구현하면 문제가 발생할 가능성이 상당히 줄어듭니다.
여러분의 간담을 서늘하게 한 다른 어려움은 무엇이었나요? 커뮤니티와 공유해 주세요.
