1. 프로젝트 진행 상황 및 계획
🥇 팀원이 작성한 리드미(README) 초안 수정하기 (완료)
🥈 이메일 알림 전송 서비스 3차 리팩토링(refactoring)하기 (진행 중, 2025.03.05 완료 목표)
🥉 기술 요건이 많이 겹치는 순으로 채용 공고 목록 보내는 코드 작성하기 (진행 전, 2025.03.06 완료 목표)
4️⃣ 사용자 500명, 일치하는 키워드 1개, 채용 공고 1,000건으로 이메일을 보낸 다음 발생하는 문제 파악하기 (진행 전, 2025.03.07 완료 목표)
5️⃣ FCM(Firebase Cloud Messaging)을 활용하여 핸드폰으로 푸시(Push) 알림 받기 (진행 중, 2025.03.09 완료 목표)
2. "서비스로 출시해도 좋을 만큼 잘 구성했다는 생각이 들었습니다."
(1) 리드미(Read) 링크
"사실 중간 발표회가 끝난 뒤에 4주 차와 5주 차에 각각 무엇을 하면 좋겠다는 계획이 있길 바랐는데, 그 부분을 발표해 주셨네요. 세부 사항은 팀 문서에 잘 기록되었겠지만, 정말 계획을 잘 세워주신 듯합니다."
"이번에도 어떤 채용 공고 키워드 검색이라는, 굉장히 기획적으로도 완성도가 높은 서비스를 만드시는데, 플로우 차트(Flow Chart)나 시스템 아키텍처(System Architecture)도 잘 그려주셨어요. 그래서 이 부분을 보았을 때 굉장히 서비스 완성도가 높다는 생각이 먼저 들었습니다."
"그리고 이 부분에 키워드를 이메일로 전송하는 과정에서 이게 서비스로 출시되어도 좋을 만큼 잘 구성하셨다는 생각이 들었습니다."
"또한 Route53을 비롯하여 AWS도 능수능란하게 사용하신다는 느낌을 받았습니다."
"기술적 의사결정을 하고 나서 전후 성능을 비교하셨을 때는, 성능이 얼마나 차이 나는지 수치로 정확하게 비교해 주셔서 발표 내용을 볼 때 굉장히 신뢰성이 있었다고 말씀드리고 싶었어요. 그래서 '아, 이 기술이 그냥 검색 기능 구현 시 성능이 좋고 검색 엔진(Search Engine)이라서 도입했습니다'가 아니라, 이만큼 성능이 개선되었다고 설명하신 부분이 좋았습니다."
"한 가지 궁금한 점은 이메일 알림 전송 속도를 개선하긴 했지만, 2000명 기준 약 1시간 40분이 걸리는 만큼, 앞으로도 개선할 예정인지 궁금했습니다."
► 이 부분은 속도와 별개로 'Too many login attempts' 오류가 발생하여 SendGrid로 대체하며 속도를 개선했고 앞으로도 개선할 예정이라고 답변했다. 최종 발표회 전까지 못하더라도 꼭 적절한 스레드(thread) 수를 찾으련다.
"사실 스레드 수가 많다고 무조건 좋다고 할 순 없거든요. 그래서 스레드 수를 결정할 때, Elasticsearch EC2에서는 보통 코어(core) 수에 특정 배수를 적용하여 스레드가 몇 개일 때 최적의 결과가 나오는지 보통 테스트하는데요. 이런 부분을 테스트하면 이 장비에서 최적의 개수를 찾을 수 있을 거예요."
"앞선 피드백과 비슷한 부분일 듯한데요. 저는 기술적 의사결정에 쓴 서식(template)이 굉장히 인상적이었어요. 동시성 제어는 표로 구성하셔서 문제 정의가 있고 그다음에 대안, 그리고 결국 우리가 무엇을 선택했는지, 구현 방식은 어떠했는지, 그다음에 결과는 어떻게 나왔는지 보여준 점. 이 첫 번째가 있었고, 두 번째 Elasticsearch 부분은 단순히 '이렇게 개선되었습니다. 이렇게 빨라졌습니다.'가 아니라, 이 기술을 도입한 배경과 근거와 수치화된 정량 지표가 있으니까, 결과에 정말 신뢰성이 있다는 생각이 들었거든요."
"그래서 기술마다 조금씩 다르겠지만, 이렇게 두 가지 서식을 적용한 점이 인상적이었습니다. 앞으로 다른 기술에도 적용해 보시면 좋겠고요. 팀 문서에도 이런 내용이 많더라고요. 아마 꾹 눌러 담아서 가지고 오셨을 텐데, 다른 기술도 이렇게 적용해 주시면 좋을 듯합니다."
"그리고 좋은 의미로 면접관님들이 물어볼 사항이 매우 많지 않을까 싶어요. 궁금한 요소가 되게 생각이 많이 나거든요. 그래서 이런 서식을 꼭 유지해 주셨으면 좋겠고, 다른 팀원분들도 함께 참고해 주셨으면 좋겠습니다."
여태까지 잘 기록해 둔 덕을 이번 중간 발표회 때 톡톡히 보지 않았나 싶다. 리드미(README)를 쓸 때도 기록한 내용을 가져다 썼으니까, 개발만큼 기록을 꼼꼼히 해야 하는 이유를 여실히 체감했다. 고생한 만큼 좋은 피드백을 받았다는 생각에 기분이 좋았다.
애석하게도 솜사탕 구름 위에 대(大) 자로 뻗은 듯한 느낌은 이번 주 일정을 계획한 동시에 가라앉고 말았지만. 팀 문서에 적진 않았지만, 당장 이번 주 금요일에 '구현 사항 설명하기 2회차' 영상을 녹화해야 한다.
개발과 기록과 면접이 이루어 낸 삼단 콜라보라니.
"팀장님, 아무리 기록하길 좋아한다지만 이 정도까지 바라진 않았는데요?"
"행복하시죠?"
"예……."
좀만 더 힘내자.
'끝을 보는 용기' 카테고리의 다른 글
Day 151 - 취하여(취업을 위하여) 프로젝트 76%, 구현 사항 설명하기 1회차 피드백을 받다, 노션(Notion)으로 일정 달력을 만들다 (0) | 2025.03.06 |
---|---|
Day 150 - 취하여(취업을 위하여) 프로젝트 72%, 이메일 알림 전송 로직을 분리하는 데 성공하다 (0) | 2025.03.05 |
Day 148 - 취하여(취업을 위하여) 프로젝트 64%, 중간 발표회 자료를 다 고쳤더니 리드미(README)가 나를 기다리네 (0) | 2025.03.03 |
Day 147 - 취하여(취업을 위하여) 프로젝트 63%, 19분 19초 동안 구현 사항을 설명하다 (0) | 2025.03.02 |
Day 146 - 취하여(취업을 위하여) 프로젝트 61%, 기능 명세서를 처음 작성하다 (0) | 2025.03.01 |