사람인 기술 블로그

사람인

2026-03-19 · 4개월 전

팀에서 Kubernetes를 도입한 이후 관리하고 있던 서비스들의 MSA 전환이 활발히 이루어지고 있습니다. 하지만 전환이 가속화 될수록 서비스간 연결이 복잡해졌습니다. 또한 Filebeat와 Metricbeat로 수집하며 파편화된 정보는 인입된 CS를 분석하기에 매우 힘들고 불필요한 시간을 보내왔습니다. 그러던 중 사람인에서 Observability 환경을 구축했다는 소식과 일부 서비스에서 도입 후 긍정적인 평가를 보여주어 적용을 검토하게 되

사람인

2025-11-11 · 8개월 전

2025년 7월 사람인의 공고/후보자 서비스의 대대적인 개편이 있었습니다.🎉 후보자 서비스에서 다양한 연계 플랫폼(점핏, 코메이트, 원더풀 시니어 등)과의 연동이 가능해졌습니다. 문제는 여기서 시작됐는데요. 각 플랫폼이 제공하는 이력서는 PDF, HTML 등 형식도 다르고 HTML 기반이라 해도 CSS, 클래스명, 레이아웃방식이 모두 제각각입니다. 이 말은 후보자 상세 페이지의 기존 스타일과 충돌해 깨질 수 있다는 것을 의미합니다. 후보자 상

사람인

2025-11-05 · 8개월 전

안녕하세요! 오늘은 Next.js 프로젝트에서 정적 파일(이미지, CSS 등)을 효율적으로 관리하고 배포하는 방법에 대해 공유해보려고 합니다. 특히 개발 환경과 운영 환경을 분리하여 관리하는 방법과 CDN 캐시 관리에 대해 살펴보겠습니다. 들어가기 전에 현재 사람인은 대부분의 서비스를 온프레미스 환경에 배포하고 있습니다. 그렇다보니 소개해드리는 내용은 AWS나 VERCEL에 배포하는 것과는 차이가 있습니다. 이점 참고 부탁드립니다. 현재 상황과

사람인

2025-11-04 · 8개월 전

새로운 서비스를 개발하며 배포 과정을 자동화하는 CI/CD 구축은 필수적인 과제였습니다. 하지만 기존에 사용하던 배포 방식은 몇 가지 고질적인 문제점을 안고 있었고, 이로 인해 더 안정적이고 효율적인 배포 전략을 모색하게 되었습니다. 첫째, 배포 중 간헐적으로 발생하는 에러가 문제였습니다. 명확한 원인 파악이 어려워 재현조차 힘든 에러는 배포의 안정성을 떨어뜨리는 주범이었습니다. 둘째, 배포 실패 시 전체 서버가 다운되는 치명적인 위험이 있었습

사람인

2025-10-28 · 8개월 전

1. 들어가며 현재 사내의 로그 수집은 Heimdall과 OpenTelemetry(w. sigNoz)를 기반으로 이루어지고 있습니다. 오류 관제의 대부분은 Heimdall의 룰(rule) 에 따라 Slack 채널로 전달되며, 실제 장애 발생 시 관련 로그가 아래와 같이 공유 되고 있습니다. (이미지 참조) 그러나 기존 메시지 템플릿으로 모니터링을 진행하면서 다음과 같은 불편함이 있었습니다. 불필요하게 긴 Stack Trace (메시지가 너무 길

사람인

2025-09-07 · 10개월 전

1. 들어가며 기존 챗봇 서비스는 정해진 규칙에 따라 답변하는 ‘룰 기반(Rule-based)’ 방식이 대부분이었습니다. 그러던 중 OpenAI의 ChatGPT가 등장하며 큰 변화의 바람을 몰고 왔습니다. 저희는 이 기술을 활용해 상담사를 통해서만 가능했던 문의 대응을 자동화할 수 있지 않을까 하고 생각했습니다. 저희 목표는 수년간 축적된 사람인의 도움말, 채용 공고, 기업 정보와 같은 내부 데이터를 LLM과 결합하여 사용자의 1차적인 문의를

사람인

2025-07-31 · 11개월 전

저희는 Kubernetes 환경에서 동작하는 서비스의 증가와 최근 k8s 환경에서 대규모 서비스 오픈을 진행 했으며, 이에 대비하여 어떻게 마이크로 서비스에서 가시성을 확보할지, 또 문제가 생겼을 경우 어떻게 쉽게 문제를 확인하고 추적 할지에 대해 고민하게 되었습니다. 그 결과, OpenTelemetry와 SigNoz 조합을 활용한 Observability 환경을 구축하게 되었으며, 그 경험을 공유하고자 합니다. 시작하게 된 배경 기존 모니터링

사람인

2024-06-25 · 약 2년 전

지난 포스팅과(사이트 신뢰성에 대한 지표는 어떻게 구성할까?) 다르게 이번엔, AWS EKS 환경을 좀 더 안정적이며 확장성 있게 운영하기 위해 고민하고 테스트 했던 내용에 대해 공유 드리고자 합니다. 사람인은 K8S 플랫폼으로 On-Premise가 주이고 최근 서비스는 AWS EKS를 사용하고 있습니다. 초기 EKS를 구축 했을 때 CA를 사용하지 않고 Auto Scaling Group을 이용하여 명시적으로 관리 했었습니다. 하지만 거기서 오

사람인

2024-04-07 · 약 2년 전

사람인에선 서비스의 레거시 영역을 점진적으로 개선해 나가고 있습니다. 그동안 FE개발팀은 긱이나 멘토링 같은 버티컬 서비스의 FE개발을 진행해왔는데, 작년부터 주요서비스의 FE분리를 시작하면서 FE 영역의 아키텍쳐에 대한 고민을 했었습니다. 그 결과 Monorepo를 적용하기로 하였고 첫번째 서비스가 배포를 앞두고 있습니다. 그 과정에서 배포 환경에 대한 고민도 같이 하게 되었고 GitOps를 도입하게 되었는데 그 과정을 소개해보려고 합니다.

사람인

2024-03-24 · 2년 이상 전

이번 포스팅은 Vue3, Composition API와 Pinia를 이용한 상태관리 (1) 글의 후편입니다. 이전 포스팅에서 Composition API, Pinia에 대한 이론적인 설명을 다루었다면 이번 포스팅에서는 실제로 Pinia를 어떤 방식으로 적용했고 어떤 작업 결과를 냈는지 다루려합니다. 글의 목차는 아래와 같습니다. 03. 적용 결과: 인재풀에서의 Pinia 04. 느낀점: 이론적 장단점과 내가 느낀 실제 Vue3가 적용된 인재풀서