kimyoungjo (김영조)

그동안 뭘 했고 앞으로 뭘 할건가 2부

Sun, 06 Jul 2025 10:45:15 +0900

3번째 직장

이전과는 다르게 취업에 있어 자신은 있는 상태였다. 짧은 시간이었지만 시간과 노력을 정말 갈아넣었던지라 베이스가 어느정도 다져진 상태였고, 무엇보다 이 업계가 이런 경험있고 현장 대응이 가능한 신입에 목말라 있다는걸 어느정도 알고 있었기 때문에 그렇게 조급하지 않았다. 해서 이번엔 지원서를 난사하기 보다는 상장사 혹은 200명 이상의 비교적 규모가 큰 기업에만 지원을 했다.

5곳 정도에 지원했고 그 중 3곳에서 연락이 와 면접을 진행했다. 위치는 인천, 천안, 안양 이었던걸로 기억한다. 그 중 그나마 좀 가까운 인천 소재의 회사를 선택했고 입사하게됐다. 경력이 약간 있다지만 기간이 너무 짧았기에 면접때에도 기존 연봉 보존만 되면 좋을 것 같다고 말씀드렸는데 앞자리를 바꿔주셔서 좀 놀랐던 기억이 남아있다.

새로 오게된 직장은 기존 직장들과 비슷하게 자동화 검사 설비를 납품하는 곳이었다. 다만 차이가 있다면 그동안은 3차벤더 회사들을 다녔다면 이번엔 2차 벤더 회사로써 원청과 한 단계 더 가깝게 일을 할 수 있었다.

입사 초반 3개월은 그냥 놀았다고 봐도 무방하다. darknet 객체 탐지 오픈소스를 회사의 요구사항에 맞게끔 dll화 하는것이 과제였는데 원래는 이 dll을 실제 프로젝트에 도입하려고 했으나 원청에서 자사 기술을 쓰고싶다고 하여 엎어졌다. 과제 자체가 취소된건 아니어서 과제는 완료했지만, 그 외 다른일이 주어지지는 않았어서 비교적 여유로운 회사생활을 약 3개월정도 보냈다.

그렇게 3개월을 소위 '날먹'을 하고 드디어 첫 업무가 주어졌다. 위치는 구미이고, 현장에 납품이 진행되고 있는 설비에 관련된 프로젝트에 합류했다. 설비의 스케일은 내가 맡았던 모든 업무를 다 합쳐도 부족해보일정도로 압도적이었다. 하나의 물체에 대해 수십장의 사진을 촬상하고 딥러닝 + 룰기반 검사가 진행되는데 그 물체의 개수가 수십개였다. 내가 거의 유일하게 꺼려질 정도로 어려워하는 개념이 멀티스레딩과 같은 동시성 처리였는데 이번 프로젝트는 내 약점을 보완하라고 명령이라도 하듯 동시성 처리의 극에 있는 프로젝트였다.

구미에서의 일정은 본사때와는 완전히 달랐다 우선 08시 30분 출근에 퇴근 시간은 정해져 있지 않아 새벽에 퇴근하기 일쑤였고 주말도 없었다. 힘들지 않다면 거짓말이지만아직 밝히지 않은 나의 2026년 상반기의 목표가 이런 빡센 일정과 관련이 있기 때문에 그렇게 나쁘게만 보고 있지는 않다. 그리고 개발은 언제나 재미있기에 힘들지만 즐겁게 구미 생활을 이어가고 있다.

회사에 들어오기 전에 나름대로 어떤 점들이 힘들지에 대해 생각을 하고 그것을 어떻게 대응할지 생각을 했었는데, 예상하지 못했던 한 가지가 클린룸이었다. 반도체 제조 현장에서 먼지 등을 최소화 하기웨해 점프슈트 + 신발 + 마스크+ 장갑을 끼고 입실해야하는 곳이 클린룸이었는데 심지어 인터넷도 되지 않아 개발에 있어 검색, LLM 에 의존했던 과거의 내가 원망스러워질 정도였다. 그래서 얼마전부터 주말 중 하루는 LLM과 구글검색을 제외하고 IDE에만 의존해서 코딩을 하고 있다. 이 부분이 진짜 너무 힘들었고, 극복 할 수 있는 문제인지 장담을 못하겠다는 생각을 했다.

현재 한창 진행중인 프로젝트기에 지금 단계에서 말 할 수 있는 내용이 별로 없어서 나중에 회고를 따로 하려고한다. 회고에 어떤 내용을 기재할지에 대해 키워드를 정리하고 있는데 정말 할 말이 많을 회고글이 되지 않을까 싶다. 정말.. 정말 많은 일이 있었다.

작년 이맘때쯤엔 학원에 틀어박혀서 미래에 대한 고민을 하고 있었는데 지금은 일이 너무 많아 어떻게 처리할지에 대해 고민하고있는게 신기하기도하고 뿌듯하기도 하다. 뜬금없는 내용이긴 하지만 학원에서 같이 공부했던 분들은 지금 어떻게 지내고 계실까 궁금하기도 하다. 다음 글은 앞으로의 1년에 대한 내용으로 작성해볼 생각이다. 나름의 계획을 가지고 있긴 한데, 좀 더 구체화해서 작성해보도록 해야겠다.

(~25.06.15) 그동안 뭘 했고 앞으로 뭘 할건가 1부

Sun, 15 Jun 2025 20:58:03 +0900

작년 10월에 비전 개발자로써 커리어를 시작해 지난 2월 3번째 회사에 입사하여 현재까지 재직중이다. 그 동안 어떤일이 있었는지 간략하게 기록해보려한다.

첫번째 직장

작년 10월 경 10명 규모의 국가 과제 위주를 수행하는 자동화 검사설비 업체에 비전 개발자로 취업했다. 비전팀은 책임님과 나 둘이었고 darknet이라는 c기반의 백본과 yolo라는 객체 탐지 모델을 이용하여 대상 물체의 외관 결함을 탐지하는 방식의 솔루션을 제공하였다.

나는 관련 지식이 거의 전무했기에 교육이 필요했지만 너무나 작은 규모의 팀 + 국가 과제의 특성상 연말에 결산이 들어가는데 내가 입사한 10월말 부터 12월까지는 회사가 정말 바빠 케어를 받지 못한 채 스스로 관련 지식을 습득했어야 했다. 지금 생각해보면 이 때 claude를 활용하면서 ai 서비스 활용 능력이 크게 늘었다고는 생각하지만 그때 당시는 정말 하루하루 멘탈이 무너져갔던 기억이 있다.

멘탈이 무너졌던 요인으로는 11월 중순부터 프로젝트에 단독으로 투입될 것 이라는 예고에 대한 압박감과 타지 생활 적응 실패라는 두가지 요인이 악재로 다가왔던것 같다. 처음 겪어보는 기술스택과 방식을 한달 이내에 습득하기엔 쉽지않아 평일 주말, 낮밤을 가리지 않고 메달렸던 기억이 난다. 내 선생님이었던 claude의 크래딧이 부족해 구글 계정을 하나 더 생성하여 2개의 claude 계정의 굴렸던 기억이 난다.

이 때 안산 다문화 거리에 있는 고시원에서 지냈었는데, 다문화 거리 특유의 스산한 분위기 + 좁디 좁은 고시원이 심적으로 편안함을 제공해야했던 집의 역할을 하지 못했다. 하여 몸과 정신은 하루하루 지쳐갔던 기억이 있다.

그렇게 예고됐던 11월 중반부터 12월 중순까지의 기한이 주어진 프로젝트에 투입되었다. 알루미늄 소재의 배터리 케이스 외관검사를 진행하는 것이었는데 단순한 객체 탐지 딥러닝 모델 학습 뿐만 아니라 카메라 + 촬영 환경을 뜻하는 광학환경, PLC와의 통신, 딥러닝 모델과 Winform 간의 tcp 통신, 카메라 트리거를 조절하기 위한 배선 설계까지 모두 담당해야했던 터라 정말 어느하나에 집중해서 학습을 할 수 없었던 기억이 난다. 그런데도 어찌저찌 기한은 맞춰야하니 그럴듯한 무언가를 만들어냈는데 하드웨어 설비에 들어가는 프로그램 특성상 디버깅을 설비를 돌리면서 진행해야하는 여건때문에 첫 디버깅이 프로젝트 기한이었던 12월 중순이었던 기억이 난다. 무교지만 그 날만큼은 어떤 신이던 믿고 싶었을 정도로 기도메타로 디버깅에 임했던 것 같다.

기한이 분명 12월 중순이었지만 정신을 차려보니 어느새 1월 중순으로 미뤄저있었다. 이유는 국가 사업의 특성상 국가가 프로젝트 비용의 절반을 지원했으니 국가의 심사를 받아야하는데 설비에 하드웨어적 에러가 너무 많이 발생하여 12월 내 마무리가 불가능하다는 판정을 내리고 원청과 협동하여 심사에 대비하기 위해 그럴듯한 시퀀스를 조작해야한다는 이유였다. 이 과정속에서 소프트웨어인 내 파트는 계속 밀리게 되었다. 그리고 더 이상 해당 설비를 조작하는 일은 없었다. 내가 12월 31일자로 퇴사했기 때문이다.

두번째 직장

공개할 수 없는 이유(궁금하시면 메일 주세요)로 첫번째 회사를 2달여만에 그만두고 1월에 바로 이직을 하게 되었다. 첫번째 직장과 비슷한 일을 비슷한 규모로 진행하는 업체였다. 그리고 이 곳에서 3주만에 내 실력을 300% 이상 끌어올려주신 책임님을 만났다.

새로 만난 책임님은 천재과에 속하는 분이셨던것으로 기억된다. 어떠한 문제를 마주했을때 해당 문제를 다각도로 분석하시며 누구도 생각치 못했던 방향으로 문제를 해결하시며 과제를 해결해오셨다고 한다. 처음에는 약간 과장이 섞인 소개라고 생각했지만 곧 그 부분들을 체감하며 인정하게 되었다.

이전 직장과 가장 큰 차이점은 온보딩 기간이 있었다는 것이다. 그리고 그 온보딩 기간동안 책임님 주도의 ojt 역시 있었다. 이전에 진행하셨던 프로젝트를 따라가며 앞으로 사용할 기술스택과 작업 시퀀스에 대해 학습할 수 있게끔 엑셀로 정리된 파일을 주셨고 각 단계마다 코드리뷰를 받듯 책임님의 체크와 질문 폭탄이 있었다. 그 과정속에서 가장 많이 들었던 말이 왜 이렇게 진행하셨나요 ? 다른 방법은 없었나요 ? 이다. 그런 과정을 몇차례 겪어보니 나도 체크를 받을때 다양한 관점에서 고민한 흔적들을 준비하여 체크를 받았었는데, 그럼에도 불구하고 더 창의적인 다른 안을 제시받았을 정도로 생각치도 못한 방안을 내놓아 주셨다. 일전의 소개가 과장이 아님을 이 때 체감을 많이 했고 나 역시 이 때 문제 해결을 위한 사고력을 많이 길렀던 것 같다. 이대로 이 분께 1년만 배우면 정말 큰 성장을 할 수 있으리라 생각했다. 하지만 그 시간을 길지 않았고 나는 1달도 채 되지 않아 퇴사하였다.

이 바닥 업무의 특성상 파견, 출장이 잦다. 파견과 출장이 잦다는 것은 부대비용이 발생한다는 것이다. 보통은 회사에서 그것을 지원해주는게 당연한 것이라고 생각했고 첫번째 직장도 그러했는데 두번째직장은 기본급 외의 수당이 제로였다. 심지어는 식대조차 지원이 되지 않았다.

직장을 다니면서 내 심각한 단점을 알게됐다. 바로 압박감에 대한 대처가 전혀 안됨 + 그로 인한 멘탈적 문제가 심각하다는 것이었다. 나를 믿어주고 응원해주거나 내가 완벽한 주도권을 가지고 일을 할때는 가진 능력 이상의 능률을 보이지만 강압적 분위기 + 내가 결정할 수 있는 사안이 없어지면 능력의 1/5도 발휘를 못한다는 것을 첫번째 직장과 두번째 직장을 거치며 느꼈고 주변인들에게 물어보니 " 응 너 원래도 그랬어 " 라는 대답을 들었다.

그래서 왜 퇴사했냐 앞선 두 문단에 묘사된 문제와 내가 이 회사에 온 이유인 책임님이 회사를 떠나실 예정이라는 사실을 알게됐기 때문이다. 안그래도 자금난에 허덕이고 있던 나는 식대조차 지원되지 않는 환경에서 정말 고생을 많이 했다. 식대만 지원되지 않는 환경이었다면 잘 아끼면서 그럭저럭 다녔겠지만 밥은 또 다같이 먹자가 회사의 모토라 매 끼니마다 만원 이상의 식비가 빠져나갔다. 내가 퇴사의사를 밝히자마자 당일 퇴사를 당했었는데, 해당 주에는 밥값이 없어 어머니께 손을 벌렸을 정도였다.

두번째 이유였던 강압적 분위기의 형성은 회사가 개발팀을 믿지 못한다는 뉘앙스의 말에서 시작됐다. 이 부분은 상세하게 말하기 좀 그래서 어떻게 표현해야할 지 모르겠는데 앞서 말한 내 특징은 신뢰받지 못함 + 강압적인 분위기에서 퍼포먼스를 낼 수 없다 이기 때문에 내 역량을 발휘할 수 없을 것 같다고 판단했다.

사실 앞서 두 이유는 부가적인 이유들이고 제일 큰 이유는 새 책임님이 사라지신다는 점이었다. 그 점 때문에 두번째 이유였던 개발팀에 대한 압박이 강하게 들어왔던 것으로 추정된다.(빈자리를 메워야하니) 뭐 그런것을 차치하고서 내가 이 회사에 오게된 이유엿던 책임님의 퇴사 소식은 나에게 더 이상 이 회사를 다녀야하는 이유를 사라지게 하는데 충분했다.

설 연휴가 매우 길었던것으로 기억하는데 해당 연휴 시작전에 퇴사했다. 그게 최소한의 예의라고 생각해서 그렇게 했는데 다음에 만약에 이런일이 있다면 그러지 않을 것 같다.

그렇게 다시 취준생활이 시작됐고 생각보다 일찍 취업이 됐다.

-계속-

CUDA Toolkit 설치중 멈춤 이슈(Visual Studio 2022)

Mon, 24 Feb 2025 10:23:36 +0900

모델 학습을 위해 GPU 활용을 도와주는 CUDA 설치중 특정 작업에서 멈추는 현상을 발견했다.

이런식으로 Visual Studio가 명시된 작업에서 installing이 진행되지 않는 현상이 발생하는데 CUDA 커뮤니티를 뒤져본 결과 Visual Studio 2022가 2월 12일 자로 17.13 버전으로 업데이트 되며 발생한 문제인것으로 확인된다. CUDA 커뮤니티 관련 글

해당 글에서 제시된 해결책은 Visual Studio 2022를 17.12이하의 버전으로 다운그레이드 하거나, Visual Studio 2022를 삭제후 CUDA를 설치하고 Visual Studio 2022를 재설치 하는것이다.(Visual Studio 2022가 설치돼있지 않은 상태에서 CUDA를 설치하라는 뜻)

필자는 댓글에 제시된 다운그레이드 방법을 시도했으나 잘 되지 않아 삭제후 설치를 진행했고 Visual Studio가 없는 상태에서 CUDA 설치를 진행 후 Visual Studio를 재설치해도 Visual Studio 상에서 CUDA를 이용한 빌드에 문제가 없음을 확인했다. 물론 관련 의존성은 dll이나 lib 등을 복사 붙여넣기로 옮기듯이 직접 해줘야한다.

+CUDA 12.6 뿐만 아니라 11.8 에서도 해당 이슈가 발생하는 것을 확인했습니다. 특정 버전의 CUDA 문제가 아닌 전 버전의 CUDA 설치에 동일한 이슈가 발생하는 것으로 추측됩니다.

+Visual Studio 2022 professional 을 사용할 수 있는 여건이 된다면 https://learn.microsoft.com/ko-kr/visualstudio/releases/2022/release-history 해당 링크에서 professional 버전에 한하여 구버전을 제공하고 있으니 17.12 이하의 버전을 설치하여 사용하면 되겠다.(필자도 현재 이렇게 사용중)

2025년에 쓰는 2024 회고록

Tue, 14 Jan 2025 20:34:50 +0900

2024년은 참 많은 일이 있었다. 그 많은 일들 중 큰 일들이 일어났던 1, 4, 5, 10, 12월에 있었던 일들을 중심으로 2024년을 회고해보려한다.

1월

유일하게 남아있는 그 때의 흔적

여러 사정으로 진로에 대해 고민하고 있던 1월에 학교 선배 형의 결혼식에 다녀왔다. 카톡으로만 연락이 왔던 터라 그냥 봉투만 할까 하다가 2019년에 선배 형들과 다녔던 학원의 기억이 너무 좋았어서 얼굴도 뵐 겸 다녀오기로 했다. 학부생 시절 여러가지 자조적인 이유로 전공을 살려 무엇을 하겠다 라는 마음이 하나도 없었는데 결혼식장에서 뵌 선배들은 모두 전공을 살려 관련 직종에 종사하고 있는 모습을 보면서 마음 속 보이지 않는 구석으로 치워두었던 개발에 대한 생각이 다시 피어올랐던 것으로 기억한다. 그렇게 2024년 목표를 개발자로의 취업으로 정했던 대전에서의 1월이 기억나 회고의 시작점으로 삼았다. 참고로 그때는 1-2달 열심히 하면 되겠지 라고 가볍게 생각했었다. 훗날에 어떤 시련이 기다리고 있는지 모른채..

4월

그 당시 친구들 단톡방에 남겼던 짤

나름의 결의를 다졌다고 생각한 1월에 비해 2-3월은 매우 초라했던 기억이 있다. 무슨 자신감이었는지 지금 돌이켜보면 준비를 거의 안한 상태에서 첫 취업 도전을 했던 것 같다. 당시에 인프런에서 C# 관련 강의 하나를 듣고 해당 강의 내용을 따라간 것을 통으로 github 에 올리고 그것을 포트폴리오랍시고 이력서에 끼워 돌렸던 것으로 기억한다. 지금 생각해보면 정말 무슨 자신감이었는지 궁금할정도로 준비된게 없었고 자신감엔 차있던 상태였다. 가서 배우면 되지 라는 생각이 제일 컸던 것 같다.

당연하게도 처참하게 깨졌다. 서류 통과 자체를 하지 못했었다. 그 때 자기객관화 라는 것을 배우게 된 것 같다. 그 자기객관화의 내용은 "난 혼자서는 할 수 없다." 였다. 그래서 학원을 알아보기 시작했고 운이 좋게도 5월 7일에 개강하는 학원 과정에 참여할 수 있었다. 개념을 배운다기 보다는 정해진 시간동안 나를 특정 일정 속에 가둬두고 싶었다. 그렇게라도 하지않으면 도저히 효율이 나올 것 같지 않았었고 실제로도 그랬다.

5월

학원에 등원하기 전 약 1주일정도 쿠팡알바를 했다 쿠팡에서 나눠준 신발인데 외관과 착화감이 나쁘지 않아 신기했다.

본격적인 학원 등원 전에 뭔가 마음을 다잡고 싶어서 1주일 정도 쿠팡 알바를 했다. 길게 서술하긴 그렇지만 진짜 인생 최악의 1주일이었다. 몸이 힘들다기 보다는 소위 빨간조끼(관리 계약직)들의 갈굼이 좀 견디기 힘들었다. 업무때 다그치는거는 이해하겠는데 쉬는시간때 이동을 빨리하라고 다그친다거나 업무가 예상보다 빨리 끝나 창고 청소를 하고 있을때도 다그침을 넘어서 닦달을 하는 모습을 보고 인간이 싫어지는 순간이었다. 이런 현장 노가다직이 좀 잘 맞으면 개발자고 뭐고 때려치고 공장이나 갈까 생각했는데 바로 철회하고 사무직이 되기 위해 노력하기로 결심했던 순간이었다.

학원에 대해서는 길게 말하지 않으려한다. 원래 취업하면 작심발언을 좀 하려고 했는데 굳이 긁어 부스럼을 만들 이유가 있나 싶다. 뭐 한 줄 요약하자면 국비 학원 == 세금 도둑 이다. 조속한 폐지가 맞는 것 같다.

그래도 개념적으로 배운 것은 없지만, 한 달마다 약 80만원 정도의 용돈 + 공부 할 수 있는 공간으로써의 가치는 매우 높았다. 학원 교육은 내게 무익했지만 학원이라는 시스템은 내게 유익했다. 덕분에 취업했으니 말이다.

10월

취업 기념으로 구매한 노트북

이전에 작성 했던 글 처럼 10월에 취업하여 10월 21일에 첫 출근을 하였다. 그 이후 있었던 이야기를 좀 해보자면, 학원에서 5개월간 난 자신감에 가득 차 있었다. 프로젝트, 팀 같은 것도 모두 내가 리딩을 했고 무엇보다도 이 상태로 현업에 나가면 실력은 좀 부족 할지언정 주도적으로 일을 할 수 있을 것 같았다. 근데 저 실력 부족의 이슈가 생각보다 훨씬 더 크더라. 배우는데 급급하다보니 주도적으로 일을 하기 보다는 맡은 일을 쳐내는데에 급급해진 나를 볼 수 있었다.

그럼에도 불구하고 버텨냈다. 회사 일이라 구체적으로 말을 하긴 그렇지만 아무튼 버텨냈다. 정말 포기하고싶은 순간이 있었지만 버텨냈다. 그 결과 꽤 큰 프로젝트를 혼자 맡아 완벽하진 않지만 마무리해냈다. 뭔가 좀 더 구체적으로 표현하고싶은데 아직 어디까지 말을 해도되는지 몰라 이번에는 여기까지만 말 하는게 좋겠다. 아무튼 내게 있어 2024년이 정말 힘든 해 였다면, 10월, 11월은 그 중에서도 특히 더 힘들었다. 그래도 힘든만큼 그보다 더 많은 것들을 얻어갈 수 있어서 좋았다. 특히 그동안의 고민은 할 수록 나 자신이 정체되고 도태되는 느낌이었는데 이번 4분기때 했던 모든 행동들과 고민들은 적어도 나 자신이 앞으로 나아가고 있음을 느낄 수 있는 행복한 시간이었다.

12월

이직을 하게되었다.

뭔 벌써 이직이냐 하겠지만, 많은 일이 있었고, 정신을 차려보니 이직이 되어있었다. 관련 이야기는 나중에 할 수 있게되는 날이 있을 것 같다.

아무튼 2025년부터 새 직장을 다니고 있고 많은 일들을 겪을 예정이다. 이번 연단위 회고를 쓰면서 느낀점이 참 글 쓰기라는게 어렵다 라는 생각이 든다. 안그래도 글재주가 부족한 편인데, 1년동안 있었던 일들을 축약해서 작성하다보니 더 횡설수설해지는 느낌이 든다. 앞으로는 최소 월단위 회고를 작성해보려고 한다. 다음글은 아마 1월 회고가 될 것 같은데 그 때 2025년의 목표 소개와 좀 더 깊은 이야기를 할 수 있게 될 것 같다.

올 해 안에 취업하기 -完-

Fri, 18 Oct 2024 02:40:21 +0900

취업했습니다.

올해 다시 개발자로서의 취업에 도전했을 때의 분야는 C# 기반 머신비전 업계였습니다. 그 사이에 여러 가지 현실적인 이유를 들면서 웹 개발로 전환하려 했지만, 이런저런 과정을 거쳐 결국은 처음에 계획했던 C# 머신비전을 다루게 됐습니다.

다행입니다.

저의 지난 20대에는 "합격"이라는 단어가 존재하지 않았습니다. 마지막으로 합격이라는 단어를 접한 것이 언제인지 생각해보니, 2014년 대학교 합격 통보를 받았을 때가 마지막이었습니다. 그때가 19살이었으니, 20대에는 합격이라는 단어가 없었다고 할 수 있겠네요.

그랬던 제가 어떻게 개발자의 꿈을 다시 품게 되었는지는 지금 정확히 기억나지 않습니다. 아마도 올해 초 학교 선배님의 결혼식에서 이미 개발자로서 자리 잡으신 선배님들을 만나면서, 마음 한켠에 빚처럼 치워두었던 개발자라는 꿈이 다시 꺼내어진 게 아닐까 싶습니다.

결코 쉽지는 않았습니다. 당시 오랫동안 학습이라는 행위를 하지 않아 학습의 갈피를 잡지 못하고 헤매던 때도 있었습니다. 하지만 그때마다 제 삶에 찾아온 포스트에 담기 어려운 개인적 이슈들이 적절한 시기에 나타나 마음을 다잡고 최선을 다할 수 있게 해주었습니다.

이렇게 우연히 다시 제게 다가온 개발자라는 꿈과, 당시엔 괴로웠지만 돌아보니 기폭제가 되어준 사건들 덕분에, 인연이 없을 줄만 알았던 '합격'이라는 단어가 천사와 같은 날개를 달고 제 앞에 내려온 것 같습니다. 정말 다행입니다. 그 어떤 표현도 이 '다행'이라는 말을 대체하지 못할 만큼 적절한 표현인 것 같습니다. 정말 다행입니다.

변하지 않겠습니다.

취업을 준비하던 지난 몇 개월 동안 정말 많은 분들을 만났고, 다양한 경험을 했으며, 여러 감정의 변화를 겪었습니다. 가장 감사한 점은 이 모든 과정에서 배운 것들입니다. 많은 분들과의 만남을 통해 제가 다른 사람에게 도움을 주는 것을 좋아한다는 사실을 깨달았고, 여러 상황을 겪으며 제 자신의 개선점을 명확히 알게 되었습니다. 또한 감정의 변화를 겪으면서 삶의 방향성을 잡을 수 있었습니다.

흔한 표현일 수 있지만, 지난 반년간의 힘들었던 취업 준비 기간 동안 가졌던 마음가짐을 잊지 않겠습니다. 이를 항상 자신을 돌아보고 발전시키는 데 활용하여 초심을 잃지 않도록 하겠습니다.

감사합니다.

제가 알기로는 이 blex라는 블로그 서비스에서 활동하시는 대부분의 분들이 저의 학교 선후배님들인 것으로 알고 있습니다. 눈에 띄는 직접적인 교류는 없었지만, blex에서 활동하면서 이러한 연결성이 힘든 시간을 극복할 수 있게 해준 큰 원동력이 되어주었던 것 같습니다.

앞으로는 현직자로서 양질의 포스트를 작성하여 blex라는 블로그 서비스의 질을 높이는 데 기여하도록 하겠습니다. 감사합니다.

올 해 안에 취업하기 -完-

혹시 이 글을 보시는 분들 중 도움이 필요한 개발자 지망생 분들이 계시다면, 제 블로그 프로필에 있는 메일 주소로 편하게 연락 주세요. 제가 할 수 있는 한 최선을 다해 도와드리겠습니다.

스크롤을 항상 최하단으로 유지하는 방법

Thu, 05 Sep 2024 15:01:51 +0900

팀 프로젝트 진행 중 채팅 봇 개발을 위해 채팅창을 퍼블리싱 하고 있었는데 채팅이 많아져 스크롤이 생겼을 때 항상 최신의 채팅 내역을 보여주기 위해 채팅창의 최하단을 항상 보여주고 싶어서 이것저것 알아봤는데 내가 떠올리지 못했던 방향으로 해결 하게 되어 포스팅을 하게됐다.

만든 채팅창 모습

import React, { useState, useEffect, useRef } from "react";

const AiChatBtn: React.FC<AiChatBtnProps> = ({
  onClick,
  children,
  className = "",
}) => {
 // 타 상수값들 생략
  const messagesEndRef = useRef<HTMLDivElement>(null);

  const scrollToBottom = () => {
    messagesEndRef.current?.scrollIntoView({ behavior: "smooth" });
  };

  useEffect(scrollToBottom, [messages]);

  //handleSendMessage 코드 생략

  return (
    <div>
      <div className="bg-white rounded-lg shadow-xl fixed bottom-24 right-10 w-[300px] h-[480px] flex flex-col">
            // 채팅창 헤더 jsx 코드
        <div className="flex-grow p-4 overflow-y-auto bg-gray-100">
          // 채팅창 jsx 코드
          <div ref={messagesEndRef} /> {/* 스크롤을 위한 참조 요소 useRef 이용 */}
        </div>
       // input창 jsx 코드
            />
            <button
             //button jsx 코드
      </button>
    </div>
  );
};

export default AiChatBtn;

useRef

동적인 ui를 만들다보면 특정 요소에만 접근하고 싶은 순간이 있다. tailwind css를 사용하기 전에는 className을 이용하여 접근하곤 했는데 tailwind css를 사용한 후로는 useRef라는 훅을 이용하여 div에 id 값을 매기듯이 지정한 후 참조하는 방식을 사용하고 있다.

위에 제시한 코드에서는 <div ref={messagesEndRef} />로 ref에 이 빈 div를 참조시켰다. 왜 빈 div를 참조시켰는지는 후에 설명하는 다른 내용들을 보면 알 수 있을 것이다.

scrollIntoView()

이번 주제로 포스팅을 하게 된 이유인데 그동안은 window.scrollTo() 이라던가 element.scrollTop 같은 메서드를 사용해왔는데 이번에는 scrollIntoView()를 사용하였다. 이 메서드에 대해 좀 더 알아보자

기본 사용법

element.scrollIntoView(options); 로 사용하고 option 값의 구성은

behavior: 스크롤 애니메이션을 정의한다.
- "auto" (기본값): 즉시 스크롤
- "smooth": 부드러운 애니메이션과 함께 스크롤

block: 요소의 수직 정렬을 정의한다.
- "start": 요소를 뷰포트의 상단에 맞춘다.
- "center": 요소를 뷰포트의 중앙에 맞춘다.
- "end": 요소를 뷰포트의 하단에 맞춘다.
- "nearest" (기본값): 가장 가까운 위치로 스크롤한다.

라는 하나의 메서드에서 옵션값만을 변경하여 다양하게 활용할 수 있다는 점을 알게되어 이번에 사용하게 되었고 그 중에서도 기본값이 nearest를 활용하기 위하여 채팅창의 최하단에 height가 0 인 빈 div를 선언하고 그것을 참조하는 ref를 만들어 해당 ref에 가까운 위치 즉 채팅창의 최하단으로 이동되게끔 하였다. 그리고 smooth 같은 behavior 값을 사용하면 transition을 적용한 것처럼 작동하여 사용자 경험도 쉽게 향상 시킬 수 있었다.

마치며

그래서 결국 기능이 채팅창의 최하단으로 스크롤을 고정시키는 것이라면 앞서 소개했던 두 개의 메서드가 직관성 측면에선 더 좋은게 아니냐는 생각이 들기도 했는데, useRef와 view를 중심으로 한 scrollIntoView() 를 활용하면 차후에 특정 내용이 담긴 div를 찾아가는 기능을 만드는 등의 확장성에 있어서 해당 메서드를 좀 더 높게 평가했고 이번엔 그것을 위한 경험을 해봤다는 것에 의의를 뒀다. 작은 채팅창 하나를 만드는데도 고려 해야 할 부분이 참 많다는 생각이 든다.

Spring Boot의 구조

Tue, 27 Aug 2024 18:00:00 +0900

백엔드에서 중요한 개념 중 하나인 DTO는 계층간 데이터를 전달하기 위해 사용되는 객체이다. 처음에 이 DTO에 대해 공부할 때 저 계층이라는 것이 프론트엔드 - 백엔드 - DB의 계층을 말하는 것인 줄 알았는데 아니었다. 정확히는 Spring Boot의 구성 요소인 프레젠테이션 계층, 비즈니스 계층, 퍼시스턴스 계층의 3계층을 의미하는 것이었고 그것에 대해서 좀 심도있게 알아봤다.

프레젠테이션 계층

엔드 포인트를 이용하여 사용자 인터페이스(UI)와 애플리케이션 간의 상호작용을 담당한다
@Controller, @RestController 어노테이션을 사용한다
HTTP 요청을 받아 적절한 비즈니스 로직으로 전달하고, 그 결과를 다시 클라이언트에게 반환한다.
View 템플릿과 함께 사용되어 동적 웹 페이지를 생성할 수도 있다.

비즈니스 계층

애플리케이션의 핵심 로직을 구현하는 계층이다.
@Service 어노테이션을 사용한다.
데이터 처리, 계산, 규칙 적용 등 실제 비즈니스 요구사항을 코드로 구현한다.
트랜잭션 관리를 담당하여 데이터의 일관성을 유지합니다.
- 트랜잭션이란 데이터베이스에서 데이터의 일관성을 보장하기 위해 일련의 작업을 하나의 단위로 묶어서 처리하는 것이다.

퍼시스턴스 계층

데이터의 영속성을 관리하는 계층이다.
- 영속성이란 데이터를 영구히 저장하여 애플리케이션이나 시스템이 종료나 재시작되어도 데이터가 사라지지 않도록 하는 것을 의미하는 것
@Repository 어노테이션을 사용한다.
데이터베이스와의 직접적인 상호작용을 담당한다 (CRUD 연산 등).
ORM을 사용하여 객체와 관계형 데이터베이스 간의 매핑을 처리한다.

내가 경험해본 백엔드는 express.js 였는데 express에서는 계층을 나누어서 관리하기 보다는 각 엔드포인트 별로 하나의 독립적인 커스텀 메서드를 작성하는 느낌이었는데 Spring에서는 그 독립적이었던 형태가 기술한 3가지의 계층을 토대로 더 세분화된 느낌이다. 익숙해지면 확실히 관리하기엔 편할 것 같다는 생각이 드는데 일단 익숙해지는데에 많은 시간을 투자해야 할 듯 하다.

Spring Boot의 디렉터리 구조

Wed, 21 Aug 2024 17:31:43 +0900

몇 번의 프로젝트를 진행하면서 디렉터리 구조는 항상 후반부에 제 발목을 잡았다. 치밀하게 계획을 해서 프로젝트에 돌입해도 끝에는 코드가 뒤죽박죽 섞여 정리가 안 되는 현상이 반복되어서 항상 고민이었는데, 이번 프로젝트의 백엔드로 선정한 Spring Boot는 MVC 패턴이라는 정해진 구조 패턴이 있어 이번에는 이를 적극 활용하여 깔끔하게 프로젝트를 끝내는 것을 목표로 잡았다.

기본 디렉터리 구조

Spring Boot MVC 프로젝트의 기본 디렉터리 구조는 다음과 같다:

src/
├── main/
│   ├── java/
│   │   └── com/example/project/
│   │       ├── controller/
│   │       ├── service/
│   │       ├── repository/
│   │       ├── model/
│   │       ├── dto/
│   │       └── ProjectApplication.java
│   └── resources/
│       ├── static/
│       ├── templates/
│       ├── application.properties
│       └── application.yml
└── test/
    └── java/
        └── com/example/project/

이제 각 디렉터리의 역할에 대해 자세히 살펴보겠다.

주요 디렉터리 설명

1. controller/

@Controller 또는 @RestController 어노테이션이 적용된 클래스들이 위치한다.
웹 요청을 처리하는 컨트롤러 클래스들이 이 디렉터리에 위치한다.
클라이언트의 요청을 받아 적절한 서비스 계층으로 전달하고, 결과를 다시 클라이언트에게 반환하는 역할을 한다.

2. service/

@Service 어노테이션이 적용된 클래스들이 위치한다.
비즈니스 로직을 담당하는 서비스 계층의 클래스들이 이 디렉터리에 위치한다.
컨트롤러와 리포지토리 계층 사이에서 중간 역할을 하며, 복잡한 비즈니스 로직을 처리한다.

3. repository/

@Repository 어노테이션이 적용된 인터페이스가 위치한다.
JPA를 사용하는 경우, JpaRepository를 상속받은 인터페이스들이 이 디렉터리에 위치한다.
데이터베이스와의 상호작용을 담당하며, 데이터의 조회, 저장, 삭제 등의 작업을 수행한다.

4. model/

@Entity 어노테이션이 적용된 클래스들이 위치한다.
데이터베이스 테이블과 매핑되는 엔티티 객체들이 이 디렉터리에 정의된다.
JPA를 사용할 때 주로 사용되며, 데이터베이스의 테이블 구조를 자바 객체로 표현한다.

5. dto/

DTO(Data Transfer Object) 클래스들이 이 디렉터리에 위치한다.
계층 간 데이터 전송에 사용되는 객체들을 정의한다.
주로 Lombok 라이브러리를 이용하여 getter, setter 메서드를 자동으로 생성한다.

6. ProjectApplication.java

프로젝트의 메인 클래스다.
@SpringBootApplication 어노테이션이 적용되며, 애플리케이션의 시작점 역할을 한다.
Java의 main 메서드와 같이 모든 것의 시작점이 된다.

7. resources/

static/: CSS, JavaScript, 이미지 등의 정적 리소스 파일들이 위치한다.
templates/: Thymeleaf 등의 템플릿 엔진을 사용할 때 HTML 템플릿 파일들이 위치한다.
application.properties 또는 application.yml: 애플리케이션의 설정 정보를 담고 있는 파일이다.

이번 Next 프로젝트에서 Spring Boot의 역할은 일정 시간마다 데이터를 크롤링해와 db를 갱신하고 그 갱신된 데이터를 프론트에게 넘겨주는 역할이다. Next의 자체 백엔드 기능을 사용해도 무리는 없었을 것 같긴 하지만 다양한 디자인 패턴과 RDBMS, 그리고 스프링 컨테이너라는 객체를 중앙에서 관리해주는 방식을 이용하면 내가 원하는 데이터의 가공에 있어서 보다 직관적으로 개발할 수 있을 것 같아 현재 계속 공부중이다. 그동안 개인 노션에 간단히 내용을 정리하면서 관련 개념을 습득했는데 그 개념들을 좀 더 자세하게 풀어서 매일 포스팅을 해 볼 예정이다.

8.14 개발 일지 [YOUR.LOL 제작기]

Wed, 14 Aug 2024 17:45:03 +0900

어제 정상적으로 데이터 안받아와진다는 유저 오늘은 또 잘 됨 ㅋㅋ

개발 일지

AddMatch 컴포넌트를 누를 시 매치 데이터를 추가적으로 받아와 상태 업데이트를 통해 매치 정보를 추가적으로 요청 할 수 있도록 구현
여러 함수에 기능적인 부분 설명 주석 작성 (앞으로 계속해서 추가해나갈 예정)

주절주절

일단 오픈 api로 구현할 수 있는 모든 것은 완성했고 전적 검색 사이트의 코어인 전적 검색 기능을 완성했으니 클라이언트 사이드는 1차적으로 완성을 했다. 이제 이전에 말했던 spring boot와 rdbms를 통해 크롤링한 데이터들을 핸들링하는 백엔드 구성에 총력을 기울일 예정이다. 고민이 좀 되는 지점은 지금 상태도 next가 자체적으로 지원하는 백엔드 기능을 통해 풀스택 프로젝트긴 한데 이를 배포를 해볼까 하는 고민을 하고있다. 아무튼 목금토일 4일간 연휴인데 이 기간동안 spring boot 실습부터 프로젝트에 필요한 기능 완성까지 달려볼 예정이다.

그냥 안됐고 이젠 그냥 됨 [YOUR.LOL 제작기]

Tue, 13 Aug 2024 20:00:34 +0900

받은 피해량과 가한 피해량 막대 그래프를 추가했다.

매치ID를 이용한 매치 정보 요청 API를 백엔드로 옮겼고 클라이언트는 react-query로 리펙토링 했다.

왜

정말 잘 되다가 갑자기 안됐다. 중요한 것은 왜 안됐었는지 아직도 모르겠다는 것이었다.

지금 YOUR.LOL의 전적 검색 구조는 여러번의 API 요청을 통해 ZUSTAND 전역 상태를 업데이트를 해가며 일종의 트리거가 되는 상태들의 변화로 비동기 작업을 동기적으로 진행하는 방식을 채택했는데 아무 변화를 주지 않았는데 갑자기 체이닝의 시작인 PUUID가 ZUSTAND에 업데이트가 되지 않았다. 시작 지점이 적용이 안됐으니 그 뒤는 당연히 안됐고 약 3시간동안 이전 버전을 약 10개정도 테스트 해보면서 뭐가 잘못됐는지를 찾았지만 찾지 못했다. 말 그대로 안 될리가 없는 상황이었다.

인증이 안됐다던지 경로가 잘못됐다던지 서버가 응답을 안한다던지 하는 거의 모든 경우에 예외를 걸어둬서 웬만한 오류는 콘솔에 출력이 될텐데 콘솔창은 깨끗했다. 진짜 눈 앞이 깜깜해진다는게 이런 느낌이구나 했는데 갑자기 잘된다. 정상적으로 ZUSTAND에 업데이트가 되고 원하는 데이터들이 전적 검색 화면에 랜더링 되더라. 진짜 이유를 알고싶어서 이전 버전 코드들과 모두 대조해봤는데 주석 처리를 한 몇 줄 제외하고는 차이도 없다. 진짜 왜 안됐는지 너무 궁금하다.

라이엇 API

진짜 더이상 오픈 API로 징징거리고 싶진 않았는데 왜 특정유저만 티어, 점수 등 RANK 관련 정보가 안받아와질까. 위에 기술했던 사고를 제외하면 오늘 제일 많이 시간을 쏟았던게 이 부분 이었다.

정상적인 경우

비정상적인 경우 승, 패도 맞지 않는 데이터가 왔고 tier도 undefined가 왔다.

이게 내 문제인지 정확하게 확인을 해야 api 탓을 할텐데 아니 근데 진짜 모든 것들을 다 테스트 해봤는데 애초에 데이터가 도착할때부터 undefined로 오는거면 내 잘못은 아니지 않나.. 아무튼 지금은 멘탈이 많이 힘들어서 내일 마무리 지어야겠다.

08.12 개발 일지 + RIOT DATA DRAGON 사용법 [YOUR.LOL 제작기]

Mon, 12 Aug 2024 18:44:49 +0900

드디어 전적 검색 데이터를 다 정리해서 적용하고 그에 맞게 퍼블리싱을 수정했다.

앞으로 할 것

도넛 차트를 이용해보고 싶어 일단 저렇게 구현은 해놨는데 뭔가 휑하고 양질의 정보가 아닌 느낌이 든다. 개선 방향 고민해보기

+버튼 누를시 추가 전적 로드

로딩시 로딩중임을 명시할 수 있는 div 디자인 해보기

로그인 구현 (spring boot + mySQL 이용 예정)

RIOT DATA DRAGON

데이터 드레곤 도큐먼트 링크

리그오브레전드 라는 게임을 주제로 한 프로젝트를 진행하다보니 게임에서 사용하는 이미지들이 필요해졌다. 처음에는 일일히 다운을 받아서 내 s3에 올린 다음 이름을 잘 정제해서 동적으로 사용할 수 있게끔 할까 생각을 해봤는데 라이엇 정도 되는 규모의 게임이면 분명히 게임 내의 이미지 등을 쉽게 가져다 쓸 수 있는 api가 있을 것이라는 생각이 들어 이것 저것 찾아보니 data dragon 이라는 라이엇이 제공하는 api가 있다는 것을 알았다.

https://ddragon.leagueoflegends.com/cdn/14.15.1/img/champion/Aatrox.png 라이엇 챔피언 이미지 가져오기

https://ddragon.leagueoflegends.com/cdn/14.15.1/img/profileicon/685.png 소환사 아이콘

https://ddragon.leagueoflegends.com/cdn/14.15.1/img/spell/SummonerFlash.png 소환사 주문

https://ddragon.leagueoflegends.com/cdn/14.15.1/img/item/1001.png 아이템

여기에 첼린저, 마스터 같은 티어 이미지가 필요했는데, 그건 제공해주지 않고 압축 파일로만 제공해주길래 다운을 받고 내 s3에 적절한 이름을 지어 호스팅 해서 사용 하는 중이다.

주의사항) 위 링크의 버전 부분이 수시로 업데이트 된다고하니 어느날 저 경로가 막혀있다면 riot data dragon에 들어가 현재의 버전을 체크해보길 바란다.

MATCH DATA 활용하기 [YOUR.LOL 제작기]

Thu, 08 Aug 2024 20:09:55 +0900

전적 검색의 핵심인 매치 정보를 요청하면 저런 형식의 데이터 객체가 10개가 온다. (5vs5 게임이므로) 좀 적어 보일 수 있는데 원래는 8만 글자가 넘는 데이터가 오는데 내가 필요한 것만 추려서 보기 좋게 세팅해뒀다.

이제 저 10개의 데이터 객체 중 내가 검색한 유저가 누구인지 가려내고 그 유저의 데이터를 중심으로 ui를 구성해나가면 될 것 같다.

이전의 포스팅에서의 의존성 체이닝을 통해 3번의 api를 거쳐 수집한 데이터이다. 이 데이터들은 zustand 전역 상태로도 기록돼 있다. 그래서 매치 정보에서도 제공되는 puuid를 현재의 puuid 전역 상태 값과 비교하여 puuid가 같은 인덱스의 객체 정보만 match 데이터로 가져오면 될 듯 하다.

match data를 어떻게 정리해야할지 아직 감이 잘 안와서 그림으로 그려보면서 요청 데이터들을 정리 해야 할 듯 하다.

08.07 개발 일지 [YOUR.LOL 제작기]

Wed, 07 Aug 2024 19:35:45 +0900

전적 검색 페이지 ui를 개편했다.

로컬 상 이라서 그런 것인지는 모르겠지만 다수의 api를 순차적으로 요청하는데 렌더링 속도가 그렇게 늦다는 느낌은 받지 못해서 3-4개의 api를 추가적으로 요청하여 종합적으로는 체이닝은 5개정도 병렬 처리는 2-3개 정도 더 구성해 볼 예정이다.

주절주절

솔직히 오늘은 집중이 좀 안돼서 리엑트 + typescript 관련 책을 하나 사서 읽었다. 예제를 중심으로 코드 따라치기가 주 일 것으로 생각했어서 그냥 머리를 비우고 읽으려 했는데 생각 외로 React의 작동 원리부터 상세하게 소개가 돼있어서 흥미있게 읽었다. 이것들을 모르고 면접장에 들어갔다면 대참사가 났을정도..? 정리를 어떻게 해야할지 모르겠지만 개인 노션에 기록해뒀다가 양이 차면 한 번에 포스팅 할 계획이다.

의존성 체이닝(구현 편) [YOUR.LOL 제작기]

Mon, 05 Aug 2024 19:17:05 +0900

React-Query의 Query Key 의존성을 이용한 의존성 체이닝


  const {
    data: account,
    error: accountError,
    isLoading: isAccountLoading,
  } = useQuery<RiotAccount, Error>({
    queryKey: ["riotAccount", gameName, tagLine],
    queryFn: () => fetchRiotAccount(gameName, tagLine), //gameName, tagLine의 의존성
    enabled: !!gameName && !!tagLine,
  }); // 1번 요청 

  const {
    data: accountDetail,
    error: accountDetailError,
    isLoading: isAccountDetailLoading,
  } = useQuery<RiotAccount, Error>({
    queryKey: ["riotAccountDetail", puuid], // 1번 요청에서 얻어온 puuid에 대한 의존성
    queryFn: () => fetchRiotAccountDetail(puuid), 
    enabled: !!puuid,
  });// 2번 요청 

  const {
    data: accountRank,
    error: accountRankError,
    isLoading: isAccountRankLoading,
  } = useQuery<RiotAccount, Error>({
    queryKey: ["riotAccountRank", encryptedId], // 2번 요청에서 얻어온 encryptedId에 대한 의존성
    queryFn: () => fetchRiotAccountRankInfo(encryptedId),
    enabled: !!encryptedId,
  });// 3번 요청

지난 글에서 계획 했던 의존성 체이닝을 react-query로 구현하였다. react-query의 query key는 useEffect의 의존성 배열처럼 key 값이 변화할 때마다 해당 쿼리를 다시 실행하는 습성이 있다. 이를 이용하여 useEffect를 남발하기 보다는 3개의 useQuery를 이용하여 체이닝을 구현해봤다.

Axios.all 같은 것도 있지 않음 ?

여러개의 axios 요청을 처리하는 Axios.all 같은 방식도 이번 프로젝트를 통해 알게 되었다. 사실 지금 나 같은 특수한 상황이 아니고서는 Axios.all 을 사용하는게 더 좋은 방법이 될 수도 있을 것 같다. 하지만 Axios.all은 다수의 api 요청을 병렬로 수행하기 때문에 이전의 포스팅에서 설명했듯 다수의 api 요청이 순차적으로 진행되어야 원하는 값을 얻을 수 있는 내 상황에는 적합하지 않았다. 그래서 의존성 체이닝이라는 개념을 도입하여 다수의 api 요청을 순차적으로 처리하였다.

개발 일지

(완료된 것)

3개의 api 요청을 의존성 체이닝을 통해 순차적으로 실행되게끔 구현.
leader board의 닉네임을 클릭 했을 시에 해당 닉네임으로 전적 검색이 되도록 수정

(해결 못한 것)

매치 데이터를 검색 직후 바로 보여 줄지에 대한 고민 (지금도 최초 로드시 3개의 api 요청이 들어가는데 이 이상 순차적으로 실행되는 api 요청을 늘릴 시에 초기 렌더링 속도가 매우 느려질 것 같아 고민중)
riot api의 매치 데이터 전처리 (인간적으로 너무 많다.)
전적 검색 페이지 퍼블리싱 (매치 데이터에서 어떤 데이터를 쓸 지 확실히 결정이 되어야 퍼블리싱이 마무리 될 것 같다.)

비동기의 동기화 (계획편) [YOUR.LOL 제작기]

Fri, 02 Aug 2024 20:11:31 +0900

React는 사용자 인터페이스를 구축하는 라이브러리로서, 사용자 경험을 향상시키기 위해 비동기 작업을 필수적으로 처리해야 한다. 비동기 작업은 데이터 페칭, 사용자 입력 처리, 서버와의 통신 등 다양한 측면에서 핵심적인 역할을 한다.

근데 이런 비동기 작업에도 단점이 존재하는데 서로에게 의존성을 가지게 되면서 복잡성이 올라가고 그로 인해 상태 관리가 어려워져 그로 인해 발생하는 오류 등을 처리하기가 어려워진다. 그래서 생각해낸게 useEffect의 의존성 배열을 이용한 useEffect의 동기적 진행의 구현이다. 언젠가 이 구조를 한 번 구현해보고 싶었는데 이번 Riot api 데이터의 엄청난 복잡성으로 인해 useEffect의 동기적 흐름을 반드시 구현해야하는 상황이 되었다.

전적 검색에 필요한 데이터

puuid: 고유성을 보장하기위한 id

gameName: 인게임 닉네임

tagLine: 동일 닉네임 구분을 위한 태그

encryptedId: 암호화된 id

accountId: 계정 id

profileIconId: 프로필 아이콘 정보

revisionDate: 최근 업데이트 일시

summonerLevel: 사용자의 레벨

tier: 사용자의 티어

leaguePoints: 사용자의 점수

wins: 사용자의 승수

loses: 사용자의 패배수

api 요청은 총 5번이 필요하다. 그 순서와 종류를 정리해보면

게임닉네임 + 태그를 통해 puuid를 얻어낸다.
puuid를 이용해 암호화 id, account id, puuid, profileIconId, revisionDate, summonerLevel 를 얻어낸다
암호화 id로 큐 타입(솔랭인지 아닌지), tier, leaguepoint, wins, loses 등의 소환사 정보를 얻어낸다.
puuid로 매치 id를 얻어낸다
매치 id로 매치의 승패 등이 담긴 매치 정보를 불러온다.

5개의 요청 모두 한번에 다 하면 좋지만 그렇게 될 경우 초기 렌더링이 너무 오래 걸릴 것 같아 초기 화면에 필수적인 정보를 가지고 있는 3번까지를 useEffect의 의존성 연결로 동기적 흐름을 만들어 요청하고 게임 내용에 대한 요청은 추가적인 버튼을 만들어 그 버튼을 누를 시 요청이 되는 구조로 설계했다.

그리고 이런 zustand 전역 상태를 하나 만들어서 요청을 통해 얻어온 데이터들을 하나하나씩 업데이트하는 과정을 통해 전역 상태 관리를 해보려 한다.

이론상으로는 useEffect가 순차적으로 실행이 되면서 복잡성이 감소할 것 같긴 한데 중요한 것은 렌더링이 어떻게 되느냐 니까 이것을 했을때와 안했을때의 렌더링 속도와 과정을 한 번 봐야 할 듯 하다. 그리고 아마 최초 검색이 gameName과 tagLine으로 시작하는 만큼 그것에 의존을 가진 useEffect도 필요하다고 생각해서 (다른 유저를 검색한다면 zustand를 비워야하니까) 이런 구조를 고려하면서 최소한의 useEffect만을 활용해서 코드 복잡도를 최대한 낮춰보려고 한다. 아마 주말 내내 시도해봐야 할 듯 하다.

08.01 개발 일지 [YOUR.LOL 제작기]

Thu, 01 Aug 2024 20:44:58 +0900

메인 페이지 퍼블리싱 완료

전체를 담기 위해 배율 조정을 했다(50%) 실제로는 더 크다. 앞으로 추가 할 것은 서비스 로고 작업을 할 건데 그게 저 가운데 YOUR.LOL 부분을 대체 할 것이고 배경 사진도 lol에 맞는 동적인 이미지를 추가 할 계획이다.

riot api 활용 계획

전적 검색 페이지에 필요한 데이터와 그 순서를 정리해봤다.

전적 검색 대상 gameName, tagLine으로 puuid 데이터 요청
puuid로 해당 id의 최근 게임의 매치 ID를 받아옴.
puuid로 해당 유저의 프로필 아이콘, 레벨 등 해당 유저에 대한 정보를 받아옴.
puuid로 챔피언 숙련도 상위 5개를 불러온다.
암호화된 id (puuid 아님)으로 해당 유저의 티어, 승, 패 등 전적에 대한 정보를 가져온다.

한 유저를 검색했을때 해당 api 요청들이 모두 이루어져야하는 상황인데 거기에 추가로

1개의 매치에 대한 정보가 담긴 데이터다 여기에서 필요한 정보는 4-5개 일 것 같은데 어떻게 처리를 해야할지 벌써 좀 막막한 것 같다.

그래서 생각해낸게 해당 유저를 검색을 하고 검색 페이지가 렌더링 됐을때 저 위의 모든 api가 동작하는 것이 아닌 갱신 버튼을 만들어서 갱신 버튼을 누를시 해당 정보를 검색하고 받아온 데이터들을 db에 넣어서 저장을 하고 별다른 갱신이 없을시 db에서 데이터를 꺼내오는 식으로 진행을 하는게 효율적이라 판단했고 이 과정은 좀 상세하게 포스팅 해 볼 생각이다.

이번 riot api를 다루면서 느낀게 왜 롤 전적검색 사이트들은 갱신버튼이 있을까 에 대한 의문이 해결되었다. 정말 너무 복잡하게 돼있어서 좀 당황스럽긴 하다. 일단 전적 검색의 구현 자체는 빠르게 될 것 같은데, 저 많은 서로에게 의존해야하는 api 요청들이 매끄럽게 잘 흘러갈지가 좀 걱정이 된다. 그리고 그걸 해결해보는게 이번 프로젝트의 핵심이 될 듯 하다.

구조 분해 할당과 React-Query [YOUR.LOL 제작기]

Wed, 31 Jul 2024 20:28:36 +0900

java, c ++ 같은 엄격한 언어들을 다루다가 javascript로 넘어왔을때 가장 이질적이었던 문법이 바로 구조 분해 할당이다.

const array = [1, 2, 3];
const [a, b, c] = array;
console.log(a, b, c); // 1 2 3

사실 이런식으로 할당하는 상상을 안해본 것도 아니고 논리적으로 이해가 안가는 것도 아닌데 막상 진짜 된다고 하니까 이질적인 느낌이 많이 들었다. 그래서 실전 코드 작성시에는 잘 쓰지 않았었다가 알고리즘 문제를 풀때서야 필요성을 느끼고 사용 했던 기억이 난다.

Tanstack-Query (React-Query)

// 오늘 캐싱을 위해 작성했던 react-query문
const { data, isLoading, error } = useQuery<LeaderboardData, Error>({
    queryKey: ["teamrank"],
    queryFn: fetchLeaderboard,
    staleTime: 60000,
    gcTime: 3600000,
  });

사실 지난번 프로젝트에 react-query(tanstack-query라고 해야하는지 너무 헷갈린다.)를 사용하긴 했지만 작동 구조를 익히는데에도 버거웠어서 문법 자체를 자세히 들여다 본 적은 없었는데 오늘 쿼리문을 작성하면서 문득 " 어 ? 이거 비구조화 할당이구나 ? " 라는 생각이 들었다. 글로 표현을 다 할 수 없을 뭔가 깨달음의 벽을 하나 넘은 느낌이 들었다. 비슷한 경험으로는 프로그래밍 씬에서 정말 많이 사용되는 객체 라는 용어를 이해했을때였는데 이번에 비슷한 느낌을 받았다.

사실 그동안 react-query를 캐싱기능만 사용했고 그저 queryFn에 의존성을 가진 기능이라고 생각을 했는데 구조가 눈에 들어오니 전체적인 구조가 이해가 가기 시작했다. 나는 어떠한 개념을 이해했을때 그것을 간략히 정리해 GPT에게 내가 이해한 것이 맞는지 확인을 하는 습관이 있다. 그때 네. 맞습니다 라는 대답이 오면 뭔가 인정 받은 것 같아 기분이 좋은데 이번에도 비슷한 경험을 했다.

이번 프로젝트는 ui/ux에 신경을 많이 쏟고 있다. 저번 프로젝트에서 가장 부족한 부분이기도 했고, 부하테스트 기반 성능테스트를 아무리 고퀄리티로 한다고 해도 유저들은 당장 자신들의 눈에 보이는 ui/ux의 변화에 더 민감하게 반응한다는 것을 깨달았다. 그래서 앞서 말한 react-query의 구조를 깨달은 것과 연결짓자면 이번에는 data 뿐만 아니라 isLoading과 error를 좀 잘 활용해보려 한다. 로딩 시간이 짧은 것이 물론 제일 좋지만 피치 못할 사정으로 로딩이 길어졌을때 혹은 에러가 떳을 때 ui/ux가 망가지는 것 만큼 허접해보이는게 없더라. 이 부분을 잘 개선해서 최소한 허접해보이지는 않는 프로젝트를 만들어보고싶다.

주절주절

배포하는 그 날 까지 아니, 배포 한 후에도 YOUR.LOL 제작기 시리즈는 매일 연재하는 것을 목표로 할 것인데, 오늘과 같이 개념적으로 무언가를 크게 배웠다고 느낀날은 이런식으로 개념 중심의 글을 작성 할 것이고 그렇지 않은 낳은 그 날 개발 한 것을 위주로 개발일지를 작성 할 것 같다. 어차피 그 날 한 것들은 커밋 로그에 잘 남아있으니 말이다.

커밋 로그 이야기가 나와서 생각이 났는데, 요즘 무지성으로 git add . 를 하지 않고 한 파일 한 파일마다 add를 해가며 commit을 하고 있는데 보통 이렇게 하는게 맞는 방법인지가 궁금하다. 사실 제일 좋은 것은무언가를 했을때마다 꾸준히 기록하는 것인데 정신 없이 코드를 치다 보면 까먹을 때가 좀 있어서 이렇게 보완을 하고 있는데 잘 하고 있는 건지 모르겠다.

RIOT ID를 가져오는 방법 [YOUR.LOL 제작기]

Tue, 30 Jul 2024 17:19:58 +0900

Riot ID

Riot은 2023년 10월부터 게임 내 닉네임을 없애고 자사 게임 내에서 공통으로 사용하는 Riot ID를 채택했다. 형식은 gameName#tag 의 방식이며 오늘 하루를 허비하게 만든 장본인이다.

원래는 어땠는데 ?

리더보드를 만들기 위해 상위 랭커들을 요청했다고 가정하면 현재는 이렇게 데이터가 도착한다.

원래는 저기에 summonerName이라는 필드가 있었고 그게 닉네임 이었어서 요청 1번에 데이터 전처리만 좀 해주면 바로 리더보드를 만들 수 있었다.

근데 이제 인게임 닉네임이 사라지고 Riot ID로 통합이 되면서 저 필드가 사라졌고 gameName을 찾기위해 사방 팔방 뛰어다닌 결과 Summoner Name to Riot ID 라는 공식 문서를 찾았다.

요약하면 현재 gameName과 tag를 얻기 위해선 총 최초 요청에서 summonerId를 얻고 그 summonerId로 puuid를 받아와서 그 puuid로 최종 요청을 해야 Riot ID인 gameName 필드를 만날 수 있다는 뜻이다. 즉 총 3번의 api 요청이 필요하다는 것을 알았다.

보기 쉽게 그림으로 표현하면

다음과 같은 3번의 api 요청 과정을 거치면

드디어 탑 랭커 10인의 이름과 만날 수 있다.

진짜 쉬운게 하나도 없는 것 같다.

07.29 개발 일지 [YOUR.LOL 제작기]

Tue, 30 Jul 2024 10:52:43 +0900

전체적 색상 푸른 계열로 변경
즐겨찾기 기능을 선수 순위, 팀 순위를 보여주는 div로 변경
json 서버를 제작하여 next 내장 라우팅으로 api 요청 구현 (다음 경기 일정 동적 생성)

주절주절

어제 업로드 하고 귀가 한 줄 알았는데 아니었어서 오늘이나마 업로드 했습니다.(오늘것도 따로 업로드 예정)
라이엇은 api를 따로 신청을 받아서 승인을 내주는데 기간이 한 일주일 걸린다고 한다 그 전까지는 기한이 24시간인 developer api key를 사용해야한다고 한다. 다시 한 번 카카오 developers 선생님들이 존경스러워 진다.

[7월 회고] 자기 객관화

Sat, 27 Jul 2024 22:54:06 +0900

선 요약

50여 곳 지원중 서류 2곳 합격
웹 개발 전반적으로 실력이 상향평준화 된 것을 체감하고 상용화 할 수 있는 수준의 프로젝트 경험이 필요함을 느낌
보다 더 많은 기회를 위해 백엔드 개발자로도 지원 병행 결정
이번 프로젝트에 spring boot 까지 접목 시켜서 프론트, 백 가리지 않고 취업 준비 예정

1차 북벌

카카오 map SDK를 이용한 프로젝트로 이번 취업 준비 첫 번째 이력서를 완성하여 지원을 해봤다. 결과는 코딩테스트 링크 2개. 즉 2곳만이 내 서류를 통과 시켜줬다는 말이다. 과제테스트 혹은 좀 고난이도의 코딩테스트를 기대했지만 프로그래머스 0단계 수준 정도 되는 내장 메서드 활용 위주의 코딩테스트가 왔다. 문제풀이에 큰 어려움은 없었고 회신에 있어서 1시간이 걸리지 않았던 것 같다. 그리고 그 후에 연락은 오지 않았다. 아마 불합격의 소식과 비슷한 의미로 보내주신게 아닐까 추측이 되었다.

첫 술에 배부를리가 없다고 생각하기도 했어서 최종 합격을 기대하지는 않았지만 면접의 기회조차 받지 못한 것은 좀 충격적이었다. 그래서 멘탈이 좀 회복된 지금 내 지난 3개월을 되돌아보며 문제점을 짚어보려고 한다.

이력서

이력서는 내가 진행했던 프로젝트 위주의 이력서를 작성했다. 신입이라 이력이라고 할 만 한 것이 없었기에 더더욱 프로젝트를 강조하고 싶었다. 그리고 블로그 포스팅에서 항상 강조했었던 기능 구현에서만 그치지 않고 성능 향상까지 이끌어 내는 과정을 담아서 나의 발전 가능성과 단순 개발을 넘어 서비스 운영 능력까지도 내비치고 싶었다. 자세한 사항은 mymap Github README 에서 확인 하실 수 있다. 저 내용을 이력서의 프로젝트에서 배운점 항목에 작성했었다.

조잡하긴 하지만 그래도 성능 향상에 대한 고민은 했다를 어필 할 수 있을 줄 알았는데 이 정도로는 역부족 이었던 것 같다. 고민만이 아닌 실제로 문제를 해결하는 과정을 그려야 하는 걸까 그럼 실제 사용자를 확보해야하는데 그건 어떡하지 라는 생각이 들었다. 이 부분은 아직도 잘 모르겠다. 지금 단계의 내가 실제 유저를 확보 할 수 있는 수준의 서비스를 만들 수 있을까 ? 라는 현실적인 문제에 봉착했다.

두번째 문제점으로는 퍼블리싱이 좀 부족했던 것 같다. 퍼블리싱이라하면 반응형 + 디자인 심미성 인데 아무리 지도 검색 서비스가 pc위주라고 해도 반응형에 대해 너무 고려하지 않고 사이즈를 고정 시켜 놓았던 점, 웹 디자인은 디자이너가 하는 거지 라는 안일한 생각으로 디자인 적인 고려가 전혀 없어 보이는 무채색 위주의 칙칙한 구성이 인사 담당자의 눈을 끌지 못한 것이 아닐까 라는 생각을 했다.

세번째로는 코드가 너무 난잡하다. 리펙토링을 할 수도 없을 정도로 난잡하다 라는 생각을 많이 했다. 나름의 변명을 해보자면 학습과 프로젝트를 병행하다보니 그날 배운걸 바로 프로젝트에 적용하는 과정이 반복됐는데 그 과정속에서 과거의 코드를 다시 들여다보면 내가 작성 한 것이 맞나 ? 라는 생각이 들 정도로 거리감이 느껴지는 난잡한 코드가 되었다. 사실 이 부분이 가장 치명적이었을 수도 있다. 결국 개발자는 코드를 작성하는 사람이니까.

Java

마침 오늘이 토요일이라 정말 많은 시간 고민을 했다. 고민의 결과는 Java의 손을 잡자 였다. Java는 내가 가장 오랫동안 다뤄온 언어이다. 학부생때 2년을 다뤘고 프로젝트로도 여러번 다뤘을 정도였다. 그래서 보다 java 스러워진 javascript인 typescript에도 쉽게 적응 할 수 있었다. 그리고 무엇보다 시장이 크다라는 압도적 메리트를 가지고 있다. 그런 관점에서 공고들을 살펴보니 상당수의 자바 백엔드 개발자를 구하는 공고에서 프론트엔드 능력을 우대사항에 적어놓은 경우가 많더라. 그래서 내가 만약 java 백엔드로 전향을 하더라도 지금까지의 프론트엔드 개발에 쏟은 시간들이 물거품이 되기는 커녕 큰 이점이 될 것이라는 생각을 했다. 그래서 java 쪽으로도 좀 적극적으로 발을 넓혀 보려 한다.

앞으로의 계획

현재 진행 중인 게임 전적 검색 프로젝트의 1차 배포 계획에 Spring과 PostgreSQL이 추가되었다. 1차 배포 버전때는 Spring boot의 역할이 회원 정보 관련 정도 일 것 같다. 개발 일지에도 적었지만 1차 목표인 전적 검색 기능은 클라이언트 사이드의 비중이 커서 당장은 어쩔 수 없는 것 같다. 하지만 그 뒤로 개발할 챔피언, 아이템 관련 페이지들은 데이터 중심이기 떄문에 백엔드의 비중이 커지리라 생각이 든다. 그리고 최종적으로는 Redis 까지 다뤄서 챗봇, 캐싱 까지 구현한 버전을 최종 버전으로 생각하고있다. 얼른 만들어서 java 백엔드로도 지원해보고싶다.

주절주절

요즘 느끼는게 정보처리기사 합격 후기 이 글에 대한 수요가 높다는걸 알았다. 정보처리기사를 준비하시는 분들은 높은 확률로 java 개발자 지망생일 확률이 높다는 생각이 드는데 그 분들의 개발 관련 글 니즈를 내가 채울 수 있지 않을까 ? 라는 생각이 들었다. 왜냐하면 blex 에디터 분들 중에는 java 개발자가 없으니까! java 준비하면서 좀 더 낮은 시선으로 세밀하게 양질의 글 많이 써서 광고가 없는 Blex 특성상 서버비는 못 벌어다 드려도 운영하실 맛이 나게끔은 해드리고싶다는 생각이 들었다.

사실 지금 멘탈이 막 그렇게 좋지는 않다. 구상하던 프로젝트는 api 문제로 인해 뒤집어 엎어야 할 상황이고 낙관적으로 바라봤던 취업은 비관에 더 가까워졌다. 하지만 뭐 어쩌겠나 모두 다 내가 선택 했던 것들의 결과인데. 그냥 열심히 노력 하는 수 밖에 없는 것 같다. 너무 뻔한 말이긴 하지만 다른 말이 필요하지 않은 것 같다. 이 시리즈의 제목이 올 해 안에 취업하기이다. 벌써 너무 조급하게 생각하지 말고 천천히 하나씩 헤쳐나가야겠다.

좋게 생각하려해도 지난 프로젝트의 결과가 너무 기대 이하라 눈에 계속 밟힌다. 나름의 문제점 분석을 해보긴 했는데 내가 분석했던 점들 외에도 다른 문제가 있었을 수도 있다. 하지만 적어도 다음 2차 북벌때는 내가 분석한 문제점들만이라도 완벽하게 보완된 모습을 보여주고싶다.