Pw4ngC0

스위칭 허브의 기능과 동작원리

스위칭 허브는 더미 허브와 달리 유입된 프레임의 목적지 MAC주소의 포트로만 프레임을 전달해주는 네트워크 장비이다.

기능과 동작원리

1.Leaning(학습) 기능 : 특정 포트로 유입된 프레임의 출발지 MAC 주소를 기반으로 MAC Address Table을 생성하여 포트별 연결된 장비의 MAC 주소를 식별한다.

2.Forwarding(전달) 기능 : 생성된 Mac Address Table을 참조하여 전송할 프레임의 목적지 MAC 주소의 포트로 프레임을 전달한다.

3.Filtering(필터링) 기능 : 목적지 포트 외에는 프레임을 전송하지 않는다.

4.Flooding(플러딩) 기능 : Mac Address Table에 등록되지 않은 목적지 MAC 주소의 프레임은 더미 허브와 동일하게 모든 포트에 전송한다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

네트워크 통신 스니핑을 탐지하는 방법

1.ping을 이용한 방법

의심이 드는 호스트에 존재하지 않는 MAC 주소로 위조한 ping을 전송한다. 이후 ICMP Echo Reply가 오면 해당 호스트는 무차별모드로 스니핑 중인것을 확인할 수 있다.

2.arp를 이용한 방법

의심이 드는 호스트에 존재하지않는 MAC주소로 위조한 non-broadcast arp request를 보냈을 때 ARP Response 가 오면 해당 호스트가 무차별모드로 설정되어 스니핑 하고있음을 알 수 있다.

3.DNS를 이용한 방법

일반적으로 스니핑 프로그램은 사용자의 편의를 위해 스니핑한 시스템의 IP주소를 inverse (reverse) dns lookup을 수행한다. 따라서 대상 네트워크에 ping sweep을 보내고 들어오는 Inverse lookup패킷을 감시하여 스니퍼를 탐지한다.

ping sweep은 해당 네트워크의 모든 호스트에게 ping 을 날리는 방식을 의미한다.

4.유인(Decoy)을 이용한 방법

스니핑 공격의 주요 목적은 계정과 패스워드를 획득하는 것이다. 따라서 보안관리자는 가짜 계정과 패스워드를 네트워크에 계속 뿌린다. 공격자는 이 계정을 이용해 접속을 시도하는 시스템을 탐지함으로써 스니퍼를 탐지한다.

5.ARP watch

초기  MAC 주소와 IP주소의 매칭값을 저장하고 ARP 트래픽을 모니터링하여 변화가 있는 ARP 패킷을 탐지하는 도구이다. 대부분 스니핑 공격기법이 ARP Spoofing을 사용하기 때문에 이를 탐지할 수 있다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

CIDR(Classless InterDomain Routing) IP 주소 할당 방식

클래스 구분 없이 IPv4 전체 bit에 대해 네트워크 ID와 호스트ID를 설정하는 주소 할당 방식이다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

제어플래그

URG : 긴급 데이터로 설정하여 순서와 상관없이 긴급 처리되도록 한다.

PSH : 수신 버퍼의 데이터를 상위 계층(어플리케이션 계층)으로 즉시 전달한다.

ACK : 송신 측에 보낸 데이터가 정상 수신되었음을 알린다.

RST : 설정된 연결을 중단한다.

SYN : 연결을 설정한다.

FIN : 설정된 연결을 종료한다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

TCP SYN Flooding 공격에 효과적으로 대응하는 기술로 TCP Syn Cookie 기능이있다.

TCP 표준에 명시된 클라이언트의 유효성을 확인하기 위한 기술이다. 

클라이언트의 유효성이 확인될 때까지 서버 측에서 'Backlog Queue(연결요청 대기큐)'에 연결요청 정보를 저장하지 않기 때문에 TCP SYN Flooding 공격에 효과적으로 대응할 수 있다.

TCP SYN Flooding 대응 방법

1.서버 설정을 통해 Backlog Queue의 크기를 늘린다.

2.보안장비 (디도스 대응 장비, 방화벽 등)를 이용한 임계치 기반의 차단을 수행한다. 

-> 동일 출발지 IP별 동시 연결개수에 대한 임계치를 설정한다.

3.First SYN Drop 기능을 이용한다.

-> 클라이언트의 첫번째 SYN 패킷 폐기 후 재요청이 오면 수락

4.TCP SYN Cookie 기능 사용

 ->sysctl -w net.ipv4.tcp_syncookies=1

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

Slow HTTP Read Dos 공격 : 공격자가 다수의 HTTP 요청에 대한 서버 응답에 대해 조작된 'TCP Zero Window 패킷'을 천천히 지속해서 전송하여 HTTP 응답 데이터 수신을 지연시킴으로써 웹서버와의 연결을 장시간 지속시켜 연결 자원을 모두 소진시키는 형태의 도스 공격이다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

DRDos 공격 원리

DRDos는 출발지 IP 를 공격대상 IP주소로 위조한 패킷을 반사서버에 대량으로 전송하여 대량의 응답이 공격대상에게 전송되도록 해 서비스 거부상태를 유발하는 공격이다.

공격방식

1.TCP  연결 설정 과정의 취약점을 이용한 방식

2.ICMP 프로토콜을 이용한 방식

3.UDP 프로토콜을 사용하는 DNS, NTP, SNMP, CHARGEN등의 서비스를 이용한 방식

DRDos공격과 Dos(DDos)공격의 차이점

Dos(DDos)는 Agent나 공격자가 공격대상에게 직접 공격한다.

DRDos는 IP패킷의 출발지 주소를 위조하고 반사서버를 경유하는 등의 동작으로 인해 공격 근원지 파악이 어렵다.

라우터에 적용할 수 있는 Unicast RPF(uRPF) 패킷 필터링 동작원리

라우터 인터페이스를 통해 유입된 패킷의 출발지 IP에 대해 라우팅 테이블을 이용하여 들어온 인터페이스로 다시 전송되는지를 검사하여 동일한 인터페이스로 전송된다면 정상 패킷으로 판단하고 그렇지 않으면 출발지 IP 주소가 조작된 비정상 패킷으로 판단한다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

안전한 무선랜 구축을 위해 무선AP에 적용할 보안설정

1.무선 AP의 도난 및 공격자의 접근으로 부터 보호할 수 있도록하는 보호케이스 설치, AP 리셋 버튼 차단 등 물리적 보안대책 확보

2.무선 AP 관리자 모드 접속 비밀번호를 설정하고 주기적으로 변경하여 공격자가 AP관리자 모드로 접속하는 것을 방지한다.

3.SSID를 초기 설정값이 아닌 새로운값으로 변경한다.

4.SSID 브로드캐스트를 하지않고 숨김모드로 동작시킨다.

5.무선 AP에서 제공하는 안전한 인증 및 암호화 방식을 적용한다.

6.무선 AP에 접속을 허용할 무선 단말기 리스트를 등록하여 임의 사용자 접근을 차단한다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

MAC Address Filtering 보안 기능 우회기법

공격자는 자신의 접속요청이 거부되는것을 확인한 후 정상 사용자와 무선AP 간의 통신 트래픽을 분석한다. 이후 정상 사용자의 MAC address를 알아내어 공격자가 정상사용자의 MAC주소로 위조하여 해당 AP에 접속을 시도한다.

이후 무선 AP는 MAC 주소 확인 후 공격자 접속을 허용한다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

WEP 암호 방식의 문제점

1.짧은 길이의 초기벡터 값 사용으로 인해 초기벡터 값 재사용 가능성이 있다.

2.불완전한 RC4암호 알고리즘 사용으로 인해 암호키 노출 가능성이 있다.

3.짧은 길이의 암호키 사용으로 인한 공격 가능성이 높다.

4.암호키 노출로 인한 무선 전송 데이터의 노출 위험성이 높다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

IPsec 보안프로토콜

AH 프로토콜 전송 모드 : AH프로토콜의 전송 모드는  IP 헤더의 전송중 변경 가능한 필드를 제외한 IP패킷 전체를 인증하고 암호화는 적용하지 않는다.

AH 프로토콜 터널 모드 : AH프로토콜의 터널 모드는 new IP 헤더의 전송중 변경 가능한 필드를 제외한 New IP 패킷 전체를 인증하고 암호화는 적용하지 않는다.

ESP 프로토콜 전송모드 : ESP 프로토콜 전송 모드는 IP 페이로드와 ESP 트레일러 부분을 암호화 하고 암호화된 부분과 ESP헤더를 인증한다.

ESP 프로토콜 터널 모드 : ESP 프로토콜 터널 모드는 원본IP패킷 전체와 ESP 트레일러 부분을 암호화하고 암호화된 부분과 ESP 헤더를 인증한다.

ESP 터널모드 패킷

|    New IP Header    |    ESP Header    |    IP Header    |    TCP Header    |    DATA    |    ESP Trailer    |    ESP AUTH    |

 터널 모드 암호화 : IP Header, TCP Header, DATA, ESP Trailer

터널 모드 인증 : ESP Header, IP Header, TCP Header, DATA, ESP Trailer

터널모드는 게이트웨이간 보안을 보장하기 때문에 New IP 헤더가 붙는다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

IPsec의 보안 서비스 6가지

1.기밀성 : 대칭키 암호화를 이용하여 데이터가 제3자에게 노출되어도 그 내용을 알 수 없도록 보장해준다.

2.비연결형 무결성 : 메세지 인증코드를 이용하여 IP패킷별로 순서에 상관없이 데이터가 위조되지 않았음을 보장해준다.

3.데이터 원천 인증 : 메세지 인증코드를 이용하여 데이터가 올바른 송신처로부터 온것임을 보장해준다.

4.재전송 공격 방지 : IP 패킷별 순서번호를 이용하여 이전데이터를 재전송하는 공격을 방지해준다.

5.접근 제어 : 보안 정책을 통해 중요한 정보 및 시스템에 접근을 제한한다.

6.제한적 트래픽 흐름의 기밀성 : ESP 프로토콜에 터널모드를 적용하면 New IP헤더에 의해 양쪽 게이트웨이 구간의 트래픽 흐름 정보는 노출되지만, 원본 IP 헤더는 암호화 되어 있으므로 최초 출발지 및 최종 목적지 구간의 트래픽 흐름에 대한 기밀성은 보장해준다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

침입 차단 시스템(방화벽)은 방식에 따라 다음과 같이 구분할 수 있다.

1. 스크리닝 라우터(screening router)방식

패킷 필터링 기능을 이용해 방화벽 기능을 함께 수행하는 라우터를 말한다. 일반적으로 외부 네트워크(인터넷)와 내부 네트워크 경계에 있는 경계 라우터를 주로 이용한다.

2.듀얼 홈드 게이트웨이(dual-homed Gateway) 방식

두 개의 네트워크 인터페이스가 설치된 베스천 호스트로 하나의 인터페이스는 외부 네트워크(인터넷)와 연결 되고 다른 하나의 인터페이스는 내부 네트워크에 연결되어 내부와 외부 사이의 접근 제어를 수행한다.

스크리닝 라우터 방식과 달리 라우팅 기능은 존재하지 않음

3.스크린드 호스트 게이트웨이(Screened Host Gateway) 방식

스크리닝 라우터(외부 스크리닝 라우터)와 싱글 또는 듀얼 홈드 게이트웨이를 조합하여 구성한 방식으로 외부 네트워크(인터넷)에서 내부 네트워크로 들어오는 트래픽은 일차로 스크리닝 라우터에서 필터링 하고 이를 통과한 트래픽에 대해 이차로 싱글 또는 듀얼 홈드 게이트웨이에서 필터링하는 방식이다.

4.스크린드 서브넷 게이트웨이(Screened Subnet Gateway)방식

스크리닝 라우터들(외부 스크리닝 라우터와 내부 스크리닝 라우터) 사이에 듀얼 홈드 게이트웨이를 조합하여 구성한 방식으로 외부 네트워크(인터넷)와 내부 네트워크 사이에 DMZ(Demilitarized Zone)이라는 네트워크 완충지역 역할을 하는 서브넷을 운영하는 방식이다. 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

웹방화벽 제조사와 이름

1.CASTLE(캐슬)

- 한국인터넷진흥원(KISA)에서 제공하는 공개 웹 방화벽

2.WebKnight(웹나이트)

-AQTRONIX(아큐트로닉스)사에서 개발한 마이크로소프트(MS)사의 IIS웹서버에서 동작하는 공개 웹 방화벽

-ISAPI(Internet Server API) 필터 형태로 동작하며, IIS 웹서버 앞단에 위치하여 모든 웹 요청에 대해 필터 정책에 따라 웹 공격을 탐지 및 차단해주는 기능 제공

3.ModSecurity(마드 시큐리티)

-Trustwave (트러스트웨이브)사의 SpiderLabs에 의해 개발된 Apache, IIS 등의 웹서버에서 동작하는 공개 웹 방화벽

- 웹 어플리케이션 공격에 대한 탐지 및 차단 기능뿐만이 아니라 웹 어플리케이션에 대한 실시간 모니터링 및 로그 분석 기능을 제공

- 일반적으로 OWASP의 RuleSet 또는 Trustwave사의 SpiderLabs 상용 RuleSet 적용이 가능
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

ESM(Enterprise Security Management)

기업 환경의 보안 관리를 위해 침입차단시스템, 침입탐지 시스템, 가상사설망, 침입 방지 시스템 등 다양한 보안장비에서 발생하는 보안 정보를 통합적으로 수집 및 관리하여 불법적인 행위에 대응할 수 있도록 하는 보안 관리 시스템을 말한다.

ESM Agent : 관리 대상 보안장비에 설치되어 사전에 정의된 규칙에 따라 보안 정보(이벤트, 로그 등)를 수집하여 ESM 매니저로 전달하는 기능을 수행한다.

ESM Manager : ESM 에이전트로 부터 전달받은 보안 정보를 저장하고 이를 분석한 결과를 ESM 콘솔로 전달하는 기능을 수행한다.

ESM Console : ESM 매니저로부터 전달받은 분석 결과에 대한 시각화, 조회, 리포팅 등의 기능과 ESM 에이전트/매니저에 대한 제어(통제)기능을 수행한다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

SIEM(Security Information & Event Manager) 솔루션 : 더 지능화되고 장기간 지속해서 이루어지는 보안 위협에 대응 하기 위해 보안장비 뿐만이 아니라 서버장비, 네트워크 장비, 엔드포인트, 어플리케이션 등 다양한 원천(source)으로부터 보안 정보를 수집하고, 빅데이터 기반의 상관관계 분석을 통해 보안 위협을 예측해내는 보안관제(운영/관리) 솔루션이다. 한마디로 요약하면 '빅데이터 기반의 데이터 통합 및 상관 관계 분석 솔루션' 이라 할 수 있다.

SIEM은 ESM의 진화단

주요기능

1)데이터 통합 : 다양한 원천에서 발생하는 보안 정보(이벤트, 로그 등)를 수집하여 통합한다.

- 정보(로그) 수집 : 관리 대상 장비에 설치된 에이전트 또는 SNMP, syslog 방식 등을 이용하여 정보(로그) 수집

- 정보(로그) 변환 : 다양한 정보(로그) 표현 형식을 표준형식으로 변환하는 과정

2)상관관계 분석 : 수집한 보안 정보를 유용한 정보로 만들기 위해 다양한 상관관계 분석 기능을 제공한다.

-정보(로그) 분류 : 이벤트 발생 누적 횟수 등 유사한 정보를 기준으로 그룹핑하여 단일 정보로 취합하는 과정

-정보(로그) 분석 : 여러 개의 정보 간 연관성을 분석하는 과정

3) 알림 : 이벤트 발생 시 보안 담당자에게 자동으로 알린다.

4)대시보드 : 분석한 결과에 대한 시각화, 조회 등의 기능을 제공한다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

보안 관제 및 대응에 대한 절차 순서

1.IDS(침입 탐지 시스템) 및 IPS(침입 방지 시스템)등 보안장비를 이용하여 실시간 트래픽 현황과 공격 탐지 로그의 추이를 파악

2.최초 이상 징후가 발생하면 관제 담당자에게 보고하고 각각의 장비별 공격 탐지지표 현황을 비교, 분석하여 공격 탐지 여부를 결정

3.해당 정보보호 시스템 및 장비를 이용하여 공격에 대한 초동 조치 시행

4.장비별 공격 탐지지표에 해당하는 정보를 수집하여 장비 간 상호 연관성 및 피해 내용 등을 고려하여 공격 유형을 식별하고 피해 범위를 분석

5.해당 공격에 대하여 공격 유형 및 대응 메뉴얼에 따라 차단을 적용

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

보안 장비 취약점 유형

1.계정관리

- 보안장비 기본(default) 계정 변경 취약점 : 기본 계정은 장비 제조업체에서 출고 시 설정되어 나오는 기본 관리자 계정을 말한다. 이를 변경하지 않고 사용할 경우 공격자의 불법적인 접근이 발생할 수 있다.

- 보안장비 기본(default) 패스워드 변경 취약점 : 기본 관리자 계정의 패스워드를 변경하지 않고 사용할 경우 공격자의 불법적인 접근이 발생할 수 있다.

- 보안장비 계정별 권한설정 취약점 : 계정별 권한 설정이 미흡할 경우 권한 없는 자에 의해 보안장비 설정 변경이 발생할 수 있다.

- 보안장비 계정관리 취약점 : 불필요한 계정을 관리(삭제 등) 하지 않을 경우 해당 계정을 통한 공격자의 불법적인 접근이 발생할 수 있다.

2.접근 관리

- 보안장비 원격관리 접근 통제 취약점 : 원격 접속 IP에 대해 접근 통제를 하지 않을 경우 공격자에 의한 계정 탈취가 발생했을 때 불법적인 접근이 발생할 수 있다.

- 보안 장비 보안 접속 취약점 : SSH, TTPS 등의 보안 접속을 하지 않으면 공격자에 의한 스니핑 공격이 발생할 수 있다.

- 세션 타임아웃(session timeout) 설정 취약점 : 세션 타임아웃을 설정하지 않으면 관리자의 부주의로 자리를 비운 사이에 권한 없는 자에 의한 악의적인 행위가 발생할 수 있다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

국가사이버 안전관리규정에 따른 사이버 위기 경보 발령 단계별 상세 내역

정상 단계 : 전 분야 정상적인 활동 단계

관심 단계 : 해외 사이버공격 피해가 확산하여 국내 유입이 우려되며 웜, 바이러스, 해킹 등에 의한 피해 발생 가능성이 증가하고 있는 상황으로 사이버 위협 징후에 대한 탐지 활동 강화가 필요한 단계

주의 단계 : 침해사고가 일부 기관에서 발생 했거나 다수 기관으로 확산할 가능성이 증가하고 있는 상황으로 국가 정보시스템 전반에 보안 태세 강화가 필요한 단계

경계 단계 : 침해사고가 다수 기관에서 발생했거나 대규모 피해로 발전될 가능성이 증가하고 있는 상황으로 다수 기관의 공조 대응이 필요한 단계

심각 단계 : 침해사고가 전국적으로 발생했거나 피해 규모가 대규모인 사고가 발생한 상황으로 국가적 차원에서 공동 대처가 필요한단계

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

SSL/TLS 주요 취약점

HEIST 취약점 : 자바스크립트로 브라우저에 대한 사이드 채널 공격을 통해 암호문의 정확한 크기를 알아냄

대응책 : 제3자 쿠키 비허용, 자바스크립트 사용 비활성화

DROWN 취약점 : SSL 2.0 취약점을 이용하여 TLS 연결 해독 가능 

대응책 : SSL 2.0 사용금지

FREAK 취약점 : 수출 등급 RSA 사용을 유도하여 brute-force 공격으로 키를 얻어냄

대응책 : RSA EXPORT Cipher Suites 비활성화

POODLE 취약점 : TLS 연결을 SSL 3.0 으로 낮춰 SSL 3.0 취약점을 이용하여 암호문을 해독

SSL/TLS 협상 시 버전 다운그레이드 공격을 통해 SSLv3.0을 사용하도록 강제한 후 중간자 공격(MITM)을 통해 암호화되어 송수신되는 정보를 탈취하는 공격이다. SSLv3.0의 블록 암호화 기법인 CBC모드를 사용하는 경우 발생하는 패딩된 암호화 블록이 MAC(메시지인증코드)에 의해 보호되지 않는 취약점을 이용한다.

대응책 : SSL 3.0 사용 금지

HeartBleed 취약점 : OpenSSL 라이브러리 하트비트 확장 모듈의 버그로 인하여 웹서버의 시스템 메모리 내용 유출

대응책 : 최신 보안 패치 적용, SSL 인증서 재발급

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

ESM은 다양한 보안장비에서 발생하는 보안 정보ㄹ 단일 관제 환경에서 수집, 분석 및 대응함으로써 상호연관분석과 일관성있는 보안 정책 적용이 가능한 통합보안관제 솔루션을 말한다.

상호연관분석 : 여러 보안장비에서 발생하는 보안정보의 연관성을 분석하여 위협에대한 보다 정확한 판단과 대응을 가능하게한다.

ESM주요 구성요소

ESM Agent : 관리 대상 보안장비에 설치되어 사전에 정의된 규칙에 따라 보안 정보를 수집하여 ESM 매니저로 전달하는 기능을 수행한다.

ESM Manager : ESM Agent 로부터 전달받은 보안정보를 저장하고 이를 분석한 결과를 ESM Console에 전달하는 기능을 수행한다.

ESM Console : ESM Manager로 부터 전달받은 분석결과에 대한 시각화, 조회, 리포팅 등의 기능을 수행하며 ESM 에이전트/매니저에 대한 제어 기능을 수행한다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

윈도우 레지스트리 최상위 루트키

1.HKCR

파일 확장명과 응용 프로그램의 연결 정보가 들어있고, 윈도우 시스템에 들어있는 개체들 및 응용 프로그램과 그 자동화에 대한 정보도 들어있다.

인터페이스 기능에 대한 바로가기 관련 키도 들어있다.

2.HKCU

현재 로그인 중인 사용자의 환경설정 정보를 가지고 있다.

주요 환경 설정 정보에는 제어판 설정, 네트워크 연결, 응용 프로그램 등이 있으며 HKU 루트키에 해당 사용자 정보에 대한 링크를 가지고 있다.

3.HKLM

개별 사용자 단위가 아닌 시스템 전체에 적용되는 하드웨어 와 응용 프로그램의 설정 데이터를 저장한다.

4.HKU

사용자별로 존재하는 하이브 파일인 ntuser.dat 파일을 로드하여 생성된다.

다중 사용자 환경에서 사용자별로 키 항목을 생성하여 환경 설정 정보를 저장한다.

5.HKCC

현재 사용중인 윈도우의 하드웨어 프로필 정보를 가지고 있다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

업무 연속성 계획과 재해복구계획의 차이점 : 업무 연속성 계획은 정보기술 뿐만이 아니라 조직이 제공하는 모든 업무 영역에 대한 연속성을 유지하기 위한 계획이고, 재해복구계획은 정보기술 영역에 국한된 의미로 주로 쓰이는 용어이다.

업무연속성 계획의 핵심절차 : 업무 영향 분석

업무 연속성 계획 5단계

1.프로젝트 범위 설정 및 기획

2.사업영향평가

3.복구전략개발

4.복구계획수립

5.프로젝트 수행 테스트 및 유지보수

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

정보보호 및 개인정보보호 관리체계 인증 : 인증 신청인의 정보보호 및 개인정보보호를 위한 일련의 조치와 활동이 인증기준에 적합함을 한국인터넷진흥원 또는 인증기관이 증명하는 것을 말한다.

정보보호 관리체계 인증 : 인증 신청인의 정보보호 관련 일련의 조치와 활동이 인증기준에 적합함을 인터넷 진흥원 또는 인증기관이 증명하는 것을 말한다.

인증기관 : 인증에 관한 업무를 수행할 수 있도록 과학기술 정보통신부 장관과 개인정보보호위원회가 지정하는 기관을 말한다.

심사기관 : 인증심사 업무를 수행할 수 있도록 과학기술정보통신부장관과 개인정보보호위원회가 지정하는 기관을 말한다.

최초심사 : 처음으로 인증을 신청하거나 인증범위에 중요한 변경이 있어서 다시 인증을 신청했을 때 실시하는 인증심사를 말한다.

사후심사 : 인증받고 난 후 매년 사후관리를 위하여 실시하는 인증심사를 말한다.

갱신심사 : 유효기간 만료로 유효기간 갱신을 위해 실시하는 인증심사를 말한다.

정책기관 : 과학기술정보통신부, 개인정보 보호위원회

인증기관 - 인증위원회 : 한국인터넷진흥원(KISA) , 금융보안원

심사기관 : 정보통신진흥협회, 정보통신기술협회, 개인정보보호협회

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

"접속기록"이란 개인정보취급자 등이 개인정보 처리시스템에 접속하여 수행한 업무내역에 대하여 개인정보 취급자등의 계정, 접속일시, 접속지 정보, 처리한 정보주체 정보, 수행업무 등을 전자적으로 기록한 것을 말한다. 이 경우 "접속"이란 개인정보처리시스템과 연결되어 데이터 송신 또는 수신이 가능한 상태를 말한다.

개인정보처리자는 개인정보처리시스템의 접속기록 등을 월 1회 이상 점검하여야 한다. 특히 개인정보를 다운로드한 것이 발견되었을 경우에는 내부관리계획으로 정하는 바에 따라 그 사유를 반드시 확인하여야 한다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

데이터베이스 보안을 위한 요구사항 5가지

1.부적절한 접근 방지 : 비인가자에 의한 데이터 접근 차단

2.추론 방지 : 기밀이 아닌 데이터로부터 기밀 정보를 얻어낼 가능성 차단

3.데이터 무결성 : 비인가자에 의한 데이터의 생성, 변경 및 삭제 등으로부터 보호

4.감사 기능 : 모든 데이터 접근에 대한 감사 기록(로그) 생성

5.사용자 인증 : 데이터에 접근하는 사용자에 대한 신뢰성 있는 신원 확인

UMC(University MakeUs Challenge)

1~3월 동안 어플리케이션 개발을 진행했다.

Java 기반 Spring Framework를 사용했으며, Mysql 데이터베이스를 사용했다. 

회원 가입, 회원 정보 수정, 로그인, 로그아웃, 회원 탈퇴 등 유저관련 기능들을 구현했으며, 로그인에서는 Kakao Login, Naver Login 과 같은 소셜 로그인 기능을 구현했다.

https://pw4ngc0.tistory.com/entry/%EC%BB%A8%ED%8C%8C%EB%A8%B8-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8

관련 후기이다.

공기업 전산직

어플리케이션 개발과 별개로 계속 진로에 대한 고민을 했었다. 

대부분의 IT관련 기업이나 IT 직무의 사무실들이 수도권에 위치하지만 수도권에서의 삶에 확신이 없어 고민을 했다.

많은 사람들과 복잡한 대중교통, 높은 집값 등의 이유와 수도권의 장점인 좋은 환경은 술을 전혀 마시지 않는 나에게 오히려 단점이라고 생각했다.

또 다른 이유는 계속 경쟁하며 살아갈 자신이 없다는 것이다.

대외활동과 군대에서 정말 뛰어난 사람들을 많이 만났다. 정말 학벌이 좋은 머리가 좋은 뛰어난 사람들, 좋은 학벌이 아닌 사람들 or 고졸 등의 사람들 중에서도 컴퓨터를 잘하고 정말 뛰어난 능력을 가진 사람들을 많이 만날 수 있었고, 이야기를 나눌 수 있었다. 

이러한 사람들은 머리가 정말 좋거나 컴퓨터를 정말 좋아하는 사람들이였다.

나름 학부생 기간동안 열심히 살았다고 생각한다. 학과공부, 대외활동, 프로젝트, 해당 활동들과 프로젝트들을 소화하기 위한 학습, 입대 후 군대에서의 개발 업무 등 어느정도 경쟁할 수 있을 정도의 삶은 살았다고 생각한다.

하지만 취업 후에도 학부생 기간 처럼 계속 열심히 살기에는 너무 힘들 것 같다는 생각이 들었다.

나는 머리가 좋지 않고 컴퓨터 공부 보다 놀거나 쉬는것을 좋아한다.

그렇기 때문에 위에서 말한 뛰어난 사람들이 많은 일반적인 대기업이나 IT기업 내에서 20~30년 동안 경쟁하기에는 어렵다고 생각했다.

위와 같은 이유들로 지방 공기업 전산직을 목표로 결정 했다.

현장실습

8월 1일 ~ 12월 31일 까지 5개월간 (주)쓰리디랩스 에서 현장실습을 진행했다.

현장실습을 진행한 이유는 보수적인 공기업 특성상 인턴이나 현장실습과 같은 회사경험을 좋게 생각할 것이라는 생각이 있었고 돈을 좀 벌고싶다고 생각해 현장실습을 지원하고 진행하게 되었다.

회사업무로는 회사내의 자체개발 소프트웨어 버그 / 기능 테스트 및 보고서 작성, 개발 업무 등을 진행했다. 

정부기관과 프로젝트를 진행하는 회사로 이전에 경험하지 못한 다양한 개발 경험들을 쌓을 수 있었다.

회사 업무도 적당히 좋았고 회사사람들도 정말 좋은분들이었다. 이런 회사가 또 있을까 싶을 정도로 좋은 사람들이 많았으며 실습생인 나에게 많은 배려를 해주어 정말 편하게 회사생활을 할 수 있었다.

회사 복지도 정말 좋았다. 매달 100만원에 가까운 간식비가 회사에서 직원들을 위해 제공되어 원하는 간식을 신청하면 주문해서 회사내에서 먹을 수 있게 해주었다. 간식 주문 업무를 담당하시는 직원분께서 편하게 요청하라고 말씀해주셔서 눈치없이 정말 편하게 요청했다. 먹고싶은 간식들을 다 먹어볼 수 있었다.

각 팀마다 매달 팀운영비가 주어졌다. 내가 속한 팀은 5명이었는데 월 30만원씩 회사에서 제공되어 회식이나 문화의날 때 사용할 수 있었다. 항상 점심에 팀회식을 진행했는데 비싸고 맛있는 음식들을 다양하게 먹어볼 수 있었다.

1~2달에 한번씩 회사 체육대회가 있었다. 마지막주 금요일에 했었는데 탁구, 풋살, 축구 등 다양한 종목들을 진행했다. 그중 11월에 진행한 축구를 제일 재밌게 했었다. 항상 회사 채용공고를 보면 이런 복지가 있는 것을 좋다고 생각했었다. 그러나 정직원 분들이 해당 날짜엔 업무진행이 불가능하여 행사날 전후로 정말 바쁘게 근무하는것을 보면서 무조건 좋은 것은 아니구나 라는 것을 알게 되었다.

유능한사람이 회사에 얻는 위치에 대해서도 알게되었다.

내가 속한 팀의 팀장님이 정말 유능한 분이였다. 대화만 해봐도 기술적으로 지식이 깊고 뛰어나신 분이란 것을 느낄 정도였다. 회사의 다른 분들과 이야기해도 항상 팀장님에 대한 평가는 좋은 평가였으며 많은 분들이 팀장님을 존경하는 것을 알 수 있었다. 

나도 회사에 입사한다면 팀장님처럼 유능한 사람으로서 인정 받을 수 있게 노력할 것이다.

 정직원분들이 정말 편하게 생활할 수 있도록 배려 해주시고, 궁금한 사항들에 대해서도 모두 답변 해주셔서 많이 배워갈 수 있었습니다. 모든 (주)쓰리디랩스 구성원 분들과 현장실습 기회를 주신 대표님, 제출 서류를 항상 검토해주시고 조언해주신 소장님, 항상 잘 챙겨주신 3팀 팀장님 및 팀원분들 정말 감사합니다. 

공기업 준비

현장실습을 진행하면서 공기업 관련 자격증 준비를 조금씩 할 수 있었다.

10월달에 보안기사 필기에 합격했으며 실기는 2023년도 1회차 시험을 준비할 생각이다.

https://pw4ngc0.tistory.com/entry/2022-4%ED%9A%8C-%EC%A0%95%EB%B3%B4%EB%B3%B4%EC%95%88%EA%B8%B0%EC%82%AC-%ED%95%84%EA%B8%B0-%ED%9B%84%EA%B8%B0

한국사 1급도 취득했다.

첫시험은 보안기사 필기시험 후 2주뒤였는데 거의 공부를 하지않았다. 보안기사 공부로 너무 지쳐있어서 거의 공부를 하지못했고 한국사를 조금 쉽게 생각했던것 같다. 

이후 11월 한달동안 진짜 열심히 준비했다. 한국사 기본기도 전혀 없었고 단순 암기 능력이 매우 낮아 한국사 공부를 하는데 어려움이 많았던 것 같다. 기본적인 개념 숙지 후 47회차부터 61회차 까지 모든 회차들을 풀면서 모든 보기들에 대한 해설도 정리하면서 오답을 진행해 원하는 등급을 얻을 수 있었다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

2023

기본적인 공기업 전산직 서류준비들을 진행할 생각이다.

1~2월 토익

3~4월 보안기사 실기

5~10월 정보처리기사 필/실기

10~11월 OPIc

이후 NCS 및 전공공부를 진행해 공기업 필기시험 준비를 진행할 생각이다. 빠르면 2024년도 늦어도 2025년도에는 원하는 공기업에 입사하고싶다.

공기업과 공공기관들의 정원을 줄인다는 기사들이 많이나왔다. 하지만 별로 의미없다고 생각한다. 1명을 뽑더라도 결국 될사람은 되기 때문에 항상 열심히 꾸준히 준비할 생각이다.

원하는 것을 얻기위해 열심히 노력하는 2023년도를 보낼것이다.

정보보안기사 필기 후기

2022년도 4회 정보보안기사 필기시험에 합격했습니다.

2022년도 4회차 시험문제와 답안 입니다. 정보보안기사 필기를 준비하시는 분들은 꼭 풀어보시는 것을 추천합니다.

틀린문제의 빨간 볼펜으로 작성한 숫자의 경우 가답안의 정답입니다. 실제 발표된 정답과 다를 수 있으므로 시험문제 아래의 정확한 답안과 대조하여 학습하시길 바랍니다.

문제

답안

점수

공부방법 및 기간

알기사 정보보안기사 필기책과 필기강의를 이용해서 학습했습니다.

필기강의를 통해서 내용을 먼저 이해하고 이해한 내용을 복습하여 암기하는 방식으로 공부를 했습니다.

현장실습 기간동안 회사와 병행하며 평일 퇴근후 3~4시간, 주말 8~10시간정도씩 한달 ~ 한달 반 정도 준비했습니다.

알기사 책의 이론내용들이 정말 잘 정리되어 있으며 강의 또한 강사님 께서 쉽게 이해할 수 있도록 설명해 주셔서 편하게 공부할 수 있었습니다. 문제의 경우 시간이 부족해 1200제중 600문제 정도만 풀고 최근 기출문제들을 풀며 공부했습니다. 각 문제들에 대해 해설이 잘 정리되어있어 이론학습 후 알기사 1200제 및 기출 책에 있는 내용들을 이용해 학습하는 것을 추천합니다.

시험

2022년도 4회차 필기 10월 8일 토요일 14:00시 PBT 시험을 응시했습니다.

시험은 2시부터 2시간 반정도 진행하여 4시반까지 진행했습니다. 12시쯤 입실하여 기출 문제들 위주로 공부를 했습니다.

-> 해당 시간동안 공부했던게 정말 큰 도움이 됐다고 생각합니다.

기출이나 예상문제들과 똑같은문제들은 10%~ 20% 정도였던것 같습니다. 많은 문제들을 풀어보지 못해 정확한 수치는 아니지만 몇몇 문제들에서 기출에서 풀었다고 생각했던 문제들이라는 느낌을 받았습니다. 또한 똑같은 문제들은 아니지만 비슷한 문제들도 정말 많았습니다.

자신있었던 시스템보안에서 점수가 가장낮게 나왔고 제일 어렵다고 생각했던 정보보안관리 및 법규에서 점수를 가장 잘받았습니다. 단점을 보완하고자 시험직전 정보보안관리 및 법규 내용을 상세하게 공부한것이 도움되었습니다. 시스템보안에서는 문제들이 어렵기도 했고, 긴장해서 실수한 부분들이 많았습니다.

 헷갈리는 문제들과 어려운 문제들에 대해서는 소거법을 통해 보기를 줄이고 찍었던것들이 정답을 받아 운좋게 합격할 수 있었습니다.

시험 합격발표는 2022.10.21 9:00시에 발표되었습니다. 필기시험 면제의 경우 시험응시일이 아닌 합격 발표일 기준 2년으로 2022.10.21 ~ 2024.10.21 기간동안 필기시험 면제를 받아 언제든 실기시험에 응시 할 수 있습니다.

후기

준비 시간이 부족해 꼼꼼하게 공부하지 못해 많이 아쉽습니다. 시험 당일날 까지도 이론지식 습득이 많이 부족하다고 느낄 정도였습니다. 좀더 꼼꼼하게 공부했더라면 더높은 점수와 동회차 실기시험도 준비할 생각이었으나 실기시험의 난이도와 준비기간 및 현재 지식 수준을 고려했을 때 동회차 실기시험은 무리가 있다고 생각했습니다.

정보보안기사 시험 자체의 난이도가 높다고 생각합니다. 범위도 다양하고 최신 취약점이나 리눅스 설정파일, 리눅스 명령어를 통한 설정 등 이론책이나 기출에 나오지않는 범위의 문제나 보기가 나오는경우도 있다 보니 전반적인 이론내용이나 기출문제들에 대해서는 정확하게 이해하고 숙달하고 있는것이 중요하다고 생각합니다. 또한 보안이라는 분야특성상 컴퓨터공학의 전반적인 지식을 바탕으로 응용하는 분야이기 때문에 컴퓨터공학에 관련된 지식만으로는 합격하기 어렵다고 느꼈습니다. 전공자분들도 꼼꼼하게 공부하시는 것을 추천합니다.

합격 커트라인은 100문제중 60문제 정답시 합격이기 때문에 어느정도 학습을 했다면 어려운 시험내용에서도 합격하는것은 가능하다고 생각합니다. 절반인 50문제는 확실하게 맞히고 50문제중 10문제를 찍어서 맞힐경우 합격이 가능하기 때문에 저와 같은 경우 처럼 학습이 부족하더라도 '합격'은 가능하다고 생각합니다. 하지만 이후 실기 시험에서는 정확한 지식내용을 요구하기 때문에 동회차 필실기를 준비하실 분들이라면 이론내용을 꼼꼼하게 학습하시는것을 추천합니다.

필기 시험을 준비하면서 학습의 부족함을 많이 느껴, 정보보안기사 실기시험은 2023년도 1회차 시험을 준비할 생각입니다.

각종 시스템해킹 기법과 네트워크 해킹기법의 경우 동아리와 BOB에서 직접 실습하고 학습했던 것들이 종종 있어 공부하기 편했습니다. 보안기사를 공부하면서 해킹동아리 및 BOB등의 경험들이 기억나 좋았습니다. 

UMC 연합동아리 활동으로 앱개발 프로젝트를 진행했다.

1월 6일 ~ 3월 22일 까지 진행했으며 개인적인 사정으로 프로젝트 팀을 나오게되었다.

마침 오늘 Play스토어에 안드로이드 버전을 런칭하여 해당 프로젝트의 리뷰를 남긴다.

프로젝트 주제

OTT 서비스들에대해 작품을 추천하는 어플리케이션이다. 넷플릭스와 디즈니+, Apple TV 등등 다양한 OTT서비스들의 작품들을 디비에 저장하고 유저들 개개인의 취향에 맞게 작품을 추천하는것이 최종 목표이다.

팀 구성

1월~2월까지는 백엔드 Spring 4명, 프론트 android 3명, 디자이너 1명으로 팀으로 진행했으며,

3월 22일 현재까지는 spring 3명, android 2명, ios 1명, 디자이너 1명으로 진행했다.

나는 Spring 파트로 프로젝트 진행을 했으며, 개인적인 사정으로 오늘까지만 프로젝트에 참여했다.

Android 어플리케이션은 현재 Play스토어에서 다운받을 수 있으며, IOS 버전도 출시될 예정이다.

프로젝트 구조

Spring, Mysql 등을 사용했으며 Spring은 intellij 프로그램을 통해 작성했다. 서버는 AWS의 Ubuntu 환경에서 작동하며 이미지 파일의 경우 S3에서 처리했으며, DB처리의 경우 JDBC로 정상적인 서비스를 구현하고 이후 JPA로 변경하는 작업을 수행했다.

대략적인 어플리케이션 동작 구조이다.

나는 서버인 Spring파트를 맡아서 프론트에서 보내는 요청에따라 DB에서 데이터를 가져와 프론트에 전송하는 기능들을 구현 했다.

Spring 구조

Spring 내부구조이다. 회원가입이나 회원탈퇴, 정보수정 등 디비의 Update, insert, delete 관련된 API들은 UserService에 구현했으며, 정보수정 및 회원 정보조회, 로그인과 같이 select구문을 사용하는경우 UserProvider에 구현했다.

프로젝트 진행

Spring에서 소셜로그인, 회원가입, 나의정보보기, 나의 정보수정, 회원 탈퇴 API를 만드는 것을 담당했다.

로그인

소셜로그인 기능으로는 카카오로그인과 네이버 로그인을 구현했다. 그중 위 코드는 카카오 로그인이다.

PostLoginReq 데이터 객체 형식으로 들어오는 데이터를 받아 유저가 디비에 존재하는지 확인하여  디비에 존재한다면 바로 로그인을 존재하지 않는다면 회원가입으로 이동하도록 설계했다.

소셜로그인 기능의 경우 사용은 많이해봤지만 구현된코드나 UMC교육기간동안 접해보지 못하여 처음에는 어려움을 많이 겪었다. 물론 관련된 코드들은 구글링을 통해서도 많이 공부할 수 있었고 해당 소셜로그인 관련 공식홈페이지에도 친절하게 알려준다. 어렵게 느껴졌던 이유는 로그인 프로세스를 이해하지못했다.

카카오 로그인 프로세스의 경우 아래와 같다.

프론트에서 카카오로그인 클릭 후 계정 로그인 -> 카카오 서버로 전송

-> 카카오서버에서 해당 유저확인후 kakao access token 발급 -> Spring에서 해당 access token을 통해 kakao 서버에 유저관련 정보 획득 -> 디비에 저장후 로그인 및 회원가입 데이터로 사용

회원가입

회원가입의 경우 사용자가 입력한 정보를 받아서 디비에 저장하는 방식이다.

nickname, 프로필사진, 성별, 생년월일, 구독하는 ott 서비스, 좋아하는 장르 등의 데이터를 받아 디비에 저장한다.

Spring에서 사진을 처리하는것이 어려웠다. MultipartFile 데이터가 들어가는 경우 front에서 Json 형태로 데이터를 받지못한다. 사진파일을 별도로 처리할수가 없어 데이터형식을 form-data 형식으로 바꾸고 각각 데이터들을 따로 받았다.

즉 로그인처럼 하나의 객체형식으로 받지못하고, 각각의 데이터를 송신받았다. 이후 Spring에서 처리하기 쉽도록 하나의 객체에 데이터들을 삽입하여 회원가입을 진행하도록 했다.

컨파머 어플리케이션의 경우 휴대폰번호, 본인인증, 본명, 패스워드 등을 요청하지 않기 때문에 디비에서도 해당 유저가 누구인지 전혀 식별할수 없다. 100% 익명성을 보장한다. 

나의 정보보기

여기서부터 jwt가 쓰인다. jwt는 spring 서버에서 발급해주는 토큰이다. 해당 토큰을 통해서 로그인한 유저를 식별하고, 본인의 정보를 조회할 수 있게 해준다. 타인의 정보를 조회할수 있는 상황을 방지하기 위하여 jwt 토큰을 사용한다.

 나의 정보수정

정보수정 코드이다. 회원가입과 많이유사하다. 닉네임이나 프로필사진, 구독중인 ott 서비스, 좋아하는 장르 등을 수정할 수 있다. S3 를 사용하여 이미지 파일들을 관리하였는데 해당 url이 노출되는것을 막기위해 검은색으로 칠했다. 저곳에는 s3 url이 들어간다. 회원가입과 다르게 사진파일을 처리하는것에 조금 어려움이 있었다. 프로필 사진을 없앨경우, 변경할경우 등등 을 고려하여 코드를 작성했다.

여기까지가 구현한 UserController 코드들이다.

이외에도 유저가 디비에 저장되어있는지 확인하는기능, 회원의 닉네임을 호출하는기능 등등 UserService 200줄, UserProvider 200줄, UserDao 350줄 정도를 작성했으나 모두 리뷰하기에는 너무 길기때문에 UserController까지만 진행하겠다.

3월 JPA

1~2월동안 정상적으로 서비스하는 Spring 코드를 완성했다. 이후 어플리케이션 성능 개선을 위해 DB 접근방식을 JDBC에서 JPA로 변경하는 작업을 했다. JPA관련학습은 인프런의 김영한님의 JPA강의를 학습했다.

Entity 설계부터 JPARepository를 이용한 쿼리문 작성 등 한달동안 JPA를 경험할 수 있었다.

Entity를 통해 디비테이블을 객체화하여 관리하는방식이 신기하고 재밌었으며, JPARepository또한 간편하게 CRUD 쿼리를 생성해주어 편했다. 해당 쿼리문을 100%신뢰 할 수 없다고생각하여 Extract JPQL Query 옵션을 통해 쿼리문을 확인했다.

Extract JPQL Query옵션을 사용하면 위처럼 쿼리문을 확인할 수 있다. 

JPARepository가 자동으로 쿼리문을 생성해주지만 해당 쿼리문들을 직접 확인하는과정은 꼭 필요하다고 생각한다.

최대한 Controller를 수정하지않고 JDBC를 JPA로 교체할려 노력했으나 이후 팀원들의 방향에 따라 Controller의 코드도 달라질 수 있다고 생각한다.

개인적인 일정으로 JPA 교체작업을 완료하지 못하여 아쉬움이 있으나 내가 작성한 Controller의 기능들에 한해서는 모두 JDBC에서 JPA로 교체하는 코드를 작성했기 때문에 어느정도 JPA를 경험할 수 있었다.

후기

초기에 기본적으로 코드작성할때는 편하게 작성했던것으로 기억한다. User를 처리하는 부분은 구글링하면 코드도 많고, UMC 교육과정동안 User관련 데이터 처리를 가볍게나마 접했으며, 해당 프로젝트 이전에 공부했던 김영한의 스프링 기초 강의에서도 User관련 처리에대해 학습했기 때문에 순수 코드를 구현하는 부분에서는 편하게 구현 했다.

이후 자체적인 코드 테스트에서부터 어려움이 생겼다. 디비쿼리문들이 오류를 출력하거나 정상적으로 작동되지 않았으며, 기존에 처리해주지 않았던 소셜로그인, 이미지파일처리 등을 구현하면서 어려움이 많아졌다.

 회원가입 및 회원정보보기 정보수정 코드들의 모든 디비쿼리들이 정상작동하지않았으나 UserDao의 디비 쿼리문 수정을 통해 해결했으며, 소셜 로그인 기능 구현의 경우 Android를 담당하시는 팀원분들과 함께 진행해야 했기 때문에 계속해서 의견을 주고받으며 오류들을 수정해 나갔다.

소셜로그인 기능을 구현후 테스트 및 코드 수정을 안드로이드 파트 분들과 협업을 통해 진행했는데 해당 과정이 가장 힘들었지만 가장 재미있었다. 안드로이드 파트 팀원분들이 작업시간을 배려해주어 편하게 작업할 수 있었다.

소셜 로그인기능을 완료한 이후 이미지파일을 처리하는 기능을 회원가입과 정보보기, 정보수정에 각각 넣는것도 어려웠다. 이미지 파일이 없는경우 모든 데이터를 json 형식으로 간단하게 처리가 되어 편하게 진행할 수 있었다.

그러나 MultipartFile 데이터가 포함된 경우 json형태로 전송하지 못하고 form-data형식으로 전송받아야 했으며, 이미지파일 추가로 인해 UserController의 Parameter, 이후 Controller에서 호출하는 모든 UserService 메소드, UserDao의 db쿼리문 등 모두 수정해 주었다.

1~2월 동안 JDBC를 통해 서비스를 완료한 프로그램에서 내가 작성한 코드들 모두 합쳐봐야 900 ~ 1000줄정도이다.

코드의 양은 많지않지만 코드를 구현하는데 있어서 고민하는 시간이 정말 많았던것 같다.

 구글링뿐만 아니라 보내는 데이터를 처리하는 방식에대한 고민, 팀원, 지인들에게 자문을 구하는 등 고민하고 코드를 수정하는데 정말 많은 시간이 필요하다는 것을 알게되었다. 

또한 코드를 실제로 테스트해봄으로써 작성한 코드들이 정상작동하는지 확인하고 수정하는것에도 시간이 많이 필요하며, 백엔드 담당을 맡게 되더라도 프론트와 함께 협업하는 상황이 반드시 발생한다는것 또한 알게되었다.

모든 기능 구현이후 자체테스트에서 문제가 발생했으며, 자체테스트를 통과하기 위해 코드를 수정했다.

이후 android와 연결하는 과정에서도 모든 기능들에 문제가 발생하여 코드를 수정하는 과정을 거쳤다.

실력이 없었기 때문에 어려움을 느낀것도 당연하다.

또한 어려움을 느꼈기 때문에 시간투자를 많이하여 어느정도 프로젝트 진행시간에 맞출 수 있었다.

프로젝트 팀원들에게 정말 많은 도움을 받았다. 본 프로젝트가 개발 프로젝트로서는 첫 프로젝트였으며 개발 실력이 가장 낮았기 때문에 팀원들에게 도움요청을 많이했다. 덕분에 많이 배울 수 있었고, 실력을 기를 수 있었다.

또한 대학교 지인들에게도 자문을 구해 어려움을 해결하기도 했다. 여러 방면으로 도움을 주신 지인, 팀원분들 모두에게 감사하다.

오류가 발생했을 때의 스트레스는 오류를 해결했을 때의 성취감에 비할바가 되지않았으며 프로젝트 기간동안 팀원분들과 함께 의논하고 문제들을 해결해 나가는과정이 정말 재미있었다.

전체적인 프로젝트의 후기는 "재미있었다" 이다.

개인적인 일정으로 함께 프로젝트를 진행하지 못함에 많은 아쉬움을 느끼지만 팀원이 아닌 컨파머 이용자로서 팀 컨파머를 항상 응원한다.

play스토어 컨파머 링크

https://play.google.com/store/apps/details?id=com.corn.cornfarmer_android

프로젝트의 후기를 최대한 생생하게 남기고자 생각나는대로 두서없이 작성했다.

이글을 마지막으로 블로그 관리 또한 개인적인 일정으로 못하게 될 예정이다.

끝

홈화면 추가

웹브라우저 url에 http://localhost:8080을 입력해서 접속하면 위의 HomeController의 home메소드가 실행된다.

Return "home"은 tempaltes의 home.html을 반환한다는 의미이다.

members/new 로 가게하는 회원가입 과 /members 로 이동시키는 회원 목록 이 있다.

위 파일 목록을 보면 원래 home의 디폴트는 static/index.html 이였다.

home의 디폴트가 home.html이 되었는데 그 이유는 요청이 들어올 때, 스프링 컨트롤러에서 해당 요청에 해당하는 메소드를 찾고 해당하는것이 없을 경우 static내에서 파일을 찾아 출력해주기 때문이다.

위의 코드에서는 컨트롤러에 @GetMapping("/") 에 해당하는 home 메소드가 존재하기 때문에 해당 메소드를 실행시켜 home.html을 반환하는 것이다.

회원가입

/member/new로 Get 요청이 들어오는 경우 실행되는 createForm 메소드이다. members/createMemberForm.html

을 반환한다.

이름을 입력받아 회원가입하고 해당 데이터를 /member/new 경로에 post방식으로 전송한다.

등록을 누를경우 해당 데이터가 /member/new 경로로 post 데이터 전송을 한다.

name을 받기위해 Controller 디렉토리에 추가해준 MemberForm이다.

createMemberForm에서 name을 반환할 경우 해당 값을 받기 위한 클래스이다.

create메소드

createMemberForm에서 post보낸 데이터를 받는 메소드이다.

post 전송방식에 매핑하기 위해  @PostMapping을 이용하고 createMemberForm에서 받은 정보가 MemberForm form으로 전송되고 해당 정보를 새로 생성한 member객체에 넣어 memberService.join을 통해 메모리에 저장한다.

해당 동작이 끝나면 home 화면으로 redirect 시켜준다.

회뭔 목록 조회

memberService.findMembers를 통해 저장된 회원들의 정보를 모두 가져온다.

model 객체에 addAttribute를 통해 가져온 정보를 model객체에 저장하고 해당 정보를 members/memberList에 반환한다.

Thymeleaf를 사용해 모든 회원들의 정보를 출력시킨다.

${member.id}는 member.getId() 메소드의 결과를 반환하고, ${member.name}은 member.getName() 메소드의 결과를 반환하여 출력한다.

3명의 회원을 등록하고 members 로 get요청하여 memberList.html을 출력한 결과이다.

MemberController에서 MemberService를 통해 회원가입을 하고 MemberService를 통해서 데이터를 조회할 수 있어야 한다.

MemberController와 MemberService는 의존관계이다.

MemberController가 MemberService를 의존한다.

스프링이 시작할 때 스프링 컨테이너에 @Controller, @Service, @Repository 등의 어노테이션을 가진 클래스 객체들을 생성하고 스프링 빈으로 등록해서 관리한다.

스프링 컨테이너 : 스프링에서 객체를 관리하는 것. 객체의 생명주기를 관리하고 컨테이너에 담겨있는 객체들을 스프링 빈(Bean)이라고 부른다.

@Controller, @Service, @Repository 어노테이션이 존재하는 클래스들의 경우 객체를 스프링 빈(Bean)으로 등록해 스프링 컨테이너에서 관리한다.

위처럼 MemberService() 객체를 new로 할당해서 사용할 수도 있지만, Spring 컨테이너에 저장된 빈을 불러서 사용하면된다.

new를 통해 객체를 생성해서 할당할 경우, 모든 Controller가 각각의 Service 객체를 사용하게 된다.

-> 자원이 낭비되며 비효율 적이다.

스프링 컨테이너에는 각 객체들이 하나만 빈으로 등록되어 해당 빈을 공유하는 형태로 사용하기 때문에 new를통한 객체 할당을 통해서 사용하는것보다 훨씬 효율적으로 사용이 가능하다.

생성자에 @Autowired 어노테이션을 사용하면 스프링 컨테이너에 빈으로 존재하는 MemberService 객체를 연결해 준다.

-> MemberController가 memberService를 의존하게 된다. (Dependency Injection : 의존성 주입)

@Controller 어노테이션이 존재하는 MemberController 클래스는 스프링이 시작할 때 자동으로 스프링 컨테이너에 스프링 빈으로 등록된다.

@Autowired 어노테이션을 통해 스프링 빈을 연결하는 경우 해당 객체또한 스프링 컨테이너의 스프링빈으로 등록되어 있어야한다. 즉 위 코드에서는 memberService가 스프링 빈으로 등록되어 있어야 한다는 것이다.

@Service 어노테이션의 경우 @Controller와 마찬가지로 스프링이 시작할때 컴포넌트 스캔에 의해 스프링 빈으로 등록된다. MemberService에서도 생성자에서 @Autowired를 사용하는데 이때 사용되는 MemberRepository 또한 스프링 빈으로 등록되어 있어야한다.

@Repository 어노테이션도 스프링 시작시 스프링 빈으로 등록시켜준다.

코드들은 위 그림과 같이 의존관계가 연결된다.

컴포넌트 스캔과 자동 의존관계 설정

@Controller, @Service, @Repository와 같이 어노테이션으로 스프링 빈을 등록하는 경우는 컴포넌트 스캔 방식에 해당한다. @Component 어노테이션이 스프링 빈으로 등록하는 어노테이션이지만, @Controller, @Service, @Repository 어노테이션의 내부에 @Component가 존재해 세가지 어노테이션 모두 스프링 빈으로 등록된다.

스프링이 시작할 때 @Component 어노테이션들을 스캔해서 스프링 빈으로 등록하는 것을 컴포넌트 스캔이라고 한다.

@Autowired는 스프링빈을 연결하는 역할을 한다.(의존 관계 설정)

@Component스캔의 범위는 @SpringBootApplication 어노테이션이 존재하는 클래스의 패키지와 해당 패키지의 하위패키지에서만 작동한다.

@SpringBootApplication 어노테이션 내부에 @ComponentScan 어노테이션이 존재한다.

**스프링은 스프링 컨테이너에 스프링 빈을 등록할 때, 기본적으로 싱글 톤 등록을 한다.**

싱글 톤 : 하나만 등록하여 해당 객체를 공유한다.

예를 들어 MemberController의 경우도 하나의 객체만 컨테이너에 스프링 빈으로 등록해서 공유한다. MemberController 객체가 여러개 스프링빈으로 등록되지않는다.

자바 코드로 직접 스프링 빈 등록하기

@Service, @Repository, @Autowired 어노테이션을 제거한 후 코드를 작성한다.

SpringConfig 파일을 새로 하나 생성한다.

@Configuration 어노테이션은 설정 파일을 만들기 위한 어노테이션이며, Bean을 등록하기 위한 어노테이션이다.

@Configuration 클래스 내부에 @Bean 어노테이션 작성시 해당 객체를 Bean에 등록한다는 의미를 가진다.

위 코드는 MemberService와 MemoryMemberRepository 객체를 Bean으로 등록하는 코드이다.

위코드를 통해 코드로 직접 스프링 빈을 등록한 경우에도 아래처럼 구조가 가능해진다.

스프링이 시작될 때, memberRepository와 memberService를 스프링 컨테이너에 올려 빈으로 등록한다.

MemberService 생성자에 파라미터로 memberRepository를 넣어주는데 이때 들어가는 memberRepository는 빈으로 등록된 memberRepository이다.

자바코드로 직접 등록할 때에도 Controller는 컴포넌트 스캔으로 올라가야 하기 때문에 @Controller 어노테이션을 꼭 써줘야한다. 또한 Controller 생성자에서 스프링 빈 객체를 가져올 때도 컴포넌트 스캔 방법인 @Autowired 어노테이션을 작성해주어야한다.

Dependency Injection의 3가지 방법

1.생성자 주입(생성자에 @Autowired 어노테이션 사용)

2.필드주입(필드에 @Autowired 어노테이션 사용)

3.Setter 주입(set 메소드가 public으로 사용되며 어디서든 호출이 가능해져 개발중 문제가 생길 수 있다.)

가장 좋은 방법은 생성자 주입이다.(생성자에 @Autowired 어노테이션을 통해 빈 객체를 연결하는것)

실무에서는 주로 Controller, Service, Repository와 같은 코드들은 컴포넌트 스캔을 사용한다고 한다. 정형화 되지 않거나, 상황에 따라 구현 클래스를 변경해야 하는 경우 설정을 통해 코드로 직접 스프링 빈으로 등록한다고 한다.

MemberRepository의 경우 Memory를 사용하는 구현체에서 DB를 사용하는 구현체로 바꿀 예정이기 때문에 컴포넌트 스캔이아닌 코드로 직접 빈에 등록하는 코드를 남겨둔다.

@Autowired를 통해 Dependency Injection을 하는 경우 MemberController와 MemberService 와 같이 스프링이 관리하는 객체 즉 스프링 빈 객체들에 한해서만 가능하다. 스프링 빈으로 등록되지 않은 객체들은 @Autowired 사용이 불가능하다.

지난 1년을 정리해보고자 한다.

탈보안

올해 초부터 고민하다가 보안분야 공부를 멈추고 개발공부를 시작하게 됐다.
군대에서도 보안쪽을 준비하기 위해 시스템프로그래밍과 네트워크 프로그래밍, 어셈블리어 등에 대한 공부를 했었고,

업무로도 시스템 프로그래밍 관련된 업무를 했었다. 점점 보안에 대한 흥미는 잃게되고 개발쪽에 재미를 느끼게 된것같다.

막연하게 개발쪽으로 공부를 해야겠다고만 생각하고 뚜렷한 목표를 세우지 못했었다.

목표가 없으면 불안함이 생긴다는 것도 이때 알게됐다.

백엔드

목표없이 복학하게 되었고, 학교 수업 및 과제로 JSP,HTML,CSS,Javascript, JAVA, Spring을 접하게 됐다.
Java/Spring에 재미를 느끼게 됐다. (CSS, HTML이 너무 재미없었다.)

Java/Spring 백엔드쪽으로 공부를 계속 할 생각이다.

여름

학교 종강후 기본을 확실하게 다지고자 JAVA를 좀더 깊게 공부하기 위해 자바의 정석으로 공부를 했다.
JAVA에 대한 기본적인 문법들과 객체지향에 대해 깊게 공부할 수 있었다.
복습 및 정리를 위해 블로그를 다시 하게됐다.
주기적인 업로드와 꾸준한 조회수로 블로그 광고도 가능하게 됐다.
생각보다 뿌듯하고 재미도 있다. 앞으로도 꾸준히 공부하고 업로드할 예정이다.

보안회사에서 근무하는 친한 친구로부터 같이 일해보자는 입사제의?를 받았다.
BOB를 끝내고 군입대 이후로 너무 입사하고 싶었던 회사라 하루정도 깊게 고민했다.
그러나 개발쪽으로 진로를 정했기 때문에 거절했다.
아쉬움이 커 더 열심히 공부를 하게된 계기가 됐다.

UMC

연합동아리인 University MakeUs Challenge에 가입해서 활동하게 됐다.
해당 동아리에 가입하기 위해 자기소개서와 면접을 준비했다. 
개발쪽 이력이 하나도 없다보니 자소서 작성과 면접준비가 어려웠다.
다행히 합격하게 됐고, 첫 개발관련 대외활동이 UMC가 됐다.

학기중 10주동안 백엔드,RestAPI, DB, Spring에대한 교육과 과제를 통해 실력을 키우고,
1~2월동안 앱개발 프로젝트를 진행하는 활동이다.
교육과 과제는 끝났고, 개발 프로젝트만 남겨놓은상황이다.
첫 개발 프로젝트를 앞두고 있지만 너무 실력이 부족한 상태이다.

Spring에대한 이해와 실력이 부족하다고 생각하여 인프런의 김영한님의 Spring강의를 듣고 블로그에 정리하기 시작했다.
현재 스프링강의를 통해 학습하는것이 정말 재미있다.

시험없는 컴퓨터공부는 재밌는것 같다.

개발 공부를 늦게 시작하다보니 실력이나 경험 모두 많이 부족한것같다.

열심히 해야겠다.

-----------------------------------------------------------------------------------------------------------------------------------

2022

인프런의 김영한님 Spring강의를 들으면서 진행하는 프로젝트에 계속 적용할 예정이다. 
학습도 중요하지만 실전에 적용하는것 또한 중요하다는것을 보안공부하면서 깨달았기 때문에 개발 공부에서 최대한 이론을 바탕으로한 실무능력향상에 초점을 두고 공부와 프로젝트를 병행할 것이다.

IPP를 준비하려한다. 학교수업은 재밌지만 시험기간때 오는 스트레스가 심해 2022-2학기는 현장실습을 통해 회사업무를 할 수 있도록 준비해볼 생각이다. 현장실습은 최대한 JAVA 또는 Spring에 관련된 업무를 하는쪽으로 하고싶다.

JAVA 코딩테스트 실력도 기를 것이다. 2023년도에 소마, 우테코도 경험해보고 싶기 때문에 코딩테스트와 Spring실력을 많이 기르는 2022년도를 보낼것이다.

비즈니스 요구사항 정리 및 설계

데이터 : 회원ID, 이름

기능 : 회원 등록, 조회

백엔드 계층 구조

컨트롤러 : MVC 컨트롤러 역할

서비스 : 도메인 객체를 이용한 핵심 비즈니스 로직이 구현됨

도메인 : 회원, 주문, 쿠폰 등과 같이 데이터베이스에 저장되고 관리되는 비즈니스 도메인 객체

리포지토리 : 데이터베이스에 접근하여 도메인 객체를 DB에 저장하고 관리하는곳

아래 프로그램에서는 DB없이 메모리를 저장공간으로 사용한다.

도메인

데이터인 회원 ID와 name이 들어간 Member객체이다.

회원 도메인과 리포지토리 만들기

MemberRepository interface이다.

리포지토리는 도메인 객체를 DB에 저장하고 관리하는곳이기 때문에 domain.Member를 import한다.

이후 Member들을 DB에 저장하거나 관리하는 메소드들을 선언한다.

DB에 따라 해당 인터페이스를 상속받아 구현한다.

Memory를 DB로 구현한 MemoryMemberRepository

MemberRepository를 상속받아 MemoryMemberRepository를 구현한다.

해당 인터페이스의 save, findById, findByName, findAll 메소드들을 해당 클래스에서 구현한다.

1씩 sequence를 더하면서 id값을 부여, store(Map)라는 임시저장소(Memory DB)에 member 저장

findById : id값과 일치하는 id를 store에서 탐색

Null이 반환될 수 있기 때문에 Optional.ofNullable로 탐색

findByName :  name값을 기반으로 store에 저장된 값 탐색

stream()의 경우 for문으로 모든원소에 접근하듯이 모든 원소들에대해 접근한다고 생각하면 된다.

filter를 통해 name과 일치하는 멤버들을 걸러내고, findAny()를 통해 걸러진 값을 반환한다.

즉 store에 저장된 값중 이름이 name과 일치하는 경우를 반환한다.

모든 값들을 Member List로 반환한다.

회원 리포지토리 Test코드 작성

개발한 기능들을 main메서드를 실행시켜 테스트하는 경우 시간이 오래걸리고, 한번에 모두 테스트하기 어렵다는 단점이 있기 때문에 테스트코드를 생성하여 메소드들을 테스트하는것이 좋다.

test내에 리포지토리 패키지를 생성하여 test클래스를 작성해준다.

@Test 어노테이션을 사용하여 해당 메소드가 테스트 메소드임을 명시해준다.

위처럼 해당 테스트 메소드를 구현한뒤 해당 메소드만 실행시켜 테스트가 가능하다.

save를 실행시킬경우 해당 테스트코드 내에서 오류가 발생하거나 실패를 하게되면 해당 실행에서 경고를 반환한다.

테스트코드가 성공할경우 아래처럼 정상 종료가 된다.

테스트코드는 항상 해당 코드를 실행시키고 검증까지 완료해야한다. save 메소드의 경우 Member 데이터 생성과 save함수 실행, 이후 findById를 통해 해당 id를 검색하고 assertThat(member).isEqualTo(result)를 통해 검증을 완료했다.

findByName 테스트 코드

findByName을 검증하기 위해 데이터를 만들고 findByName을 통해 result를 반환받고 assertThat(result).isEqualTo(member1)을 통해 검증했다.

findAll() 테스트 코드

2개의 member를 생성 및 save하고 findAll()을 실행한다.

이후 findAll()의 반환의 결과가 2개 인지 확인하여 검증한다.

테스트코드의 경우 모든 메소드들을 한꺼번에 실행하여 테스트하는것도 가능하다.

여러 메소드를 한꺼번에 실행할 경우 각 메소드들이 순서와 상관없이 실행된다.

각 메소드들이 실행되면서 같은 데이터를 save하는 경우 에러가 발생한다.(중복 저장 예외)

이러한 문제를 해결하기 위해 아래의 코드를 추가해준다. 

@AfterEach는 해당 클래스내의 각 메소드들이 실행을 끝낼때 마다 실행되게하는 어노테이션이다.

MemoryMemberRepository의 clearStore메소드

위 메소드를 통해 각 메소드들이 끝날 때마다 저장소를 비워준다.

-> 중복 저장 예외를 방지할 수 있다.

위의 개발과정은 MemoryMemberRepository를 모두 구현하고, 테스트 코드를 통해 해당 클래스의 메소드들을 검증 했다. 해당 개발 과정을 뒤집어 테스트 코드를 먼저 작성하고 검증이 완료된 후 메소드를 구현할 경우 테스트 주도개발(TDD)이라고 한다.

MemberService 메소드 작성

Join() 메소드

join 내부에서 member중복을 검사하는 코드를 작성한 뒤 외부의 새로운 메소드로 생성했다.

ifPresent를 통해 findByName의 반환값이 존재한다면 throw new IllegalStateExceptioon("이미 존재하는 회원입니다.")를 실행시킨다.

ifPresent는 값이 존재할 경우 내부 로직을 실행시키는 기능을 제공한다.

위와 같이 MemberService 코드를 구현했다.

회원가입, 전체 회원조회, 회원ID를 통한 회원 조회 등 비즈니스적인 메소드들이 구현된다.

MemberService 테스트 코드 구현

위처럼 테스트코드의 메소드명을 한글로 지정해도 상관없다.

테스트 코드를 구현할 때 given-when-then 구성으로 코드를 작성하는것이 좋다.

given : 주어지는 것

when : 실행했을 때

then : 결과

어떤 것이 주어진 상황에서 코드를 실행했을 때 결과가 이렇게 나와야 한다는 과정을 정리하여 작성하는 방법이다.

given-when-then 의 회원가입 테스트코드

멤버가 given으로 주어지고 join메소드를 실행했을 때 검증을 위해 findOne을 통해 나오는 결과가 무엇인지 확인하는 과정이다.

중복 회원가입 예외 테스트코드

assertThrows는 두번째 인자로 주어진 로직 실행시 첫번째 인자에 해당하는 예외가 발생하는지 검사하는 함수입니다.

첫번째 인자가 IllegalStateException이 아닌 NullPointerException이라면 assertThrows에서 에러를 반환한다.

해당 로직에서 정상적으로 IllegalStateException 을 발생시키면 해당 예외를 예외객체 e에 저장하고,

assertThat을 통해 해당 예외 메세지를 "이미 존재하는 회원입니다." 와 비교하여 검증을 완료한다.

Service테스트 코드에서도 테스트별로 멤버들을 생성하고 저장하기 때문에 아래 코드를 넣어준다.

MemberService의 생성자 코드

MemberService의 생성자 인자로 memberRepository가 주어지며 각 MemberService마다 memberRepository를 별도로 갖게 된다.

테스트코드에서의 MemberService

@BeforEach를 통해 모든 메소드들이 실행되기전 해당 코드가 실행되도록 했다.

테스트코드 메소드들이 실행될 때 마다 MemoryMemberRepository()를 생성하고 서비스를 따로 생성해주며 서비스 객체 생성때마다 memberRepository를 생성해준다.

즉 각 테스트 메소드들이 각각의 memberService와 memberRepository를 갖게된다.