나작코

[일상] 문과 비전공자에서 주니어 개발자가 되기까지

Sigfriede — Wed, 30 Jul 2025 01:01:56 +0900

직장 얘기 XXX

평생 문과로 살다가 개발 직군으로 전향하게 된 계기

제목에 단어가 덕지덕지 붙어있지만 딱히 틀린 말은 없다. 나는 작년 3월부터 개발자로 출근했다. 보통 백엔드라고 적긴 했지만 업무 환경 상 프론트 + 백 둘 다 하고는 있다. 회사에서는 주로 자바스크립트 + 자바 + SQL을 다룬다.

나는 초등학교 고학년~ 중학생 시기에 진로를 소설가로 정했다. 인문계 고등학교로 진학하여 당연히 문과를 골랐다. 대학교를 진학할 때에는 전공도 문예창작학과로 정했다. 다른 학과는 안중에도 없었고, 입시에서 떨어진다면 대학 진학은 포기하기로 마음먹었다.

대학생활은 즐거웠다. 주변에 재밌는 사람들이 많았다. 전공 수업은 기대했던 분위기와는 사뭇 다르기도 했지만 그럭저럭 들을만 했다. 그리고 눈 떠보니 졸업 시즌이었다. 나는 아무것도 할 줄 아는 게 없었다. 복수전공을 한 것도 아니고 학교에 다니면서 그 흔한 토익, 토플 같은 어학 시험조차 친 적 없었다. 돈은 벌어야겠는데, 뭘 해야할 지 알 수 없었다.

마침 집 주변에서 아르바이트 자리가 나서 평일 내내 8시 반부터 5시 반까지 일을 했다. 휴학을 한 적이 없으므로, 휴학한 셈치고 일을 하면서 뭘 할지 생각해보기로 했다. 문예지나 신춘문예 등단을 노리거나, 인터넷 소설을 연재하거나, 출판사 또는 신문사 또는 방송사 같은 전공과 관련된 직장을 알아보거나, 일반 사무직으로 근무하는 것 정도였다. 사실 아르바이트를 하면서 글쓰기를 병행하는 건 어렵지 않을 것 같아서 태블릿을 들고다니면서 점심 먹으면서, 퇴근 후에 썼는데 아무리 생각해도 글쓰기를 업으로 삼을 엄두가 나지 않았다.

그래서 그냥 직장을 다녀야겠다고 마음 먹었다. 취직을 준비하면서 자격증은 필요할테니 퇴근하고 무작정 컴퓨터 학원에 갔다. 학원에서는 이것저것 가르친다고 했다. 나는 컴활을 따기로 했다. 퇴근을 하고 바로 학원에 가서 한두 시간 공부하다가 스터디 카페에 갔다. 둘 다 집에서 해도 됐을 것 같은데, 그냥 그러고 싶었다. 분위기에서 주는 안도감이 좋았다.

컴활에서 실기를 공부하는데 비주얼베이직을 이용해서 간단한 코드를 짜는 게 있었다. 기껏해봐야 if문이나 switch문 정도였을 텐데 그게 참 재밌었다. 대학다닐 때 교양으로 들었던 파이썬이나 스크래치 수업(자의X 안들으면 졸업 못함...)은 듣는 게 그렇게나 고역이었는데. 나는 결국 종강할 때까지 for문 문법을 외우지 못했지만, 졸업한 뒤에야 문득 그때 생각이 났다. 처음으로 코딩이 배워보고 싶다는 욕구가 생겼다.

자격증을 딴 뒤 곧장 코딩을 가르치는 학원을 찾았다. 내 지역은 소도시여서 그런 학원은 없었고, 아무래도 인근 큰 도시로 다녀야 할 것 같았다. 대신 내일배움카드로 배울 수 있는 인터넷 학습처가 있길래 바로 수강했다. 한두 달 정도 들었던 것 같다. 입문자용이다보니 다루는 내용이 너무 적어서 좀 더 전문적인 내용으로 들어보고 싶었다. 마찬가지로 주변에서 국비지원으로 다닐만한 학원은 없었고, 인터넷으로 강의하는 부트캠프가 몇 있었다. 그중에 가장 마음에 드는 곳을 골라 수강신청을 했다.

강의 일정이 시작되기 전에 맛보기로 열어준 강의를 따라가는 것조차 머리가 어지러웠다. 학교를 다니는 내내 수포자였고, 과학 계통 선생님들은 내 얼굴을 모를 정도로 내내 잤다. 그런데 그냥 했다. 사실 주변에서는 계속 만류했었다. 누가 들으라고 협박한 거 아니고, 내가 듣고 싶어서 듣는 거고, 막상 또 듣다보니 알 듯 말 듯도 해서 계속 들었다. 시간은 자꾸만 가고 수료일은 다가오는데도 나는 아무것도 몰랐다. 자료구조가 뭐고, 알고리즘이 뭐고, 개발자짤을 보면 막 이해가 돼서 웃긴데, 내가 짤 수 있는 코드는 아무것도 없는 것도 웃겼다. 마치 대학을 졸업할 때와 비슷한 기분이어서 다시 졸업식이라도 하나 싶었다.

그래도 계속 해보고 싶었다. 이왕 시작한 거 끝은 보려고. 개발 관련한 인터넷 강의를 더 샀다. DB, 설계, 언어 관련된 책을 막 샀다. 부트캠프를 마치고(사실 제대로 된 수료도 아니었음) 반년정도 더 공부해서 포트폴리오 비슷한 무언가를 만들었다. 구직 사이트를 가리지 않고 이력서를 수십, 수백 개씩 넣고 아무데나 연락오기를 기도하면서 기다렸다. 그리고 운이 좋아서 그중 하나에 취직하게 된 것이다. 그리고 나는 취직한 지금도 아무것도 모른다. 아침마다 출근해서 레거시 코드로 범벅된 SVN과 이클립스를 보면 눈물 한번 흘려주고 일을 시작한다.

하지만 나는 작년, 재작년으로 돌아간대도 개발을 계속 하지 않을까 싶다. 우선 내 성향에는 잘 맞고 만족스럽다. 개발은 늘 고통스럽지만 해결된다면 또 그렇게 좋을 수가 없다. 그래서 문돌이 1000%였던 내가 개발자로 살게된 걸 딱히 후회한 적은 없다. 만약 전공을 살려 취직한다 하더라도 후회하지 않으리라는 보장도 없다. 저마다의 고통이 있는 법이다. 그래서 누군가 개발자 할까말까 고민한다면 나는 무조건 추천할 것 같다. 여러 가지 이유가 있겠지만 가장 큰 건 해보지 않고서는 모른다는 점이다. 개발은 사실 안 맞으면 모를 수가 없다. 적성에 안 맞는데 취직을 노린다면 빨리 다른 길을 알아보는 것도 나쁘지 않다. 이제는 무작정 배운다고 취업을 보장할 수가 없다. 특히 공부하기를 싫어한다면 절대 비추하는 직업.

취업시장이 얼어붙니 마니는 대부분의 업계가 비슷하고 정도의 차이만 있지 않나 싶다. AI의 발전이 어쩌니마니도 비슷한 맥락이라고 생각한다. AI의 발전으로 개발자의 생계가 위협받는다고 하지만 이 역시 개발자에만 해당되는 이야기는 아니다. 개발자 인력의 대부분이 대체될 정도라면 다른 직종이라고 살아남을 것 같은가. 살아남더라도 그게 몇 직군이나 될 것 같은가. 종종 강 건너 불 구경 같은 태도를 보고 있으면 그냥 우습다.

가끔씩 블로그가 생각나 들어와보는데 예전에 올려두었던 취준 근황 글이나 코딩테스트 글을 여전히 보는 사람들이 있어, 생각나는대로 작성해보았다. 아마 코딩에 입문하거나 적응하는 사람이 대부분일 것으로 보인다. 이 글을 읽는 당신이 스스로 선택한 것에 자신감을 잃지 말고, 남에게 휘둘리지 않았으면 좋겠다. 항상 좋은 결과가 있기를.

쓰다보니까 너무 길어져서 직장 이야기는 다음에나 해야겠다... 그래봐야 별건 없겠지만.

[SQL] SELECT문의 실행 순서

Sigfriede — Sun, 28 Jul 2024 18:12:57 +0900

SELECT문은 다음과 같은 순서로 작성되어야 한다.

1. SELECT
2. FROM

3. WHERE

4. GROUP BY

5. HAVING

6. ORDER BY

7. LIMIT

그러나 다음과 같은 순서로 실행된다.

1. FROM: 대상으로 하는 테이블

2. WHERE: 조건을 만족하는 행

3. GROUP BY: 대상을 기준으로 묶어 하나의 행으로 보여줌

4. HAVING: GROUP BY에서 묶어진 값들 중에서 조건을 만족하는 그룹

5. SELECT: 모든 또는 선택한 열을 조회

(SELECT 절에서 AS를 설정하므로 이를 기점으로 AS 처리된 이름 사용 가능)

6. ORDER BY: 열을 기준으로 기준에 따라 오름차순 또는 내림차순 정렬

7. LIMIT: 조회된 행 중에서 몇 번부터 몇 번까지 보여줄 것인지 설정

작성되어야 하는 순서와 실제로 동작하는 순서가 다르므로 유의해야 한다. 예를 들어 WHERE에서 조건을 걸 때 AS 처리 된 이름을 사용하고자 한다면 오류가 발생한다. SELECT가 실행되기 이전이므로 WHERE에서는 AS 처리 된 이름을 알 수 없다. 따라서 작성되는 순서와 실행되는 순서의 차이를 충분히 고려하여 SQL문을 작성해야 오류가 발생하지 않고 자신이 원하는 데이터만을 반환할 수 있다.

[일상] 문과 비전공자 백엔드 지향 개발자 취업준비 근황

Sigfriede — Wed, 19 Jun 2024 23:17:00 +0900

이런 기분은 오랜만이다. 너무 딱딱한 제목인가. 하지만 이 글의 내용을 가장 잘 표현해주는 문장이다. 몇 달째 글을 작성하지 않아서 혹시 이 사람도 포기한 게 아닐까 하는 의심이 있을까봐서 미리 선수치는 것이기도 하다. 본론부터 말하자면 나는 제법, 어쩌면 아주 잘 살고 있다. 누군가는 내 근황이 궁금하지 않을지도 모르겠지만 이 블로그의 방문자가 꾸준히 있다는 건 그만큼 개발 공부를 열심히 하는 사람들이 많다는 뜻일 듯도 해서, 문과 비전공생이 개발자 도전기를 간략하게 풀어보고자 한다.

작년 3월에 개발 온라인 학원을 다니기 시작해서 9월 말 무렵에 끝이 났다. 본격적으로 취업 시장에 뛰어든 건 올해 초부터였는데 이력서부터 자소서까지 개발괴발로 써서 지원한 수십 군데 모두 칼같이 떨어졌다. 어쩌다 면접이 한 군데 붙어서 지방에서 서울까지 왕복 네 시간, 십 만원이라는 금액을 들여서 간 곳에서는 사실 경력자를 뽑고 있다는 대답이 돌아왔다. 이력서에 다 적혀있을테니 몰라서 부른 건 아닌 것 같고 이제 생각해보면 돌려서 불합격이라는 말을 해주셨던 게 아닐까 싶은 생각이 들었다. 포트폴리오도 준비 안 했고, 첫 면접이었다보니 아이스브레이킹용 가벼운 질문에도 벌벌 떨면서 대답했으니 그럴 수밖에. 아무것도 모르는 내가 싫었다. 처음에는 그저 면접을 망쳤다는 생각에 회사를 박차고 나오면서 낯선 지하철역 입구 앞에서 눈물도 조금 보였다.

두 번째 면접은 인근 지역에서 한다는 취업 박람회에서 열린 간이 면접이었다. 처음 면접을 망쳐서였는지 이번에도 망할 것 같다는 생각이 들었다. 꽤 오랜 시간을 기다렸고, 기다리는 동안 꽤 초조했다. 막상 면접에 돌입하니 분위기가 전반적으로 나쁘지 않았다는 생각이 들어서 붙으면 어떡하지라는 생각이 들었다. 그리고 떨어졌다.

세 번째 면접도 본가에서 멀지는 않은 곳이었다. 면접 분위기는 나쁘지 않았지만 너무 형식상의 질문이 많았다. 개발은 어떤 계기로 하게 되었는지, 어떤 방식으로 공부했는지, 팀 프로젝트에서는 어떤 역할을 맡아 했는지 같은 뻔한 것들이었다. 기술 질문 같은 것들도 달달 외워 갔는데 그런 것들은 하나도 물어보시지 않아서 나한테는 별로 기대하는 게 없다는 생각이 들었다. 무난한 질문들이었으므로 대답은 잘 했지만 이번에도 불합격이라는 의미모를 확신이 있었다. 면접은 애매하게 점심시간에 걸친 시간에 진행되었는데, 면접을 보고 나와서 밥을 먹으며 면접 내용을 곱씹었다. 며칠동안 이번엔 어떤 포트폴리오를 만들어야하나 고민했는데, 갑작스레 합격 통보 문자를 받았다. 다음 주부터 출근할 수 있냐는 물음에 나는 냉큼 된다고 했고, 주말에 집을 보고 바로 계약해서 어영부영 첫 자취까지 하게 되었다.

취업을 준비하는 동안 많이 우울했지만, 생각해보면 나는 운이 좋은 편이었다. 불황임에도 취업 준비 기간이 길지도 않았고, 썰에 나올법한 이상하리만치 무례한 면접관을 만나지도 않았다. 팀원 분들도 다정해서 적응하기까지 많은 것들을 알려주고 모르는 게 있어 물어보면 친절히 답변해주는 편이다. 입사한 지는 벌써 세 달을 넘겼고, 여전히 거짓말처럼 아무것도 못하고 있다. 학원에서 배웠던 방식과는 꽤 거리가 멀어서 같은 자바 언어를 쓰고 있음에도 아직도 낯설다. 프론트도 해야해서 자바스크립트도 알아야 하고(프레임워크를 써서 많은 걸 알지는 않아도 된다), 또 학원에서는 JPA 기술을 주로 썼기 때문에 직접 쿼리짤 일이 거의 없었는데 지금 직장에서는 매일매일 쿼리 지옥에 시달리고 있다. 요즘에는 퇴근하고 나서. '초보자를 위한 SQL 200제'라는 책을 보면서 쿼리를 연습하고 있는데 쉽지 않다. 정보처리기사도 필기는 한 번에 붙었는데 실기 떨어져서 다시 준비해야 한다 히히... 앞으로는 시간 날 때 공부한 것들을 다시 적어볼까 한다. 취업하자마자 직장이 너무 바빠서 일정에 끌려다니면서 블로그 작성을 차일피일 미루다보니 벌써 네 달이나 지났다.

사실 얼마 전까지만해도 퇴사하고 싶었다. 직장에 다니기 전까지는 취업만 하면 어떤 코드든 짜주지 싶은 마음이었는데도 막상 직장 다니게 되니 코드한테 두들겨 맞는 것 같았다. 일이 고된 것보다도 개발 일이 나랑 맞는지 끊임없이 의심하고 고민하다가 결국 포기하고 그냥 개발자로 살기로 했다. 알 수 없는 버그가 발생할 때마다 한숨이 튀어나오고 머리를 부여잡지만, 그럼에도 고쳐나간 버그를 보면 그렇게 기쁠 수 없다. 하지만 다들 나와 똑같은 과정을 반복한다고 생각하면 제법 위로가 된다.

근황은 대충 이쯤 마무리하면 될 것 같다. 개인의 기억을 줄줄이 나열할 뿐인 이 글이 누군가에게 도움이 될 리는 없겠지만 약간의 공감과 위안을 이끌어낼 수 있었으면 좋겠다. 눈을 뜨면 불안하기만한 이 세상 속에서 모두가 행복해졌으면 좋겠다.

화이트박스 테스트(White Box Test)와 블랙박스 테스트(Black Box Test)

Sigfriede — Mon, 5 Feb 2024 18:00:24 +0900

화이트박스 테스트(White Box Test)란 모듈의 원시 코드를 오픈시킨 상태에서 프로시저 설계의 제어 구조를 사용하여 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법이다. 프로그램의 제어 구조에 따라 선택, 반복 등의 분기점 부분들을 수행하여 논리적 경로를 제어한다. 설계된 절차에 초점을 두며 테스트 과정의 초기에 적용된다. 모듈 안의 동작을 직접 관찰한다.

화이트박스 테스트는 절차적 설계의 논리적 복잡성을 측정하는 기초 경로 검사(Base Path Testing)와 제어 구조 검사(Control Structure Testing) 등이 있다. 제어 구조 검사는 다시 여러 가지로 나눌 수 있는데, 모듈 내 논리적 조건을 테스트하는 조건 검사(Condition Testing), 반복 구조에 초점을 맞춘 루프 검사(Loop Testing), 변수의 정의와 변수 사용의 위치에 초점을 맞춘 데이터 흐름 검사(Data Flow Testing)가 있다.

화이트박스 테스트의 검증 기준에는 소스 코드의 모든 구문이 한 번 이상 수행되도록 검증하는 문장 검증 기준(Statement Coverage), 소스 코드의 모든 조건이 True와 False인 경우가 한 번 이상 수행되도록 검증하는 분기 검증 기준(Branch Coverage), 소스 코드의 조건문에 포함된 개별 조건식의 결과가 True와 False인 경우가 한 번 이상 수행되어 검증하는 조건 검증 기준(Condition Coverage), 분기 검증 기준과 조건 검증 기준을 모두 만족하는 분기/조건 기준(Branch/Condition Coverage)이 있다.

블랙박스 테스트(Black Box Test)란 기능 테스트라고도 하며 각 기능이 완전히 작동되는 것을 입증한다. 소프트웨어 인터페이스에서 실시되며 주로 구현된 기능을 테스트한다. 부정확하거나 누락된 기능, 인터페이스 오류 등을 발견하기 위해 사용되며 테스트 과정의 후반에 적용된다.

블랙박스 테스트는 해당 입력 자료에 맞는 결과가 출력되는지 확인하는 동치 분할 검사(Equivalence Partitioning Testing), 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 경계값 분석(Boundary Value Analysis), 입력 데이터 간 관계와 출력에 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 원인-효과 그래프 검사(Cause-Effect Graphing Testing), 과거의 경험이나 확인자의 감각으로 테스트하는 오류 예측 검사(Error Guessing), 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 확인하는 비교 검사(Comparison Testing) 등이 있다.

모듈(Module)

Sigfriede — Fri, 2 Feb 2024 12:00:29 +0900

소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능을 모듈(Module) 단위로 분리한다. 모듈은 단독으로 컴파일과 재사용을 할 수 있다. 결합도(Coupling)와 응집도(Cohesion)로 모듈의 독립성을 측정할 수 있으며, 결합도는 약하고 응집도가 높으면 소프트웨어의 품질이 높다.

결합도

약함 ↕ 강함	자료 결합도 (Data Coupling)	모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도
	스탬프 결합도 (Stamp Coupling)	모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도
	제어 결합도 (Control Coupling)	어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용하여 통신하거나 제어 요소를 전달하는 결합도
	외부 결합도 (External Coupling)	어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도
	공통 결합도 (Common Coupling)	공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
	내용 결합도 (Content Coupling)	한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도

응집도

강함 ↕ 약함	기능적 응집도 (Function Cohesion)	모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
	순차적 응집도 (Sequential Cohesion)	모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도
	교환적 응집도 (Communication Cohesion)	동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도
	절차적 응집도 (Procedural Cohesion)	모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
	시간적 응집도 (Temporal Cohesion)	특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
	논리적 응집도 (Logical Cohesion)	유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도
	우연적 응집도 (Coincidental Cohesion)	모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도

[JPA] Soft Delete와 @SQLDelete

Sigfriede — Wed, 31 Jan 2024 12:00:55 +0900

데이터베이스에서 데이터를 삭제할 때 정책에 따라 Hard Delete와 Soft Delete로 나눌 수 있다. Hard Delete는 물리 삭제, Soft Delete는 논리 삭제로도 부른다. 물리 삭제는 데이터베이스 상에서 완전히 제거하는 것이고, 논리 삭제는 데이터를 남겨두되 컬럼을 별도로 만들어서 삭제 여부를 확인하는 것이다. 보통 삭제일시 컬럼의 null 여부 또는 삭제여부 컬럼의 true와 false 값을 확인한다.

논리 삭제의 경우에는 데이터를 삭제하지 않으므로 결과적으로는 특정 컬럼을 update 한다. 이때 @SQLDelete 라는 어노테이션을 유용하게 사용할 수 있다. 이 어노테이션은 데이터를 삭제하는 로직을 작성하면, 데이터를 삭제하는 대신에 미리 설정한 특정 컬럼의 값을 변경해준다. 다음과 같이 사용할 수 있다.

import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;
import java.time.LocalDateTime;
import org.hibernate.annotations.SQLDelete;
import org.hibernate.annotations.Where;

@Entity
// UPDATE 테이블명 SET 삭제여부판별컬럼명=조건 WHERE 변경할 데이터
@SQLDelete(sql = "UPDATE member SET withdrawal_status= true WHERE member_id = ?")
// clause = 삭제여부판별컬럼명=조건
@Where(clause = "withdrawal_status = true")
public class Member {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "member_id")
    private Long id;

    private boolean withdrawalStatus;
}

위 예시는 회원이 탈퇴할 때, 탈퇴 상태를 true로 갱신한다. 만약 삭제일시로 판별하고 싶다면 다음과 같이 작성할 수도 있다.

@SQLDelete(sql = "UPDATE member SET withdrawal_date = CURRENT_TIMESTAMP WHERE member_id = ?")

CURRENT_TIMESTAMP는 현재 시각을 의미한다. 이 설정은 데이터 삭제시에 탈퇴일시 컬럼을 현재 시각으로 갱신한다. 이때 탈퇴여부는 null 여부로 판별할 수 있다.

이 과정을 거치면 데이터는 논리적으로 삭제되었다. 그러나 데이터 조회 시에는 논리삭제 여부와 관계없이 모두 조회되므로 @Where 어노테이션을 이용하여 논리적으로 삭제된 데이터는 조회되지 않도록 조치를 해야한다. 다만 버전에 따라 다르게 조건을 설정할 수 있다. 위의 예시(@Where)는 deprecated 되었고 현재 Hibernate 6.3에서는 @SQLRestriction 사용을 권장한다. 변경된 형식은 다음과 같다.

@SQLRestriction("status <> 'DELETED'")

//이 어노테이션 관련 여러 테스트를 진행해봤는데, 클래스에 이 어노테이션이 붙어있으면 삭제여부 컬럼의 update문이 나가지 않고, select문만 나가는 버그가 발생하는데 혹시 이유 아시는 분 있다면 댓글 부탁드립니다,,,

//컬럼에 붙이면 update문 정상동작 하는 것으로 보입니다! 근데 soft delete한 내역까지 다 보여요 ^^... 아마 @SQLRestriction 문제같은데 이유를 잘 모르겠어요,,, 저도 버그 고치면 글 수정하도록 하겠습니다

[JPA] @CreatedDate와 @LastModifiedDate

Sigfriede — Mon, 29 Jan 2024 12:00:56 +0900

어떤 정보를 관리할 때 데이터의 생성된 날짜와 수정된 날짜를 저장해야되는 경우도 있다. 일일이 저장할 수도 있겠지만, 이 어노테이션을 이용하면 별도의 코드 없이도 자동으로 저장하게 할 수 있다. @CreatedDate는 데이터의 생성일을, @LastModifiedDate는 데이터의 마지막 수정일을 저장한다. 이 어노테이션들은 다음과 같이 사용할 수 있다.

import jakarta.persistence.Entity;
import jakarta.persistence.EntityListeners;
import java.time.LocalDateTime;
import org.springframework.data.annotation.CreatedDate;
import org.springframework.data.annotation.LastModifiedDate;
import org.springframework.data.jpa.domain.support.AuditingEntityListener;

@Entity
@EntityListeners(AuditingEntityListener.class)
public class 예시 {

    @CreatedDate
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime modifiedAt;
}

사용하려는 엔티티 클래스에 @EntityListeners(AuditingEntiryListener.class)를, 생성일과 수정일을 자동으로 저장하고자 하는 컬럼에 어노테이션을 붙이면 된다(이름은 생성일과 수정일이지만 시간까지 저장된다). 또 다음과 같은 별도의 설정이 필요하다.

import org.springframework.context.annotation.Configuration;
import org.springframework.data.jpa.repository.config.EnableJpaAuditing;

@Configuration
@EnableJpaAuditing
public class JpaAuditingConfiguration {
}

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.data.jpa.repository.config.EnableJpaAuditing;

@EnableJpaAuditing
@SpringBootApplication
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(LibraryApplication.class, args);
    }
}

둘 다 해야하는 건 아니고, 둘 중 하나 편한 것을 고르면 된다. 만약 이 설정을 빼놓으면 앞선 설정을 인식하지 못하여 값이 저장되지 않는다. 값이 null에서 갱신되지 않는 이유는 이 부분을 빠뜨려서 생긴 버그일 확률이 높다.

[네트워크] URI(uniform resource identifier)

Sigfriede — Fri, 26 Jan 2024 12:00:04 +0900

도메인(domain)이란 인터넷에 연결된 컴퓨터를 사람이 쉽게 기억하고 입력할 수 있도록 문자(영문, 한글 등)로 만든 인터넷주소를 뜻한다. 일반적으로 사람이 인터넷 프로토콜 주소(http://168.192.0.0 등)를 외우기는 어렵기 때문이다. 따라서 도메인을 이용하여 사람이 인터넷에 접근하기 쉽도록 하는데, 이에 URI(uniform resource identifier)가 쓰인다.

URI란 통합 자원 식별자로, 정보 리소스를 고유하게 식별하고 위치를 지정할 수 있는 것이다. HTTP는 주어진 URI로 객체를 찾아오는데, URI는 프로토콜, 서버, 리소스를 모두 명시하고 있다. 이는 URL(uniform resource locator)과 URN(uniform resource name)으로 나눌 수 있다.

URL은 리소스 식별자의 가장 흔한 형태이다. 특정 서버의 한 리소스에 대한 구체적인 위치를 서술하여 리소스가 정확히 어디에 있고 어떻게 접근할 수 있는지 알려준다. 대부분 세 부분으로 이루어진 표준 포맷을 따른다. 통상적으로 URI와 URL을 같은 의미로 사용한다.

	사용되는 프로토콜 (scheme, 스킴)	서버의 인터넷 주소	웹 서버의 리소스
예시	http://	www.oreilly.com	index.html

URN은 콘텐츠를 이루는 한 리소스에 대해, 그 리소스의 위치에 영향을 받지 않는 유일무이한 이름이다. 리소스를 옮기더라도 문제없이 동작하며, 리소스가 이름을 변하지 않게 유지한다면 여러 종류의 네트워크 접속 프로토콜로 접근해도 문제없다. 그러나 여전히 실험 중인 상태이므로 널리 채택되지는 않았다.

예시	urn:ietf:rfc:2141

※ HTTP 완벽 가이드(데이빗 고울리, 브라이언 토티, 마조리 세이어, 세일루 레디, 안슈 아가왈)을 참고하여 작성한 글입니다. 참고자료에는 게시글보다 상세하고 정확한 설명이 기재되어 있습니다. 이 게시글에 문제가 되거나 부정확한 부분이 있다면 알려주시면 감사하겠습니다.

[Java] 접근 제어자(access modifier)

Sigfriede — Wed, 24 Jan 2024 12:00:56 +0900

접근 제어자(access modifier)는 한 번에 네 가지 중 하나만 선택할 수 있다. 클래스, 멤버변수, 메서드, 생성자에 사용되며, 해당하지 않는 외부에서의 접근을 막는다. 외부로부터 데이터를 보호하고(데이터가 유효한 값을 유지하고 외부에서 함부로 변경할 수 없도록), 내부에서만 사용되어 외부에는 불필요한 데이터를 감추기 위해 사용한다.

private: 같은 클래스 내에서만 접근할 수 있다.
default: 같은 패키지 내에서만 접근할 수 있다.
protected: 같은 패키지 내 다른 패키지의 자식 클래스에서 접근할 수 있다.
public: 모두 접근할 수 있다.

제어자	같은 클래스	같은 패키지	자식 클래스	전체
public	O	O	O	O
protected	O	O	O	X
(default)	O	O	X	X
private	O	X	X	X

※ 자바의 정석(남궁성)을 참고하여 작성한 글입니다. 참고자료에는 게시글보다 상세하고 정확한 설명이 기재되어 있습니다. 이 게시글에 문제가 되거나 부정확한 부분이 있다면 알려주시면 감사하겠습니다.

[Java] 제어자(modifier)

Sigfriede — Mon, 22 Jan 2024 12:00:49 +0900

제어자(modifier)는 클래스, 변수 또는 메서드의 선언부에 함께 사용되어 부가적인 의미를 부여한다. 클래스나 멤버변수와 메소드에 주로 사용되며, 여러 제어자를 조합하여 사용할 수 있다.

static

인스턴스에 관계없이 같은 값을 가지며 변수 하나를 모든 인스턴스가 공유한다. static이 붙은 멤버변수, 메소드, 초기화 블럭은 인스턴스를 생성하지 않고도 사용할 수 있다. 이를 사용하면 인스턴스를 생성하지 않으므로 편리하고 속도도 더 빠르다는 장점이 있다.

final

거의 모든 대상에 사용할 수 있다. 변수에 쓰면 값을 변경할 수 없고, 메소드에 쓰면 오버라이딩을 할 수 없고, 클래스에 쓰면 부모가 될 수 없다. 일반적으로 선언과 초기화를 동시에 하지만, 인스턴스 변수는 생성자에서 초기화 할 수 있다.

abstract

메서드의 선언부만 작성하고 실제로 기능하는 부분은 구현하지 않은 추상 메소드를 선언할 때 또는 클래스 내에 추상 메소드가 있다는 것을 명시적으로 드러낼 때 쓰인다. 추상 클래스는 인스턴스를 생성할 수 없다. 추상 클래스 자체는 쓸모없지만 원하는 메소드만 오버라이딩 할 수 있다.