기술 포트폴리오

01무엇이고, 어떤 일을 하나

• 문제·본인 역할·선택한 방법·결과를 일관된 구조로 제시한다.
• 비교 대안과 선택 이유를 연결하여 판단 과정을 설명한다.
• 민감정보를 제거한 설정과 시험 근거로 결과를 확인하게 한다.

02어떤 순서로 동작하나

1. 문제와 전체 구조

   해결하려던 문제와 시스템 전체의 동작 경로를 먼저 설명한다.

2. 본인의 역할

   설계·구현·설정·시험·문서화 중 직접 맡은 부분과 공동 수행을 구분한다.

3. 선택과 동작

   왜 그 방식을 골랐는지, 구성 요소와 처리 과정이 어떻게 연결되는지 설명한다.

4. 관찰과 검증

   환경·입력·기대 결과·실제 결과와 판단 근거를 제시한다.

5. 한계와 개선

   확인하지 못한 조건, 남은 문제와 다음 검증 계획을 명확하게 밝힌다.

03먼저 알아둘 용어와 구성요소

본인 기여

팀 활동 중 자신이 직접 결정·구현·검증한 작업 범위이다.

산출물

작업 결과로 만들어진 설계도·코드·설정·보고서·시험 기록 등이다.

STAR

상황·과제·행동·결과를 구분하여 사례를 설명하는 구성 방식이다.

제약 조건

시간·권한·자원·정책처럼 선택 가능한 해결책의 범위를 제한하는 조건이다.

04예제로 따라가기

• 가상 초안: 교육용 초안 “SIEM 구축 완료, 공격 탐지 100%”는 입력 범위·역할·판정 근거가 없다. 이 문장은 실제 사용자 성과를 나타내지 않는다.
• 범위 한정: 가상 프로젝트의 범위를 로그인 로그 한 종류의 수집·정규화·실패 횟수 경보로 좁힌다. 모든 공격 종류나 장기 운영을 검증한 것은 아니다.
• 기여 구체화: 전체 구조를 보여 주고 본인 역할을 파서의 시간대 처리·오류 분류·검증 표본 작성으로 표시한다. 수집 장비와 화면 구축의 공동 기여를 따로 적는다.
• 결정 설명: 실패 행을 버리는 대신 별도 오류 저장과 건수 집계를 선택한 이유를 설명한다. 저장량·운영 검토 부담이 늘지만 누락을 추적할 수 있다는 장단점을 함께 적는다.
• 근거 제시: 예시 표본의 기대 결과와 실제 결과, 수정 전후 차이, 코드·설정 버전과 보고서 위치를 연결한다. 검증한 입력 집합을 쓰지 않은 백분율 표현은 삭제한다.
• 한계와 다음 검증: 대량 입력·서로 다른 제품 형식·늦게 도착한 이벤트는 추가 시험으로 남긴다. 그 시험의 입력 규모와 완료 기준까지 적어 개선 계획을 구체화한다.

05혼동하기 쉬운 점과 확인 기준

• 정의 다음 질문: 구성 요소의 입력·출력·상태를 설명하고 어느 조건에서 다음 단계로 넘어가는지 말한다. 정의를 반복하는 답변에서 실제 동작 설명으로 이어간다.
• 반례로 검증: “실패 로그 한 건이 누락되면?”, “같은 입력이 두 번 오면?”처럼 조건을 바꿔 결과를 예측한다. 모르는 분기는 관찰할 자료와 확인 방법을 제시한다.
• 근거와 추론 구분: 화면에서 확인한 사실과 원인에 대한 가설을 다른 문장으로 표현한다. 설정을 바꿔 해결됐다는 사실만으로 정확한 원인이 입증되는 것은 아니다.
• 범위 밖의 질문: 직접 사용한 버전·구성과 다른 조건이라면 차이를 먼저 밝힌다. 확인한 경험을 넓혀 말하기보다 적용 가능한 원리와 미확인 부분을 구분한다.
• 협업 질문의 증거: 의견 충돌의 원인·대안·합의 기준·본인의 행동·결과를 구체적으로 말한다. 다른 팀을 평가하는 주장보다 작업과 의사결정 기록을 사용한다.
• 증거 접근성: 설정·코드·검증 자료를 다시 찾지 못하면 구체적인 후속 질문에 답하기 어렵다. 공개 가능한 상세 자료와 요약 사이에 명확한 참조를 둔다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.