요약: LION은 /컴과 명령으로 GitHub 저장소나 현재 프로젝트를 분석하고, 프로그래밍부터 수학 기초까지 15개 컴퓨터과학 영역을 아키텍처·보안·운영·가치 관점과 연결해 평가하는 Hermes용 리뷰 스킬이다.

문제: 코드 리뷰만으로는 프로젝트를 판단할 수 없다

프로젝트의 품질을 소스 코드의 문법이나 테스트 통과 여부만으로 판단하기는 어렵다. 실제 운영에서는 다음 질문이 함께 필요하다.

  • 데이터 흐름과 시스템 경계는 명확한가?
  • 알고리즘·자료구조 선택이 규모에 맞는가?
  • 운영체제·네트워크·데이터베이스의 실패 조건을 고려했는가?
  • 클라우드와 온프레미스 중 어느 배포 모델이 적합한가?
  • 보안 권한과 공급망 위험은 통제되는가?
  • 이 프로젝트가 고객·조직에 어떤 부가가치를 만드는가?
  • 기술적 발견을 개발자·운영자·경영진에게 다르게 설명할 수 있는가?

LION은 이 질문을 하나의 리뷰 프로토콜로 묶는다.

LION의 기본 사용법

/컴과 현재 프로젝트
/컴과 https://github.com/owner/repository
/컴과 ~/project

리뷰 대상은 기본적으로 읽기 전용으로 다룬다. 파일 수정, 배포, 데이터베이스 변경, 인프라 조작은 하지 않고, 필요한 경우 별도 승인과 롤백 계획을 제시한다.

1. 15개 컴퓨터과학 렌즈

LION은 다음 15개 영역을 모두 점검한다.

영역 점검 대상
프로그래밍 C/C++, Java, 객체지향, 타입, 오류 처리, API 경계
자료구조·알고리즘 복잡도, 자료구조, 병목, 확장성, 트레이드오프
컴퓨터 구조 CPU·메모리·I/O, 논리·디지털 가정, 임베디드 제약
운영체제 프로세스, 스레드, 스케줄링, 파일, 시그널, 자원 제한
네트워크 프로토콜, TLS, 타임아웃, 재시도, 연결 풀, 서비스 디스커버리
데이터베이스 SQL, 스키마, 인덱스, 트랜잭션, 일관성, 분산 DB
소프트웨어공학 요구사항, 모듈성, 설계패턴, 테스트, 프로젝트 관리
웹·모바일 HTTP/API, 프론트·백엔드 경계, 접근성, 브라우저 보안
인공지능·데이터 모델·데이터 생명주기, 평가, 드리프트, RAG·에이전트
이론 컴퓨터과학 이산수학, 오토마타, 계산가능성, 형식언어, 상태 불변식
프로그래밍 언어 언어 의미론, 컴파일러·인터프리터, 빌드·런타임 위험
보안 인증·인가, 비밀, 주입, 암호, 의존성, 공급망, 대응
그래픽·멀티미디어 렌더링, 영상 파이프라인, HCI, 접근성, 지연시간
분산·클라우드 합의, 큐, 멱등성, 오토스케일링, 병렬처리, 클라우드 자원
수학 기초 미적분, 선형대수, 확률·통계, 최적화, 지표의 타당성

모든 영역을 억지로 통과시키지 않는 것이 핵심이다. 저장소에 근거가 없으면 not evidenced로 표시하고 필요한 추가 증거를 적는다.

2. 리뷰 프로토콜

1단계: 범위와 증거 목록

먼저 브랜치·커밋·시각을 기록하고 README, 빌드 파일, CI, 배포 매니페스트, 테스트, 외부 서비스, 데이터 저장소를 인벤토리화한다.

결과는 다른 사람이 동일한 범위로 재현할 수 있어야 한다.

2단계: 구조와 데이터 흐름

입력 → API/경계 → 도메인 로직 → 상태·데이터 → 외부 시스템 → 출력

이 흐름을 따라 모듈 결합도, 응집도, 공유 상태, 동기식 병목, 장애 경계, 변경 집중점을 찾는다. 모든 발견은 증거–영향–심각도–다음 행동으로 기록한다.

3단계: 보안성 검토

LION은 다음을 하나의 위협 모델로 본다.

  • 인증과 인가 경계
  • 시크릿·토큰·환경변수 관리
  • 입력 검증과 SQL/명령/경로 주입
  • SSRF·역직렬화·파일 업로드
  • TLS·네트워크 노출
  • 테넌트 격리와 최소권한
  • 패키지·컨테이너·CI 공급망
  • 개인정보가 포함된 로그
  • 백업·복구·사고 대응
  • 클라우드 IAM과 온프레미스 호스트 권한

“취약점이 발견되지 않았다”와 “안전하다”는 같은 말이 아니다. 검사 범위와 미검토 영역을 함께 남긴다.

3. 클라우드와 온프레미스의 비교

동일한 애플리케이션도 배포 환경에 따라 실패 조건과 비용이 달라진다.

영역 클라우드 온프레미스
컴퓨트 오토스케일링, 쿼터, 인스턴스 비용 하드웨어 용량, 전력, 부품 장애
네트워크 VPC, 로드밸런서, egress, DNS 라우팅, 방화벽, VLAN, VPN, 물리 링크
스토리지 내구성, 백업, 수명주기, egress RAID/PV, 디스크 장애, 백업 매체
보안 IAM, 관리형 ID, 감사 로그 호스트 권한, 패치, 망분리, bastion
신뢰성 리전·존·관리형 서비스 HA, quorum, 예비 부품, 점검 시간
배포 CI/CD, 레지스트리, IaC, 롤백 GitOps, 에어갭, 이미지 미러
관측성 로그·메트릭·트레이스 보관 비용 수집기·저장소·시간 동기화

운영 판단에는 RTO, RPO, SLO, 용량, 롤백, 담당자를 반드시 포함한다. “클라우드가 편하다” 또는 “온프레미스가 싸다”는 전제 대신 워크로드의 실제 요구사항을 비교한다.

4. 가치와 생산성

LION은 코드량·커밋 수·AI 생성량을 생산성으로 보지 않는다. 고객 가치와 품질, 재사용, 검토·재작업·장애 비용을 함께 본다.

\[P = \frac{V \times Q \times R}{T + C + D}\]
  • $V$: 고객에게 전달된 가치
  • $Q$: 품질·보안·요구사항 충족도
  • $R$: 재사용률
  • $T$: 개발·검토 시간
  • $C$: 커뮤니케이션·변경 비용
  • $D$: 장애·재작업 비용

AI가 코드를 빠르게 만들어도 리뷰와 테스트 병목이 커지면 전체 생산성은 떨어질 수 있다. 따라서 AI 생성 코드 승인률, 재작업률, 결함 유출률, 배포 리드타임, 고객 결과를 함께 측정해야 한다.

5. 기술 커뮤니케이션 산출물

한 번의 분석으로 네 가지 독자를 지원한다.

  1. 경영진: 결론·상위 위험·의사결정 필요사항
  2. 개발자: 구조·코드·테스트·보안의 근거와 조치
  3. 운영자: 배포·관측성·SLO·백업·롤백·소유권
  4. 비기술 이해관계자: 가치·트레이드오프·다음 질문

우선순위는 다음 형식으로 표현한다.

우선순위 발견 증거 영향 조치 검증 조건
P0–P3 짧은 문제 정의 파일·로그·명령 왜 중요한가 가장 작은 안전한 행동 통과 조건

이 형식은 “코드가 나쁘다” 같은 추상적 평가를 “어떤 근거로 무엇을 바꾸고, 무엇으로 확인하는가”로 바꾼다.

6. LION의 판정 체계

  • ready: 제시된 사용 목적에 필요한 근거와 통제가 확인됨
  • conditional: 명시된 보완 조건을 충족하면 사용 가능
  • not ready: 치명적인 위험 또는 운영 증거가 부족함
  • insufficient evidence: 검토 범위만으로 판정할 수 없음

판정은 모델의 자신감이 아니라 증거의 범위와 품질을 기준으로 한다.

7. 기대 효과와 한계

기대 효과

  • 코드 리뷰와 운영 리뷰를 하나의 보고서로 통합
  • 컴퓨터과학 기초와 실무 아키텍처 연결
  • 보안·클라우드·온프레미스 판단의 누락 감소
  • 개발자와 경영진 사이의 번역 비용 감소
  • 프로젝트 경험을 재사용 가능한 조직 지식으로 전환

한계

  • 정적 저장소 분석만으로 실제 장애율·성능·보안성을 확정할 수 없음
  • 15개 렌즈의 covered 표시는 깊이를 보장하지 않음
  • 재무·법률·노무 판단은 별도 전문가 검토 필요
  • 운영환경 변경은 명시적 승인과 별도 실행 절차가 필요

결론

LION의 목표는 “모든 프로젝트에 점수를 매기는 AI”가 아니다. 프로젝트를 컴퓨터과학의 기초, 소프트웨어공학, 보안, 운영, 경제적 가치, 사람들의 커뮤니케이션이 연결된 시스템으로 보게 하는 것이다.

좋은 프로젝트 평가는 코드를 읽는 데서 끝나지 않는다. 왜 만들었고, 어떻게 실패하며, 누가 운영하고, 어떤 가치를 남기는지까지 설명해야 한다.

LION은 /컴과라는 짧은 명령으로 이 종합 리뷰를 반복 가능하게 만들고, 기술 판단을 조직의 의사결정 언어로 변환하는 것을 목표로 한다.

References

LION은 의사결정 보조 도구이며, 보안감사·법률감사·재무감사·성능벤치마크를 대체하지 않는다.