보안과 개발의 최전선: 인증, 코드 품질, 그리고 AI 시대의 개발 관행 분석

최근 기술 트렌드를 조망해 보면, '보안 강화'와 '개발 프로세스의 자동화 및 고도화'가 밀접하게 관련되어 있음을 알 수 있습니다.

단순히 취약점을 수정하는 것을 넘어, 개발 라이프사이클 전체를 재검토하여 보안과 개발 효율을 동시에 달성할 수 있는 시각이 요구되고 있습니다.

본 기사에서는 여러 기술 기사를 바탕으로 현대의 보안 대책이나 개발에서 중요한 논점들을 정리하고, 실제 개발 현장에서의 응용 가능성에 대해 고찰합니다.

사이버 보안은 매우 광범위한 분야입니다. 특정 기술이나 공격 수법만을 배우기보다는 전체적인 그림을 파악한 후 필요한 영역을 심층적으로 다루는 것이 중요합니다.

특히, 공격자의 시점인 레드팀(Red Team)이나 침투 테스트(Penetration Test)뿐만 아니라 방어, 리스크 관리, 취약점 관리 등 여러 관점에서 보안을 이해할 필요가 있습니다.

대표적인 학습 자료나 개념으로는 다음이 거론됩니다.

또한, SBOM(Software Bill of Materials)은 소프트웨어의 구성 요소를 파악하기 위한 메커니즘입니다. 사용 중인 라이브러리에서 취약점이 발견된 경우, 영향을 받는 시스템을 특정하는 데 도움이 됩니다.

참고 기사:

조직의 보안 대책은 한 번 설정했다고 끝나는 것이 아닙니다. 사용자, 디바이스, 시스템 구성 변화에 맞춰 지속적으로 재검토해야 합니다.

특히 중요한 것이 인증(Authentication)과 접근 제어(Access Control)입니다.

기존의 비밀번호 인증이나 SMS를 통한 인증 코드는 피싱 공격 등의 표적이 될 가능성이 있습니다.

그래서 주목받고 있는 것이 패스키(Passkey)입니다.

패스키는 공개키 암호 방식을 이용한 인증 기술로, 서비스 측에 저장된 공개키와 사용자 측에서 관리되는 비밀키를 사용하여 인증합니다.
인증 대상 도메인과 연결되는 구조 덕분에 가짜 로그인 화면에 인증 정보를 입력하도록 유도하는 피싱 공격에 대한 높은 내성을 가집니다.

다만, 조직에 도입할 때는 대응 디바이스, 계정 복구 수단, 관리자용 운영 규칙 등도 검토해야 합니다.

인증을 강화하는 것만으로는 시스템 전체의 안전성을 충분히 확보할 수 없습니다. 인증 후에 무엇을 허용할지 결정하는 접근 제어 역시 중요합니다.

• Conditional Access (조건부 접근): 사용자, 디바이스 상태, 접속 출처 등의 조건에 따라 접근을 통제하는 메커니즘 -
• 최소 권한의 원칙: 업무 수행에 필요한 범위로만 권한을 부여하는 사고방식 -
• PIM (Privileged Identity Management): 특권 접근을 필요한 시점에 한정하여 부여하고 관리하는 시스템

이들을 조합함으로써, 인증 정보가 유출되었거나 불필요한 권한이 남아있던 경우의 리스크를 줄일 수 있습니다.

참고 기사:

여러 사람이 참여하는 대규모 개발 조직에서는 코드 품질뿐만 아니라 레포지토리나 접근 권한 관리도 중요합니다.

예를 들어, 다음과 같은 문제가 발생할 수 있습니다.

• 프로젝트에서 벗어난 멤버의 접근 권한이 남아있는 경우
• 외부 협업자의 권한이 정기적으로 재검토되지 않는 경우
• 장기간 사용되지 않은 레포지토리가 방치되는 경우
• 관리 대상 증가로 인해 수동 검토 부하가 높아지는 경우

이러한 과제에 대한 접근법으로 GitHub에서 소개하는 'Evergreen'이라는 GitHub App을 이용한 자동화가 있습니다.

Evergreen에서는 외부 협업자의 접근 권한을 주기적으로 검토하고, 불필요해진 권한의 삭제를 촉구하는 메커니즘이 소개되었습니다. 또한, 활동이 없는 레포지토리 탐지 및 아카이브도 대상에 포함됩니다.

특히 주목할 만한 설계 사상은 Fail Secure (안전側に倒す) 입니다.

예를 들어, 권한 검토 요청에 응답이 없을 경우, 접근 권한을 유지하는 것이 아니라 박탈하는 방향으로 설계합니다.

물론 실제로 도입할 때는 실수로 필요한 권한을 삭제하지 않도록 예외 처리나 복구 절차, 알림 방법 등을 포함하여 설계해야 합니다.

이러한 사고방식은 GitHub에 한정되지 않고, 사내 시스템의 계정 관리나 자동화 처리에도 응용될 수 있습니다.

API를 이용한 데이터 수집에서는, 얻고자 하는 정보뿐만 아니라 어떤 단위로 데이터를 수집할지도 중요합니다.

GitHub의 스타(star) 개수 추이를 추적하는 경우를 생각해 보겠습니다.

기존 방식으로는, 스타를 준 사용자들을 개별적으로 가져와 그 정보를 통해 시계열 데이터를 재구성하는 방법이 사용되었습니다. 하지만 스타 수가 많은 리포지토리에서는 대량의 API 요청이 필요해져 처리 시간이나 데이터베이스에 부하가 증가합니다.

이 문제에 대해 GitHub 기사에서는, 사용자 단위의 정보를 얻는 것이 아니라 일별 스타 획득 수를 얻는 접근법을 소개하고 있습니다.

중요한 것은, 목적에 비추어 필요충분한 데이터를 얻는 것입니다.

예를 들어, 스타 추이를 그래프로 만들고 싶다면, 개별 사용자 정보가 반드시 필요한 것은 아닙니다. 날짜와 건수만 있다면 시계열적인 경향을 파악할 수 있습니다.

이렇게 데이터의 '입자(granularity)'를 재검토함으로써 다음과 같은 이점을 얻을 수 있습니다.

• API 요청 수 감소
• 데이터베이스 부하 완화
• 처리 시간 단축
• 데이터 수집 처리 단순화
• 필요한 데이터 저장 용량 감소

이는 주가 데이터 집계, 접근 로그 분석, 업무 시스템 실행 이력, 배치(batch) 처리 가동 상황 등에도 응용할 수 있는 생각입니다.

다만, 집계 데이터만으로는 개별 사용자 행동을 분석할 수 없기 때문에, 분석 목적에 따라 적절한 데이터 입자를 선택해야 합니다.

참고 기사：

AI를 통한 콘텐츠 생성(content generation)이 일반화되는 가운데, 기술적인 성능뿐만 아니라 창작물의 독창성(originality)에 대해서도 논의되고 있습니다.

AI는 인간의 모호한 아이디어를 문서, 이미지, 프로그램 등의 구체적인 결과물로 변환하는 강력한 수단입니다.

한편으로, AI가 생성한 결과물을 그대로 완성품으로 간주해도 될까요?

AI는 학습한 데이터로부터 패턴을 획득하고, 입력된 지시(prompt)나 문맥에 기반하여 출력을 생성합니다. 따라서 기존 작품과의 유사성이나, 창작성을 어떻게 평가할 것인가라는 과제가 있습니다.

하지만, AI를 이용하는 것과 인간이 창작에 관여하지 않는 것은 동의어가 아닙니다.

예를 들어, 다음과 같은 프로세스가 생각될 수 있습니다.

• 인간이 모호한 아이디어를 제시한다
• AI가 여러 안이나 구현 방법을 제안한다
• 인간이 내용을 평가하고 방향성을 수정한다
• AI와 인간이 시행착오(trial and error)를 반복한다
• 인간이 최종적인 품질이나 표현을 판단한다

이 프로세스에서 AI는 단순히 답을 내놓는 도구가 아니라, 아이디어를 구체화하기 위한 벽치(brainstorming/sounding board) 상대방으로 기능합니다.

소프트웨어 개발도 마찬가지입니다. AI가 생성한 코드를 그대로 채택하는 것이 아니라, 설계 의도, 가독성(readability), 유지보수성(maintainability), 보안(security), 라이선스상의 우려 등을 인간이 확인함으로써 결과물의 품질을 높일 수 있습니다.

참고 기사：

지금까지의 내용을 실제 개발 업무에 적용하는 시점에서 정리합니다.

보안 대책을 릴리스 직전 검토에만 국한하면, 문제 발견이 늦어지고 수정 비용이 증가할 가능성이 있습니다.

따라서, 개발의 각 단계에 보안 대책을 통합하는 것이 효과적입니다.

계정이나 리포지토리가 늘어날수록, 수동적인 권한 관리는 어려워집니다.

정기적인 재고 조사(inventory)나 불필요 계정 탐지를 자동화함으로써, 관리 비용을 줄이면서도 권한 방치로 인한 위험을 낮출 수 있습니다.

다만, 권한의 자동 삭제를 도입할 경우에는, 오탐지 시 복구 절차나 감사 로그(audit log)를 정비하는 것이 중요합니다.

API 요청 수를 줄이려면, 단순히 처리를 고속화하는 것뿐만 아니라, 가져오는 데이터 자체를 재검토하는 것이 효과적입니다.

예를 들어, 업무 자동화 실행 상황을 분석할 경우, 모든 로그를 매번 읽어 들이는 대신, 실행 일시, 처리 시간, 성공/실패 건수 등을 집계해 두면, 대시보드 업데이트나 이상 감지(anomaly detection)를 효율화할 수 있습니다.

반면에, 장애 조사에 필요한 상세 로그는 별도로 보관하는 등, 집계 데이터와 상세 데이터를 구분하여 사용하는 설계가 요구됩니다.

AI는 코드 생성뿐만 아니라, 설계 벽치, 테스트 케이스 작성, 오류 원인 분석, 문서 작성 등 다양한 공정에서 활용될 수 있습니다.

다만, AI의 출력을 무조건 채택하는 것이 아니라, 다음 사항을 확인할 필요가 있습니다.

• 생성된 코드가 요구 사양(requirement)을 충족하는지
• 예외 처리나 경계값(boundary value) 대응이 적절한지
• 보안상의 문제가 없는지
• 기존 시스템과의 호환성(compatibility)이 있는지
• 유지보수 및 운영할 수 있는 구조인지

또한, 기밀 정보나 개인 정보를 다루는 환경에서는 사용하는 AI 서비스의 데이터 처리 방침이나 조직의 정보 보안 규정을 확인하는 것도 필수적입니다.

이번에 다룬 글들을 통해 현대 개발 현장에서는 보안과 개발 효율을 별개의 과제로 다루기보다, 개발 프로세스 전체를 설계하는 관점으로 접근해야 한다는 중요성을 알 수 있습니다.

특히 다음 4가지가 중요하다고 생각합니다.

• 보안의 체계적인 이해: OWASP Top 10, CWE, CVE, SBOM 등을 활용하여 취약점과 의존 관계를 관리할 것 -
• 인증 및 접근 관리의 지속적인 개선: 패스키(Passkey), 조건부 액세스(Conditional Access), 최소 권한 원칙(Principle of Least Privilege) 등을 적절히 조합할 것 -
• 자동화와 데이터 설계의 최적화: 권한 관리나 데이터 수집 메커니즘을 검토하여 운영 부하를 줄일 것 -
• AI와 인간의 협업: AI를 아이디어 구체화나 개발 지원에 활용하면서도, 최종적인 품질과 안전성은 검증을 통해 확보할 것

기술 발전으로 개발 자동화가 진행될수록, 그 메커니즘 자체를 안전하게 설계하고 운영하는 중요성 또한 높아집니다.

단순히 새로운 도구를 도입하는 것이 아니라, 무엇을 보호해야 하고, 무엇을 효율화하며, 어디에 인간의 판단을 남겨야 하는지.

이러한 시각을 갖는 것이 AI 시대의 지속 가능한 개발로 이어지지 않을까요.