처음 외부활동을 마치고 취업을 처음부터 준비를 하기도 전 활동했던 외부활동 단체에서 인턴쉽 프로그램 관련 공고문을 확인하게 되었다.

살면서 인턴이란 것을 한번도 경험해보지 못했던 나로써 실무경험을 해볼 수 있다는 매력적인 특징 때문에 깊게 고민해보지 않고 바로 지원해보았던 것 같다

어느곳인지는 말할 수 없으나 처음 인턴쉽 실무에 들어가기 전 교육을 받으며 같이 인턴쉽 프로그램을 진행하는 동기들과 친해지는 시간을 가지며 팀프로젝트도 진행해 보았다. 일정 기간동안 실무를 경험하게 되었다. 무엇보다 회사를 선택하는 기준이라는 것이 없던 나에게 첫 실무경험을 접해보며 원래 개발자란 이런 일은 하는 것인가..? 실 업무를 하며 항상 스스로에게 질문을 던져보았던 것 같다.

처음부터 원하는 일을 할 수 있을거란 생각(인턴 실무를 다같이 하는 줄 알았다..) 그러나 실제로는 뿔뿔이 흩어졌다.. 같이 인턴쉽 프로그래밍을 진행했던 동기들 대부분도 묶여서 흩어졌으나 특별하게 나는 혼자서 배정받게 되었다(이때부터 힘들어지기 시작했던 것 같다)

첫 출근날.. 급하게 자리를 만들어서 배정을 받게 되었고 이어서 실무 업무를 진행하기 위한 기초 도메인지식에 대한 간략한 설명을 상사분께 듣게 되었다. 처음부터 이쪽을 원해서 온 것도 아니었으며 이런 도메인이 있는지는 알았으나 실제로 내가 해보게 될줄 몰랐다.

처음부터 한번에 많은 이야기를 듣게 되어서인지 명확하게 들리지도 기억에 남지도않았던 것 같다. 이후 협력업체의 보안프로그램과 IP설정등을 진행해야했기에 첫주차 포함해서 두번째주차 절반까지는 실무에서 사용되는 기초 데이터베이스개념과 도메인관련한 개념을 핸드폰검색을통해서 계속 공부했던 것 같다..(이때 정말 시간이 안갔던 것 같다) 주변에 바쁘게 일하시는 분들이 대부분이었기에 따로 질문을 하기에도 어려웠으며 하루 질문을 두번? 정도밖에 못했던 것 같다.

이후 PC환경 세팅이 마치는대로 실무에서 사용되는 프로그램등을 설치하고 개발을 시작할 줄 알았으나 실제로 진행되었던 일은 이미짜여진 코드를 활용하는 위주의 업무였다. 개발적인 지식뿐만아니라 개발을 하기위한 프로그램관련 공부도 많이했다.. 이 프로그램을 잘 다루어야 내가 개발할 수 있기에..

물론 코드 분석을 잘 해야 하는 것도 필요했고 코드수정에 필요한 해당 개념을 알고있어야 하는것도 꼭 필요했다고 느낀다(도메인 지식, 개발 지식 등)

그러나 내가 원했던 스킬셋과는 전혀 연관되어지지 않았던것 때문인지 재미가 없었다 다만 남은 인턴기간을 끝까지 채우기 위해 최소한의 공부를 진행했던 것 같다.. (1인분은 해야겠다 라는 생각..) 그래서 욕심도 크지 않았을 뿐더러 발전시키고 싶지도 않았던 것 같다.

계속해서 기초적인 업무숙제(?) 를 받으며 생활하며 퇴근 후 직무와 관련된 많은 정보를 찾아보았던 것 같다.. 인턴쉽이 끝나고 정규직보다는 바로 다른 회사를 가야겠다 생각하게 되었다.

솔루션 개발, SI 개발, SM 등등..

그리고 한 가지 명확하게 피부로 느낄 수 있었던 것은 나는 SI쪽의 방향과 맞지 않았던 것 같다. 한 프로젝트를 위한 스킬셋과 도메인지식 등을 공부할 수 있었고 다음 프로젝트도 연계해서 진행한다면 물론 이어서 공부할 수 있겠으나 기본적으로 협력업체와의 갑 을 관계에 따라 필요기능만 따라서 구현하게 되고 그 기능마저도 특별하게 확장성과 유지보수등을 고려해서 개발되는것이 아닌 프로젝트의 기간에 급급하게 개발되는 것이 대부분이었다.(확실히 내가 원하는 스킬셋으로 성장할 수 있는 환경이 아니라는것 하나는 명확했다)

그러면서 지금까지 클린코드는 어떻게 작성해야하는지.. 확장성있는 코드를 작성하는 방식은 무엇인지.. 이런것을 고집해야한다는 내 생각이 많이 무너졌다.

그래서 이 글을 읽는 사람들에게 한 가지 말해주고싶었던 것은 회사의 이름만 보고도 물론 취업을 준비할 수 있으나 직무에 대한 정보를 많이 찾아보고 지원하길 바란다. ( 특히 회사가 어느 방식의 개발을 진행하는지도 중요한 것 같다 )

그리고 내가느낀 첫 인턴이었기 때문에 확실히 한 부분만 보고 전체를 판단할 수는 없다고 생각한다.

다른 SI회사는 또 다를지도 모르고 성장할 수도 있다. 얻어가는 건 분명히 있다고 생각한다. 그것이 내가 원하는 것일지 원하지않는 것일지 이것은 잘 모르겠으나..

새로운 지식을 많이 배우며 프로젝트위주의 개발을 진행해야하기에 마감기한 안에 코드를 빠르게 개발할 수 있는 능력자분들은 조금더 이쪽분야와 맞을 수도 있겠다 생각한다.

인턴쉽프로그램을 통해 직무에 관한 많은 정보를 찾아보게 된 계기가 있었던 것 같고 현재는 스타트업과 중견기업 면접을 기다리고 있다. 이후 9월 말쯤에 다시한번 이 카테고리에 글을 남길 수 있을 것같다.

문서 객체 모델(DOM)

DOM의 개념

• 문서 객체 모델 (DOM : Document Object Model) 은 XML, HTML 문서의 각 항목을 계층적으로 표현해 생성, 변형, 삭제 를 할 수 있도록 돕는 인터페이스이다.
• 쉽게말해 웹 브라우저에서 HTML문서의 요소를 제어하기위해 생겨났으며, DOM은 동적으로 문서의 내용, 구조, 스타일에 접근할 수 있다.
• 브라우저 사이에 DOM 구현이 호환되지 않음에 따라 W3C에서 DOM의 표준 규격을 작성하게 되었다.
• DOM의 역사는 1990년 초반 넷스케이프와 마이크로 소프트사의 IE사이에서 브라우저 전쟁과 밀접한 관련이 있다. 이 전쟁 중 최전선에 있던것이 웹 브라우저의 레이아웃 엔진으로 사용했던 JavaScript, JScript였고 이 스크립트 엔진이 DOM을 주 API로 사용했던 것이다.

DOM은 W3C의 표준이며 W3C의 표준화한 API들의 기반이 된다.

DOM의 구조는 트리구조형태로 이루어지며 다음사진과 같다.

W3C DOM표준은 세 가지 모델로 구분된다.

• Core DOM : 모든 문서 타입을 위한 DOM 모델
• HTML DOM : HTML문서를 위한 DOM 모델
• • HTML DOM은 HTML문서를 조작하고 접근하는 표준화된 방법을 정의합니다. 모든 HTML요소는 HTML DOM을 통해 접근할 수 있다.
• XML DOM : XML 문서를 위한 DOM 모델
• • XML DOM은 XML문서에 접근해 그 문서를 다루는 표준화된 방법을 정의하고, 모든 XML요소는 XML DOM을 통해 접근 가능하다.

그렇다면 웹페이지에서 이 DOM은 어떻게 사용될까?

DOM이 사용되기 전 브라우저와 서버사이에서 화면이 그려지는 과정을 먼저 확인해보자.

Critical Rendering Path(CRP)라는 개념을 먼저 알아보자.

이 CRP는 브라우저에서 서버로부터 HTML문서를 받아서 랜더링을 진행할 시 진행되며 다음과같이 6단계로 나누어져있다.

1. DOM 트리 생성
2. CSSOM 트리 생성
3. JavaScript 실행
4. Render 트리 생성
5. 레이아웃 생성
6. 페인팅

과정이 있다.

여기에서 위에 설명한 DOM트리 생성과정이 진행되고 이 DOM트리로부터 html, element, text 에 대한 노드가 생성된다.

이후 CSSOM이라는 DOM과 유사한 트리가 생성되는데 이 CSSOM은 DOM과는 다르게 구조는 비슷하지만 상속관계와 선언관계등을 상관하지않고 각 노드에 관련되어서 생성된다. CSS의 특징으로는 상속된 계단식 특성을 가지고있음으로 부분적으로 실행이 불가능하고 문서의 뒷부분에 스타일이 재정의 될 경우 의도치않게 CSS가 적용되는 문제가 발생할 수도 있다.

JavaSciprt는 파서 차단 리소스로 간주되는데 흔히 html파일을 작성 중 script영역의 태그를 선언하고 스크립트 코드를 작성하게된다. 이 sciprt부분 부터는 기존 DOM의 파싱이 차단되기때문에 항상 HTML태그에 따른 내용을 전부 작성한 후 sciprt태그와 코드를 작성해야 한다. 혹은 이 JavaScript가 파서를 차단하지 않도록 하기 위해서 async옵션을 주기도 한다.

이후 Render Tree가 만들어지는데 이 Render Tree는 위에서 파싱된 DOM, CSSOM을 조합하여 결과적으로 랜더링 될 내용을 나타내는 트리이다.

레이아웃 생성에서는 뷰포트의 크기를 설정하는 단계이고 meta태그에 설정된 뷰포트에 맞게 설정된다.

마지막으로 페인팅으로는 페이지의 가시적인 내용을 픽셀로 변환해 화면에 나타나는 작업을 진행한다.

Reference

• https://ko.wikipedia.org/wiki/%EB%AC%B8%EC%84%9C_%EA%B0%9D%EC%B2%B4_%EB%AA%A8%EB%8D%B8
• http://www.tcpschool.com/javascript/js_dom_concept
• https://wit.nts-corp.com/2019/02/14/5522
• https://m.blog.naver.com/magnking/220972680805
• https://www.joinc.co.kr/w/man/12/DOM
• https://wonism.github.io/critical-rendering-path/
• https://bitsofco.de/understanding-the-critical-rendering-path/

#include <stdio.h> // 스튜디오라는 헤더
#include <math.h> // 매스라는 헤더

int main()
{
  printf("라이브러리는 무엇일까?");
  return 0;
}

/* header file */
#include <stdio.h>

# define SIZE 1024
# define MAX_NUM 2147483647
# define MIN_NUM -2147483648

typedef struct    n_list
{
  void        *data;
  struct    n_list    *next;
}

JAVA-직렬화란?

Serializable(직렬화)

• 직렬화(Serializable)는 무엇인가?
  • 직렬화는 자바 시스템 내부에서 사용되는 객체 또는 데이터들을 외부 자바 시스템에서도 사용할 수 있도록 바이트(byte)형태로 데이터를 변환하는 기술과 바이트로 변환된 데이터를 다시 객체로 변환하는 역직렬화를 포함합니다.
  • 시스템적으로 JVM의 Runtime Data Area(Heap and Stack Area)에 상주하고 있는 객체 데이터를 바이트 형태로 변환하는 기술과 직렬화된 바이트 형태의 데이터를 객체로 변환해 JVM으로 상주시키는 형태를 말하기도 합니다.
• 그렇다면 이런 직렬화는 어떤 경우에 사용되는 것일까?
  • 생성한 객체를 가지고 파일에 저장할 때
  • 저장한 객체를 읽어올 때
  • 다른 서버에서 생성된 객체를 받을 때

즉 우리가 만든 클래스가 파일에 읽거나 쓰고, 다른 서버로 보내거나 받을 경우 반드시 이 직렬화를 이용하기 위해 Serializable interface를 implements해주어야 합니다.

public class Temp implements Serializable{
  //다음과 같은 방식으로 implements하여 사용한다.
}

이러한 Serializable interface를 구현하는 클래스들을 확인해보면 serialVersionUID라는 값이 존재합니다.

이 serialVersionUID는 필수값은 아니지만 호환 가능한 클래스는 serialVersionUID 값이 고정되어있습니다.

serialVersionUID가 선언되어 있지 않으면 클래스는 기본 해쉬값을 사용합니다.

public class HashMap<K, V> extends TempMap<K,V>
  implementes Map<K,V>, Serializable{
  private static final long serialVersionUID = 123456789L;
}

이런식으로 static final long 으로 선언하고 변수명 역시 serialVersionUID로 선언해야 자바에서 인식합니다.

이러한 UID의 값은 언제 사용될까요?

처음 Serializable의 정의쪽을 기억해봅시다. "다른 서버로 보내거나 받을 경우"어떠한 클래스를 보내고자 할 때 받는 쪽 서버에도 역시나 동일한 클래스를 가지고 있을겁니다. 그러나 새로받은 클래스와 원래 존재했던 클래스가 단순히 이름만을 가지고 자바가 같다고 파악하지 않고 위에서 설명한 이 serialVersionUID를 통해 버전을 확인하고 두 버전이 동일 할 경우에만 같은 클래스로 인식하게 됩니다. 또한 UID가 같더라도 클래스 내부 변수의 개수나 타입등이 다르다면 이 경우에도 다른 클래스라 인식합니다.

Reference

• https://velog.io/@sa1341/Java-직렬화를-하는-이유가-무엇일까
• https://devlog-wjdrbs96.tistory.com/268