정보보안 역사

• 1950년대 이전
  • 애니그마와 콜로서스
    • 처음은 평문 메시지를 암호화 메시지로 변환하는 장치로 개발되었다.
    • 은행 통신보안을 위해 개발됐지만, 2차 세계대전에서 독일군 군사통신 보안용으로 사용되었다.
    • 문자판의 키 하나를 누르면 나란히 원판 3개가 회전하며 복잡한 암호가 만들어진다.
    • 영국에서 암호를 해독하는 기계를 만들었다. → 콜로서스 (앨런 튜링이 만들었다.)
    • 종이테이프에 암호를 천공하여 천공된 암호문이 애니그마의 암호와 일치 할 때 까지 비교하는 방식으로 해독하였다.
  • 1960~70년대
    • 최초의 인터넷 ARPA
      • 1967년 미국 국방부에서 컴퓨터 연결망을 개발
      • 현재의 인터넷의 기초가 되었다.
    • 유닉스 운영체제의 개발
      • C로 개발되었다.
      • :: 운영체제는 사용자가 하드웨어를 작동 할 수 있도록 도와주는 역할이다.
      • 1969년 캔 톰프슨과 데니스가 유닉스를 개발하였다.
      • 개발자 툴 및 컴파일러에 접근하기 쉽고 여러 사용자가 동시에 사용 할 수 있다는 특성을 갖고있다. (해커 친화적)
        • 해커들은 윈도우보다는 리눅스를 사용한다.
      • 큰 데이터를 처리할때 사용된다. (안정성이 가장 좋다.)
      • 유닉스에서 파생된 것이 리눅스이다.
    • 최초의 이메일 전송
      • 1971년 레이머드 톰린슨이 개발하였다.
      • 64노드의 아르파넷에서 @(엣)를 사용한 최초의 이메일을 발송하였다.
      • 실제적으로 이메일 서비스를 자세히 들여다보면 프로토콜을 주고받는 서버가 존재한다.
    • 마이크로소프트 설립
      • 74년 MITS 회사가 세계 최초로 조립식 개인용 컴퓨터 앨테어 8800을 판매했다.
      • 앨태어 8800은 조립식으로 소프트웨어 X 토글 스위치의 불빛을 보고 결과를 해독하는 형식이다.
      • 75년 빌 게이츠는 풀 앨런과 앨테어 8800에서 동작하는 앨테어 베이직을 작성 하기로 하여 마이크로소프트를 설립했다.
    • 애플 컴퓨터의 탄생
      • 79년 애플 컴퓨터가 스티브 워즈니악과 스티브 잡스의 손에 탄생되었다.
      • 데스크톱 PC 보급과 함께 PC 통신 하드웨어를 사용하여 원격 시스템을 해킹했다.
  • 1980~90년대
    • 네트워크 해킹의 시작
      • 네트워크 해커라는 개념이 처음 탄생되었다.
      • 414 Gang ⇒ 대표적인 네트워크 해킹 사건
        • 414 Private 이라는 BBS의 일원들이 만든 해커 그룹 / 60개 컴퓨터 시스템에 침입하여 중요 파일을 삭제하였다.
      • 1981년에는 캡틴 잽 이라는 별명을 가진 이언 머피 가 AT&T의 컴퓨터 시스템에 침입하여 전화 요금을 조작하였다.
    • 정보 권리 논쟁의 시작
    • //
    • 해킹의 등장
      • 해킹이 발전하면서 역사적으로 유명한 해커들이 본격적으로 등장하였다.
        • 1987년에는 케빈 미트닉이 컴퓨터 판매 회사인 산타크루스 오퍼레이션의 시스템에 침입하였다.
        • 88년 코넬대학 대학원생이었던 로버트 모리스는 웜 바이러스 를 구동하여 미국 전역에 피해를 끼쳤다.
          • 2000년도에 우리나라도 네트웤이 마비되는 상황이 있었다.
        • 로터스 123을 개발한 미치 케이퍼와 존 발로는 정부의 임의적인 정보 검열에 저항해 전자프런티어 재단을 결성함.
          • 전자 프런티어 재단은 국제 사회에서 표현의 자유, 저작물의 자유로운 이용, 개인정보 보호, 정보 투명성을 위한 활동을 수행하였다.
      • 데프콘 해킹 대회
        • 세계 최초의 큰 규모 해킹대회
        • 1990년 라스베이거스에서 개최
        • 자신의 팀을 보호하며 상대 팀을 공격해 상대 시스템을 많이 해킹한 팀이 승리한다.
      • 해킹 도구의 개발
        • 94년 인터넷 브라우저인 넷스케이프가 개발되어 웹 정보에 대한 접근이 가능해졌다.
        • 해커들은 BBS에서 웹 사이트로 옮기고 해킹 정보와 해킹 툴을 웹에서 공개했다.
    • 2000년대 이후
      • 분산 서비스 거부 공격(DDoS)
        • 2000년 2월 이후
        • 네트워크를 스캔한 후 취약한 서버에 trojans 라는 클라이언트 프로그램을 설치하여 정해진 시간에 목표 사이트에 수많은 패킷을 전송함으로써 사이트가 다운되도록 하는 공격
      • 웜과 바이러스
        • 2000년 러브 버그 바이러스 / 87억 5000만 달러의 경제적 손실을 입혔다.
        • 2003년 1월에 마이크로소프트의 MS SQL 2000서버를 공격하는 슬래머 웜이 전국 네트워크를 마비시킨 사건이 발생했다.
        • 2004년에는 베이글 웜, 마이둠 웜, 넷스카이 웜 이라는 웜 삼총사가 등장했다.
        • 바이러스와 웜의 차이
          • 바이러스 → 파일 자체가 존재하고 사용자가 어떠한 액션을 취해야한다.
          • 웜 → 알아서 네트워크를 찾아가며 번식한다.
      • APT 공격의 등장
        • 지능형 지속 공격 → 전문적인 지식을 가지고 특정 목표를 타겟을 잡아 취약점을 찾고 길게는 몇달동안 설계를 하여 공격한다.

오늘 진행한 것들 🤔

• 리액트 공부
  • 타입스크립트로 리액트 프로젝트 진행
    • 타입 지정하는법 학습 
    • 인터페이스로 props 를 넘기는 법 학습 (파라미터로 넘기는법)
  • 테일윈드 / styled component 학습
    
    • 테일윈드가 컴포넌트 내부에 선언될시에 코드가 정신이 없어지는 것을 방지하기 위해서 스타일드 컴포넌트에 테일윈드를 적용하는법을 배웠다.
  • 커스텀 훅 응용
  • Material UI 응용
• 프로젝트 진행
  • 메인페이지 뼈대 템플릿 구성
  • 메인페이지 보드 구현
  • 커스텀 모달 구현
  • 커스텀 네비바 구현 (모바일용)
  • 반응형 템플릿 구현

오늘 겪었던 문제 🤔

• 반복문으로 리스트를 반환해주는 컴포넌트를 생성시에 타입스크립트가 타입 오류를 내뿜는 문제가 있었다.
  • 이유는 단순히 컴포넌트는 단 하나만의 영역을 반환해야 하는데 array 타입을 반환해서 생기는 문제였다.
  • <> 와 </> 로 감싸주면 오류가 발생하지 않는다.

오늘의 배운점🤔

• 커스텀 훅을 응용해보았다.
  • 검색을 해보니까 단순히 state 로 상태만 관리하게 된다면, 값이 변경될때마다 해당 컴포넌트가 리렌더링이 된다는 사실을 알게 되었다.
  • 내가 누군가..? 나는 직전까지 백엔드를 찍먹해봤던 응애 개발자.. 나에게 있어서 성능 하락은 용납되지 않는다.
  • 코드를 조금이라도 줄이고, 반복되는 핵심 로직은 밖으로 빼낼 필요가 있었다.
  • 리액트 같은 경우에는 백엔드와 비슷하게 성능을 신경써야 하는 부분이있었다.
  • 백엔드같은 경우에는 데이터베이스 접근 빈도라던가, 한번에 여러개의 데이터를 불러올때의 속도라던지.. 가 있다고 친다면, 프론트엔드는 리렌더링 되는 횟수가 성능에 영향을 끼치는것 같았다.
  • 거기에 가장 좋은 코드는 유지보수가 가능한 코드가 아니던가 ..?
  • 그래서 알아낸게 useCallback 과 커스텀훅이었다
    
    • 커스텀훅 같은 경우에는 핵심 로직을 굳이 밖에다 빼놓을 필요도 없고, 코드를 줄이고 싶고, 밖에다 주구장창 state 와 effect 를 적어둘 필요를 줄여준다.

• 리액트의 꽃은 아무래도 컴포넌트의 재사용성을 높여서 최대한 블록 끼워맞추기 처럼 이랬다 저랬다 하는데 지장이 없도록 하는게 아닐까.. 라는 생각이 든다.
• 리액트에서 제공해주는걸 백분 활용해서 컴포넌트를 만들다보면 차곡차곡 쌓여서 정말 홈페이지를 구성하기 너무 간편해진다. 제이쿼리로 주구장창 당장 확인도 ㅇ잘 안되는 코드를 작성했을때 얼마나 답답했던지.. 리액트 최고

컴포넌트와 Prop

• 컴포넌트 → 재사용 가능한 개별적인 여러 조각
  • 프론트에서 가장 중요한 능력중의 하나는 개발되어야 하는 화면을 보았을때, 이를 어떠한 조각으로 볼 수 있고 어떻게 합칠지 파악하는 능력이다.
  • 단순 카카오톡 친구창을 보더라도, 각종 아이콘이 정렬되어있는 헤더와 내 프로필이 보여지는 프로필칸, 그리고 친구 목록이 보여지기 전에 나타나있는 구분선, 그리고 친구목록이 나타나는 공간과 친구목록 이렇게 크게 5가지로 나눌 수 있다.
    • 더 세세하게 나눌수도 있을것 같다. 예를 든다면 헤더에서의 버튼이 존재하는 공간과, 타이틀이 존재하는 공간
    • 프로필에서의 이미지가 존재하는 공간과, 내 이름, 그리고 설명
    • 친구목록에서의 친구 수, 친구의 프로필 이미지, 프로필 이름, 설명
  • 하나하나의 컴포넌트는 Props라는 객체를 받아올 수 있다. → 상위 컴포넌트가 하위 컴포넌트에게 내려주는 데이터

• 친구가 적혀있는 부분을 단순 컴포넌트로 나눴을때 이렇게 코드가 작성이 되지 않을까 싶다.

<Header title="친구" />
const Header (props) => {
return <Text>{props.title}</Text>;
}

• 이런식으로 밑에 export 로 버튼이 더 붙어있는.. 이런방식으로 코드를 작성하면 렌더링이 저렇게 되지 않을까 ? 🧐

const MyProfile = (props) => {
  return <Text>{props.my_name}</Text>; 
}

• 이런식으로 props 객체를 내려줄 수 있다. 그러면 해당 객체는 어디서 데이터를 정의해줘야할까?

export default function App() {
  return (
    <View style={styles.container}>
      <Header title="헤더입니다."></Header>
      <MyProfile my_name="브린스"></MyProfile>
      <Division></Division>
      <FriendSection></FriendSection>
      <FreindList></FreindList>
    </View>
  );
}

• 이런식으로 상위 컴포넌트에서 데이터를 정의해줄 수 있다. (html 태그속 attribute 와 비슷한 느낌을 받았다. / data-id 같은)
• 컴포넌트를 만들때는 클래스형 컴포넌트, 함수형 컴포넌트 총 두가지의 방식이 있다.
  • 클래스형 컴포넌트
    • 리액트에서 class 키워드가 필요하다. (react 에서 컴포넌트를 상속받아야한다.)
    • render() 메소드가 반드시 필요하다. → 그 안에 필요한 컴포넌트들을 띄우는 방식이다.
    • 변화하는 값인 state, 생명주기인 lifeCycle 관련 기능을 사용 가능하다.
    • 함수형보다 메모리 자원을 더 사용한다.
  • 함수형 컴포넌트
    • state, lifeCycle 관련 기능을 사용할수 없어서 순수 컴포넌트라고 불린다.
      • 해당 부분을 hook으로 해결한다.
    • 클래스형보다 메모리 자원을 덜 사용하는 장점이 있다.
    • 컴포넌트 선언이 편하다. (가독성이 조금 더 좋다.)
    • 공식문서에서도 함수형 컴포넌트 + hook 사용을 권장한다.
      • 과거에는 클래스형 컴포넌트를 많이 사용했지만 , 19년도에 업데이트된 16.8버전 부터 리액트 hook을 지원해줘서 공식문서에서도 권장하고있다.

오늘 진행한 것들 🤔

• 토이프로젝트 진행
  • 랭킹 페이지 구현

• 팀 토이 프로젝트 진행 
  • 많은 오류들의 무수한 악수 요청을 받았다. 모두 수정 완료.
  • 전체 뷰를 구현했다. (템플릿은 엉망이고... 기능만 확인하는 용도로 구현한 것 같다.)

오늘 겪었던 문제 🤔

• 랭킹 페이지에서 캐릭터 이름을 검색할때 몇위인지 나오는게 아닌, 해당 캐릭터 이름을 가진 캐릭터 안에서의 랭킹이 출력되었다.
  •  해당 부분은 내림차순으로 리스트를 반환할때마다, 캐릭터의 랭킹 카운트를 같이 조회하도록 해서 순위 자체를 같이 받아와서 출력하도록 구현하였다.
  • 따라서 한번의 출력당 총 11번의 검색을 진행한다.

오늘의 배운점🤔

• 정말 api 하나 짜는데 10분 걸린다고 치면 프론트 하나에 30분정도를 소요하게 되는것 같다.
• 대충 구현하려고 해도 다른 신경써서 구현한 부분들과 조화롭지 못한 탓에. 자꾸 똑같은 실수를 반복하고있다.
• 나 자신과 타협을 해야겠다는 생각이 들었다. 앞으로도 이런식으로 프로젝트를 진행하면 내 정신과 몸은 남아나지 않을것. 곧 개발에대한 흥미가 떨어질 수 있다는 소리이다.

오늘 진행한 것들 🤔

• 토이프로젝트 진행
  • 계정 탈퇴 구현
  • 계정 모험단 정보 출력 로직 구현
  • 테스트 코드 작성
  • 계정 프로필 아이콘 설정 (모험단 캐릭터로) 구현

오늘 겪었던 문제 🤔

오늘 해결한 오류 🤔

오늘의 배운점🤔

• API는 몇개 안짰지만.. 프론트를 엄청 오래 만지고있다.. 나도 얼른 협업 하고싶다.. 🫠

내일도 화이팅!

오늘 진행한 것들 🤔

• 토이프로젝트 진행
  • Querydsl 추가
  • AOP aspect 추가
    • 유저 인증 체크 Aspect
    • 게시글/댓글 검증 체크 Aspect
    • 모험단 자동 등록 Aspect (캐릭터 조회시에)
  • 캐릭터 랭킹 테이블 로직/뷰 구현
  • 모험단 자동 등록 로직/ 모험단 랭킹 뷰 구현
  • 책임 분리 
    • 결합도 조절 (도메인별로 따로 관리할 수 있도록 분리)

오늘 해결한 오류 🤔

오늘의 배운점🤔

• 크게 배운점도 없고.. 크게 오류난것도 없는.. 아주 무난한 하루..
• 흐음...

내일도 화이팅!

오늘 진행한 것들 🤔

• 토이 팀 프로젝트
  • 예외처리 설계
  • 테스트코드 작성법 설계
  • 뷰 구현

• 토이 개인 프로젝트
  • 코드 리팩토링
  • 테스트 코드 작성
  • AOP를 활용한 중복 코드 제거 (Validation, 인증)

오늘 겪었던 문제 🤔

• AOP 인증 체크 관련 문제
  • Pointcut 을 선언하지 않고, 파라미터를 체크하지 않은 단순 security context holder 에서 authentication 객체를 가져와 체크를 하게되면, authenticationprincipal 객체가 null일때 처리를 못하고 null pointer exception 이 발생하게 되는 문제가 있었다.
    • @Before 로 args < 로 principla 객체를 가져와서 모든 메소드에 principal 객체를 (인증이 필요한 메소드) 매개변수로 넣어주고 체크를 해서 처리하도록 했다.

오늘의 배운점🤔

• • 팀 프로젝트 설계를 끝냈다.
    • 다행히 팀 프로젝트 난이도가 크게 높지 않아서 설계가 예상했던것보다 얼마 안걸렸다.
    • 오늘 내가 놀랐던건, 라이브 코딩으로 다른거를 참고하지 않고 테스트 코드에 대해서 팀원들에게 설명을 해주는데  한순간의 막힘도 없이 쭉쭉 써내려가고 있었다 ㄷㄷㄷㄷㄷ
    • 한두달전에 비하면 정말 폭풍성장했다는걸 오늘 느꼈다.
  • 스프링 AOP 를 알게 되었다.
    • 전에는 AOP 관련 강의를 들어도 이해가 전혀 가지 않았는데.. 오늘 드디어 감을 살짝 익혔다.
    • 따라서 중복되는 코드들에 적용을 시켜보았다. 전체적으로 봤을때 인증 관련 검증과 (객체가 null인지) binding validation 에서 사용할 수 있을것 같아서 적용시켜보았다.
    • 인증 관련은 before 로 메소드 호출 전에 확인을 했고, validation (binding result 타입을 이용한 에러 메세지 전송) 은 around 로 메소드 호출 도중에 체크를 하고, 문제가 없다면 계속 수행하도록 구현했다.
    • 코드가 굉장히 짧아졌다.
      • 인증 관련은 인터셉터를 이용해서 접근을 가로챌까 생각을 했지만, aop는 단순히 어노테이션 혹은 패키지명을 적어주고 정의만 해주면 클래스 두개로만 처리가 가능했지만, 인터셉터는 각 컨트롤러 별로 클래스를 따로 생성해 관리해야할것 같았다.
      • 인터셉터로 게시판까지 처리를 하고, aop를 적용시켰는데 너무 비교가 되어서 aop를 남기고 인터셉터 관련 메소드와 클래스는 제거했다.
      • aop의 편의성을 지금 알게되었다.... 지금이라도 알게되서 너무 다행이고 앞으로 코드를 작성할때 얼마나 많은 도움을 받을 수 있고, 한걸음 더 나아가 고민거리를 던져줘서 재미까지 챙겨주는 aop.. 사랑해요

오늘 진행한 것들 🤔

• 토이 팀 프로젝트 
  • 게시판 만들기 설계
    • 데이터베이스 설계
    • API 엔드포인트 설계
    • 비즈니스 로직 설계
• 개인 토이 프로젝트
  • 테스트 코드 작성과 리팩토링

오늘 겪었던 문제 🤔

오늘 해결한 오류 🤔

오늘의 배운점🤔

• 처음으로 팀 설계를 진행해보았다.
  • 확실히 같이 진행하는 인원이 있으면 재미도 두배, 안정성도 두배인것같다.
  • 내가 개인 프로젝트를 진행할때 놓칠 수 있을만한 부분을 다 챙겨가는거같다.
  • 특히 api를 설계할때, 기존의 개인 프로젝트는 단순한 틀만 만들고 꾸준한 수정을 진행했던 반면, 팀으로 진행하니 미리 여러 api들을 설계 후 진행해 크게 어려울게 없을것 같았다.
• 테스트 코드 작성
  • 테스트 코드 작성에 대해서 대해서 새로운걸 알게되었다.
    • 하나의 메소드가 하나의 책임만을 갖고있어야 한다는것.
    • 해당 부분을 인지하고 테스트 코드를 작성할때, 알아서 코드도 리팩토링을 하게 되더라.
    • 테스트코드를 매번 밀린 숙제 하듯이 작성했었는데, TDD의 필요성을 점점 느끼고있다.
    • 팀프로젝트를 계속 진행할 일이 생긴다면.. TDD 방식으로 개발을 하는게 맞을까... 라는 생각을 꾸준히 해왔는데, 맞다 라는 쪽으로 기울어지고 있는것 같다.
  • 내가 짜놓은 코드의 문제점에 대해서 또 한번 깨닳았다.
    • 하나의 책임만을 갖고있어야 하는데, 메소드가 여러개의 행동을 동시에 진행한다던지, 그러한 비즈니스 로직이 여러개 존재했다.
    • 마찬가지로 , 스프링이 여러 기능을 제공해주는데 단순히 자주 쓰는 기능만 사용하고, 다른 기능들은 찾아서 활용해볼 노력조차 하지 않고있었다.
      • 대표적으로 어드바이스, AOP, 인터셉터이다.
        • 인터셉터 같은 경우에는 매번 인증을 확인하는 절차라던지, 그걸 컨트롤러단에서 똑같은 코드를 몇번을 반복하며 처리하고있었다.
        • 정말 쓸데없는 짓이었다. 인터셉터로 단순히 메소드 하나만 띡 만들어주면 그 반복되는 몇줄 혹은 몇십줄의 코드가 깔끔하게 처리되는것이다.
        • AOP같은 경우에는 현재 프로젝트상 성능 확인이 필요한 부분 (캐릭터 상세 조회시에 한번에 10번 이상의 api를 호출함) 이라던가, 쨋든 공통적으로 처리되어야 하는 부분 (인터셉터와는 별개로)은 또 따로 메소드로 뺄 수 있지만, Util 클래스가 아닌 이상 주입을 시키기 애매한 클래스에서 동작하는 메소드가 존재할 때도 있다.
          • 이럴때 AOP를 사용하여 적절한 행동을 실행하도록 정의 하고, 어노테이션만 붙여주면 공통적으로 실행하기 때문에 관리가 편해진다.
        • 어드바이스 또한 글로벌 예외처리로 매번 꾸준히 컨트롤러에서 캐치를 해준다거나 할 필요 없이 따로 클래스 하나만 생성해 각 예외를 어떻게 잡을지만 처리한다면 문제가 해결된다.
      • 공통적으로 공통된 행동을 분리시킴에 있어서 효과적인 방안을 제시해준다.
      • 이래서 본인이 사용하는 프레임워크에 얼마나 이해도를 갖고있느냐가 결국 유지보수를 하기 쉬운 코드를 만들 수 있는 지름길이 된다.. 공부가 답이다.
      • '객체지향'은 정말 코드를 짜면 짤수록 내가 더 부족함을 느끼게 하는 단어이다.. 나태해지지말고 꾸준히 해야겠다.
    • 별개로 몇달동안 내가 코딩인지 코딩이 나인지 모를정도로 살아왔는데.. 점점 한계가 오는거같다. 이대로 가는게 맞는것일지.. 방안을 찾아봐야겠다.
  • 내일도 화이팅!