연말 여행 사진 촬영 겸 취미생활을 위해 중고로 구매한 리코 RG 3

장점은 내장 필터 기능을 사용하면 보정 없이도 꽤나 괜찮은 질감의 사진을 찍을 수 있고 부피가 작아 가볍게 사용하기 좋다

필름 사진 느낌 나는 색감은 좋은데, 그 색감을 살려 찍는 게 쉽지 않다. 아마도 내가 노출의 3요소를 컨트롤하지 못해서 인 듯?
사실 생각 없이 막 찍으면 폰카보다 못하다.

모든 사진은 보정 없이 jpeg 원본이다

한 4주간 야근 + 주말 출근으로 그동안 코테 공부했던 거 원복 됬음. 어쨌든 겨우 프로그레머스 레벨 2 시작하는 수준이라 이번 코테 합격은 꿈도 안 꾸긴 했지만, 일 하면서 공부한다는 게, 특히나 일정 관리가 어려운 이 회사에서는 참 어렵구나 다시 한번 상기하게 됐음.
어쨌거나 코테 준비로 인강 듣고 공부하는 것도 중요하지만 실전경험도 쌓여야 찐으로 집중 해야 할 코테에서 효율이 나올테니까 최대한 많이 응시해보려고 하는데, 저번 주에 카카오 코테도 출근하느라 응시조차 못해서 많이 화났었음...

1번

간단한 구현, 문제는 정말 간단했지만 역시나 실력이 모자라서 푸는데 30분 걸렸음. 10~15분 안에 풀어야 뒷 문제 푸는데 문제없었을 듯함.
어쨌거나, 이런 문제조차도 풀 수 없는 실력에서 이 정도면 발전을 했다고 봄. 물론 뒷 문제를 못 풀어서 문제.

2번

읽기엔 간단해 보였지만 역시나 실력이 부족해서...
간단한 구현 + 스택 구조 이해로 보임.
TC 1, 2, 3는 통과했는데, 4번은 통과 못했고, TC 난이도가 3 < 1 < 2 < 4 순으로 보여 순서대로 해결하며 확장하다 보니 2번에서 해결하면서 4번으로 구조 변경하기가 어려웠다고 판단됨.
문제 푸는데 1시간 반 가까이 걸렸는데, 이 문제도 한 30분 안에 해결했어야 뒷 문제 푸는데 여유 있었을 듯?

3번 / 4번

어려움;
문제 처음 읽는 순간 아 2개는 포기해야겠다고 생각했음.
4번은 트리, 완 탐으로 해결 가능해보임.
어쨌거나 언젠가는 이 정도 문제는 풀어야 하는데...

계열사 채용 사이트에서 직접 지원, 3주 만에 메일로 과제 받았음. 과제 내용은 공개된 곳에 게시하지 말라고 해서 서술하지는 못하지만, java, 네트워크에 대한 이해도가 높고 기초지식이 많이 요구되는 내용이었음. 5일 기한이 주어졌고, 재직 중인 회사 작업 일정 때문에 월요일 연차 사용하고 금요일 저녁부터 월요일까지 3일간 문제 해결하는 데 시간 썼음.

공고가 1년 차부터이고, 전체 구현 완료 여부가 합격/불합격의 기준은 아니라는 조건 때문에 쉽게 생각했는데, 생각보다 쉽지 않았음. '내가 java에 대해서 아직 잘 모르는구나'라고 느끼게 되었음. 확실히 코테보다 기술 과제가 더 어려운 듯?
제출 직전에 소스 최대한 정리 했는데, 불필요한 import랑 미사용 메소드라니 섬세하지 못했다는 생각이 들었음. 근데, 나는 System.out.println 이런 건 습관적으로 쓰지 않는데, (System.out.println 치는 것보다 logger.debug 치는 게 더 경제적이기 때문에) 혼용해서 사용했다는 의견은 좀...그렇지만 이 정도로 디테일하게 리뷰를 해줬다는 점에서 대체 이 회사는 어떤 회사인지 궁금하고, 다른 큰 테크기업이 많지만, 이 회사에서 일해보고 싶다 생각함. 아, 제일 중요한 건 기초부터 다시 공부해야 할 것 같은데, 공부할 게 너무 많아서 어디서부터 손대야 할지, 그리고 회사에서 야근이 많은데 과연 투자 투자할 수 있는적인 시간이 얼마나 확보가 될지 너무 막막하다.

1년 회고

현 회사를 1년간 재직 하면서의 회고를 하려 함. 앞으로 성장/공부/이직을 어떤 목표와 방향, 자세로 해야 할지를 목표를 세우려 보니 3년간의 과거를 되돌아볼 필요를 느꼈고, 현재 재직 중인 회사부터 첫 회사까지의 회고를 해보기로 함. 보통 회고는 연말에 하거나 프로젝트가 끝나고 하던데, 지금 나의 시점에서는 재직 회사 1년 회고부터 과거를 되짚어 볼 필요가 있다고 생각했음. 사실 이직하지 않아야 할 사유를 찾는 중인데, 이직 해야 할 사유밖에는 보이지 않음...

이전 직장의 이직 사유

• 올드한 스펙의 프로젝트 SM에 불만족(java 1.7, spring 3.대)
• 복지는 괜찮은데, "회사에 다닌다"는 것보단 "프리랜서로 일을 쳐낸다"는 느낌이었음
• 8개월 만에 협업이 뭔지 잊음
• 처음엔 열정젹이었으나, 이전 프리랜서 개발자의 코드를 수정하면서 점점 "작동만 하면 돼!"하고 작업하는 모습에서 염증을 느낌

현 직장의 선택 사유

• 규모가 크진 않아도 자사 서비스 운영업무를 함
• 시스템의 크라우드 전환 예정
• 유지보수를 한다고 해도 할 수 있는 일의 범위가 꽤 넒은 것
• 기존 시스템은 올드하지만, 신규 프로젝트가 예정 중임
• 유명 커머스 시니어들과 함께 입사 예정

회사의 업무 외적 장/단점

• 직원 휴게실에서 커피 무료, 간식이 500원 미만
• 직원 휴게실은 직원이 직접 청소해서 위생이 안 좋음
  • 사무실에서 쥐 나옴
• 직원 할인
  • 준명품 의류 브랜드 50~70% 할인가 구매 가능
• 성과금 200% 확정
  • ㅈ소기업 3년차 연봉 치고는 굉장히 많이 받는 편
• 야근 수당, 택시비 지원 없음
• 야근 식대 8천 원 -> 강남 물가로는 먹을 게 없음

이 회사에서 배운 것

• Git, GitHub, Jenkins를 실무에서 사용하긴 처음
  • PR, 코드리뷰, Jenkins 설정 등 해봄
  • 코드리뷰를 받기 위해, 리뷰어의 시간을 절약해주는 방법도 나름대로 생각해 봄.
• aws, ec2 클라우드 환경, 블루/그린 무중단 배포, auto scaling의 경험, 클라우드 환경의 얉은 경험.
• 하드 코드/중복 코드 제거/구조화, 10년 전 기술
• 기획/MD, CS 직군과의 협업, 많은 실제 사용자의 피드백
• 티몬 출신 팀장님한테 배운것
  • 모듈화, 경제적으로 개발하기 위한 고민.
  • 고민이 길어지면 조언을 구할 것, 그리고 그 조언에서 배운 것들.
  • 아직 이해하진 못하지만 시스템 아키텍쳐 적인 것들
  • TC, 개발 산출물
• nhn 출신 과장님한테 개발 외적으로 배운 게 좀 있음
  • TC, 회의록, 개발 철학 (아무래도 작은 규모의 SI, SM에서는 이런 문서와 효율성 좋은 코드보다는 작동하는 코드 결과만 만들면 되기 때문에 경험할 수 없었음)
  • 기본적이지만 작은 규모의 회사에선 배울 수 없는 사소한 것들, 근데 이제 안 계심
• 절차지향 코드 작성
  • oop, class 사용법 다 까먹을 정도
  • (반어임)
• 이전에 유지보수하던 외주 개발자들이 10년 차 이상이라 했는데, 소스 코드를 보니 아무리 연차가 쌓여도 개발을 잘하는 건 아니라는 것을 알게 되었다. 그리고 nhn 출신 과장님한테 성장을 잘하려면 개인의 노력도 중요하지만, 업무 환경도 중요하다는 가르침(?)을 받았다.
• 일 잘하는 시니어가 되기 위해서는 개발도 잘 알아야 하지만 회사, 사업, 생태계, 흐름 이런 것에 관심도 갖고 알아야 한다는 걸 느꼈다.

1년동안 한 일

페이징 처리

처음 소스 받고 한 일은 이벤트 페이지의 하단의 상품 목록 페이징 처리하는 업무였다. 세상에 상품 목록을 가져오는데 페이징 처리가 안 돼 있다니.. 이때 삽질을 많이 했는데 원인은 당연히 페이징 처리가 어려운 게 아니라, 처음 보는 프로젝트 구조였다. 도메인별로 MVC 패턴의 구조화를 해두는 게 정석이라면, 이 회사의 소스는 기능별로 비지니스 로직이 FE, controller, service, SQL, db function에 파편화되어있었다. ORM을 MyBatis를 사용하는데, DAO를 한곳에서 query id, hash map으로 받아 사용하는 방식은 처음 봤는데, DAO에서 반환하는 객체는 쿼리 결과가 single row인지 multi row인지 단일 컬럼인지 구분도 안 되었다. 따로 변환하는 메소드가 있었고, 심지어 DB insert 후 PK를 가져오는 것도 불가능했다. 2 ~ 3일이면 가능해야 할 페이징 처리하는데 구조 문제로 7일 정도 걸렸던 것 같다. 아 물론 소스 파악할 시간도 없이 작업을 했으니 공수가 오래 걸릴 수밖에 없기도 했지만.

불필요한 로그

나는 과거의 내 자신이 로그 성애자인 줄 알았음. 근데 여기 소스를 보고 그 생각이 달라짐. FE에서 console.log 수십 줄은 물론이고 BE에서 System.out으로 생성한 로그는 페이지 한번 이동하는데 300~500줄씩 됐었음. File IO로 리소스를 잡아먹는 구구절절한 로그는 성능 저하의 원인이었고, 트래픽이 몰리는 시간이면 서버 응답이 15초 이상 걸리는 기능도 있었다. 이런 상태를 보기 힘들어서 log4j를 적극 활용, 지금은 로컬이나 개발 서버에서 필요한 로그만 남기고 운영 서버에선 결제 관련 통신 로그를 제외하고는 아무것도 출력되지 않는다. 그리고 지금은 디버거 모드를 적극 활용중.

그 외

쓰다보니 시간이 너무 오래 걸린다, 아래 기능들도 기억이 흐려지기 전에, 시간 나면 상세하게 서술 해 보자.

• 이벤트 기능 구조화
• AWS 전환
  • redis session
  • 파일 시스템의 S3 API 전환
• 수기 업무 기능 추가
  • 월 정산
  • 고객 데이터 추출
• SVN -> GIT 전환
• 마켓팅 설문조사 기능
• 오프라인 매장 방문 고객 온라인 가입시 혜택 지급 기능
• 택배사 전환
  • 기존에 CJ 택배로 하드코딩된 배송 시스템을 롯데 택배로 전환하면서 추후 다른 타 택배사 배송 기능도 추가 가능하도록 구조화
• 추가구성상품
• CJ 풀필먼트

놀랄 노에 노할 노, 충격 적인 코드 퀄리티

하드코딩이 심각한 소스는 MVC 구조를 무시하고 있었다. FE에서 데이터를 처리, 외부 시스템 API 요청을 하거나, Service/DAO/ mapper 계층을 무시하고 비지니스 로직이 controller나 SQL, DB function으로 처리하는 로직이 많았다.
심지어 jsp안에서 jstl이나 el 문법을 사용하지 않고 절차지향으로 짜인 java 코드는 간단한 UI를 수정하는 데 걸림돌이 되어 공수가 배가 되는 경우도 있었다.
그리고 OOP를 전혀 사용하지 않는 소스는 controller에서 request parameter를 String Array로 받고, SQL 결과를 Map으로 받아서 처리하는 방식이였다. 처리 못 할 것은 없지만, 작업하는데 신경써야 할 것도 많고 소요 시간이 물리적으로 오래 걸리 수밖에 없는 구조였다. 일부 기능은 class를 쓰도록 수정을 했지만 10년 가까이 이런 방식으로 유지보수 된 소스는 OOP로의 수정이 무색했고, 이런 낮은 퀄리티의 소스는 시간이 지나 익숙해지기는커녕 마주하면 피가 거꾸로 솟는 게 뭔지 실제로 경험하게 해줬다.
그 외에도 사용하지 않거나 중복되는 쿼리/메소드/클래스/jsp, 메소드 명이나 주석과 실제 기능이 다른 경우도 많았다. 이런 중복 되는 코드는 또 에디터로 일괄 수정을 할 수 없도록 변수명이 다르거나 일부 조건만 다른, 사람이 손으로 수정할 수밖에 없는 소스다. 정말 고난이도 고난이라고 느꼈음.

이건 내 사정이고요

사실 낮은 퀄리티에서 오는 기술 부채는 개발팀이 감당해야 할 일이고, 협업 관계의 기획, MD, 마케팅 직무의 사람들은 알바가 아니였다. 당장 매출을 올려야 하는 이 사람들은 우선순위를 무시하고 급하게 요청하는 일이 많았고, 당장 퇴근 직전에 데이터를 뽑아 달라고 한다든지, 배포 직전에 기능이나 문구를 수정해 달라는 등의 요청은 작업의 흐름을 끊었고 어디까지 작업했는지 잊는 일도 비일비재했다. 이런 사정 속에서 MD 팀장은 개발팀에서 나오는 실수나 기술 부채를 해결하느라 늦어지는 일정을 정말 좋아했는데, 그 이유는 나도 모르겠다. 아니, 알고 싶지도 않다.

이직 결심

이유는 여러 가지가 있지만 가장 큰 이유는 성장에 대한 욕심이 크다. 그렇다면 성장할 수 없다고 느낀 이유를 고민해봤다.

middle, senior의 부재

개발팀의 인원은 총 4명으로 CTO 역할을 하는 팀장님, 프리랜서로 기존 시스템을 유지보수하다 정규직 입사하게 된 차장님, 신규 프로젝트의 빌드를 목적으로 이직한 과장님, 그리고 나 이렇게 구성됐었다. 신규 프로젝트는 엎어지다시피 해서 과장님은 저번달 말에 이직했고, 팀장님은 이번달 말에 퇴사 의사를 표했다. 차장님께도 분명 배울 건 있지만, 사실상 로직 적이나 아키텍쳐적인 도움보다는 SQL적 도움을 받을 수 있는 분이다. 같이 고민해주거나 조언을 구할 사람이 한 명 밖에 없다는 건 내가 잘못된 방향으로 가더라도 잡아줄 수 없는 환경이라고 생각했다.

퀄리티

프로젝트를 구성하는 파일 중 아무거나 열어도 3~4000줄은 기본이였다. 10년 가까이 SI/SM으로 개발된 소스는 퀄리티를 전혀 신경 쓰지 않고 개발되었다. 당연하게도 외주 개발자들은 퀄리티보다 기능 구현이 최우선이였고, JAVA 코드를 적극적으로 사용한 JSP 파일은 물론이고, MVC 패턴이 무색하게 비지니스 로직은 JSP, Controller, SQL에 퍼져있었다. Java를 쓰면서 OOP를 무시한 소스는 소스 파악이 힘들고 유지보수도 쉽지 않았다. 심지어 SQL로 처리하는 로직이 많아 동시 접속자 수가 많아지면 DB 서버의 CPU 점유율이 90%를 쳤고, 언제 터질지 모르는 시한폭탄은 java 소스로 변환하기도 쉽지 않았다. 레거시 개선이 실력 향상에 도움이 된다고 하지만, 혼자 작업 해야 할 범위가 너무 많고, 개편 하기 전에 신규 프로젝트가 인수인계가 더 빠를 것이기 때분에 의미가 없어 보임.

깊이와 효율성

내가 할 일의 범위가 넓은 것이 장점일 줄 알았지만, 상품, 결제, 이벤트, 정산, 회원의 도메인들과 UX, UI, 자사의 비즈니스에 대한 이해보다는 간단한 수정이지만, 반복된 소스로 간단한 노가다만 하는 경우가 많았다. 물론 이런 문제도 보이는 데로 어느 정도 구조화를 했지만 워낙 중복 소스가 많다 보니 깊이 없는 개선 작업의 끝은 보이지 않았다.
그리고 소스의 퀄리티가 낮다 보니 파악도 쉽지 않고 퀄리티를 높이기도 쉽지 않았다. 간단한 기능 하나를 수정하려 해도 FE, controller, service, SQL, db function까지 수정해야 하는게 천지. 멘틀까지 구조를 바꿔야 하는 소스는 오히려 내가 버그를 더 만드는 게 아닌가 싶은 생각밖에는 안들었고, 반복되는 소스가 10개가 넘어가게 되면 내가 뭘 수정하고 있었는지도 헷갈려서 작업 효율성 또한 많이 떨어졌다. 소스의 효율성과 개발적 깊이를 올리기에 쉽지 않을뿐더러 내 시간을 투자해서(야근, 주말 특근) 퀄리티를 올린다고 해서 겨우 3년 차가 혼자 고민한 게 과연 나이스한 방법일지, 내 성장에 도움이 될지 모르겠다.

기술 스택

신규 프로젝트를 기대하고 이직해 왔지만 1년 동안이 지나면서 바뀐 상황을 보니 신규 프로젝트에 내가 개발자로 기여하지 않게 될 것으로 사실상 확정이다. 신규 프로젝트는 외주 개발이 확정되었고, 개발팀의 역할은 사실상 현 시스템 유지보수, 신규 프로젝트 완성 시 인수인계 및 유지보수 전환의 방향으로 된 것. 거버넌스를 나눠 내부 개발을 하기엔 개발팀에 사람도 없고, 채용공고를 내도 지원하는 사람이 없다.
그리고 신규 프로젝트 개발이 외주로 완성돼서 인수인계하는 시기를 예상하면 적어도 1년, 사실 그 이상을 예상하는데, 그동안 java 1.7에 spring 3.1, mybatis 프로젝트를 유지보수하면 5년 차가 되도록 트렌디한 기술은 접할 수 없을 것이고 빅테크까진 아니더라고 더 큰 기업으로의 이직의 하는데 필요한 경험은 못 할 것이라고 생각된다.
다양한 기술 스택을 원하는 요즘 공고는 물론 모든 기술을 원하는 것은 아니겠지만 jpa, redis, spring boot, java 1.8 이상 정도는 경험해야한다고 생각한다. 지금 프로젝트 스펙으로는 아무것도 경험할 수 없고, 개인 프로젝트를 진행해서 공부한다고 해도 회사에서 요구하는 것은 실무 경험이기 때문에 도태되고 있다는 느낌이 강하다.

오히려 내가 해볼 수 있는게 많으니 성장의 기회다??

오히려 문제가 많고, 고칠 게 많은데다 혼자 손대야 할 도메인이 많기 때문에 내 성장에 도움이 된다는 의견이 있는데 짧은 식견과 현실적 상황을 보면 동의가 잘 안된다. 어차피 신규 프로젝트를 하는데 굳이 내가 시스템을 구조를 파악하고, 개선한다? 이미 많은 기능이 비효율적으로 개발되었는데 하나하나 개선한다고 그 노력이 UX와 매출에 긍정적 영향을 미친다? 신규 프로젝트 끝나기 전에 그 성과가 크게 눈에 띌지 의문이다.

남은 한해 계획

암튼 잘하는 사람들이랑 일하는 회사로 이직하고 싶다 보니 나도 잘해야 하는데, 암튼 쉽지 않음. 당장 큰 기업으로 이직은 어려울 것 같으니 꾸준히 공부해야 함. 꾸준한 공부는 실패하지 않을 것이라 믿고 있음. 욕심이 많으면 해야지 어쩌겠어?
근 몇 개월간 공부해야 할 것들이 정~~말 많다고 느꼈다. 프로그래밍 언어나 프레임웤(당장 실무에서 쓰는), 웹 관련 기술, CS, 인프라, 포트폴리오 등등.. 하나의 주제를 파기보다는 여러 분야를 두루두루 기반을 쌓아야겠다 싶음. 특별한 일정의 변수가 없다면, 야근 + 출퇴근 이동시간 하면 하루에 3시간 정도의 공부할 시간이 확보되는 데 어쨌든 시간을 잘 쪼개서 이직 + 기반 공부를 하겠다고 다짐했다. 중고등학교, 편입해서 방통대 다닐 때보다 더 공부 많이 하는 듯...

• 자소서 재정리 (9월 말 예상)
• 10월까지 프로그래머스 코테 레벨 2 풀기
  • 11월부터 레벨 3 시작
• 12월 까지 jpa 학습 -> 포폴 준비
• CS -> 간간히 블롣그 올리며 얉게라도 공부하기
• 3개월에 한번 회고하기
• 다 중요하지만 건강은 꼭 챙겨야 함. 주에 3일 런닝 꼭 하기..!

HTML form의 입력값 JSON 객체로 변환시키기

    const formToJSON = (elements) => [].reduce.call(elements, (data, element) => {
            data[element.name] = element.value;
            return data;
        },
        {}
    );

    let form = formToJSON(document.querySelector('#event01Form'))
    console.log(form, '\n', JSON.stringify(form));

배열 (Array)

• 데이터를 나열하고, 각 데이터를 인덱스에 대응하도록 구성한 데이터 구조
• 각 원소의 물리적인 위치(메모리 주소)의 순서가 배열의 인덱스 순서(논리적인 순서)와 일치

배열이 필요한 이유

• 같은 종류의 데이터를 효율적으로 관리하기 위해 사용
• 같은 종류의 데이터를 순차적으로 저장

장단점

• 장점
  • 빠른 데이터 접근
• 단점
  • 추가/삭제가 쉽지 않음
  • 최대 길이를 미리 지정해야 함

객체지향 → 역할, 책임, 협력을 투영하는 새로운 세계

토끼책에서 객체지향에 대해 가장 중요하게 여기는 개념은 오브젝트 사이의 메세지가 핵임이며 모든건 메세지 위주로 돌아가야한다는 점이다. 메세지가 곧 역할을 만들고 책임을 만들며 협력의 접점을 만들기 때문이다.

각 오브젝트는 결국 자기만의 역할, 책임을 분명하게 가지게끔 만들어야 하며, 협력을 하려 할때 오브젝트 A는 오브젝트 B의 역할, 책임 내부를 들여다보는(OOP의 패러다임을 깨버리는)순간 의존성이 강하게 걸리며 OOP의 사상과 멀어지게 된다. 오로지 내 입장에서 '무언가'를 하려한다는 메세지를 전파하는 것, 그 자체로 끝나야하며, 그게 좋은 구조의 OOP이고, 디커플링 된다.

현재 재직중인 회사의 개발 소스들은 역할과 책임, 협력 없이 한 프로세스에서 모든 역할을 하며 그러다 보니 파편화된 소스가 너무나도 많다. 그리고 그런 파편화로 인해 유지보수성에 어려움을 겪고, 많은 버그에 개발팀은 물론 운영 MD팀, CS팀, 배송팀까지 업무에 어려움을 겪고 있다. 이런 문제로 업무의 효율과 공수에 비효율이 생기고, 사용자들은 좋지 않은 사용 경험을 넘어 불쾌감을 느끼는 일도 허다하다.

소스 수정이 있을 때마다 개선을 한다고 해보지만 2014년부터 유지되오던 시스템의 방대함과 기한이라는 두개의 큰 벽앞에서 쉽지 않다. 그렇지만 당장의 시간 비용이 더 들어서 추후 비용을 덜 들일 수 있다면 어떤게 더 이득인지 생각해 볼 필요가 있다고 생각한다.

이 책을 읽고 역할, 책임, 협력을 나눠 잘 짜여진 구조의 시스템에 대한 목마름이 생겼다. OOP의 철학이 잘 녹아든 소스 위에서 일 하고싶다.

네트워크 보안을 강화시키는 방법으로 암호 기법, 디지털 서명, 웹 보안 프로토콜, 방화벽, 프록시 서버 등을 알아봄

주요 용어

• 암호화 :
  누구나 읽을 수 있는 평문을 제 3자가 읽을 수 없는 형태인 암호문으로 변환하는 과정
• 복호화 :
  암호문을 평문으로 변화하는 과정
• 대치암호 :
  평문의 각 글자를 다른 글자로 대치하여 암호문을 만드는 방식
• 전치암호 :
  평문의 글자를 재배열하는 방식으로 문자의 위치를 바꿔서 암호문을 만드는 방식
• 스트림 암호화 :
  평문과 같은 길이의 키 스트림을 생성하여 평문과 키를 비트 단위로 합하여 암호문을 만드는 방식
• 블록 암호화 :
  평문을 일정한 길이의 단위(block)로 나눈 뒤, 각 블록 단위로 암호화 과정을 수행하여 암호문을 얻는 방법
• 대칭 키 암호화 :
  암호화에서 사용하는 암호화와 키와 복호화에 사용하는 복호화 키가 서로 같음 암호화 방식
• 공개 키 암호화 :
  암호화에 사용하는 암호화 키와 복호화에 사용하는 복호화 키가 서로 다른 암호화 방식.
  암호화 키는 일반인에게 공개하는 공개키이고 복호화 키는 개인이 공개하지 않는 비밀 키임
• 공개 키 기반 구조 (Public Key Infrastructure; PKI) :
  일반 사람들이 공개 키 암호화 기법을 믿고 사용할 수 있도록 공개 키 인증서를 발행하고
  그에 대한 접근을 제공하는 인증서 관리 기반 구조
• 방화벽 (firewall) :
  네트워크와 네트워크 사이에서 패킷을 검사하여 조건에 맞는 패킷만을 통과시키는 소프트웨어나 하드웨어를 총칭
• 프록시 서버(proxy server) :
  내부 네트워크에 접속되어 있는 클라이언트를 대신하여 외부 네트워크에 접속하여 클라이언트가 요청한 통신 서비스를 제공하는 서버

암호 기법

암호 기법의 개요

• 암호화 (Encryption) :
  누구나 읽을 수 있는 평문(plaintext)을 제 3자가 읽을 수 없는 형태인 암호문(chipertext)으로 변환하는 과정
• 복호화 (decryption) :
  암호문을 평문으로 변환하는 과정
• 키 (key) :
  암호화 키, 복호화 키
  과정 : 평문 -> 암호화(암호화 키) -> 암호문 -> 복호화(복호화 키) -> 평문

암호화의 주요 기능

• 전달 과정의 기밀성 보장
• 정보의 무결성 보장
• 송신자와 수신자의 정당성 보장
• 네트워크 보안의 5가지 요구사항
  • 데이터의 기밀성 보장
  • 데이터의 무결성 보장
  • 정당성 보장 : 실체 인증, 데이터 인증, 부인 방지

암호화 기술

암호화 기술 - 분류

• 동작 형태 :
  대치 암호, 전치 암호, 혼합 암호, 대수화 암호
• 평문의 처리 방법 :
  스트림 암호화, 블록 암호화
• 암호화 키 :
  대칭 키 암호화, 공개 키 암호화

동작 형태

• 대치 암호 (치환 암호; substitution cipher)
  • 메세지의 각 글자를 다른 글자로 대치하는 방식
  • 예 : Caesar 암호
• 전치 암호 (전위 암호; transposition cipher)
  • 평문의 글자를 재배열하는 방식 (문자의 위치를 바꿔 암호문을 작성)

    • 

    • 

• 혼합 암호 (product cipher)
  • 대치와 전치 두 방법 모두 사용하는 방식
  • 예 : LUCIFER, ENIGMA, ABFGVX, DES 등
• 대수적 암호 (algebraic cipher)
  • 각 글자를 숫자로 바꾸어 수학적으로 처리하는 방식
  • 예 : 순환잉여검사 (CRC), Vernam 암호 방식

평문 처리 방법

• 스트림 암호화 (stream cipher [state cipher] encryption)
  • 평문과 같은 길이의 키 스트림을 생성, 평문과 키를 비트 단위로 합하여 암호문을 얻는 방법
  • 평문을 한 번에 한 비트씩, radom하게 생성되는 키 스트림과 XOR 연산으로 합하여 전송함
• 블록 암호화 (block cipher [state cipher] encryption)
  • 평문을 일정한 길이의 단위(block)으로 나눈 뒤, 각 블록 단위로 암호화 과정을 수행하여 암호문을 얻는 방법
  • 예 : LUCIFER, DES
  • 비교

암호화 키

• 대칭 키 암호화 (symmetric key encryption)
  • 암호화 키 = 복호화 키
  • 유사어 :
    • 공통 키 (common key) 암호화
    • 비밀 키 (secret key) 암호화
    • 관용 암호화 (conventional encryption)

  • 

  • 장점 :
    • 구현이 용이
    • 실행 속도가 빠름
  • 단점 :
    • 키 분배 및 관리가 어려움
    • 인증과 송수신 부인 방지가 보장되지 않음
  • 에 : RC2, RC4, RC5, IDEA, DES, Triple DES, AES
  • DES (Data Encryption Standard)
    • 대칭 키를 사용하는 블록 암호화 방식
    • IBM에서 개발한 LUCIFER의 확장된 형태,
    • 평문의 한 블록(64 비트)을 공통 키(54 비트)를 이용, 전치, 대치, XOR 연산 등을 16회 반복하여 암호문 한 블록(64 비트)을 완성함

    • 

  • AES (Advanced Encryption Standard)
• 공개 키 암호화 방식 (public key encryption)
  • RSA 암호화 알고리즘
    • 가장 대중화된 공개 키 암호화 방식
    • 2 개의 큰 소수 p, q를 구하고, 두 소수의 곱 n을 구해 사용하는데, 이 암호화 방식의 안전도는 n의 소인수 분해 난이도에 종속됨
  • 장점
    • 공통 키 암호화 방식의 키 분배 문제 해결
    • 디지털 서명 기능 (부인 봉쇄 가능)
  • 단점
    • 구현의 어려움
    • 처리 속도가 느림

키 관리

공개 키 관리

• 공개 키는 공개되므로 위/변조가 가능
• 공개 키 인증서 (certificate)
  • 공개 키를 인증하는 전자적 증명문서
  • 인증 만기일, 인증서 발급기관 이름, 일련번호, 인증서 발급 기관의 디지털 서명
  • 인증서의 형식은 ITU-T X.509 표준에 따름

공개 키 기반 구조

• Public Key Infrastructure (PKI) :
  공개 키 인증서를 발급하고 사용할 수 있는 인증서 관리 구조
• 인증기관 (Certificate Authority; CA) :
  일반인에게 개인 키와 공개 키를 부여하고,
  인증서를 통해 상대방의 공개 키를 제공하는 서비스 기관
• 인증서 :
  • 기재된 통신 객체 (개인, 기관, 컴퓨터)의 신분 보증
  • 인증기관의 디지털 서명이 포함되어 인증기관의 개인 키 없이는 위/변조 불가능

디지털 서명 (digital signature)

디지털 서명의 개요

• 공개 키 암호화 방식에서의 메세지 암호화는
  개인 키를 이용한 메세지 작성자만이 할 수 있으므로
  이를 이용하여 메세지릐 작성자 본인을 알리는 서명을 작성함
• 서명 알고리즘 및 증명 알고리즘

• 

• 

디지털 서명의 유효성

• 디지털 서명의 유효성을 위한 5가지 조건
  1. 서명자 인증 (user authentication) :
     디지털 서명의 서명자를 불특정 다수의 사람들이 검증할 수 있어야 함
  2. 부인 불가 (non-repudiation) :
     서명자는 서명 이후 서명 사실을 부인할 수 없어야 함
  3. 변경 불가 (unalterable) :
     서명한 문서의 내용은 변경할 수 없어야 함
  4. 재사용 불가 (not reusable) :
     어느 한 전자문서의 디지털 서명을 다른 전자문서의 디지털 서명으로 사용할 수 없어야 함
  5. 위조 불가 (unforgeable) :
     적법적인 서명자만이 디지털 서명을 할 수 있어야 함

웹 보안 프로토콜

웹 보안 프로토콜 분류

• 응용계층 프로토콜
  • 이메일 보안 : PGP, PEM, S/MIME
  • HTTP 보안 : S-HTTP; Secure HTTP
  • 원격 로그인 보안 : SSH; Secure Shell
• 전송계층 프로토콜
  • SSL; Secure Socket Layer
  • TLS; Transport Layer Security
• 네트워크계층 프로토콜
  • IPSec; Internet Protocol Security

응용계층 웹 보안 프로토콜 - 이메일 보안

1. PGP; Pretty Good Privacy
   • 공개 키 암호화 방식 사용
   • 기능
     • 기밀성 : 제 3자는 이메일 내용을 볼 수 없음
     • 메세지 인증 : 메세지가 위/변조 되지 않았음을 인증
     • 사용자 인증 : 이메일의 발신자가 누구인지 확인
     • 송신자 부인 방지 : 이메일 발송 부인의 방지
2. PEM; Privacy Enhanced Mail
   • IETF (Internet Engineering Task Force)에서 표준으로 제정한 공개 키 암호화 방식의 이메일 보안 방식
   • 표준으로 제정되었으나 실제로 활용되지 못함
3. S/MIME (Secure/Multipurpose Internet Mail Extension)
   • MIME으로 캡슐화 된 이메일에 대해 공개 키 암호와 디지털 서명을 제공해주는 이메일 보안 표준 프로토콜
   • 공개 키 암호화 방식, RSA 암호 방식을 이용

전송계층 웹 보안 프로토콜 - SSL

• Secure Socket Layer
• 웹 페이지 보안 프로그램으로 대부분의 웹 브라우져가 지원해 줌
• Netscape Communication사에서 개발한 de facto standard
• http 외에도 ftp, SMTP, Telnet 등의 응용에도 적용 가능
• SSL이 적용된 웹 페이지의 URL은 https로 시작되며 보안 포느 443을 사용

• 

전송계층 웹 보안 프로토콜 - TLS

• Transport Layer Security
• SSL을 계승한 전송 계층의 보안 프로토콜
• TLS의 상위 계층의 응용 프로토콜과는 독립적이기 때문에 어떤 응용 프로그램도 TLS를 이용하여 안전한 통신 가능

네트워크계층 웹 보안 프로토콜 - IPSec

• IPSec (Internet Protocol Security)
• IP 게층 (네트워크 계층)에서 동작하는 보안 프로토콜
  • Authentication Header; AH : 송신자의 인증
  • Encapsulation Security Payload; ESP : 송신자의 인증과 데이터 암호화
• IP 계층에서의 데이터 기밀성, 데이터 무결성, 데이터 인증 등의 보안 서비스 제공

방화벽과 프록시 서버

방화벽의 개요

네트워크와 네트워크 사이에서 패킷을 검사하여 조건에 맞는 패킷만을 통과시키는 (packet filtering) S/W, H/W를 총칭

방화벽의 종류

• 배스천 호스트; bastion host

  • 

• 스크리닝 라우터; screening router

  • 

• 이중 홈 게이트웨이; dual-homed gateway
  • 2개 이상의 네트워크에 동시에 접속된 Bation host

  • 

• 스크린 호스트 게이트웨이; screened host gateway
  • 스크리닝 라우터와 스크린 호스트(bation host, dual-homed gateway)를 혼합한 형태의 방화벽

  • 

• 스크린 서브넷; screened subnet
  • 외부 네트워크와 내부 네트워크 사이에 DMZ 역할을 하는 완충 지역 개념의 서브넷

  • 

프록시 서버의 개요

• 내부 네트워크게 있는 Client를 대신하여 인터넷에 접속하고
  Client가 요청한 통신 서비스를 Client가 요청한 통신 서비스를 다시 Client에게 제공해 주는 서버
• 동작 절차
  1. Proxy server는 client의 요청에 따라 외부 서버에게 서비스 요청
  2. 외부 서버는 proxy server에게 요청한 서비스 전달
  3. Proxy server는 전달 받은 서비스를 client에게 전달

프록시 서버의 기능

• 안정성 :
  사용자 인증 기능, 서비스 이용 제한 등의 기능을 proxy server에 두면
  client는 일괄적 보호를 받음
• 익명성 :
  외부 서버에 접근하는 것은 proxy server이므로,
  client의 고유정보가 노출될 가능성이 감소함
• 신속성 :
  사용자가 열람한 웹 사이트의 정보를 캐시에 임시적으로 보관해 놓는데, 이를 이용하면 client가 동일한 웹 사이트에 접속하는 경우 신속하게 할 수 있음

요약

1. 암호화란 누구나 읽을 수 있는 평문을 권한이 없는 제 3자가 알아볼 수 없는 형태로 재구성하는 과정을 의미,
   암호화의 역과정으로 암호화 평문으로 복원하는 것을 복호화라고 함
2. 키의 종류에 따른 암호화 방식으로는 DES로 대표되는 대칭 키 암호화 방식과 RSA로 대표되는 공개 키 암호화 방식이 있음
3. 디지털 서병은 네트워크상에서 문서나 메세지를 송수신할 때 디지털 문서에 서명자 인증, 문서의 위/변조 방지, 송신 부인 방지 등의 기능을 제공하는 암호화 기술을 사용하여 서병하는 방법
4. 인터넷 보안을 위해 사용되는 주요 기술로는 웹 보안 프로토콜을 사용하는 방법, 방화벽을 사용하는 방법, 프록시 서버를 사용하는 방법이 있음
5. 방화벽은 네트워크와 네트워크 사이에 송/수신 되는 패킷을 검사하여 조건에 맞는 패킷들만 통과시키는 소프트웨어나 하드웨어를 총칭함
6. 프록시 서버는 내부 네트워크에 있는 클라이언트를 대신하여 인터넷에 접속, 클라이언트가 요청한 통신 서비스의 결과를 클라이언트에게 제공하는 서버임

출처 : 방송통신대 강의 자료실 정보통신망 강의록