(주)시선아이티 현장실습 자기소개서

4문항 전문

1. 01

   지원동기

   1,929자 · 공백 포함

   게임을 만들고 싶어 소프트웨어를 전공했습니다. 재학 중에 딥러닝이 빠르게 발전하는 것을 보면서 인공지능의 다양한 활용에 관심이 생겼고, 게임에도 기계학습을 붙일 방법이 많겠다고 생각했습니다. 그래서 졸업 연구 주제로 지속적 강화학습을 통한 추격 NPC 난이도 조절을 선택했습니다.

   플레이어의 이동 경로를 학습해 NPC가 플레이어의 성장에 맞춰 지속적으로 대응하도록 만들었습니다. 강화학습으로 학습시키며 보상과 패널티 식을 여러 번 바꿔 보았고, 어느 구성이 잘 배우는지 누적 보상으로 비교해 골랐습니다. 학습에 쓰지 않은 경로에서도 잘 예측하는지 확인했습니다. 그 과정에서 게임 개발보다 인공지능 기술 자체에 더 관심이 생겼습니다.

   졸업 연구를 마친 후에는 대한적십자사 경기혈액원에서 사회복무요원으로 복무하며, 게임 개발이 아니라면 어느 방향으로 가야 할지 고민할 시간이 생겼습니다. 업무를 보조하며 소프트웨어로 해결할 수 있어 보이는 문제들이 보였고 업무에 쓰이는 도구를 몇 개 만들었습니다. 당연히 환영받을 것이라 기대했지만 그렇지 않았습니다. 어떤 것은 업무용 PC가 내부망에 묶여 있어 제가 만든 웹 앱에 접속할 수 없었고, 어떤 것은 사회복무요원에게 열람이 제한된 자료가 필요해 정식 도입이 막혔습니다. 실제 조직에서 쓰이는 시스템은 무엇을 만들지보다 어떻게 도입할지를 먼저 확인해야 한다는 것을, 전부 만들고 난 뒤에 알았습니다.

   그 무렵 붙잡은 것이 헌혈량 데이터였습니다. 상급 기관이 운영하는 실시간 대시보드가 있었지만 원형 그래프가 몇 초마다 다른 화면으로 넘어가고 숫자는 호버해야 보여서, 직원들이 자주 확인하는 전국 순위와 오늘 실적량을 한눈에 볼 수 없었습니다. 그래서 해당 페이지에서 API를 추출해 테이블로 가공하고 정렬 기능을 붙여 다시 보여 주도록 만들었습니다.

   데이터를 그대로 흘려보내기 아까워 Supabase에 연결해 수집을 시작했습니다. 한 시간 단위로 스냅샷을 남겨 직전 시간과의 변화량과 요일별 헌혈량을 기록했고, 한 달쯤 쌓이자 일정한 패턴이 나타나 헌혈 장소를 섭외할 때 근거로 쓸 만하다고 판단했습니다.

   두 달치가 모이자 날씨 예보를 붙여 다음 일주일의 헌혈량 예측을 시도했습니다. 헌혈의 집과 헌혈버스는 운영 요일도 날씨의 영향도 달라 모델을 따로 학습시켰습니다. 학습에 쓸 수 있는 데이터가 적었기 때문에 기온과 강수를 각각 단변량 회귀로 풀어 계수를 뽑고 요일은 편차만 다루는 단순한 형태로 가져갔습니다. 매일 정해진 시각에 도는 스케줄러를 걸어 다음 주 예측값을 내고 일요일마다 그 주 데이터로 모델을 갱신하는 파이프라인을 돌렸습니다. 상급 기관이 대시보드를 개편하며 API 주소를 닫아 프로젝트는 중단됐지만, 데이터를 실제로 유의미하게 다뤄 본 경험이 되었습니다.

   그다음은 에이전트였습니다. 에이전트가 조명받기 시작하던 시기에 하네스 엔지니어링에 매력을 느꼈고, 운영 환경을 직접 설계해 오픈소스로 공개했습니다. SDK와 RAG 메모리 시스템, 권한과 생애 주기 관리를 하나의 시스템 안에 어떻게 담을지 고민하며 처음부터 직접 만들었고, 지금도 개발을 이어가고 있습니다.

   이번 실습은 정보시스템 개발과 AI 챗봇 개발 두 축으로 안내받았습니다. RAG로 에이전트를 만들어 본 경험은 있지만 제가 쓰려고 만든 도구였고, 챗봇처럼 정확한 정보가 보장되어야 하는 시스템은 해 보지 못했습니다. AI가 통합된 시스템과 인프라를 만드는 일에 큰 매력을 느낍니다.

   정보시스템 쪽은 요구사항 분석과 설계에서 시작해 개발과 테스트를 거쳐 산출물 정리까지 이어집니다. 제가 해 본 것은 그중 만드는 부분뿐이고, 앞뒤에 붙는 절차는 혼자서는 만들 수 없었습니다. 이전 실패의 경험들에서도 제품의 동작이 틀려서 멈춘 것은 하나도 없었고, 멈춘 이유는 전부 만들기 전에 확인했어야 할 조건이었습니다. 이제는 조직의 요구사항을 파악하고 제품으로 산출하는 절차를 실무의 방식으로 배우고 싶어 지원했습니다.

2. 02

   성격의 장·단점

   1,890자 · 공백 포함

   당연하게 반복되는 일에서 비효율을 발견하면 도구로 바꾸는 편입니다. 사회복무요원으로 복무하는 21개월 동안 업무 도구를 다섯 종 만들었고, 그중 일부는 제가 소집해제한 지금도 경기혈액원에서 쓰이고 있습니다.

   헌혈 장소를 섭외하는 영업팀 직원이 차량으로 하루에 여러 장소를 돌며, 지도 앱에서 손으로 경유지 순서를 바꿔 가며 최적 조합을 찾고 있었습니다. 외판원 순회 문제라고 보고 웹 앱으로 만들었습니다. 카카오맵 API로 장소 검색과 길찾기를 구현하고, 교통상황에 따라 같은 두 지점도 방향에 따라 이동 시간이 달라 양방향을 모두 구한 뒤 분기한정으로 최적 순서를 찾았습니다. 일부 직원은 지금도 사용하고 있습니다.

   헌혈자들은 대기 중에 복용한 약이나 다녀온 지역을 말하며 헌혈이 되는지 물었습니다. 문진을 담당하는 간호사가 아닌 직원들은 기준을 외우지 못해 매번 휴대폰으로 검색해 안내했습니다. 그런 모습이 헌혈자에게 신뢰를 주기 어렵다고 생각해, 적십자사 홈페이지에 공시된 문진 기준을 하나의 데이터베이스로 정리하고 키워드 검색이 가능하도록 만들었습니다. 공시 항목을 6가지 타입으로 정의해 즉시 판단할 수 있게 했고, 기준일을 선택하면 헌혈 가능 날짜까지 계산되도록 했습니다. 공시 데이터가 내부 기준과 달라 정식 도입에는 못 갔지만 제가 소집해제하기 직전까지 저를 비롯해 몇몇 직원들은 편리하게 사용했습니다.

   더 나은 효율을 위해 계속 고민하고 방법을 찾아 행동하는 것은 저의 장점이라고 생각합니다. 문제는 능동적으로 제품을 만들기 시작하면서도, 정작 요구사항을 인터뷰하는 일에는 민망함을 느껴 소극적으로 행동했다는 것입니다. 매일 아침 기관명과 날짜만 바꿔 명단을 출력하는 것을 보고, hwpx 라이브러리로 한글 문서를 생성해 이메일로 보내는 웹 앱을 만들었습니다. 소개했더니 기존 방식이 익숙하다며 쓰지 않아 중지됐습니다. 제게 좋아 보이면 남에게도 좋을 것이라고 낙관했고, 의견을 먼저 구하는 데 적극적이지 못했습니다.

   만든 것을 조직에 제안할 때도 같았습니다. 헌혈버스마다 다른 기념품 목록을 헌혈자가 직접 고르고 관리자가 화면에서 목록을 바꾸는 키오스크를 만들어 사내 업무 개선 제안 공모전에 냈고, 지사 심사는 통과했지만 본사에서 떨어졌습니다. 무엇을 만들었는지는 설명했지만 그것이 왜 필요한지를 심사하는 사람의 언어로 옮기지는 못했다고 생각합니다.

   두 번째 약점은 시간 관리입니다. 개인 프로젝트에는 마감이 없어서 릴리스 가능한 상태를 만들기 전에 계속 기능을 추가했습니다. IT 기사를 읽다가 유사한 도메인의 프로젝트가 더 나아 보이는 아키텍처를 쓰고 있으면 리팩터링을 하기도 했습니다. 그래서 릴리스는 몇 달씩 늘어지기 일쑤였습니다. 지금은 루틴과 마감 기한을 스스로 정해 최대한 빠르게 릴리스 가능한 상태까지 만들고, 이번 버전에 넣지 않을 것을 먼저 적어 둡니다.

   두 가지 모두 혼자 일해서 생긴 습관입니다. AI로 개발 속도가 올라가면서 한동안은 혼자서도 무엇이든 이룰 수 있겠다고 생각했는데, 진행할수록 제 경험과 능력이 얼마나 부족한지 확인하게 됩니다. 지금 세워나가는 규칙도 아직 정착이 안 돼서 일관성을 유지하기가 어렵습니다. 대학 조별과제 말고는 다인 개발 워크플로우를 겪어 본 적이 없고, 제가 쓴 코드가 리뷰를 받아 본 적도 없습니다. 이 단점을 절차가 정해진 환경에서 함께 일하며 보완해나가고 싶습니다.

   혼자 만든 시간이 남긴 것도 있습니다. 요청을 받아 만든 것보다 사람이 무엇에 시간을 쓰는지 보고 만든 것이 많아서, 말로 나온 요구 뒤에 무엇이 있는지 먼저 헤아리는 편입니다. 다만 그 판단이 맞았는지 확인해 줄 사람이 저뿐이었고, 늘 만들고 난 뒤에야 드러났습니다. 타인의 요구사항에도 그 눈이 쓸모가 있는지 확인하고 싶습니다. 실습에서는 제 판단을 결론이 아니라 질문의 형태로 먼저 놓겠습니다.

3. 03

   현장실습 참여에 대한 포부

   1,905자 · 공백 포함

   대한적십자사 경기혈액원에서 사회복무요원으로 근무하며 공공기관이 실제로 쓰는 업무 프로그램이 어떤 것인지 어깨너머로 계속 보아 왔습니다. 적십자사의 정보시스템인 BIMS를 접했고, 실제로 사용하는 직원들이 어느 화면에서 무엇을 불편해하는지도 계속 들어 왔습니다. 그러한 경험이 SI 산업을 이해하고 요구사항을 파악해 만족할 만한 제품을 만드는 데 도움이 될 것이라고 생각합니다.

   안내받은 실습 과정은 제가 지금까지 해 온 프로젝트와 겹치는 부분이 있습니다. RAG로 문서를 검색해 에이전트에 제공하는 구조를 직접 구현했고, 청킹 단위를 바꾸면 무엇이 좋아지고 나빠지는지, 단일 검색 방식이 어떤 질의를 놓치는지 겪어 봤습니다. 모호한 질문에 섣부르게 답하지 않도록 에이전트 루프를 짠 경험도 있습니다. 대부분의 사용자는 구체적인 지시가 아니라 모호한 문장으로 질문하고, 그때 그럴듯한 답을 내놓는 것이 가장 위험하기 때문입니다. 제가 모호성을 줄이려고 시도했던 방식을 실습에서 만들 시스템에도 적용해 보겠습니다.

   반대로 대화 설계와 프롬프트 최적화는 다뤄 본 적이 없습니다. 제가 만든 도구와 기관의 정보시스템에 있는 챗봇간의 차이는 모르는 것을 모른다고 명확히 말하는 능력이라고 생각합니다. 잘못된 정보가 나가면 안 되기에, 그 부분에서 대화를 어떻게 설계해야 하는지를 배워 신뢰할 수 있는 챗봇을 만들겠습니다.

   LangChain은 써 본 적이 없습니다. 다만 그 프레임워크가 감싸고 있는 툴 콜링 루프와 컨텍스트 관리, 문서 검색은 직접 구현해 봤습니다. 여섯 제품이 함께 쓰는 공통 계층을 직접 분리하며 프레임워크가 대신해 주는 것을 겪었기에, 비교하며 익히는 데는 어렵지 않을 것 같습니다. 실습 시작 전까지 공식 문서를 따라 기본 구성을 세워 보고, 제가 만든 것과 어디가 다른지 정리해 두겠습니다.

   가장 배우고 싶은 것은 절차입니다. 요구사항 정의서와 화면 설계서, WBS와 ERD를 만들어 본 적이 없고, 마르미-III 같은 방법론에 맞춰 단계별 산출물을 남기는 일도 이름만 압니다. 단위 테스트는 제 프로젝트에서 써 왔지만 설계 문서를 기준으로 케이스를 뽑아 본 적은 없고, 통합 테스트와 SP 인증 기준에 맞춘 최종 산출물은 아예 처음입니다. 무엇을 만들지 늘 제가 정해 왔기 때문에, 다른 사람이 쓴 정의서를 읽고 그에 맞춰 구현해 본 적도 없습니다. 이름만 아는 것들을, 이번 실습에서 직접 만들어 보며 익히겠습니다.

   실습이 끝났을 때 남기고 싶은 것이 둘 있습니다. 하나는 제가 정하지 않은 요구사항 하나가 정의서에서 화면 설계서를 거쳐 코드와 테스트 케이스까지 어디로 이어졌는지 따라간 기록입니다. 지금까지는 어디까지 만들면 된 것인지를 늘 제가 정했습니다. 완료 여부를 제 기준이 아니라 문서로 판정받는 과정을 한 건이라도 끝까지 통과해 보고 싶습니다. 다른 하나는 챗봇이 어떤 질의에 어떻게 답해야 하는지를 미리 정해 둔 평가셋입니다. 정답이 정해진 질문과 그렇지 않은 질문을 나누고, 검색 방식이나 프롬프트를 바꿨을 때 나아졌는지를 정량적인 수치로 확인하고 싶습니다.

   코드가 동작하는 것과 조직에 쓰이는 것 사이에 무엇이 있는지는 직접 겪었기 때문에, 요구사항을 정의하는 단계에서부터 비판적으로 바라볼 수 있습니다. 복무 중에 만든 것들이 어느 지점에서 막혔는지 각 단계에 대응시키며 익히겠습니다. 챗봇 단계에서는 그 평가셋부터 만들어 두고 시작하고, 산출물은 끝에 몰아서 쓰지 않고 각 단계가 끝날 때마다 함께 남기겠습니다.

   넉 달 동안 하고 싶은 것은 한 프로젝트가 요구사항에서 인수까지 가는 과정을 한 번 통과해 보는 일입니다. 실습이 끝날 때는 제가 만든 부분을 다음 사람이 그대로 이어받을 수 있게 넘기겠습니다. 그 한 바퀴를 돌고 나면 다음에는 어느 단계에서 무엇을 먼저 물어야 하는지 알고 시작할 수 있습니다. 그런 경험이 지금 제게 가장 필요합니다.

4. 04

   자유기술 (직무 위주)

   1,999자 · 공백 포함

   이번 직무와 가장 가까운 작업은 직접 만들어 오픈소스로 공개한 AI 에이전트 운영 환경입니다. 백그라운드 데몬에서 비동기 태스크로 에이전트를 띄워 사용자가 창을 닫아도 작업이 계속 돌아가게 하고, 그 위에 기억과 지식, 권한과 도구, 모델 통합을 붙였습니다. 그중 가장 오래 붙잡은 것은 메모리입니다. 같은 모델에 같은 질문을 넣어도 무엇을 회상하느냐에 따라 답이 달라졌기 때문입니다.

   설계에서 가장 먼저 나눈 것은 회상할 두 출처의 분리였습니다. 둘 다 에이전트가 읽고 쓸 수 있지만, 사용자가 직접 편집할 수 있는가와 생애 주기를 갖는가가 달랐습니다.

   하나는 '지식'입니다. 사용자가 일상적으로 쓰는 마크다운 문서 저장소로, 에디터로 직접 쓰고 고치는 평문 파일입니다. 정통 RAG 구조를 따라 문서를 청킹해 색인하고 질의가 들어오면 검색해 주입합니다. 문서 간 연결은 양방향 백링크로 추적합니다. 생애 주기는 없고, 기준은 평문 파일이라 색인은 언제든 다시 만들 수 있습니다.

   다른 하나는 '기억'입니다. 에이전트가 작업 중 알아낸 것을 남기는 구조화된 저장으로, SQLite 또는 JSON에 저장합니다. 회상은 RAG와 같지만 감쇠·보호·압축·정리가 붙어 있다는 점에서 정적 문서 검색과 다릅니다. 기억 항목은 인지 과학 SOAR/ACT-R 모델에서 따온 아홉 타입으로, 중요도에 따라 세 단계로 분류됩니다. 사용자가 에디터로 고칠 수 없고 API로만 접근합니다.

   범위도 다릅니다. 지식은 전역에 하나입니다. 기억은 작업 공간마다 독립되지만, 사용자 프로필과 선호 타입은 공간을 가리지 않고 전역으로 공유됩니다. 핵심 기억은 어느 공간에서나 살아있고, 그 공간에서만 의미 있는 것은 그 공간에 머물게 했습니다.

   두 축 모두 같은 검색 계층으로 꺼냅니다. 검색은 한 가지만 쓰지 않았습니다 — 벡터 검색만으로는 함수명 같은 정확 일치 질의를 놓치고, BM25만으로는 표현이 다른 같은 뜻을 놓쳐, 순위의 역수를 더하는 RRF로 융합했습니다. 융합 결과를 직접 구현한 Flash Attention으로 재순위해 문맥상 관련성을 보완합니다.

   지식과 기억을 일정 크기로 자르되 문장이 끊기지 않게 하고, 고정 크기와 문단 경계 방식을 함께 뒤릅니다. 벡터 검색엔 임베딩이 필요한데, 환경에 따라 원격 API, 로컬 GGUF 소형 모델, TF-IDF 세 단계로 바꿔 끼웁니다.

   에이전트가 작업 루프 중 알아낸 것을 스스로 남길 수 있게 두 도구를 줬습니다. 하나는 기억 도구로, 사용자에 대해 알게 된 사실, 관찰한 패턴, 교정받은 선호를 세션을 넘어 저장해 같은 실수를 반복하지 않게 합니다. 다른 하나는 지식 도구로, 에이전트가 조사해 정리한 것을 마크다운 노트로 남기며 읽기·쓰기·삭제·이동·검색·백링크 조회까지 가능합니다. 에이전트가 한 번 답하고 끝나는 게 아니라, 쓸수록 기억이 쌓이고 정확해집니다. 사용자가 맥락을 매번 설명할 필요가 없고, 에이전트는 이전에 배운 것을 다음에 활용합니다.

   기억이 쌓이기만 하면 찾는 데 방해가 됩니다. 감쇠는 에빙하우스 망각 곡선으로 가중치를 줄이되 자주 꺼낸 기억은 감소를 늦춥니다. 중요도는 보존도에 접근 횟수의 로그를 곱해 냅니다. 자동 보호는 접근 횟수와 세션 등장 횟수로 보호 등급을 정합니다. 두 번 접근하면 낮은 보호, 다섯 번이거나 사용자 교정이 있으면 높은 보호, 사용자·선호 타입은 영구 보호됩니다. 사용자가 관리하지 않아도 자주 쓰는 것은 살아남고 안 쓰는 것은 사라집니다.

   압축과 정리는 기억이 일정량을 넘기면 비슷한 것끼리 묶어 요약하고 쓸모없는 것을 지웁니다. 다섯 단계의 압축 계층을 따라 오래된 기억을 점진적으로 요약합니다. Dream이라는 네 단계 백그라운드 작업이 주도하는데, 도중에 멈춰도 체크포인트에서 이어 끝낼 수 있습니다.

   안내받은 커리큘럼 중 데이터 준비, RAG 구현, 외부 API 연동은 이미 부딪혀 본 문제라 초반부터 손을 보탤 수 있고 설계 근거를 대며 이야기할 수 있습니다. 나머지는 팀의 절차를 따라 익히되, 제가 겪은 시행착오만큼은 반복되지 않게 하겠습니다.

자수 검증

사용자 표기 글자수는 원본 글자수(문단 사이 줄바꿈 포함) — 지원 시 제출한 값. 빌드 글자수는 화면에 렌더된 문단 텍스트의 공백 포함 합계로, 문단 사이 빈 줄 제외. 두 값 모두 2,000자 제한 안에 들어간다.