코딩하는 eroke

IBK시스템 신입직원 서류전형에 합격해 필기시험을 봤다.

채용 절차는 아래와 같다. (서류-필기-1차면접-2차면접)

IBK시스템 필기시험은 JATIS (Job Ability Test of IBK System) 라고 불린다고 한다..

시험은 100문항으로 IT상식, S/W공학, 프로그래밍, 인프라 및 보안, 데이터베이스 

출제범위만 보면 ㅎㄷㄷ하지만 정보처리기사 수준으로 나오니 쫄지말자

과목별로 기억을 더듬어보자면..

1. IT 상식

별 희한한게 나온다.. 젤 충격이었던건 정보관련 포털의 URL 맞추기....

프로그래밍 언어별 특징같은 기본적인 것도 나온다.

2. 프로그래밍

자바를 전혀 못하는 전공자/비전공자여도 상관이 없다.

자바의 정석만 완독하고 가면 된다!

자료형부터 시작해서 예외처리 같은 자질구레한 부분도 다~~~ 읽고 가는걸 추천한다.

생성자를.. 좋아하는 것 같다. ㅎㅎ

3. 인프라 및 보안, DB

이 분야는 나누기 애매할 정도로 많이 출제되지도 않았다.

인프라/보안은 정처기 수준에서 출제되었고 (OSI 7계층, 보안용어 등등)

DB는 SQLD 보다 쉽게 출제된 것 같다. 정처기+기본쿼리만 숙지하면 될 듯 싶다.

2시간짜리 시험이었지만 다 푸는데 50분 정도 소요되었고 일찍 푼 사람들이 많았던걸로 기억한다.

(시간을 아주 넉넉하게 주는 편이니 긴장하지 말고 편하게 푸는 걸 추천) 

퇴실할 때 코로나키트도 받았다. 미니 손소독제와 마스크, 마스크 스트랩 등이 들어있었다. (감동)

+결과

8월에 IT직무 신입으로 코스콤 필기시험을 보러 갔었다.

시험시간은 09:30~13:30 (9시 입실) 수능 또 보는 느낌이 들정도로 길고 힘들었다..

1. 인성
일반적인 인성검사. 선택형, 직선형, 간접형으로 출제되었고
고민하지 않고 바로바로 풀어서 15분 정도 남았다.

2. 직무능력 (NCS)
주제, 문법, 자료해석, 도형, 창의수리, 물리...
시간 모자랐음.. 오답 감점 없음!

3. 논술+객관식
객관식은 30문항 정도에 논술은 4개에 소문제 3~5개씩 나왔고 필수로 풀어야하는 문제가 지정되었다.
필기시험의 가장 핵심요소로 생각된다.

(필수1) 계산단순구현

(선택 1)
디자인패턴/
운영체제 페이지교체알고리즘, 이상현상/
알고리즘 두개 비교, 함수부, 의사코드 작성

대학생 때 자료구조+알고리즘 시험보는 느낌..
어떤 유형으로 나올지 몰라 준비를 못했는데 가물가물한 기억을 더듬어가며 손코딩하다 왔다. ㅠㅠ
필수문제는 쉬웠으나 그 외 선택형 논술문제들이 난이도가 꽤 높았고 (준비를 안했다면)
IT 필기 시험 중에는 가장 개발자스러운 시험이었다.


결과는 약 한달 뒤에 나왔으며 예상대로 불합격이었다.
+ 필기 합격 후에는 영어면접도 필수라고 하니 참고하세용

Git err : ! [rejected] master -> master (fetch first) 발생 시

원격저장소와 로컬저장소를 동기화 해주면 해결된다.

git pull --rebase origin master

위 명령어로 동기화 후 push해보면 원격저장소에 잘 올라간다.

Reference

이클립스는 간혹 프로젝트를 신규생성할때 한글이 깨진다. 매번 구글링하기 귀찮아서 박제...

1) Window > Preferences > General > Workspace > Text file encoding=UTF-8

2) Window > Preferences > General > Content Types

3) Window > Preferences > Web >  Files 인코딩 확인하기 

그리고 JS나 XML 파일이 고냥 검은 문자들로만 나와서 가독성이 똥망일때는

Window > Preferences > General > Editors > File Associations

위치에서 파일 형식이 없으면 *.파일형식 추가해주고

Associated editors 에  Add를 해보면 기본적으로 Generic Text Editor 가 있으니 추가 후 Default , Apply 해주면 된다.

알록달록해진 나의 js 코드 ㅎㅎ 

끝!

문제

0~23시간 동안 시간 별로 집계된 입양 횟수 조회하기 

Solution (MySQL)

with recursive num(h) as (
    select 0 as h
    union all
    select h+1
    from num
    where h<23
)

select t1.h as HOUR, count(HOUR(t2.datetime)) as COUNT
from num as t1
left join animal_outs as t2
on t1.h=hour(t2.datetime)
group by t1.h

결과

'SQL에서 재귀는 처음 써봤당 신기,,

문제

Solution (MySQL)

SELECT id,name,p2.host_id from places as p1
inner join (
    select host_id, count(host_id) as cnt from places
    group by host_id
    having cnt>=2
)as p2
on p1.host_id=p2.host_id
order by ID

결과

JPA (Java Persistence API) 

JAVA에서 제공하는 API / 자바 어플리케이션에서 RDB를 사용하는 방식을 정의한 인터페이스 

자바 ORM 기술에 대한 표준 명세 (스프링 X)

데이터를 객체지향적으로 관리 > 개발자가 비즈니스 로직에 집중 

동작 과정

Java 애플리케이션과 JDBC 사이에서 동작

개발자가 JPA 사용 (개발자가 JDBC API 사용 X) > JPA 내부에서 JDBC API 사용 > SQL호출 > DB 통신

ORM (Object-Relation Mapping) : DB데이터 <-mapping-> Object 필드

객체-관계 매핑 = 자바 클래스와 DB 테이블을 매핑

SQL 매핑 X, SQL 자동 생성됨 (JPA, Hibernate)

필드 변경 시 JPA에 추가만 하면 됨

JPA : 자바객체-DB 매핑 위한 인터페이스 제공

JPA 구현체(인터페이스) : Hibernate, EclipsLink, DataNucleus, OpenJPA, TopLink Essentials

Spring Data JPA : 스프링에서 제공하는 JPA 프레임워크

> Spring Data JPA가 Hibernate보다 구현체 교체/ 저장소 교체 용이

SQL Mapper : SQL <- mapping -> Object 필드

SQL로 DB 조작 (Mybatis, jdbcTemplate)

필드 변경 시 모든 SQL 수정해야 함

JDBC  : Java Data Access 기술의 근간 (자바 API)

계층화 아키텍처

Reference

RPC : Remote Procedure Calls

= 다른 컴퓨터의 프로그램의 프로시저를 실행하는 프로그램을 허용하는 프로토콜

개발자가 원격 상호 작용에 대한 세부 정보를 명시적으로 코딩하지 않아도 됨

프레임워크가 자동 핸들링

클라이언트 코드에서는 직접 서버 코드의 함수를 호출하는 것처럼 보임

클라이언트 코드 언어 ≠ 서버 코드 언어 : 다른 언어로 쓰일 수 있음

gRPC = Communication 프레임워크

마이크로서비스는 여러 PL들로 만들어짐 (ex : back-end = Go, front-end = java)

이 서비스들 간의 소통 필요

마이크로서비스 간의 교환되는 메시지 수 = 엄청나게 많음 >>> 빠른 소통이 좋음

개발자는 핵심 로직구현만 집중하도록 하고 소통은 프레임워크에게 맡기기

gRPC = High-performance Open-source Feature-rich Framework

• originally developed by Google
• 지금은 Cloud Native Computing Foundation 파트 (CNCF - like 쿠버네티스)
• gRPC 메시지는 기본적으로 Protobuf (이진형식)로 인코딩 됨 > 송수신 효율적 but 사람이 못읽음

gRPC는 Protocol Buffers를 통해 클라이언트 코드와 서버 인터페이스 코드를 생성.
옵션에 따라 생성하는 언어 변경 가능
>>> 하나의 proto 파일을 사용해서 go, python, java, swift 등 다양한 언어의 서버/클라이언트 코드를 생성할 수 있음

'g'는 gPRC 릴리스마다 다름 (https://github.com/grpc/grpc/blob/master/doc/g_stands_for.md)

gRPC 작동원리

1. 클라이언트는 stub 생성 (서버랑 같은 메소드 제공)
2. stub는 gRPC 프레임워크를 호출 (내부 네트워크를 통해서 호출)
3. 클라이언트와 서버는 서로 상호작용을 위해 stubs 사용 >>> 서로의 코어 서비스 로직의 권한만 필요)

gRPC - HTTP API 비교

.proto 파일 : gRPC서비스/ 메시지 계약 정의

gRPC 한계

브라우저에서 gRPC 서비스 직접 호출 불가능

> gRPC-Web 사용 (양방향 스트리밍 불가, 서버 스트리밍 제한적)

> RESTful JSON Web API 에서 HTTP 메타데이터로 .proto 파일에 주석으로 gRPC 서비스 사용

(애플리케이션= json Web API, gRPC 둘다 지원)

Reference

유튜브 TECH SCHOOL 의 [gRPC #1~3] 강의

출처(Origin)란?

Protocol과 Host, 포트 번호(:80, :443)까지 모두 합친 것

동일 출처 정책?

서로 다른 출처의 리소스 간 상호작용을 방지하기 위해 클라이언트 측 웹 애플리케이션(웹브라우저 등)에서 적용되는 보안 정책

> 악의적인 행동 뿐 아니라 origin 간의 적법한 상호작용도 방지함 > 해결 방안 = CORS

CORS란? (교차 출처 리소스 공유)

웹 페이지 상의 제한된 리소스를 최초 자원이 서비스된 도메인 밖의 다른 도메인으로부터 요청할 수 있게 허용하는 구조

도메인/ 포트가 다른 서버의 자원을 요청하는 것 

추가 HTTP 헤더를 사용해 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제

웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행함

웹페이지는 교차 출처 이미지, 스타일시트, 스크립트, iframe, 동영상을 자유로이 임베드할 수 있음

특정 cross-domain 요청, 특히 Ajax 요청은 기본적으로 금지됨 (동일-출처 보안 정책 위배)

CORS는 교차 출처 요청을 허용하는 것이 안전한지 아닌지를 판별하기 위해 브라우저와 서버가 상호 통신하는 하나의 방법을 정의함

CORS 요청 유형

1) 단순 요청 : 바로 시작 가능

(1) 브라우저가 Origin 헤더(리소스 공유를 위한 리소스 출처를 포함)를 요청에 추가함 

(2) 대상은 http 메소드와 Origin 헤더 값을 CORS 구성의 메소드/출처 정보와 비교

(3) 일치하면 Access-Control-Allow-Origin 헤더를 응답에 포함시킴 (초기 요청의 Origin 헤더의 값 포함)

2) 실행 전 요청 : 기본 요청 진행 전에 '실행 전' 요청을 서버에 보내 권한 받아야 함 

• GET, HEAD, POST 외의 메서드 사용
• POST 메서드를 text/plain, application/x-www-form-urlencoded, multipart/form-data가 아닌 Content-Type과 함께 사용
• 커스텀 헤더를 설정. (ex: X-PINGOTHER)

(1) 브라우저가 기본 요청의 Requested Method/ Requested Headers 를 포함하는 OPTIONS 요청 보냄

(2) 대상은 리소스 허용하는 http 메소드/ 헤더값 반환

    > 실행전 요청의 메소드/헤더 중 하나라도 대상 리소스에서 허용하는 메소드/헤더 집합에 없으면 요청 실패

관련 헤더

요청 헤더

• Origin
• Access-Control-Request-Method
• Access-Control-Request-Headers

응답 헤더

• Access-Control-Allow-Origin
• Access-Control-Allow-Credentials
• Access-Control-Expose-Headers
• Access-Control-Max-Age
• Access-Control-Allow-Methods
• Access-Control-Allow-Headers

Reference

SW 아키텍처에 대한 책을 읽다가 DevOps에 대한 재밌는 칼럼이 있어 정리해봤다.

기존 개발 운영체계는 개발팀, 운영팀이 분리되어 있다.

문제점
개발팀은 애플리케이션에만 몰두
운영팀은 인프라에만 몰두

장애 발생 시 서로에게 책임 전가, 회피 !!!
>>> 강제적으로 모여야 원인 파악이 가능

배포 후 고객은 운영팀에게 개선 요구 >>> 처리는 개발팀이 가능
=파국

이 문제점들은 실제로 운영, 개발을 해본 경험상 매우 공감되는.. 사실 개발, 운영팀이 분리된 기업의 현실 그 자체다 ㅋㅋ..

대안
DevOps = 개발과 운영을 합치자!
적극 활용 기업 = Netflix
잦은 배포 가능, 배포 실패율도 감소

테스트도 개발과정의 일부로 = TDD(Test Driven Development), CI(Continuos Integration)

한 팀 내에서 개발, 테스트, 배포, 운영, 사용자 피드백 수용
>>> 개발 사이클 매우 빠름. 연속적. 연결적





Reference
조대협의 서버사이드 : 대용량 아키텍처와 성능 튜닝 (조대협)