OneDev

2026 상반기 IBK기업은행 신입행원 채용 필기/실기시험 후기 [IT]

one_dev — Tue, 19 May 2026 08:37:27 +0900

0. 들어가며

저는 2025 하반기에 기업은행에 처음 지원했다가 필기 탈락했고, 2026 상반기 필기 합격 후 실기시험에 합격했습니다.

아래에 작성된 내용은 제 경험을 바탕으로 작성되었으며 이후의 공채에서는 바뀔 수 있습니다.
가장 정확한건 채용 공고에 나와있으니 공고를 잘 읽으시면 되겠고, 기업은행 유튜브 채용설명회 등 현직자분들 인터뷰하신 것도 참고하시면 좋을것같아요.

+ 채용공고에 나와있는 문의처로 문의해도 친절하게 알려주십니다

기업은행 실기시험 IT 직무 후기는 찾아보기 힘들더라구요...같은 블로그만 수십번은 돌려본것같습니다
특히 벨로그 한 곳을 많이 봤는데 작성자분께는 감사를 표합니다 많은 도움이 됐어요 ㅎㅎ
~~이거 직접 써보니 쓰는것도 일이네요~~

1. 서류

적부이기 때문에 블라인드 위배나 회사명 잘못쓰는 등의 경우가 아니면 어렵지 않게 통과할 수 있습니다.
하지만 실기시험 심층인터뷰(면접) 순서에서 입행지원서를 기반으로 많이 질문하시기 때문에
대충 썼다가는 나중에 필기 덜컥 붙고 면접 준비할 때 피눈물 흘리는 수가 있으니 열심히 쓰시길!
(그게 접니다 ㅎ....아무리 퇴근하고 비몽사몽할 때 썼다지만 너무 못써서 면접준비하는내내 부끄러웠습니다...)

2. 필기

필기는 NCS(40문제) + 전공 객관식(30문제) + 전공 주관식(5문제) 로 구성되며 120분간 진행됩니다.
(문제당 배점 : NCS 1.5점 / 전공 객관식 1점 / 전공 주관식 2점)

저는 직장을 다니며 공부를 해야했기에 그렇게 많은 시간을 내지는 못했습니다
퇴근하고 운동하고 스터디카페가서 90분 NCS하고 30분 전공공부 하고 집가서 자기를 반복했는데
이거 사람 할짓이 못되는거같아요 ㅠㅠ 직병하시는 분들 화이팅입니다....
다만 2025 하반기 필기시험 준비할 때 추석 연휴가 껴있었고, 해당 연휴 기간에 NCS를 빡세게 준비했었던게 큰 도움이 된것같습니다.

제가 혼자 괜히 눈치보면서 사진같은거 잘 못찍는 사람이라 사진이 별로 없네요...

(1) NCS

NCS 준비는 혼잡에서 나온 금피셋으로만 했습니다. (다른 책도 보고싶었는데 직장 다니면 시간이 없음...)

오카방에서 다른 분들 이야기하시는걸 들어보니 독끝? 인가 더 어려운 문제집도 있는것같더라구요

맨날 반타작도못해 상처를 안겨준 나쁜 책

1) 공부법(?)

금피셋은 회차별로 60분 잡고 풀었고 노트 한장 찢어서 1번~30번 미리 적어둔 뒤에 답 옮겨 적는 연습까지 병행했습니다.
매 회차 풀때마다 이전 회차에서 한 실수는 안한다는 마인드를 가지고 이전 회차에서 실수했거나 아쉬웠던 부분 기록해놓고,

다음 회차 풀때는 최대한 반영하려 노력하는 식으로 공부했습니다. (하지만 사람은 같은 실수를 반복하고...)

개인적인 생각이지만, 금피셋 60분잡고 풀었을 때 모든 회차를 안정적으로 16~18 문제 이상 맞출 수 있는 정도가 되시면 어느정도 안정권이 될것같습니다 (찍는것 제외). 이렇게 말씀드리는 이유는 제가 회차별로 13~16 문제 맞췄는데 턱걸이로 붙었기 때문입니다. 다시 한번 말씀드리지만 개인적인 생각이라 믿지는 마시길 바랍니다.

제가 NCS를 깊이(?) 공부해보거나 강의도 들어본 적이 없어서 저는 저만의 전략을 세웠습니다.

저도 그랬고, 필기 합격하신 분들 공통적으로 하는 얘기가 "시간 내에 최대한 많은 문제 풀기 " 가 가장 중요하다고 생각됩니다.

그래서 저는 아래처럼 해봤는데 각자의 상황에 맞춰서 하시면 좋을것같아요.

전공 먼저 30분 투자하고 나머지는 ncs에 투자 (전공은 모르는건 시간 투자해도 못풀기 때문에....ncs에 더 많은 시간을 투자하려고 했습니다)
자료해석은 과감히 버린다(제가 어림산에 약해서 오래걸리더라구요...수학 전공이지만 산수는 못합니다)
문제당 2분이 넘어가면 버린다 or 슥 보고 2분 넘어갈 것 같으면 버린다

그리고 찍으실땐 한 번호로 미시는걸 추천드립니다
저같은 경우에는 2분 남았을 때 NCS 3문제(묶음)를 못 푼 상황이었는데, 3문제 모두 같은 번호(지금까지 제가 작성한 답안중에 제일 적게 나온 번호)로 밀었는데 많이 맞았습니다!

2) 난이도

2025 하반기, 2026 상반기 필기시험을 본 경험으로 NCS 난이도에 대해 말씀드리면
2025 하반기는 금피셋보다 어려웠고, 2026 상반기는 금피셋보다 쉬웠다 라고 말씀 드릴 수 있을것같습니다.
두 시험의 난이도가 극과극이었기 때문에 이후 시험은 어떻게 나올지 예상하기가 어렵네요 ㅠ

2025 하반기의 경우 기업은행을 포함해 저의 첫 NCS 시험이었는데 문제지를 보자마자 멘붕이 와버렸습니다..
~~(지원자는 완전히 멘탈이 나가버렸습니다)~~
일단 시험지의 크기가 거의 신문지 급이어서 불편했고, 지문도 금피셋과 비교도 안될 정도로 길었습니다.
시험이 끝난 후에 오픈카톡방에서 "기업은행은 NCS 굇수를 만들려는건가..." 하는 카톡을 봤던 기억이 나네요 ㅋㅋ
(그래서 이번 상반기 필기 준비할 때 "나는 NCS 괴수가 되겠어" 라는 마음가짐으로 공부했죠)
2025 하반기는 제가 61~62점 받고 아쉽게 떨어졌던걸로 기억하는데 이 때 관련 자료는 아무것도 기록해둔게 없네요

이번 2026 상반기 필기시험을 준비할 때는 25 하반기 때의 난이도로 예상을 하고 공부했는데 생각보다 쉬워서 당황했습니다....
분명 금피셋 맨날 반타작도 못하고 그러는데 필기시험 당일에 술술풀리니까 되려 당황스럽더라구요 ㅋㅋ
그럼에도 어렵게 나올것이라 예상하고 그에 맞춰 공부하시는걸 추천드립니다 ㅎㅎ
시험지 크기도 줄어들어서 보기 편했습니다

제일 중요한건 내가 어려우면 남들도 어렵고 내가 쉬우면 남들도 쉽다는 사실...
다른 분과 비교하지 마시고 본인 실력 키우시는데만 집중하시길 추천드립니다!

(2) 전공

전공의 경우 정보처리기사 시험과 유사해서 정보처리기사 책으로 준비하시면 될것같습니다.
저같은 경우는 24년 6월에 정처기를 따기는 했지만 시간이 너무 오래지나서 많이 까먹은게 많아 고생좀 했습니다 ㅎㅎ...
(심지어 책도 수제비 2024년 버전으로 공부했습니다 ㅎ...)
아직 정처기 없으신 분들은 필기시험 전공 대비도 같이 한다는 마인드로 같이 하면 좋을것같아요!

+ 이번에 전공 공부 할때 시간은 없는데 정처기 범위는 넓고...급한 마음에 책을 정독하자니 눈에도 잘 안들어오고... 그런 마음에 그냥 컴퓨터 일반 문제집을 사서 양치기를 하자! 는 마인드로 박미진 컴퓨터 일반 기출문제집을 사서 공부했습니다.
이건 정독보다 일단 문제를 푸는걸 선호하는 제 습관 때문에 이렇게 한거고 편하신 방법으로 하시면 될것같아요
개인적으로는 정처기책으로 공부하시는게 더 도움이 될것같다고 생각합니다.
문제가 컴일 책보다는 정처기 책과 더 유사한것같아요.

(다시 생각해보니 그냥 정처기 책으로 문제 양치기 했으면 안됐나...? 왜 이런생각은 다 끝나고 날까요 ㅋㅋ)

26년에 24년 책으로 공부하는 사람이 있다?

(3) 결과

결과는 82점으로 턱걸이 합격했습니다 ㅎㅎ
이번 IT 필기 커트는 81점이고, 81점 내에서 동점자 규정에 따라 합/불이 갈린것으로 알고있습니다
이 점수에는 각종 가점이 포함된 점수이고, 저는 정보처리기사 자격증이 있어서 5점 가점 받았습니다

은센이가 축하해주는거 처음봤는데(서류말고) 진짜 기대도안하고 있다가 감동핑...

친절하게 분석 결과도 알려줍니다

~~문제해결능력이 높고 의사소통능력이 낮다고? 이거 완전 이과 특이자나~~
오픈카톡에서 얘기들어보니 동점자가 많으면 백분위가 확 깎일 수 있다고 하네요 ㅎㅎ

3. 실기

실기시험은 기흥연수원에서 하루동안 진행됐습니다.
이번 실기시험은 4월 27일 ~ 5월 11일 동안 진행되었고, IT 직군은 첫날인 4월 27일에 진행했습니다.
아침 일찍 을지로 본점에 모여서 셔틀버스를 타고 기흥연수원으로 이동해 일정을 소화하고, 일정이 모두 끝나면 다시 셔틀 버스를 타고 을지로 본점으로 돌아왔습니다. (퇴소는 개별 퇴소가 가능했지만, 입소는 무조건 을지로 본점에 모여야 했습니다)

IT직군의 경우 퇴소시 셔틀버스가 죽전, 서울역 등을 경유하지 않고 바로 을지로 본점으로 왔는데, 다른 직군의 경우 죽전과 서울역을 들렀다는 카더라를 오카방에서 봤습니다. 정확한 정보는 아닙니다.

이번 실기시험은 (1) 코딩테스트 > (2) 토론면접 > (3) 개인발표 > (4) 심층인터뷰 순서로 진행됐습니다. (토론 면접 후 점심식사)
한 조는 다시 A팀, B팀이 으로 나뉘었습니다. 토론면접은 A팀 vs B팀 구도로 진행됐으며 개인발표, 심층인터뷰 시간에는 A,B팀이 엇갈려 진행했습니다 (한 팀이 진행할 때 다른 팀은 대기하면서 교통비 배부받는다던가 그런식으로요)

이번 IT직군 응시자는 최종선발인원의 8배수인 120명이었고, 한 조에 12명씩 (6명씩 2팀으로 구성) 총 10조였습니다.

결시의 경우 저희 조에는 없었고, 다른 조에 결시가 있는지는 경황이 없어서 확인을 못했는데 거의 없었던걸로 기억합니다.

복장의 경우 비즈니스 캐주얼로 안내가 나왔는데 대부분 정장이었습니다.
실기시험 도중 인사담당자님과 Q&A시간이 있었는데, 복장 관련 질의가 있었습니다.
그 때 말씀주신것이 "복장에서 오는 피로도가 상당한 것을 인지하고 있고 하루동안 많은 일정을 진행하는 점을 고려해 지원자들이 편하게 임할 수 있게 정장이 아닌 비즈니스 캐주얼로 안내를 드린다"고 하셨습니다.
"다만 많은 분들이 그럼에도 정장을 입고 오는 마음이 어떤 마음인지는 알고 있다" 라고 말씀을 주셔서 꼭 정장이 아니어도 단정한 비즈니스 캐주얼이면 괜찮을것같아요.

물론 저는 보수적으로 입고가자 생각해서 정장에 노타이로 입고갔습니다.

기흥연수원에 도착 후 대강당에 모여서 인사담당자분이 간단한 안내를 해주셨고,
저희 긴장 풀어주시려는 건지는 모르겠지만 이것저것 얘기를 해주셨는데 내용은 하나도 기억안나네요 ㅎㅎ
대강당 자리에 웰컴키트와 노트북이 놓여있었고, 그 노트북으로 코딩테스트를 진행했습니다.

그리고 매 공채마다 키워드를 정하시는것 같은데 이번에는 "청춘" 이었습니다.

대기할 때 노래 틀어주시는 플리도 청춘과 관련된걸로 잔뜩 틀어주시더라구요

웰컴키트 / 사진엔 안나왔는데 칫솔치약도 있습니다

점심식사는 토론면접이 끝난 후에 조별로 식사를 했습니다.
밥 잘나왔는데 사진찍는걸 깜빡했네요...제가 갔을 때는 카레/가라아게/새우튀김우동이 나왔습니다.
다른건 몰라도 밥사진은 꼭 찍어야지 했는데 이걸 깜빡할줄이야..
(다른 후기들에서도 그렇고 인사담당자분도 그렇고 기흥연수원 밥이 그렇게 맛있다고 얘기하셔서 기대감MAX로 품었다가 살짝놀란게...가라아게 다리살이 아니라 가슴살이어서 당황했습니다...보통 가라아게라고 하면 다리살을 기대하니까요)
기대치가 너무 높았어서 그렇지 맛은 있었습니다 ㅎㅎ
그리고 졸릴까봐 그러시는 건지는 모르겠지만 다들 밥을 조금드시더라구요?
인사담당자분도 이후 순서 진행하려면 든든히 먹어둬라 하셨고 저도 든든히 드시는걸 추천드립니다 (졸릴정도로는 말구요)
저는 배고프면 집중이 안되는 사람이라 싹싹비우고 나왔습니다.
주변에 싹싹비운사람이 없어서 조금 당황스럽고 부끄럽기도 했습니다.

조별로 식사할 때 면접위원분들과 같이 앉아 얘기를 하면서 먹는데
저는 어쩌다보니 조별 자리의 가장 끝에 앉았고 자연스럽게 면접위원분들과 토크할 기회는 없었습니다.
가까이 앉으신 분들은 하하호호 이런저런 얘기 하시더라구요
저는 낯을 좀 많이 가려서 면접관님 근처에 앉았으면 서로 어색할뻔 했는데 다행(?)이었습니다.

산책로가 잘되어있다고 하셔서 식후에 산책을 해보고싶었지만
저희 조 식사 순서가 거의 마지막이어서 산책할 시간은 없었습니다 ㅠ
시간 되시는 분들은 소화도 시키고 잠도깰겸 산책해보시면 좋을것같아요!

그리고 흡연하시는 분들은 흡연장소가 있긴 한데 점심식사 이후 1번만 허용해줬습니다 참고해주세요

(1) 코딩테스트

- 알고리즘 2문제, SQL 1문제 (65분)
- 무난했습니다. 알고리즘은 둘 다 구현이었고, 백준 기준으로 실버 중반? 느낌이었습니다 (아아 백준...그는 갔습니다....)
- SQL도 쉬웠습니다. 프로그래머스 기준으로 레벨 2~3 정도?
- 코딩테스트까지 어렵게 내버리면 지원자들 많이 힘들어할까봐 기업은행측에서 배려하는게 아닐까? 라는 개인적인 추측이긴한데 어디까지나 100% 제 뇌피셜이니까 믿지는 말아주세요.

(2) 토론면접

이때부터는 조별로 진행되었고, 면접위원 두 분 + 진행위원 한 분이 함께 들어오십니다.
(이분들이 이후 순서까지 쭉 함께하셨습니다. 일정을 같이 소화하면서 친밀감을 쌓고 지원자가 심층인터뷰 시간에 편하게 얘기할 수 있도록 이렇게 하시는것같아요)
하나의 조 안에서 A/B팀이 나뉘었는데요, 토론면접은 A팀 vs B팀 구도로 진행됐습니다.
그리고 찬성/반대는 선택권 없이 A팀이면 찬성, B팀이면 반대 이런식으로 정해주셨습니다.

- 이번 주제는 요즘 떠오르는 IT 관련 기술 도입에 대한 찬반이었습니다.
- 자료를 나눠주시고 먼저 각자 자료를 분석할 시간을 주십니다. (정확한 시간은 기억이 나질 않습니다...한 5분?)
- 자료의 양은 다른 후기에서 봤던것처럼 토론 하기에는 충분했습니다. 다만 뭔가 반대측에 유리한 자료가 많고 찬성측에 유리한 자료는 적었던 느낌이었습니다.(저는 찬성측이었어서 자료보면서 흠...지겠는데...? 했습니다 ㅎㅎ)
- 이기고 지는것보다 본인의 논지와 근거를 얼마나 조리있게 표현하고 상대방과 어떻게 의사소통하느냐가 훨씬 중요할것 같아서 크게 개의치는 않았습니다.
- 각자 자료보는 시간이 끝나면 팀끼리 말 맞춰보고 역할 분배 해볼 수 있는 시간을 짧게 주셨습니다(한 4~5분?).
저희 조는 크게 (1) 기조발언 누가할 지 정하기 (2) 찬성측이 밀어붙일 만한 논거들 정리&보완하고 (3) 반대측 예상주장에 대한 답변정리 이정도 했던걸로 기억하는데, 시간이 짧다보니 제대로된 토의는 어려웠던것같습니다. (역할분배가 큰 의미가 있나 싶은게 일단 5분이 역할을 제대로 나누기엔 짧은 시간이기도 하고, 발언권이 본인 팀 순서로 넘어왔을 때 한 2~3초만 공백이 생겨도 누군가는 얼른 대답해야될것같은 그런 압박이 생겨서 잘 안지켜지더라구요 ㅋㅋ )
- 이후 토론이 시작되며 총 24분간 진행되었습니다 (각 팀별12분)
- 진행자(또는 사회자)는 없었습니다
- 찬성, 반대 무조건 번갈아가면서 말해야되며 팀에서 말 안하는 사람이 있어선 안된다고 했습니다
- 한 팀에서 발언이 끝나면 무조건 상대 팀에서 발언해야하며, 같은 팀에서 첨언 못합니다
- 어느 팀이 먼저 발언할지는 정해주셨습니다. (저희 조의 경우 반대측에서 시작해달라고 콕 집어서 말씀해주심)
- 면접관님들 계신 책상에 아이패드 같은 걸로 각 팀별 남은 시간을 표시해주셨고, 발언 중인 팀의 시간이 흘러가는 방식으로 시간이 체크되었습니다.
- 마지막에 한명씩 어느 팀이 승리한것같은지와 이유를 말하는 시간을 30초 정도 짧게줬습니다. 이게 다른 분들 하시는거 들어보니까 다들 쿠션어 많이 쓰시려고 구구절절 말하시던데 이러면 30초가 훌쩍 넘어버리더라구요. 그래서 이거는 간결하게 "저는 00팀이 이겼다고 생각한다 + 이유" 정도로 간단하게 말씀드리길 추천드립니다

나름 토론은 자신있다 생각했는데...레전드 아무말 대잔치 찍고 왔습니다.
돌이켜보면 다들 말은 또박또박 잘하지만 내용은 아무말 비중이 높은 그런 시트콤 같았달까요?
재밌기도하고 아쉬움도 남는 시간이었습니다.

토론/개인발표/심층인터뷰 모두 당시에는 할말이 생각 안나고 다 끝나고 나서야 "아 이렇게 대답할걸 ㅠㅠ" 잔뜩 생각이 났는데 아마 다들 비슷하지 않으실까 생각합니다...
그럼에도 이 시간으로 되돌아가면 더 잘할 수 있을것같냐? 라는 질문에 '네' 라고 대답하기는 어려워서 마음을 비우려합니다 ㅎㅎ

(3) 개인발표

- IT기술 관련 주제를 주고, 이 서비스를 고도화하거나, 개선할 부분을 발표하는 방식이었습니다.
- (예) 주제 : 00서비스 → 00서비스에 대한 기본적인 설명이 자료로 제공됨, 00 서비스에 대해 고도화 또는 개선할 내용을 발표
- 단, 고도화 또는 개선할 분야는 선택지가 주어졌습니다. 예를 들어 [보안/UI/...] 이렇게 선택지가 여러개 주어지면 이 중 하나를 선택해 "나는 00서비스를 [보안]분야에서 ~~ 이러이렇게 고도화를 기획했다", "나는 00서비스 [UI] 분야에서 다음과 같은 개선점을 기획했다"라는 느낌으로 생각하시면 될것같습니다.
- 정확한 워딩은 기억안나지만, "팀장이 되었다 생각하고, 회의에서 팀원들에게 왜 이런 기획을 했는지 소개하고 어필하는" 그런 느낌이었습니다.
- 왜 그렇게 기획했는지, 구체적인 방법, 기대효과, 예상문제 등 발표
- 준비는 20분, 발표는 4분이었습니다
- 질의응답 없이 각자 발표만 진행했고, 본인 발표가 아닐 때는 다른 조원들의 발표를 들을 수 있었습니다
- 자료용지 1장, 참고용 메모장(?) 1장 주고 자료를 보고 본인이 발표할 내용을 메모장에 정리합니다.(이걸 보면서 발표)
- 면접관에게 제출하는 용지는 없었습니다. 이전에는 면접관에게 제출할 용지도 따로 작성을 했다고 어디서 봤는데...이번엔 없었습니다. 다만 본인이 정리한 메모장을 거두어가는데 이게 점수에 반영되는지 안되는진 모르겠습니다. (반영 안될 가능성이 높아보이고 반영되더라도 큰 영향은 안줄것같다고 개인적으로 생각합니다)
- 발표 순서는 조에서 제비를 뽑아 결정했습니다.
- 준비할 때는 아이디어 짜내느라 시간을 너무 많이 써서 미처 생각을 못했는데, 다른분들 발표를 들으니 구체적인 방법까지 그 짧은 순간 다 준비를 하셨더라구요...예를 들어 어떤분은 "이러이러한걸 구현하기 위해 Kafka를 도입하고~~ " 이런식으로 말이죠... 저는 20분동안 구체적인 기술은 생각 못하고 큰 틀만 기획했기 때문에 임기응변으로 "~~문제가 예상되는데 ~~ 기술 써서 ~~하면 될것같다"고 한문장으로 퉁쳤습니다
- 스스로 잘했다고 느낀건 "내가 왜 이 기획을 헀는지"에 대한 이유를 명확히 설정하고, 전달도 잘한것같다는 점 ㅎㅎ
- 스스로 못했다고 느낀건 "그래서 구체적으로 뭘할건데?"가 조금 모호하지 않았나 ㅠㅠㅠㅠㅠㅠㅠ

개인발표는 개인적으로 실기시험 전에 특별히 무언가 준비한다고 대비되는 발표는 아니라고 느꼈습니다.
(물론 스터디든 자료조사든 안하는거보단 낫겠지만요)
평소 IT기술에 대한 관심, 내가 쓰는 기술에 대한 고찰, 맞닥뜨렸던 문제들에 대한 고민 등등 여러 경험을 미리미리 쌓아두는 편이 훨씬 도움이 될것같았습니다.

(4) 심층인터뷰(면접)

면접은 2대1로 12분동안 진행됐습니다. (진행위원님도 들어와계셨는데 면접에는 관여 안하셨습니다)
저는 저희 조의 1번이어서 첫번째로 들어갔는데 참 다행이었습니다.
면접 순서에 장단점이 있다지만 저는 빨리 끝내고 맘편히 쉬고싶었거든요 ㅎㅎ

면접장 들어가기 전에 문 앞에서 잠시 대기하는데, 이때 진행위원님이 긴장하지 말라고 이것저것 스몰토크 걸어주셨는데 참 감사했습니다.
그런데 스몰토크하다가 정신을 차려보니 다른 지원자는 다 면접실 들어갔는데 저만 안들어갔더라구요 ㅋㅋ
저도 놀랐고 진행위원님도 화들짝 놀라서 얼른 들어가라고 해주셨던 해프닝이 기억에 남네요

오전부터 면접관님들과 여러 순서를 함께했고, 장소도 토론면접과 개인발표 진행했던 공간에서 진행되어 그나마 편한 분위기였던것같습니다.
그래도 엄청 긴장되더라구요 ㅋㅋ 이렇게 긴장해본적은 오랜만인것같았습니다
그럼에도 면접 중간중간 이분들이 지원자의 진솔한 이야기를 이끌어낼 수 있게끔 많이 노력해주고 계시구나라는게 피부로 와닿을 정도로 친절하게 대해주셨습니다 ㅠㅠ

면접 끝난 직후에는 분위기가 좋았던것같다고 생각 했는데
면접 복기를 하다보니 대답을 정말 개판으로 했다는걸 깨닫고 (동문서답 레전드 레전드...)
분위기가 좋았던건 순전히 면접관분들의 노력 덕분이란걸 다시 느꼈습니다...
면접관 선생님들 감사합니다...
(오카방에서 후기를 보니까 모두가 그린라이트를 느낀것같더라구요 ㅋㅋ)

그리고 인사담당자 중 한 분으로 추정되는 분이 제 면접을 중간부터 지켜보신 건지,
면접이 끝난 후에 저에게 목이 너무 아파보인다고 얼른 가서 물좀 마시라고 해주신거 너무 감동이었습니다 ㅠㅠ
~~사실 전날 노래부르다 목이 나간거라고는 말 못했습니다...걱정해주셔서 감사했습니다...~~

나중에 안 사실인데 순환면접관(?) 이라고 불리시는분같았어요.

면접 질문의 경우 입행지원서(자기소개서+직무기술서 모두 포함)에서 주로 나왔습니다.
아래에 면접 질문을 써두긴 했지만 면접관 by 면접관이고 각자의 경험과 스펙도 전부 다르기 때문에 "본인 입행지원서를 기반으로" 준비하시길 바랍니다 ㅎㅎ

저는 제 입행지원서 보면서 노션에 예상질문 50개정도 리스트업하고 답변 준비했었는데,
2~3개정도만 예상질문 나왔고 나머지는 다 프리스타일로 해야만 했습니다 ㅋㅋ ㅠㅠ
면접준비하실 분들은 계속 입행지원서 보면서 질문 대비하시는게 가장 중요해보이고,
여건이 된다면 다른분께 예상질문 물어봐도 좋을것같아요.

그런면에서 면접스터디를 하고싶었지만...
구했던 면스가 1회차 이후 갑자기 방이 폭파돼버려서 그냥 혼자 준비했습니다 ㅠ
면스는 하실 수 있으면 하시는게 좋을것같아요.
토론도 그렇고 개인발표도 그렇고 1번이지만 해봤던게 도움이 많이 됐습니다.

특히 토론의 경우 긴장하거나 과열될 때 본인의 안좋은 습관이 드러날 수 있기 때문에
면스에서 다른건 안해도 토론은 해보시길 추천드려요!

면접 질문을 공개해도 되는건가 고민을 많이 했는데
입행지원서에 관련된 내용이 주를 이루었기 때문에 저에게만 물어볼 수 있는 질문이 많았고
그 외 질문들은 누구나 예상할만한 공통질문이라고 생각해 공개합니다.

그리고 제가 서두에 자소서를 진짜 개판으로 썼다고 말씀드렸잖아요?
(대충썼거나 내용에 잘못된게 있다는건 아니지만 뭐랄까...진짜 대학생이 쓴것같이 너무 진솔한 그런 날것의 느낌...?)
이를 뒤늦게나마 인지해서 직무기술서는 그나마 사람답게 작성했더니
직무기술서에서 많이 물어봐주셨습니다 ㅎㅎ...

[심층인터뷰 질문]
- 1분 자기소개는 안했습니다. (면바면 아시죠? 질문 안받더라도 준비하세요)

Q. (직무기술서 프로젝트 관련)
- 00 프로젝트에서 맡은 역할이 뭐였는지? 직무기술서에서만 봤을 땐 정확히 어떤걸 했다는건지 이해가 잘 되질 않는다

Q. (직무기술서 주요성과 관련)
- 00 문제 성능개선했다고 썼는데 측정은 어떻게 했는지? 속도 느린게 00문제가 원인이라고 어떻게 판단했는지?
(정학한 워딩은 기억안남... 그래도 직무기술서에 썼던 내용 관련 질문이었음)

Q. (입행지원서 교육관련)
- 교육과정을 보니까 MSA가 보이는데(교육과정명에 MSA가 들어감) 현재 재직중인 직장의 솔루션에 MSA 구조를 반영한다면 어떻게 할 수 있을것같은지?

Q. 현재 직장에서 이직하려는 이유가 있는지?

Q. 기업은행도 00솔루션이 있는데, 현직장의 솔루션이 기업은행의 솔루션과 비교했을 때 차별점이 있는지? 어필한다면?

Q. 은행 IT직무에 관심을 가지게 된 계기가 있는지?

Q. 본인이 AI보다 나은점이 있다면?

Q. 마지막하고싶은말?

※ 다른 지원자가 면접 보는 동안 신상이력서라는걸 작성했습니다.
임원면접시 임원 분들이 보게될 입행지원서의 요약본이라고 설명을 해주셨는데요,
그래서 입행지원서에 없는 내용은 작성해선 안된다고 하셨습니다.
기본인적사항/장단점/취미,특기/존경하는 인물/직무경험/기타활동/자기소개사항(150~200자 정도로 간단하게)/키워드로 본인을 소개 등등을 적었습니다.

그리고 이력신상서는 컴퓨터에서 작성하기 때문에, 본인이 뭐라고 작성했는지 기록해두는 것을 추천드립니다. (실기시험 붙으면 면접준비할 때 봐야되니까요). 저는 출력해간 입행지원서에 손으로 썼는데, 핸드폰으로 쓰는 분도 계셨습니다.

저의 경우 1번으로 면접을 봤기 때문에 면접이 끝난 후 신상이력서를 작성하기 시작했는데요,
그 외 분들은 신상이력서 쓰는 도중에 본인들 차례가 되면 심층인터뷰 다녀오셨습니다.

실기시험의 합격자 배수가 1.7배수이기 때문에 떨어질 확률이 높아서 기대보다는 걱정이 앞섰지만....

자소서때문에 면접준비할 때 힘들었던것 생각하면서 열심히 썼습니다.

(5) 실기시험 마무리

모든 순서가 끝난 후에는 다시 대강당에 모여서 인사담당자분이 이런저런 얘기를 해주시고 마지막으로 쿠키영상을 보고 나왔습니다. 쿠키영상이 감동적이었어서 우시는 분들도 꽤 계셨는데, 저는 쿠키영상의 소재가 개인적으로 너무 익숙했기때문에 그냥저냥 봤습니다 (청춘버스 273 다큐멘터리였나 그랬는데 학교다닐 때 매일 봤던 버스였거든요)

끝나고 나갈 때 대강당 문앞에서부터 건물 나갈때까지 면접위원, 진행위원분들이 큰 박수로 격려해주셨는데
너무 감동스럽기도하고 감사하기도하고 한편으론 내향인이라 부담스럽기도하고 여하튼 좋은 기억으로 남았습니다 ㅎㅎ
그리고 나갈 때 샌드위치 + 소정의 선물을 줬습니다

(TMI) 퇴소할 때 화장실 신호가 와서 버스타기 전에 화장실을 한번 들렸다가 타야겠다 생각을 하고 있었는데,
퇴소할 때 대강당 문앞에서부터 건물 밖으로 나가는 문앞까지 엄청난 박수로 배웅을 해주셔서 저도 모르게 화장실을 안들리고 바로 박수를 따라(?) 이동해 버스에 바로 탑승해버렸고 버스에서 인고의 시간을 보내게 되었습니다...저처럼 고통겪으시는 분들은 없으시길...

(TMI) 지원자 + 면접위원 + 진행위원 모든 분들이 IT 직무라고는 믿기지 않을 만큼 미남 미녀가 많으셔서 제가 금융일반 순서에 잘못온것은 아닌가 했는데 요새 IT 분들이 예전과 다르게 멀끔하시더라구요...(선입견 맞습니다) IT 컷 많이 높아졌다고 새삼 느끼게 되었습니다.

먹을 장소가 마땅치않아서 집와서 먹었습니다 / 무드워터

(6) 실기시험 결과

IT직군이 실기시험 전체 일정 중 첫날인 4월 27일에 시험을 봤고,

결과 발표는 5월 15일 스승의날로 모두가 예상을 하고 있었습니다.

첫날 봤어서 그런지 기다리는 시간이 너무 길었습니다 ㅠㅠ

오카방에서 모두가 기멘을 외치며 기다리는걸 보는데 저도 긴장되고, 천명이 넘는 분들이 간절히 결과 발표를 기다리고 있다고 생각하니 참....청년들 사는게 너무 빡빡하다는 생각도 들었습니다....

여하튼 15일에 약속의 5시가 되어 오카방을 보니 결과가 떴음을 알 수 있었습니다.

카톡방을 우르르 나가는 분들도 게시고....안도의 한숨을 내뱉는 분도 계시고...

그리고 후기를 들어보니까 불합격이면 은센이도 없고 회색화면에 텍스트만 있다고 하더라구요 ~~ㅠㅠ 잔인해~~

제가 5시 퇴근이어서 퇴근하면서 결과를 조회했는데.....

....

은센아 ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ 보고싶었어 ㅠㅠㅠㅠㅠㅠㅠㅠ

어안이 벙벙했습니다....

처음에는 기쁜 마음도 안들고 눈물날라그랬어요...

우는거 들킬까봐 후다닥 회사를 나와 걸어가는데 다리도 후들거리고 속도 울렁거리고....

아마 긴장이 갑자기 풀려서 그랬던게 아닐까 싶어요 ㅠㅠ

결과 조회 누르기 전에 속으로 떨어졌다고 여러번 복창하고 열었는데 이게 무슨.....

ㅠㅠㅠㅠㅠ 진짜 은센이의 웃는 저 모습은 사람 홀리는 뭔가가 있는것같아요

감사합니다...감사합니다....

1년 넘게 이직준비하면서 50군데는 넘게 떨어졌는데....그렇게 환하게 웃어주면 난 미친다 은센아....

취준 힘들다 진짜....

이제 최종 면접이 남았네요...

배수로 보면 1.7배수라 실기보다는 할만해보이지만, 이 모든과정을 뚫고 오신 진또배기분들 사이에서 살아남을 수 있을까 하는 걱정이 앞서는게 사실입니다...또 최종까지 와서 떨어지면 멘탈 어떡하나 걱정도 많이 됩니다....

여하튼 좋은 기회 주신만큼 최선을 다해 해보겠습니다 ㅠㅠ

저도 제가 왜 붙었는지는 모르겠습니다...

실기시험 이후에 오카방에서 다른 분들 얘기하시는 걸 들어봤을 때 공통적으로

"처음에는 본인이 잘했던 점과 실기시험에서 붙을만한 이유가 생각나고,

시간이 흐를수록 본인이 못했던 점과 실기에서 떨어질만한 이유만 생각난다"고 하더라구요 ㅠㅠㅠ(저도 그랬거든요...)

그래서 결과발표 직전에는 실기시험때 아쉬었던 점들만 머릿속에 맴돌면서 잠도 못자고 그랬는데....

면까몰이라는 말이 맞는것같습니다.....

제가 면접관님이나 인사담당자가 아니기 때문에 정확한 평가 기준은 알 수 없지만,

저는 (1) 경청 (2) 진솔함 (3) 논리적 말하기(+두괄식) 이 3가지를 챙기려고 많이 노력했던것같습니다.

근데 이게 도움이 된건지는 평가기준을 모르기 때문에 확실하게 말씀드리긴 어려울것같아요 ㅠ

5. 마치며

하루동안 엄청난 일정을 소화했기 때문에 힘든 하루였지만,
실기시험이 끝난 후 지금까지도 따듯함이 마음에 남을 만큼 정말 좋았던 기억으로 남았습니다.
실기시험을 통해 간접적으로나마 기업은행의 분위기, 문화, 사람들을 접할 수 있었고
더더욱 기업은행에서 일하고 싶어져서 떨어지더라도 또 도전할 것 같습니다.

보통의 기업은 자소서, 코테, 역량검사 등등 이것저것 다 하고 떨어지면 많이 허탈하지만 기업은행은 그러지 않을것같아요.
(이렇게 지극정성으로 대해주셨는데 감히 어떻게 원망을...? 이런 느낌이랄까요)
돌이켜봤을 때 아쉬운 점들이 있는게 사실이지만 이미 지난일이니 어쩌겠습니까 ㅎㅎ

다시 한 번 기업은행 관계자분들께 감사하다는 말씀을 드리며 글 마치겠습니다.

6. 면접시험(최종면접) (작성중)

최종면접은 5월 26일 화요일에 진행했습니다.

저희 조는 남성분들로만 11분이셨는데, IT 직군 최종면접 대상자가 이론상 26명임을 감안했을 때 다른 조는 어떻게 구성된거지? 의문이 들었습니다 (다른조는 여성분들만 14명인지...? 아니면 이번에 디지털 직군은 혼성 조가 있었다고 들었는데 IT도 혼성조가 있었는지...?)

면접 시작시간 45분전 ~ 30분전까지 기업은행 본점 1층에 집결해 잠시 대기한 후 면접준비실(?)로 이동했습니다.

저는 45분전보다 일찍도착해 시간이 남아서 어떡하지 고민하다가 주변 산책 후에 들어갔는데, 시간에 맞춰 가보니 이미 많은 분들이 와계시더라구요...일단 들어가서 기다릴 수 있는지 확인이나 해볼껄 그랬습니다 ㅎㅎ

건물 넘 이쁘다....

1층에서 엘레베이터를 타고 4층이었나 내려서 면접준비실까지 이동하는데 카펫이랑 풍선들로 예쁘게 꾸며두셨더라구요

다른 후기들에서 보긴 했지만 직접 눈으로 보니 기분이 싱숭생숭했습니다 ㅎㅎ

면접준비실에서 모인 후에 다른 지원자분들과 이런저런 얘기도 하고, 인사담당자님이 OT도 해주셨습니다.

기억에 남았던 거는 조별로 인사연습을 했던게 기억에 남습니다.

다른 후기에서는 조별로 '구호'를 연습했다고 하시길래 조별로 구호를 만들어야 되나 걱정이 됐는데요 (이런거 쥐약임)

다행히 이번엔 조별로 미리 통일을 해주셨습니다. 간단하게 "00조입니다 열심히하겠습니다" 이런식으로 말이죠.

그렇게 준비를 마치고 면접실에 입장했는데 확실히 분위기는 실기시험에 비해 많이 무거웠습니다.

다대다 면접이었고 저희 조 기준으로 지원자는 11명이었으며
[면접관 4분 + 외부감사관 1분 + 인사부 직원분 1분] 이렇게 총 여섯 분이 저희 맞은편에 계셨습니다.

면접관분들 중 두 분은 외부 면접관, 다른 두 분은 부행장님들이셨고, 부행장님들은 가운데 앉아계셨습니다.

TMI지만 이번에 기사를 찾아보던 중 올해 초에 IT 부행장님이 새로 부임하셨단 기사를 보고

설마 이분에 면접에 들어오시려나? 라는 마음으로 부행장님 기사 사진을 띄워놓고 면접 준비를 하고 그랬는데

실물로 뵈니까 포스가 넘치시더라구요 ㄷㄷ

서론이 길었는데 바로 면접 후기로 넘어가자면

조진것같습니다.....

순서는 크게 다음과 같이 진행됐습니다.

30초 자기소개
외부면접관 질문 (개별질문)
IT부행장님 질문(공통질문)
외부면접관 질문 (개별질문)
마지막 하고싶은 말

먼저 외부면접관 두분은 지원자의 입행지원서를 기반으로 전부 다른 질문을 해주셨습니다.

다음으로 IT 부행장님은 말씀 안하고 계실 때는 포스가 정말 무시무시하셨는데 저희를 배려해주신건지 질문하실 때는 되게 온화하게 해주셔서 감사했습니다.

제가 다른 후기들에서 찾아봤을 때도 그렇고 일반적인 임원면접 후기들을 봐도 그랬지만,

임원면접의 경우 두괄식으로 간결 명료하게 대답하는게 중요하다고 생각해 저는 모든 답변을 짧고 명료하게 대답하려 노력했습니다. 제가 했던 답변들을 돌이켜 봤을 때 말을 절거나, 동문서답하는 등의 문제는 없었던것 같습니다.

그럼에도 걱정되는 것은....

다른 지원자분들이 전부 말을 길게하시더라구요...

이게 한두명 정도만 길게하면 "아 저분 길게 말씀하시네" 정도로 생각하고 끝나겠지만, 저 빼고 전부 길게 말씀하시니

시간이 많이 소요되었고 부행장님 한 분은 질문을 못하시는 상황까지 이어졌습니다.

그러다보니 총 면접시간 50분 중에 제가 답변한 것은 한 2분...? 정도 되는것같아요 (30초 자기소개/마지막할말 제외)

심지어 꼬리질문도 하나도 없고....

이게 꼬리질문 여부 자체가 좋은/나쁜 시그널임을 판단할 수 있는 기준이 아니란 것을 머리로는 알지만

막상 현장에서 겪으니 아찔하더라구요 ㅋㅋ ㅠㅠ

그래도 신입행원 공채인데 조금 더 열심히 어필하는 모습을 보였어야 됐나...? 그런 아쉬움도 남습니다 ㅠㅠ

병풍같다는 느낌도 받았는데 제발 병풍합ㅠㅠㅠ

끝나고 나서는 같은 조 분들과 사진을 찍었습니다. 포토존을 만들어 두셨더라구요?
사진 찍고 1층 로비에서 사진을 공유받았습니다.

기업은행 최종면접까지 온것도 기념할만한 일이긴 한데... 사진 찍고 떨어지면 마음 아플것같아요 ㅠㅠ

최종면접 결과는 OT 때 6월 4일 ~ 6월 8일중으로 나올것이라고 말씀해주셨습니다.

다만 6월 3일이 공휴일이기도 하고, 이전에도 조기발표됐던 선례가 있어서 6월 2일에 나오진 않을까 내심 기대를 해봤는데 이번엔 조기발표는 없었습니다.

또 최종 점수는 면접시험70% + 실기시험30% 점수 합산으로 계산되는데 (채용공고상 오피셜)

카더라 통신에 의하면 최종면접이 70%로 퍼센트는 높지만, 지원자들 한명 한명을 세세하게 판단하기에는 시간이 짧기도 하고 다들 고만고만해서 변별력이 잘 없기 때문에 실기시험의 점수가 유의미하게 작용한다라는 소문이 있습니다.

최종합격의 경우 오후 4시 20분경부터 직접 전화를 돌리시기 때문에 매일 4시만 넘어가면 긴장되고 일도 손에 안잡히네요 허허...

좋은 결과 있기를!

[BOJ] 1325-효율적인 해킹(Java) - BFS/시간초과

one_dev — Mon, 13 Apr 2026 21:10:33 +0900

BFS로 풀이했다.

구현 자체는 어렵지 않았으나...4번이나 시간초과가 떴다

수정 내용은 다음과 같다.

수정 -> 시간초과를 반복하다 5번째에 통과했기 때문에 각 수정 내용이 얼만큼의 성능 개선을 이루었는지는 모르겠다

요점은 불필요한 반복은 최대한 제거했다는거(물론 더 제거할 여지가 있을수도 있다)

1. 큐 구현체 LinkedList → ArrayDeque 변경

아래는 Claude가 설명해준 내용임
캐시 효율 — 현대 CPU는 메모리를 캐시 라인 단위(보통 64바이트)로 읽어옵니다. ArrayDeque는 연속 메모리라 한 번 캐시에 올라오면 다음 요소도 이미 캐시에 있어요. LinkedList는 노드가 힙 곳곳에 흩어져 있어서 매번 캐시 미스가 발생합니다.
GC 부담 — LinkedList는 노드 객체를 계속 생성/소멸하므로 GC가 더 자주 돌아요. BFS처럼 enqueue/dequeue가 수백만 번 일어나면 차이가 납니다.
시간복잡도는 동일 — offer/poll 모두 O(1)이라 Big-O로는 구분이 안 되고, 실제 상수 계수에서 차이가 납니다.
그럼 LinkedList는 언제 쓰나?
- List 인터페이스도 동시에 필요할 때, 즉 중간 삽입/삭제를 인덱스로 자주 해야 할 때입니다. 순수하게 Queue/Deque로만 쓴다면 ArrayDeque가 항상 우선입니다. Java 공식 문서에도 Queue가 필요하면 LinkedList보다 ArrayDeque를 권장한다고 명시되어 있어요.

2. 정답 출력시 반복문에서 System.out.print 호출 → StringBuilder 사용

3. 방문여부 체크용 visited 배열을 매 bfs마다 초기화 (new boolean[]) → 전역 변수로 뺴고 Arrays.fill(visited, false); 로 초기화

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;

public class Main {
	static List<List<Integer>> list = new ArrayList<>();
	static boolean[] visited= new boolean[10001];
	static int[] arr;
	static int max;
	static int n;
	static int m;
	
	public static void main(String[] args) throws NumberFormatException, IOException {
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		StringTokenizer st = new StringTokenizer(br.readLine());
		
		n = Integer.parseInt(st.nextToken());
		m = Integer.parseInt(st.nextToken());
		arr = new int[n+1]; // i번 컴퓨터에서 시작해 해킹할 수 있는 컴퓨터 수
		max = 0;
		
		// 인접리스트 초기화
		for(int i = 0; i <= n; i++) {
			list.add(new ArrayList<>());
		}
		
		// 0. 다음 m개의 줄에 신뢰하는 관계 입력
		for(int i=0; i< m; i++) {
			st = new StringTokenizer(br.readLine());
			// a가 b를 신뢰한다 -> b를 해킹하면 a도 해킹할 수 있다
			int a = Integer.parseInt(st.nextToken());
			int b = Integer.parseInt(st.nextToken());
			
			list.get(b).add(a); // b를 해킹할 연달아 해킹할 수 있는 컴퓨터 리스트에 a를 넣는다
		}

		// 1. n개의 컴퓨터에 대해 반복문을 돌며 각 컴퓨터에서 해킹할 수 있는 컴퓨터 수를 arr에 저장
		for(int i=1; i<=n; i++) {
			Arrays.fill(visited, false);
			arr[i] = bfs(i);
		}
		
		// 2. 정답리스트를 오른차순 정렬 ->  정렬 없이 출력준비 동시에
		StringBuilder sb = new StringBuilder();
		List<Integer> answerList = new ArrayList<>();
		for(int i=1; i <=n; i++) {
			if(arr[i] == max) {
				answerList.add(i);
				sb.append(i).append(' ');
			}
		}
		
		// 출력
//		for(int k : answerList) {
//			sb.append(k).append(' ');
//		}
		System.out.println(sb.toString());
	}
	
	private static int bfs(int p) {
		int rv=1;
		
//		Queue<Integer> que = new LinkedList<>();
		Queue<Integer> que = new ArrayDeque<>();
		que.add(p);
		visited[p] = true;
		
		while(!que.isEmpty()) {
			
			int cur = que.poll();
			List<Integer> targetList = list.get(cur);
			for(int target : targetList) {
				if(!visited[target]) {
					que.add(target);
					visited[target] = true;
					rv++;
				}
			}
		}
		
		max = Math.max(max, rv);
		
		return rv;
	}
}

[백준] 16928-뱀과 사다리 게임(JAVA) (BFS , Map)

one_dev — Sat, 4 Apr 2026 16:28:15 +0900

※ 아이디어

현재 위치에서 주사위를 굴려 이동할 수 있는 번호를 큐에 담는다
이 때 그 칸이 사다리/뱀인 경우 → 사다리/뱀을 타고 도착하게될 칸의 번호로 담는다
사다리/뱀을 타고 이동하는 경우 주사위를 굴려 이동하는게 아니기 때문에 카운팅은 하지 않는다
사다리, 뱀의 정보는 꺼내 쓰기 좋게 Map을 사용하는게 좋겠다고 생각했다 ( O(1) 이니까)
문제에서 항상 100번 칸에 도착할 수 있는 입력만 주어진다 라고 했으니 큐에서 꺼낸놈의 번호가 100이면 바로 종료
(큐의 특성상 주사위를 굴린 횟수가 1, 1, ..., 1, 2, 2, ..., 2, 3, 3, ... 이런식으로 될거기때문에)

※ 놓쳤던 점

처음에는 사다리/뱀을 타고 도착하게 될 칸도 방문 체크를 했었는데, 그렇게 하게 되면 다른 경우를 체크하지 못할 수 있다
- 예) 사다리를 타고 50번에 도착해 방문체크를 했다 가정 → 주사위를 굴려 50번에 도착하거나, 뱀을 타고 50번에 도착하는 경우를 거르게 됨
사다리/뱀을 타고 도착한 곳에 또 사다리/뱀이 있는 경우를 생각하지 못했다

[맞은 코드]

import java.io.*;
import java.util.*;

public class Main {
	static int n;
	static int m;
	static boolean[] visited;
	static Map<Integer, Integer> ladderMap = new HashMap<>();
	static Map<Integer, Integer> snakeMap = new HashMap<>();
	
	public static void main(String[] args) throws IOException {
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		StringTokenizer st = new StringTokenizer(br.readLine());
		
		n = Integer.parseInt(st.nextToken()); 
		m = Integer.parseInt(st.nextToken());	
		visited = new boolean[101];
		
		// 1. 사다리 정보 입력
		for(int i=0; i<n; i++) {
			st = new StringTokenizer(br.readLine());
			int ladderIndex = Integer.parseInt(st.nextToken());
			int ladderDestination = Integer.parseInt(st.nextToken());
			ladderMap.put(ladderIndex, ladderDestination);
		}
		// 2. 뱀 정보 입력
		for(int i=0; i<m; i++) {
			st = new StringTokenizer(br.readLine());
			int snakeIndex = Integer.parseInt(st.nextToken());
			int snakeDestination = Integer.parseInt(st.nextToken());
			snakeMap.put(snakeIndex, snakeDestination);
		}
		
		int rv = bfs();
		
		System.out.println(rv);
	}
	
	private static int bfs() {
		// 3.bfs로 탐색
		Queue<int[]> que = new LinkedList<>(); // {위치, 주사위굴린 횟수}
		que.add(new int[] {1, 0}); // 시작위치=1, 굴린횟수=0
		visited[1] = true;
		
		while(!que.isEmpty()) {
			int[] curNode = que.poll();
			int curIndex = curNode[0];
			int curTry = curNode[1];
			
			if(curIndex == 100) {
				return curTry;
			}
			
			for(int i=1; i<=6; i++) {
	            int nextIndex = curIndex + i;
	            if(nextIndex > 100) continue;
	            
	            int dest = getDestination(nextIndex); // 사다리/뱀 최종 목적지 계산 (사다리 타고 도착한 곳에 또 사다리/뱀이 있는 경우 등)
	            
	            if(!visited[dest]) {
	                visited[dest] = true;
	                que.add(new int[] {dest, curTry + 1});
	            }
	        }
		}
		
		return 0;
	}
	
	// 사다리/뱀이 있으면 최종 목적지까지 한번에 이동
	private static int getDestination(int pos) {
	    while(ladderMap.containsKey(pos) || snakeMap.containsKey(pos)) {
	        if(ladderMap.containsKey(pos)) pos = ladderMap.get(pos);
	        else pos = snakeMap.get(pos);
	    }
	    return pos;
	}
}

[틀린 코드]

- 사다리/뱀을 타고 이동할 때 방문체크를 했었다

import java.io.*;
import java.util.*;

public class Main {
	
	public static void main(String[] args) throws IOException {
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		StringTokenizer st = new StringTokenizer(br.readLine());
		
		int n = Integer.parseInt(st.nextToken()); 
		int m = Integer.parseInt(st.nextToken());	
		boolean[] visited = new boolean[101];
		
		// 1. 사다리 정보 입력
		Map<Integer, Integer> ladderMap = new HashMap<>();
		for(int i=0; i<n; i++) {
			st = new StringTokenizer(br.readLine());
			int ladderIndex = Integer.parseInt(st.nextToken());
			int ladderDestination = Integer.parseInt(st.nextToken());
			ladderMap.put(ladderIndex, ladderDestination);
		}
		// 2. 뱀 정보 입력
		Map<Integer, Integer> snakeMap = new HashMap<>();
		for(int i=0; i<m; i++) {
			st = new StringTokenizer(br.readLine());
			int snakeIndex = Integer.parseInt(st.nextToken());
			int snakeDestination = Integer.parseInt(st.nextToken());
			snakeMap.put(snakeIndex, snakeDestination);
		}
		
		// 3.bfs로 탐색
		Queue<int[]> que = new LinkedList<>(); // {위치, 주사위굴린 횟수}
		que.add(new int[] {1, 0}); // 시작위치=1, 굴린횟수=0
		int minTry = 17;
		
		while(!que.isEmpty()) {
			int[] curNode = que.poll();
			int curIndex = curNode[0];
			int curTry = curNode[1];
			
			visited[curIndex] = true;
			
			if(curIndex == 100) {
				minTry = Math.min(minTry, curTry);
			}
			
			// 현재 위치가 사다리 또는 뱀이면 주사위를 굴리지 않고 바로 이동
			if(ladderMap.containsKey(curIndex)) {
				que.add(new int[] {ladderMap.get(curIndex), curTry}); // 주사위는 안굴리기 때문에 1 증가 해주지 않음
				continue;
			}
			if(snakeMap.containsKey(curIndex)) {
				que.add(new int[] {snakeMap.get(curIndex), curTry}); // 주사위는 안굴리기 때문에 1 증가 해주지 않음
				continue;
			}
			
			for(int i=1; i<=6; i++) { // 주사위를 굴려서 나올수 있는 경우 6가지
				int nextIndex = curIndex + i;
				if(nextIndex<= 100 && !visited[nextIndex])
					que.add(new int[] {nextIndex, curTry + 1});
			}
		}
		
		System.out.println(minTry);
	}
}

[ORACLE] 오라클 TNS

one_dev — Wed, 4 Mar 2026 20:59:44 +0900

※ 일을 하다보니 타 업체의 DB에 붙어야할 경우가 생긴다.

당연하게도 접속정보를 알아야하는데, tnsnames.ora 정보를 처음 받았을 때 당혹감이란....

이것저것 값 끼워맞춰보면서 몇시간만에 접속 성공한 경험은 두번 다시 안하고 싶다...

TNS에 대해 잘 알면 도움이 될것같아 정리한 포스팅

1. TNS (Transparent Network Substrate) 란?

Oracle이 개발한 네트워크 프로토콜 스택
Oracle에 접속하는 방법 중 하나이다 (클라이언트가 접속할 때 쓸 수도 있고 서버가 접속할 때 쓸수도 있는)
Oracle DB에 접속할 때 '어디에, 어떻게 연결할지' 를 적어두는 전화번호부 같은 것
- 전화를 걸때, 번호를 직접 입력해 전화할 수도 있지만 연락처에 저장돼있다면 연락처만으로 전화를 걸 수 있는 느낌
다음과 같은 파일로 구성된다
- tnsnames.ora
  - 클라이언트 alias 정의
  - 클라이언트 측에서 DB접속 별칭을 정의할 수 있다 (alias)
- listener.ora : 서버 수신 설정
- sqlnet.ora : 네트워크 옵션

2. TNS 구조

MY_ALIAS =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.100)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = mydb)
    )
  )

위처럼 정의하면 개발자가 @MY_ALIAS 라고만 써도 Oracle이 알아서 192.168.1.100:1521/mydb 를 찾음

사진 링크 : https://bangu4.tistory.com/13

ALIAS
- tnsnames.ora에서 정의하는 접속 별칭
- 클라이언트에서 @MY_ALIAS로 접속 시 이 블록 전체를 참조함
DESCRIPTION
- 하나의 접속 정보 묶음 최상위 블록
- 접속하고자 하는 타겟 데이터베이스의 정보
- ADDRESS(네트워크 정보)와 CONNECT_DATA(DB 정보)를 감싸는 컨테이너
ADDRESS
- PROTOCOL
  - 통신 프로토콜
  - 보통 TCP 많이 사용
- HOST
  - DB 서버 IP 또는 호스트명
- PORT
  - Oracle Listener 포트
CONNECT_DATA
- SERVER : 접속 방식
  - DEDICATED(전용 프로세스) / HARED(공유)
- SERVICE_NAME
  - DB 서비스명. listener.ora의 서비스명과 반드시 일치해야 함
  - SERVICE_NAME 대신 SID를 쓰는 경우도 있음
  - SERVICE_NAME vs SID (별도 포스팅에서 자세하게 다룰 예정)
    - SERVICE_NAME : 논리적 서비스 단위, RAC 환경 및 Oracle 9i 이후 권장
    - SID : 물리적 인스턴스 식별자, 구버전 방식

3. Java에서의 TNS 활용

// Thin 방식 (TNS alias 사용)
String url = "jdbc:oracle:thin:@MY_ALIAS";

// Thin 방식 (호스트IP:PORT:SID 등 직접 기술)
String url = "jdbc:oracle:thin:@192.168.1.100:1521:ORCL";

// OCI 방식 (tnsnames.ora 필수)
String url = "jdbc:oracle:oci:@MYDB";

/* [Thin] 방식
- 순수 Java로 구현된 드라이버로, Oracle 클라이언트 설치 없이 동작
- JVM만 있으면 어디서든 실행 가능
- 별도 Oracle Client 설치 불필요
*/

/* [OCI]
- Oracle Call Interface의 약자로
- Oracle Client 라이브러리를 JNI로 호출하는 방식
- Oracle Client설치/ tnsnames.ora 파일 필수
- 성능은 Thin보다 유리한 경우도 있으나, 환경 의존성이 높음
*/

자주 발생하는 오류
- ORA-12541 : No Listener
  - Listener가 꺼져 있거나 포트 막힘
- ORA-12154 : TNS could not resolve alias
  - tnsnames.ora에 alias 없음 또는 경로 오류
- ORA-12170 : Connect timeout
  - 네트워크 방화벽, 잘못된 HOST//PORT 등
- ORA-12514 : Listener does not know service
  - SERVICE_NAME 불일치

[MySQL] GROUP BY 와 임시테이블(메모리 설정으로 쿼리 성능 개선이 가능했던 건에 대하여)

one_dev — Mon, 9 Feb 2026 22:42:27 +0900

1. 문제상황과 해결

업무를 하는데 특정 화면에서 Proxy Error 라는 화면이 뜬다는 버그를 접수받았다.

확인해보니 쿼리 실행시간이 너무 오래걸려 타임아웃이 뜬것이었다.

141만건 정도 되는 데이터를 GROUP BY 집계하는 것이 문제였다

정확한 시간은 기억이 안나지만 약 5분간 로딩이 돌다 타임아웃이 뜬것으로 기억한다.

처음 1시간은 인덱스 설계 및 도입을 해보았으나 이미 인덱스는 많이 있었고 인덱스로 해결되는 문제가 아니었다.

다음 2시간 정도는 쿼리 최적화를 진행했으나 더이상의 최적화가 사실상 불가능한 구조였다.

이 과정중 쿼리를 쪼개 소요시간을 측정한 결과 group by가 포함된 서브쿼리에서 가장 많은 시간이 소요됨을 확인했다.

그리고 group by 실행시 내부적으로 임시테이블이 생성되는데, 이 테이블이 어디에 생성되는지(메모리 vs 디스크)에 따라 속도에 큰 영향을 미칠 수 있음을 알게되었다.

실제로 세션 레벨에서 메모리를 늘려 임시테이블이 메모리에 생성되게 해보니 기존에 쿼리 실행에만 2분이상 걸리던것이 20~25초로 줄어들었다.

2. GROUP BY의 내부 동작 원리 (MySQL 기준) - 임시테이블 생성

(1) 데이터 스캔

(2) 임시테이블 생성 ← 스캔한 데이터를 집계

(3) 임시테이블의 각 행을 순회하며 집계

(4) 결과 반환

# 회계원장에서 20XX-XX-XX 일자 이전의 모든 내역을 group by로 처리하던 상황


# MySQL은 GROUP BY를 처리할 때 다음 과정을 거침:

## 1단계: 데이터 스캔
┌──────────────────────────┐
│  부서  │  과목  │  금액  │
├──────────────────────────┤
│ A      │ X      │ 100    │
│ B      │ Y      │ 200    │
│ A      │ X      │ 150    │ ← 같은 그룹
│ C      │ Z      │ 300    │
│ A      │ X      │ 50     │ ← 같은 그룹
└──────────────────────────┘

## 2단계: 임시 테이블 생성
┌───────────────────────────┐
│  부서  │  과목  │  금액  │
├───────────────────────────┤
│ A      │ X      │ 0      │
│ B      │ Y      │ 0      │
│ C      │ Z      │ 0      │
└───────────────────────────┘

## 3단계: 각 행을 순회하며 집계
for each row:
    group_key = (row.부서, row.과목)
    temp_table[group_key] += row.금액

## 4단계: 결과 반환

문제는 임시테이블에 어디 생성되냐에 있었다

내 클로드는 메모리가 디스크보다 약 500빼 빠르다고한다(헉)

## 임시 테이블: 메모리 vs 디스크

### 메모리 임시 테이블 (빠름 ⚡)

RAM에 해시 테이블 생성
┌──────────────────────────┐
│ Hash Table (in Memory)   │
├──────────────────────────┤
│ (A,X) → 300             │ ← O(1) 접근
│ (B,Y) → 200             │
│ (C,Z) → 300             │
└──────────────────────────┘

접근 속도: 나노초 (0.000001ms)
처리량: ~50 GB/s


### 디스크 임시 테이블 (느림  )

/tmp 디렉토리에 파일 생성
┌──────────────────────────┐
│ File: /tmp/ML123456      │
├──────────────────────────┤
│ Offset 0: (A,X) → 300    │
│ Offset 512: (B,Y) → 200  │
│ Offset 1024: (C,Z) → 300 │
└──────────────────────────┘

접근 속도: 밀리초 (5-10ms)
처리량: ~0.1 GB/s (HDD)

3. GROUP BY의 접근 패턴 (랜덤 I/O vs 순차 I/O)

group by 는 랜덤I/O 패턴을 가짐

왜 GROUP BY는 랜덤 I/O인가? → 데이터가 정렬되어 있지 않기 때문

141만건을 group by 할 때 각 행마다 임시테이블의 해당 그룹을 랜덤하게 찾아야 하고

디스크에서는 매번 헤드 이동이 필요하다.

적고보니 2~3분 걸린거만해도 적게걸린게 아닌가 싶긴하다.

# 회계원장 테이블 실제 저장 순서
일자 | 부서 | 계정
2023-01-15 | C      | Z
2023-01-10 | A      | X
2023-01-20 | B      | Y
2023-01-12 | A      | X  ← A-X가 떨어져 있음
2023-01-18 | C      | Z  ← C-Z도 떨어져 있음


# 임시 테이블 접근

1행 처리: C-Z 그룹 찾기 (임시테이블 offset 5000)
2행 처리: A-X 그룹 찾기 (임시테이블 offset 0)     ← 점프
3행 처리: B-Y 그룹 찾기 (임시테이블 offset 2500)  ← 또 점프
4행 처리: A-X 그룹 찾기 (임시테이블 offset 0)     ← 다시 점프

→ 매 행마다 임시 테이블의 다른 위치로 점프

---
### 메모리 vs 디스크에서 랜덤 I/O

#### 디스크 (HDD)에서 랜덤 I/O

디스크 헤드가 물리적으로 이동해야 함:

1. 현재 위치: Track 100, Sector 50
2. 목표 위치: Track 500, Sector 30
3. 헤드 이동 시간: 5-10ms (Seek Time)
4. 회전 대기 시간: 0-8ms (Rotational Latency)
총 접근 시간: 평균 10ms

141만 건 × 10ms = 14,100초 (약 4시간!)
→ 실제로는 캐싱으로 더 빠르겠지만 여전히 매우 느림


#### 메모리 (RAM)에서 랜덤 I/O

전기 신호로 즉시 접근:

1. 메모리 주소 계산: 0x1A2B3C4D
2. 메모리 컨트롤러가 해당 주소로 즉시 접근
3. 접근 시간: 50-100ns (나노초)

141만 건 × 0.0001ms = 0.14초
→ 랜덤이든 순차든 거의 차이 없음


# 핵심 차이

디스크 랜덤 I/O: 위치 이동이 병목
메모리 랜덤 I/O: 위치 이동 비용이 거의 0


### 실제 성능 차이

141만 건 GROUP BY 처리

디스크 임시 테이블 (랜덤 I/O):
┌────────────────────────────┐
│ 1. 원장 테이블 읽기: 5초     │ (순차 I/O)
│ 2. 임시테이블 업데이트:    │
│    - 141만번 랜덤 접근     │
│    - 각 접근마다 10ms      │
│    - 캐시 적중률 50%       │
│    = 약 28초              │ (랜덤 I/O 병목)
│ 3. 정렬: 8초              │
├────────────────────────────┤
│ 총: 33초                   │
└────────────────────────────┘

메모리 임시 테이블 (랜덤 I/O):
┌────────────────────────────┐
│ 1. 원장 테이블 읽기: 5초     │ (순차 I/O)
│ 2. 임시테이블 업데이트:    │
│    - 141만번 랜덤 접근     │
│    - 각 접근마다 0.0001ms  │
│    = 약 0.14초            │ (랜덤 I/O 영향 없음)
│ 3. 정렬: 6초              │
├────────────────────────────┤
│ 총: 11초                   │
└────────────────────────────┘

개선: 28초 감소 (랜덤 I/O 병목 제거)


### 왜 메모리는 랜덤 I/O에 강한가?

#### HDD (기계식)
┌─────────────────────────┐
│   회전하는 플래터        │
│   ●───────────────●     │
│   │               │     │
│   └─ 헤드가 이동 ─┘     │
└─────────────────────────┘

랜덤 접근 시:
1. 헤드를 목표 트랙으로 이동 (물리적 이동)
2. 플래터가 회전해서 목표 섹터가 올 때까지 대기
3. 데이터 읽기/쓰기

→ 물리적 이동이 병목!

#### SSD (전자식)
┌─────────────────────────┐
│   Flash 메모리 셀        │
│   [][][][][][][]        │
│   [][][][][][][]        │
└─────────────────────────┘

랜덤 접근 시:
1. 컨트롤러가 주소 계산
2. 해당 셀로 전기 신호 전달
3. 데이터 읽기/쓰기

→ 순차보다는 느리지만 HDD보다 훨씬 빠름

#### RAM (메모리)
┌─────────────────────────┐
│   메모리 칩              │
│   [][][][]...           │
│   주소 버스로 직접 접근  │
└─────────────────────────┘

랜덤 접근 시:
1. 메모리 주소 계산 (즉시)
2. 주소 버스로 접근 (즉시)
3. 데이터 읽기/쓰기 (즉시)

→ 순차든 랜덤이든 속도 동일

4. 세션단에서 메모리 증가

- 왜 세션단에서 메모리 증가시켰나?

- (1) 나에게 DB 설정을 변경할 수 있는 권한은 없음

- (2) 설정파일 수정하면 mysql 재시작 필요. 운영중인 고객사 서버라 중단할 수가 없었음

SET SESSION tmp_table_size = 536870912;      -- 512MB
SET SESSION max_heap_table_size = 536870912; -- 512MB
SET SESSION sort_buffer_size = 67108864;     -- 64MB

# 자바에서 쿼리 실행하기전에 위의 쿼리 먼저 실행
Statement stmt = conn.createStatement();

 stmt.execute("SET SESSION tmp_table_size = 536870912");
 stmt.execute("SET SESSION max_heap_table_size = 536870912");
 stmt.execute("SET SESSION sort_buffer_size = 67108864");

[COS PRO 1급 기출문제] (1차) 5.소용돌이 수 (Java) - 구현/dp

one_dev — Wed, 4 Feb 2026 22:22:53 +0900

생각의 흐름은 이러했다

→ 일단 배열만 만들면 구하는건 최대 n번 연산 안에 끝나니까 괜찮지 않을까

→ 그래도 배열 만들기 전에 규칙성 있으면 활용하고 싶은데?

→ 규칙성 찾다가 포기, 일단 구현으로 해보자

→ 구현 후 규칙성 발견해 dp풀이

(1) 구현 (소용돌이 수 만들기)

소용돌이 수 배열을 만든 다음에 대각선의 합을 구하는 방식이다

class Main {
    public int solution(int n) {
        // 1. n x n 격자 생성
        int[][] grid = new int[n][n];
        
        // 2. 소용돌이 수 채우기
        int num = 1;
        int row = 0, col = 0;
        int[] dr = {0, 1, 0, -1}; 
        int[] dc = {1, 0, -1, 0};
        int dir = 0; 

			for (int i = 0; i < n * n; i++) {
            grid[row][col] = num++;
            
            if (i == n * n - 1) break; // 마지막 숫자
            
            // 다음 위치 계산
            int nextRow = row + dr[dir];
            int nextCol = col + dc[dir];
            
            // 방향 전환이 필요한 경우
            if (nextRow < 0 || nextRow >= n || nextCol < 0 || nextCol >= n 
                || grid[nextRow][nextCol] != 0) {
                dir = (dir + 1) % 4; // 방향 전환
                nextRow = row + dr[dir];
                nextCol = col + dc[dir];
            }
            
            row = nextRow;
            col = nextCol;
        }
			 // 3. 대각선 합 구하기
        int answer = 0;
        for (int i = 0; i < n; i++) {
            answer += grid[i][i];
        }

        return answer;
    }

(2) dp

격자는 크게 두 개로 나눌 수 있다 : 바깥 껍데기와 내부의 격자로

→ 내부의 격자는 한바퀴를 돌아 바깥 껍데기가 완성된 후에 채워지기 시작하므로, (바깥껍데기의 길이 + 1) 부터 시작한다

→ 내부 격자의 모든 값에서 이 (바깥 껍데기의 길이 + 1) 을 빼면, 1부터 시작하는 소용돌이 수가 된다

→ dp[n] = [바깥 껍데기의 양 끝 수] + dp[n-2] + [바깥 층 크기 x 내부 격자 대각선 원소의 개수]

소용돌이 배열이 포함하고 있는 가장 큰 소용돌이 배열은 (4n-3) 부터 시작하는 소용돌이 배열

n=4 일떄를 예시로 보면 내부 격자에서 바깥 테두리 크기인 12를 빼면 1부터 시작하는 소용돌이 수임을 알 수 있다

class Main {
    public int solution(int n) {
        int[] dp = new int[n + 1];
        
        if (n >= 1) dp[1] = 1;
        if (n >= 2) dp[2] = 4;
        
        // DP 계산
        for (int i = 3; i <= n; i++) {
            int outer = 1 + (2 * i - 1);  // 바깥 층 양 끝
            int layerSize = 4 * i - 4;     // 바깥 층 크기
            int innerCount = i - 2;        // 안쪽 대각선 원소 개수
            
            dp[i] = outer + dp[i-2] + layerSize * innerCount;
        }
        
        return dp[n];
    }

dp 의 경우 뭔가 설명을 이거보다 더 잘할 수 있을거같은데 적절한 워딩이 생각이 안난다...

[TypeDB] TypeQL 개요

one_dev — Wed, 28 Jan 2026 14:24:42 +0900

0. TypeQL 개요

- 공식홈페이지 소개 : " TypeQL is the declarative, strongly-typed, and intuitive query language used by TypeDB."

( TypeQL은 TypeDB에서 사용하는 선언적이고 강력한 타입의 직관적인 쿼리 언어입니다.)

- TypeDB를 조작하기 위한 자체 쿼리언어이다

1. TypeQL 주요 키워드 및 구문 ( $, sub, owns, isa, has)

본 포스팅은 문법을 설명하기 위함은 아니지만, 알아두면 아래의 내용들을 이해하는데 도움이 될것같아 먼저 서술함

1) $ : 변수 선언 기호

변수는 쿼리 내에서 재사용 가능

# $u, $n, $f 등은 모두 변수
match
  $u isa user, has username $n;
  $f (friend: $u) isa friendship;
  
  # 변수 사용 예시
  
  match
  # $person 변수에 user 엔티티를 할당
  $person isa user;
  
  # $person이 가진 username 속성 값을 $user_name 변수에 할당
  $person has username $user_name;
  
  # $person이 가진 email 속성 값을 $mail 변수에 할당
  $person has email $mail;
fetch
  $user_name;  # username 값만 가져오기
  $mail;       # email 값도 가져오기

2) sub : 상속/하위 타입 정의(계층 구조 정의)

"~의 하위 타입이다" 라는 뜻

define

  user sub entity;   	# user는 entity의 하위 타입이다 (user는 엔티티의 한 종류)
   
  admin sub user;		 # admin은 user의 하위 타입이다 (admin은 user의 한 종류)
  
  username sub attribute, value string;  	# username은 attribute의 하위 타입이다
  
  friendship sub relation;   # friendship은 relation의 하위 타입이다
  
  #계층구조 예시
  
  define
  # 사람은 엔티티의 하위 타입이고 이름(name)을 속성으로 가진다
  person sub entity,
    owns name;
  
  # 직원은 사람의 하위 타입이고 사번(employee-id) 속성으로 가진다
  employee sub person,
    owns employee-id;
  
  # 관리자는 직원의 하위 타입이고 부서(department)를 속성으로 가진다
  manager sub employee,
    owns department;

3) owns : 속성 소유 정의

엔티티나 관계가 특정 속성을 가질 수 있음을 정의

define
  # user는 username과 email 속성을 소유할 수 있음
  user sub entity,
    owns username,  # username 속성 소유 가능
    owns email;     # email 속성 소유 가능
  
  # friendship 관계도 속성을 소유할 수 있음
  friendship sub relation,
    relates friend,
    owns since,     # since 속성 소유 가능
    owns strength;  # strength 속성 소유 가능 (예: 친밀도)
   
# owns 수식어로는 @key, @unique, @card 등이 있다
define
  user sub entity,
    # @key: 이 속성은 고유해야 함 (중복 불가, 필수)
    owns email @key,
    
    # @unique: 이 속성은 고유해야 함 (중복 불가, 선택사항)
    owns username @unique,
    
    # @card: cardinality, 속성 개수 제한
    owns phone-number @card(1..3);  # 최소 1개, 최대 3개

4) isa : 인스턴스 타입 지정

" ~~ 는 ~~의 인스턴스이다" 라는 뜻
~~ISA계좌 아님~~
데이터 삽입이나 조회시 사용

# 데이터 삽입
insert
  # $u1은 user 타입의 인스턴스
  $u1 isa user, has username "김철수";
  
  # $f는 friendship 타입의 인스턴스
  $f isa friendship;
  
# 데이터 조회
match
  # user 타입의 모든 인스턴스를 $u에 할당
  $u isa user;
  
  # admin 타입의 모든 인스턴스를 $a에 할당
  $a isa admin;

5. has : 속성값 지정/조회

insert
  # user 인스턴스를 생성하면서 속성 값 지정
  $u isa user,
    has username "김철수",    # username 속성에 "김철수" 값 할당
    has email "kim@test.com"; # email 속성에 "kim@test.com" 값 할당
    
match
  # user 타입이면서 username 속성을 가진 것을 찾음
  # 그 username 값을 $n 변수에 할당
  $u isa user, has username $n;
  
  # 특정 username 값을 가진 user 찾기
  $u isa user, has username "김철수";
  
  # username이 "김철수"이고 email도 가진 user 찾기
  $u isa user,
    has username "김철수",
    has email $e;  # email 값은 $e 변수에 할당

2. 엔티티(Entity), 속성(Attribute), 관계(Relation)

1) 엔티티 (Entity)

독립적으로 존재할 수 있는 개념이나 객체
데이터베이스의 주요 대상(예: 사용자, 회사, 제품 등)
RDB의 테이블과 유사하지만 더 유연한 타입 계층 구조 지원

define  # 정의 시작
  
  user sub entity,			# user라는 엔티티 타입 정의 (entity의 하위 타입)
    owns username,  		# user는 username 속성을 가질 수 있음
    owns email;     		# user는 email 속성을 가질 수 있음
  
 
  company sub entity, 		# company라는 엔티티 타입 정의
    owns company-name;  	# company는 company-name 속성을 가질 수 있음

2) 속성 (Attribute)

엔티티나 관계가 가지는 실제 데이터 값
여러 엔티티가 동일한 속성 값을 공유 가능
속성 자체가 독립적인 개념으로 존재 (RDB의 컬럼 값과 차이점)

define

  username sub attribute, value string;   # username이라는 속성 타입 정의, 값의 타입은 문자열(string)
  
  email sub attribute, value string;   # email이라는 속성 타입 정의, 값의 타입은 문자열(string)
  
  company-name sub attribute, value string;   # company-name이라는 속성 타입 정의, 값의 타입은 문자열(string)

엔티티와 속성은 객체지향 프로그래밍의 "클래스-멤버변수"의 관계와 유사하지만 차이점이 있음

(1) TypeDB의 속성은 "엔티티와 관계없이 독립적으로 존재" (Java를 예시로 들면 Java는 각 객체마다 별도로 값을 저장하는 반면, TypeDB속성은 속성값을 한 곳에 저장하고 여로 엔티티가 참조)
(2) TypeDB에서는 속성 자체를 검색할 수 있음
(3) TypeDB에서는 속성도 속성을 가질 수 있음 (메타데이터)
그래프 데이터베이스의 노드-엣지 관계에 더 가까움

### 엔티티와 속성: OOP와의 비교

## 엔티티와 속성의 관계는 얼핏 보면 클래스와 멤버변수의 관계와 동일해보임

# Java 클래스
public class User {
    private String username;
    private String email;
}


# typeql
define
  user sub entity,
    owns username,
    owns email;


# 차이점
1. 속성의 독립성: TypeDB의 속성은 데이터베이스에 독립적으로 존재하며, 여러 엔티티가 동일한 속성 값을 공유할 수 있음
2. 속성의 속성: 속성 자체도 다른 속성을 가질 수 있음 (메타데이터)
3. 값 기반 검색: 속성 값으로 직접 검색하여 해당 값을 가진 모든 엔티티를 찾을 수 있음

3) 관계 (Relation)

엔티티들 간의 연결을 표현
관계 자체도 속성을 가질 수 있음
n-ary 관계 지원 (2개 이상의 엔티티 연결)
relates로 역할 정의, plays로 참여 가능한 엔티티 지정

define
  
  friendship sub relation,			# friendship이라는 관계 타입 정의 (relation의 하위 타입)
    relates friend,  				# friendship 관계는 'friend'라는 역할을 포함함
    owns since;      				# friendship 관계는 since 속성을 가질 수 있음
  

  user sub entity,					# user 엔티티가 friendship 관계에서 friend 역할을 할 수 있음
    plays friendship:friend;  		# 'friendship 관계의 friend 역할'을 수행
  

  since sub attribute, value datetime;		  # since라는 속성 타입 정의, 값의 타입은 날짜시간(datetime)

4) TypeDB의 최상위 타입(root type) : entity, relation, attribute

entity, relation, attribute 3가지 타입은 Java의 Object 클래스처럼 자동으로 존재함
사용자가 정의한 모든 타입은 이 3가지 중 하나의 하위 타입이어야 함

## 타입 계층 구조

entity (최상위 엔티티 타입)
  ├─ person
  │   ├─ employee
  │   │   ├─ manager
  │   │   └─ developer
  │   └─ customer
  ├─ company
  └─ product

relation (최상위 관계 타입)
  ├─ employment
  ├─ friendship
  └─ ownership

attribute (최상위 속성 타입)
  ├─ name (value string)
  ├─ age (value long)
  └─ email (value string)

5) 실제 사용 예시

스키마 정의

define
  # user 엔티티 타입 정의
  user sub entity,
    owns username,              # user는 username 속성 소유 가능
    plays friendship:friend;    # user는 friendship 관계에서 friend 역할 수행 가능
  
  # friendship 관계 타입 정의
  friendship sub relation,
    relates friend @card(2),    # friend 역할은 정확히 2명이어야 함 (cardinality)
    owns since;                 # friendship은 since 속성 소유 가능
  
  # 속성 타입들 정의
  username sub attribute, value string;    # 문자열 타입
  since sub attribute, value datetime;     # 날짜시간 타입

데이터 삽입 (Data pipeline)

insert
  # $u1 변수: "김철수"라는 username을 가진 user 엔티티 인스턴스 생성
  $u1 isa user, has username "김철수";
  
  # $u2 변수: "이영희"라는 username을 가진 user 엔티티 인스턴스 생성
  $u2 isa user, has username "이영희";
  
  # $f 변수: $u1과 $u2를 friend 역할로 연결하는 friendship 관계 생성
  # 이 관계는 2024-01-01이라는 since 속성 값을 가짐
  $f (friend: $u1, friend: $u2) isa friendship,
    has since 2024-01-01;

데이터 조회

match
  # $u 변수: user 타입의 인스턴스를 찾음
  # $n 변수: 그 user가 가진 username 속성 값을 찾음
  $u isa user, has username $n;
  
  # $f 변수: $u가 friend 역할로 참여하는 friendship 관계를 찾음
  $f (friend: $u) isa friendship;

# match에서 찾은 결과 중 $n(username 값)만 가져옴
fetch
  $n;

3. 스키마쿼리(Schema queries)와 데이터 파이프라인(Data piplines)

TypeQL은 크게 스키마쿼리( Schema queries) 와 데이터 파이프라인( Data pipelines) 으로 나뉜다.

+ TypeDB 3.0 이상부터 지원하는 함수(Functions)도 있다

스키마쿼리(Schema queries) : 스키마를 정의
- 단일 단계로 구성됨 (single-stage)
- 데이터베이스 스키마를 수정한다
- 성공확인 메세지 반환 / 별도의 내용 출력하지 않음
- 키워드 : define, undefine, redfine 등
데이터 파이프라인 (Data pipelines)
- 여러 단계로 구성됨 (mutli-stage)
- 데이터베이스에서 데이터를 읽고 쓰며 데이터를 출력함
- 키워드 : match, select, sort, reduce, insert, delete 등
함수(Functions) : 함수는 형식화된 입력 인수를 받는 데이터 파이프라인 템플릿
- 재사용이 가능한 쿼리 템플릿, 지정된 입력 인자를 받음
- 함수는 데이터를 쓰기/삭제 불가
- insert , delete 등의 쓰기 단계에(write stage) 포함할 수 없음
- 키워드 : match, select, sort, reduce 등
(참고) 스테이지(stage) : 데이터 파이프라인을 구성하는 개별 단계(step)
- 문장(statements) 으로 구성된다
- (예) define 스테이지는 다음과 같은 문장으로 구성됨 : user owns username
- (예) match 스테이지는 다음과 같은 문장으로 구성됨 : $u has username $n 또는 $type owns username

쿼리 유형(Query Type)	역할	스테이지 키워드 (Stage keywords)	Multi-stage 여부
스키마 쿼리 (Schema queries)	schema stages	define, undefine, redefine	no
데이터 파이프라인 (Data pipelines)	read and write stages	match, select, sort, reduce, insert, delete, …	yes
함수 (Functions)	read stages	match, select, sort, reduce, …	yes

4. 정의문과 패턴문(Definition vs Pattern statements)

Definition 과 patterns 는 TypeQL 에서 각자 다른 역할을 맡는다.

(1) Definition statements (변수 없음)

Schema queries는 항상 정의문과 함께 사용
타입 정의, 인터페이스 정의, 상속 관계 선언
type definition, interface definition, subtyping definition 3가지 종류로 나뉜다
- type definition : 적절한 키워드로 새로운 타입을 정의한다
- interface definition :

define
  entity user, plays friendship:friend;
  relation friendship, relates friend @card(2);

(2) Pattern statements (변수 있음)

Data pipelines와 Functions에서 사용
Data pipelines은 항상 패턴문과 함께 사용
변수를 포함한 쿼리 패턴
타입 조회, 데이터 검색, 함수 호출, 값 계산 등

match
  $some-type plays $some-role;
  friendship relates $some-role;

[TypeDB] TypeDB Core(CommunityEdition) 설치 (linux, podman)

one_dev — Sun, 18 Jan 2026 10:08:59 +0900

공식홈페이지가 잘돼있다. 본 포스팅은 linux 를 기준으로 포스팅 했지만 macOS, Windows 운영체제도 공홈에 잘 나와있다.

※ 공식홈페이지 : https://typedb.com/docs/home/install/ce/

1. 서버에 직접 설치(컨테이너 X)

(1) 설치

# 설치 스크립트
curl -sSL https://typedb.com/install.sh | sh && export PATH="$HOME/.typedb:$PATH"

# 또는 apt 사용
sudo apt install software-properties-common apt-transport-https gpg
gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-key 17507562824cfdcc
gpg --export 17507562824cfdcc | sudo tee /etc/apt/trusted.gpg.d/typedb.gpg > /dev/null
echo "deb https://repo.typedb.com/public/public-release/deb/ubuntu trusty main" | sudo tee /etc/apt/sources.list.d/typedb.list > /dev/null
sudo apt update
sudo apt install typedb

(2) 실행

typedb server

2. 컨테이너에 설치 (podman)

[TMI] 왜 컨테이너에 설치하려고 했는지?

typeDB를 설치하게 된 계기는 운영중인 테스트서버에 깔아보라는 디렉션이 내려와서...

> 운영중인 테스트 서버는 자바버전이 전부 8인데, typeDB 2 버전 이상부터는 자바 11 이상이 요구된다고 한다.

> typeDB 1.xx 버전을 설치하면 되긴 하지만 그래도 현재 3버전까지 나온 시점에 2버전 이상은 깔고싶었다.

> 하지만 운영중인 서버의 자바 버전을 임의로 올려버릴 수도 없었다(아무리 테스트서버라고 해도)

→ 컨테이너에 깔자!! 라는 결론이 나왔다...

원래는 Docker 설치 후 도커 컨테이너에 typeDB 설치하려고 했으나 "podman" 이란게 깔려있어 도커 설치할 때 충돌났다.

찾아보니 podman은 레드햇에서 만든 컨테이너 시스템으로 도커와 기능, 명령어 대부분 유사하다고 해서 podman 컨테이너에 설치했다

docker도 거의 비슷한 방식으로 하면 될듯함

# (1) podman 통해 typeDB 실행 (실행시 이미지 다운)
sudo podman run -d \
  --name typedb \
  --restart unless-stopped \
  -p 1729:1729 \
  -v typedb-data:/opt/typedb-all-linux/server/data \
  -v typedb-logs:/opt/typedb-all-linux/server/logs \
  docker.io/vaticle/typedb:latest
  
# 컨테이너 실행 확인
sudo podman ps

# 로그 확인 (TypeDB가 정상 시작되었는지)
sudo podman logs typedb

# (2) TypeDB 콘솔 접속(CLI)
sudo podman exec -it typedb ./typedb console

[TypeDB] TypeDB 란?

one_dev — Thu, 15 Jan 2026 22:52:39 +0900

1. TypeDB 란?

TypeDB : 지식그래프 (Knowledge Graph) 데이터베이스, 온톨로지(Ontology) 기반 데이터베이스

TypeDB 공식 홈페이지에서 말하는 TypeDB : "강력한 타입 시스템을 갖춘, 다형성을 지원하는 범용 트랜잭션 데이터베이스" 입니다 (이건 추상적인듯)

(*) 공식 홈페이지 설명 : https://typedb.com/docs/home/what-is-typedb/

- 기존의 RDB, NoSQL 과 차이점은 TypeDB는 "관계" 에 중점을 둠 (엔티티-관계 중심)

- 저장된 데이터를 조회만 가능한 RDB, NoSQL과 다르게 DB레벨에서 추론 기능을 지원

- "관계", "의미", "추론"

RDB	NoSQL	TypeDB
테이블과 행으로 데이터 구조화	유연한 데이터 구조	엔티티-관계-속성 모델
외래키로 테이블 간 관계 표현	수평 확장성에 최적화	의미론적 관계 표현
복잡한 조인 연산에 최적화	수평 확장 용이	복잡한 그래프 탐색에 강함, 조인 없이 관계 쿼리
인덱스를 통한 빠른 검색	대용량 데이터 처리	대용량 처리는 RDB/NoSQL 대비 제한적
생태계 방대함	생태계 보통	생태계 작음

2. TypeDB 특징

TypeQL 이라는 자체 쿼리 언어 사용
강력한 타입 시스템 : TypeDB에서는 타입을 생성하여 스키마를 작성 데이터 구조를 명확하게 정의하고, 타입 안정성을 보장
다형성 지원 : 객체지향 프로그래밍의 상속 개념처럼, 데이터 타입들 간의 계층 구조와 상속 관계를 표현
그래프 기반 : 관계형 DB처럼 테이블이 아니라, 엔티티들 간의 관계를 자연스럽게 표현하는 구조로 복잡한 JOIN 없이도 연결된 데이터를 쉽게 다룰 수 있음
개념적 모델링(Conceptual Schema)
- 전통적인 DB는 물리적 테이블 구조부터 설계하지만, TypeDB는 온톨로지처럼 '개념'과 '관계'를 먼저 정의
- 예) 회계 시스템에서 '계정과목', '부서', '거래' 같은 개념들과 그들 간의 관계를 의미론적으로 표현
의미론적 관계 표현(Semantic Relationships)
- 단순히 외래키로 연결하는 게 아니라, 관계 자체가 '의미'를 가짐
- '소속되다', '승인하다', '포함하다' 같은 관계를 명시적으로 정의할 수 있음
추론 능력(Reasoning)
- 온톨로지의 핵심인 '추론' 기능을 지원
- 명시적으로 저장되지 않은 데이터도 규칙을 통해 추론해낼 수 있음
- 예) "A부서가 B부서의 상위부서이고, B가 C의 상위부서면 → A는 C의 조상부서다" 같은 규칙을 정의하면 자동으로 추론
계층 구조와 상속(Taxonomy & Inheritance)
- OWL 같은 온톨로지 언어처럼 타입 계층을 만들 수 있음
- '법인' → '금융법인' → '은행', '증권사' 이런 식의 분류체계를 자연스럽게 표현하고, 상위 타입의 속성과 관계를 하위 타입이 상속받음

Window 11 작업표시줄 아이콘 깨질 때

one_dev — Tue, 12 Aug 2025 21:26:58 +0900

윈도우 업데이트 후 부팅할 때마다 자꾸 작업표시줄 아이콘이 깨진다;;

(윈도우 업데이트 할때마다 뭐가 이상해져서 하기싫어서 미루다 자동 업데이트 당해버린....)

크게 3가지 방법을 소개했는데 결국은 윈도우탐색기를 재시작하는 것이니 취향껏 골라하면 될듯하다.

1. 탐색기 재시작

2. 그래도 안되면 아이콘db 캐시 삭제 후 재시작

- AppData > Local 경로 접속 > IconCache.db 파일 삭제 후 재시작 (숨긴 항목 체크해야 보임)

IconCache.db 삭제

3. 명령어로도 삭제&재부팅 가능함

cmd 창 열고 아래 명령어 순서대로 실행 (윈도우 검색에 cmd 또는 명령 프롬프트 검색)

그 다음 아래 명령어 4줄 한줄씩 실행 -> 작업표시줄이 잠깐 사라졌다가 원상복구되는걸 볼 수 있다

각 줄의 의미는

(1) 파일탐색기 태스크 강제 종료

(2), (3) 캐시 삭제

(4) 파일탐색기 재시작

정도로 이해하면 될듯하다

taskkill /f /im explorer.exe
attrib "%userprofile%\appdata\local\iconcache.db" -s -r -h
del /q "%userprofile%\appdata\local\iconcache.db"
start explorer.exe

필자는 3번의 명령어를 bat파일로 만들어 실행하는 편임.

(메모장 등 열어서 3번 명령어 복사 -> 이후 파일 확장자를 .bat로 변경 -> 파일 더블클릭하면 자동으로 4줄 실행됨)