6주 동안 실전 프로젝트를 진행하면서 학습한 내용을 기록하고, 팀의 리더로서 프로젝트 매니징 경험을 기록하는 시리즈입니다.

---

최종 발표

👉 안녕, 특허 방문하기

👉 안녕, 특허 GitHub 방문하기

1. 기획 배경 및 시연 영상

특허정보 검색의 필요성에 따라 많은 사람들이 특허 검색 서비스를 찾고 있고, 정부에서도 대국민 특허정보검색서비스(KIPRIS)를 운영하고 있습니다.

그런데 직접 키프리스를 사용해 본 결과, 다음과 같은 불편함이 있었습니다.

① 너무 많은 검색 기능과 세분화된 분류

② 복잡한 UI와 부가 정보

③ 어려운 연산자 조합 검색

이로 인해 특허 검색의 진입 장벽이 높다고 판단하였고,
비전문가나 초보이용자도 쉽게 이용할 수 있는 특허 검색 서비스를 기획하였습니다.

👉 안녕, 특허 시연 영상 보러가기 (자막과 함께 시청해 주세요~!🔛)

---

2. 아키텍처 및 기술 도입 배경

Logstash 도입 이유

1. 요구사항
   • 대용량 csv 데이터의 빠르고 안정된 업로드
   • 간단한 데이터 전처리
2. 대안
   • Filebeat
   • Logstash ✅
3. 도입 이유
   • 필터 기능 ⇒ Filebeat는 기능이 제한적
   • 데이터 업로드 속도 ⇒ worker thread를 통한 데이터 업로드의 병렬 처리 가능

파일비트는 로그스태시에 비해 리소스를 적게 쓰는 장점이 있습니다.

하지만 로그스태시는 다양한 필터기능을 갖추고 있고, worker thread를 통한 데이터 업로드의 병렬처리가 가능하다는 장점이 있습니다.

따라서 대량의 csv데이터를 가공하여 엘라스틱서치에 업로드하는 데는 로그스태시가 적합하다고 판단하여 채택하였습니다.

Elasticsearch 도입 이유

1. 요구사항
   • 검색 결과 1초 내 반환 목표
   • 8000만 건의 대용량 데이터 운용
2. 대안
   • RDB vs NoSQL
   • Search Engine(Elasticsearch) ✅
3. 도입 이유
   • 전문 검색 기능 ⇒ 분석기 커스터마이즈 + 역인덱싱으로 검색 정확도 향상
   • 역인덱싱 ⇒ 검색 데이터 양에 구애받지 않고, 키워드 검색 시 O(1)의 시간 효율성으로 조회 가능

안녕 특허 서비스의 목표는 데이터 조회 시 결괏값을 1초 내로 반환하는 것과,
대용량의 데이터 운용, 사용자의 검색 편의성과 정확도의 개선입니다.

엘라스틱서치는 여러 플러그인을 이용한 전문 검색 기능을 갖추어 검색 정확도를 높이는데 적합합니다.
또한, RDB에서의 색인 기능과 다른 역색인 기능과 캐싱 기능을 제공합니다.
그에 따라 검색 데이터양과 상관없이 시간 복잡도를 O(1)로 관리할 수 있는 장점이 있습니다.

이러한 이유로 저희 서비스에 최적화된 기술은 엘라스틱서치라고 판단하여 도입하였습니다.

---

3. 기술적 도전과 배움

Elasticsearch 메모리 설정 문제

자세한 내용을 담은 블로그 포스팅입니다.😊

👉 Elasticsearch GC Overhead 문제로 사용자 정의 사전 적용 실패

오타 교정 기능 + 검색 결과 정확도 개선 문제

자세한 내용을 담은 블로그 포스팅입니다.😊
👉오타 교정 기능 적용 이후 검색 결과 정확도 향상을 위한 인덱스 매핑 변경 과정-①
👉오타 교정 기능 적용 이후 검색 결과 정확도 향상을 위한 인덱스 매핑 변경 과정-②

4. 앞으로의 계획

1. 사용자 정의 사전 적용
   로컬환경에서는 사용자 정의 사전을 사용했지만 EC2에서는 OOM 문제로 인해 적용하지 못했는데요,
   EC2 업그레이드 이후 사용자 정의 사전을 적용해 볼 예정입니다

2. 새롭게 추가되는 데이터 수집
   키프리스에서 새롭게 추가되는 특허 데이터들을 주기적으로 서버에 저장하는 데이터 파이프라인을 구상할 예정입니다.

3. 사용자 클릭 로그 확보
   사용자들의 클릭에 대한 로그 정보를 확보하여 검색 결과 정확도 향상의 분석 자료로 활용해 보는 시간을 가질 것입니다.

---

🚨 여기서부터는 저만의 기록이기 때문에 경어체를 쓰지 않겠습니다..!

피드백 및 느낀 점

- 기술 선택 근거가 명확하고, 개선하려고 엄청 고민하고 행동한 흔적이 잘 보인다.
- 완성도가 높아서 신기하다.

생각하고 걱정했던 것보다 더더욱 좋은 피드백들을 받았다.
특히 검색 정확도와 검색 속도 관련해서 긍정적인 피드백을 받을 때마다 진짜 보람차고 뿌듯해서 날아갈 뻔 🤭💨

멘토님들께서 피드백과 더불어 여러 방향의 질문을 하셨다.
데이터 정형화 쉽지 않았을텐데 전처리는 어떻게 했는지,
ELK 처음 설정할 때 어떤 문제가 있었는지,
트래픽은 어떻게 분산했고 왜 그렇게 했는지 등등 확인을 위한 질문이었다.

모든 질문에 최선을 다해 답변을 드렸지만, 아직 부족한 느낌이 들고 만족스럽지 않았다.
최대한 구체적으로 답변할 수 있게 프로젝트를 다시 돌아보고 정리해 봐야겠다.

---

최종 회고

무엇을 배웠나

1. 프로그래밍을 대하는 자세

기술을 활용할 때는 공식 문서부터 본다

⇒ 기술은 버전별로 내용과 기능이 많이 다르기 때문이다

사실 이 프로젝트 하기 전부터 공식 문서의 중요성은 익히 들어왔다. 회고 글이나 공부법을 소개하는 글에서 공식 문서의 중요성을 얘기하는 사람들이 많았기 때문이다. 하지만 나는 별 감흥이 없었다.
그때 당시 마인드는,

ㅇㅖ ..? 한국어로 적혀 있어도 어렵운데 이걸 영어로 보라구요 ? 
나름 영어 가까이하면서 살아왔는데도 이건.. 어우.. 너무 어려운 걸요🥲

근데 많은 우여곡절 끝에 이런 변화가 생겼다
포스팅을 똑! 같! 이! 따라 해도 나만 안 되는 경우가 너무 많아 ~ 근데 이유도 각양각색 ~

블로그로 쉽게 이해하려고 하다 시간이랑 노력 많이 날아갔다..... 아주 호되게 당했다🤭
그제야 왜 많은 선배님들이 공식 문서의 중요성을 설파하셨는지 조금 알 것 같았다.

사실 일반 블로그 포스팅들도 여전히 많이 본다. 아주 많이 본다.
좋은 정보를 잘 정리해 주신 분들이 너무 많아서 항상 감사한 마음으로 챙겨봄..ㅎㅎ
근데 순서를 좀 바꿔서 이제는공식 문서부터 보는 습관을 가지려고 노력한다.

IT 기업에서 운영하는 기술 블로그, 컨퍼런스 챙겨보기

개발 공부를 시작한 지 얼마 안 됐을 때도 보기는 봤었다.
워낙 여기저기 기웃거리면서 신기한 정보 듣는 거 좋아해서 기술 컨퍼런스는 자주 신청했었고(그렇다고 제대로 이해했다는 소리는 아님), IT 기업 기술 블로그도 구글링 하다가 몇 번 보곤 했다.

근데 그때는 흰색은 바탕이오~ 검은색은 글자로다~ 이런 경우가 대부분이었는데,
시간이 지날수록 포스팅을 보고 이해하는 게 점점 많아져서 짜릿하다

실제로 학습한 내용을 프로젝트에 적용하기도 했었다.

• 우아콘에서 마이크로서비스로의 전환기를 보면서 아키텍처 설계와 서비스 안정화의 중요성을 깨달았다. 이걸 보고 확장성을 늘 고려해야 한다고 판단하였기 때문에 기획 단계에서부터 MVP 이후 확장 가능성이 있는 기능들을 정리했다. 아키텍처 설계의 경우, 서버 부하를 줄이고 성능을 개선하기 위해 메인 서버를 스케일 업하였고, 대용량 데이터를 엘라스틱서치에 넣기 위한 데이터 파이프라인 서버를 새로 구축했다.
• 검색 기능 개발할 때는 정말 많은 IT 기술 블로그를 봤다. 배민부터 무신사, 당근마켓, 브랜디, 오늘의 집, 다나와 등등 검색이 안 들어가는 서비스가 없다 보니 관련 자료를 많이 찾을 수 있었다. 원래는 우리 특허 서비스에 사용자 정의 사전을 적용하지 않을 생각이었다. 기업들은 다 ML팀에서 만들어 준다며.. 우리는 누가 뭘 키워드로 검색할 줄 알고 그걸 만들어.. 했는데 기술 블로그 글들을 보고 사용자 정의 사전을 어떻게든 찾아내야겠다는 결심을 했다. 다들 기본적으로 쓰고 있는데 우리도 실 서비스 못지않은 퀄리티 내려면 무조건 써야지! 이런 생각을 했기 때문..ㅎㅎ 어쨌든 결국 찾아냈고 정확도 문제도 해결했다~!
• 네이버 컨퍼런스(DEVIEW)도 검색 서비스의 전체 사이클을 이해하는 데 많은 도움이 됐다. 특히 검색 결과 정확도 개선할 때 아주 핵심적인 힌트를 얻었다. 인덱스 텀과 쿼리 텀 일치시키기! 아주아주 당연한 건데 왜 놓치고 있었을까요🥲 DEVIEW 덕분에 해결했슴다 (하하)

솔직히 여전히 많이 많이 어렵다. 학습한 자료들도 A부터 Z까지 제대로 이해했다고 자신할 만한 정도도 아니고.. 하지만 이 자료들을 내 개발 공부의 지표로 삼고 꾸준히 챙겨 볼 예정이다.
이해하는 게 많아진다 = 실무에 가까워지고 있다! 이렇게 생각하기 때문이다.

2. 무엇이든 할 수 있다는 자신감

역시 언제나 그랬듯이 끈질기게 매달리면 결국 할 수 있다! 또 한 번 깨달았다.

사실 기우제처럼
끈질기게 매달렸더니 해결됐다(❌)
해결할 때까지 끈질기게 매달렸다(⭕)

이거지만..🤭

프로젝트하면서 소통 문제부터 기능적 문제까지 매 순간이 트러블 슈팅이었다.
하지만 진심으로 모든 문제를 잘 해결하고 싶어서 다각도로 많이 고민했다.
가장 놀랐던 점, 중학생 때 전교회장하면서 했던 고민을 똑같이 하고 있더라. 그때도 혼자서 다 챙기려다 힘들어했었는데.. 여전히 그걸 못 고치고 또 힘들어하고 있었다.

그때처럼 리더십에 관한 책을 사서 읽고, 부모님께 지혜를 배웠다.
아버지는 그때와 똑같은 가르침을 주셨다.
혼자서 다 하는 건 진정한 리더십이 아니다. 모두가 조직에 대해 오너십을 갖게 해야 한다.
이걸 잊고 살다가 다시 한번 리더십에 대해 고민하고 깨달음을 얻었다.
이번엔 조직에 관한 아티클도 읽고 유튜브 명강의도 찾아 들었다.

모든 채널에서 얻은 좋은 리더와 좋은 조직에 대한 핵심은 이거였다.
"모든 구성원들이 조직에 대해 오너십을 갖도록 하기"
"심리적 안전감이 드는 조직 분위기를 형성하기"

일의 체계와 명확성을 갖도록 역할을 분배하고, 각자 맡은 역할을 잘 수행할 수 있게 매일 스크럼으로 확인했다.
문제가 생길 땐 내 일, 네 일이 아니라 우리 모두의 일이 되도록 했다. 실수하거나 일정에 차질이 생기더라도 괜찮아요 우린 함께라서 결국 해낼 수 있어요 를 피력하려고 많이 노력했다.

이렇게 문제가 생길 때마다 치열하게 고민했기에 큰 프로젝트를 무사히 잘 마무리할 수 있었다고 생각한다.
근데 다 떠나서 가장 중요한 건 좋은 팀원들을 만났기 때문, 함께 성장하고자 열정 넘치는 팀원들과 함께였기 때문에 가능했던 일이라고 생각한다.

3. 많은 사람들의 도움이 있었기에 가능했던 일 + 이타적인 자세

6주 내내 입에 달고 살았던 말이 있다. Shout out to XXX ~~!~!!!
shout out shout out ~! 장난처럼 말했지만
진심으로 shout out 할 분들이 많다.

Thanks to.

실전 프로젝트 첫날, 팀원들과 그라운드 룰을 정하면서 “이 시기를 되돌아봤을 때, 스스로 후회하지 않을 만큼 치열한 6주를 보내고 싶다.”라는 이야기를 나눴습니다.

6주가 지난 지금, 스스로 생각하기에 치열하게 보냈다고 자신할 수 있어 뿌듯합니다.

어느 것 하나 쉬웠던 적이 없던 프로젝트였습니다.

2주 차 때는 기획 변경 후 mvp 개발하느라 스파르타로 진행되었고,
3주 차 때는 서비스를 위한 ELK 구축 자체가 막막했고,
4주 차 때는 지금 가는 방향이 맞는지, 기한 내 완성은 될는지, 프로젝트 일정을 어디까지 잡아놔야 할지 등으로 걱정이 가득했고,
5주 차 때는 오타 교정 기능에 따른 검색 결과 정확도를 개선하느라 잠을 이루지 못했습니다.

매주 새로운 어려움을 마주했지만, 모든 걸 이겨내고 계속 나아갈 수 있었던 건 각자의 역할에 최선을 다하고 열정 넘쳤던 팀원들 덕분이라고 생각합니다.

마지막까지 최선을 다 한 우리 팀원들 덕분에
이번 6주 차는 “행복”, “뿌듯함”, “성취”라는 키워드로 기억될 것 같습니다.

프로젝트 시작부터 마무리까지 아낌없는 조언과 가르침 주신 멘토님 너무 감사드립니다. 길을 잃은 느낌이 들 때마다 멘토링 사전 노트에 질문을 썼는데,  멘토님의 가르침 덕분에 길을 찾고 다시 나아갈 수 있었습니다.

프로젝트 진행에 어려움이 없도록 살펴주시고 도와주신 매니저님께도 감사의 말씀을 드립니다.

어려움이 생겨 도움을 요청했을 때마다 자신의 프로젝트처럼 같이 해결법을 고민하고 열심히 도와주신 스프링팀 1조 팀원분들! 진심으로 감사합니다

단순히 ‘새로운 기술을 사용했다!’에서 그치지 않고
새로운 기술을 왜 사용했는지, 어떻게 사용했는지, 어떤 어려움이 있었고 어떻게 해결했는지를 설명할 수 있는 프로젝트를 진행한 것 같습니다.

이 경험이 앞으로 있을 많은 프로젝트 진행에 큰 도움이 될 것 같습니다.