refactor: 모집공고 등록 API 수정 및 상세 조회 기능 추가 완료

[SongJaeHoonn]

Summary

#651

1. 새로운 랜딩페이지에서 노출될 모집 공고를 위한, 모집 공고 상세 조회 기능(/api/v1/recruitments/{recruitmentId})을 추가했습니다.
2. 모집공고 테이블에 제목, 소개, 설명 칼럼을 추가했습니다.

모집 공고 제목 : title

모집 소개 : teamIntroduction

모집 일정 : processTimeline

모집 설명 : jobDescription

Tasks

• recruitment 테이블에 칼럼 추가
• 모집공고 상세 조회 기능 구현
• 최근 5개 조회 응답에 title 추가

ETC

POST 모집 공고 등록 (/api/v1/recruitments)
l  모집 공고 제목 title
l  모집 공고 소개 teamIntroduction
l  모집 시작 날짜 startDate
l  모집 마감 날짜 endDate
l  모집 일정 processTimeline
l  모집 대상 target
l  모집 타입 applicationType
l  모집 설명 jobDescription

GET 모집 공고 목록 (/api/v1/recruitments)
l  id
l  모집 공고 제목 title
l  모집 시작 날짜 startDate
l  모집 마감 날짜 endDate
l  모집 타입 applicationType
l  모집 대상 target
l  모집 상태 status
l  수정 일시 updatedAt

GET 모집 공고 상세 조회(/api/v1/recruitments/{recruitmentId})
l  id
l  모집 공고 제목 title
l  모집 공고 소개 teamIntroduction
l  모집 시작 날짜 startDate
l  모집 마감 날짜 endDate
l  모집 일정 processTimeline
l  모집 타입 applicationType
l  모집 설명 jobDescription
l  모집 대상 target
l  모집 상태 status
l  수정 일시 updatedAt

SQL

ALTER TABLE recruitment ADD COLUMN title VARCHAR(100) NOT NULL DEFAULT '';
ALTER TABLE recruitment ADD COLUMN team_introduction TEXT NOT NULL DEFAULT '';
ALTER TABLE recruitment ADD COLUMN process_timeline TEXT NOT NULL DEFAULT '';
ALTER TABLE recruitment ADD COLUMN job_description TEXT NOT NULL DEFAULT '';

Screenshot

• 모집 공고 목록(최근 5건)

• 모집 공고 상세 조회

[limehee]

추가된 컬럼들이 접두어로 recruitment를 사용하는 것으로 보여요. 하지만 접두어가 없어도 해당 데이터가 recruitment와 관련되었다는 점이 충분히 분명하기에, 접두어를 제거해도 무방할 것 같아요.

또한, 데이터 예시를 보면 recruitmentDetail은 팀에 대한 소개를, recruitmentDescription은 지원자가 채용 후 참여하게 될 환경과 업무의 특성을 의미하는 것처럼 보여요. 작성될 내용의 특성을 더 구체적으로 나타낼 수 있도록 컬럼명을 변경하는 것이 작업자는 물론 협업이나 유지보수 측면에서도 더 효율적일 것 같아요.

마지막으로, recruitmentSchedule은 채용 과정별 일정을 작성한 컬럼으로 보이는데, startDate와 endDate 컬럼과 의미가 혼동될 여지가 있어 조정이 필요해 보여요. 컬럼 이름을 명확히 구분되도록 개선하는 것을 제안드려요.

[SongJaeHoonn]

@limehee

추가된 컬럼들이 접두어로 recruitment를 사용하는 것으로 보여요. 하지만 접두어가 없어도 해당 데이터가 recruitment와 관련되었다는 점이 충분히 분명하기에, 접두어를 제거해도 무방할 것 같아요.

저도 작업하며 변수명에 대해서 많은 고민을 했었습니다. 코딩보다 어려운게 변수 이름 짓는 것 같아요
일단 프론트에게 전달받은 변수명을 바탕으로 칼럼들을 추가했는데, 저 역시도 recruitment 접두어는 제거하는 것이 낫다고 판단합니다.

또한, 데이터 예시를 보면 recruitmentDetail은 팀에 대한 소개를, recruitmentDescription은 지원자가 채용 후 참여하게 될 환경과 업무의 특성을 의미하는 것처럼 보여요. 작성될 내용의 특성을 더 구체적으로 나타낼 수 있도록 컬럼명을 변경하는 것이 작업자는 물론 협업이나 유지보수 측면에서도 더 효율적일 것 같아요.

가장 팀에 대한 세부적인 내용이 들어간다고 생각해서 detail이라고 해도 괜찮을 것 같은데 별로일까요?
description의 경우 코어팀 모집에서는 지원자가 채용 후 참여하게 될 환경과 업무의 특성이 들어가겠지만, 다른 모집의 경우 다른 설명 내용이 들어갈 수 있기에, 심지어 위 사진의 제목이 "설명"이라 description으로 하게 되었습니다. 혹시 좋은 변수명이 있으시다면 추천해주시면 감사하겠습니다!

마지막으로, recruitmentSchedule은 채용 과정별 일정을 작성한 컬럼으로 보이는데, startDate와 endDate 컬럼과 의미가 혼동될 여지가 있어 조정이 필요해 보여요. 컬럼 이름을 명확히 구분되도록 개선하는 것을 제안드려요.

startDate와 endDate로 모집 기간을 나타내고,
recruitmentSchedule은 말씀해주신대로 채용 과정별 전반적인 일정을 문자열로 받게 되어 Schedule이라는 표현이 전반적인 일정이라는 느낌과 가장 잘 어울린다고 생각해서 이렇게 이름을 지어봤는데, 조금 더 생각해보겠습니다.

[limehee]

가장 팀에 대한 세부적인 내용이 들어간다고 생각해서 detail이라고 해도 괜찮을 것 같은데 별로일까요?
description의 경우 코어팀 모집에서는 지원자가 채용 후 참여하게 될 환경과 업무의 특성이 들어가겠지만, 다른 모집의 경우 다른 설명 내용이 들어갈 수 있기에, 심지어 위 사진의 제목이 "설명"이라 description으로 하게 되었습니다. 혹시 좋은 변수명이 있으시다면 추천해주시면 감사하겠습니다!

• detail이라는 이름은 주체가 명시되어 있지 않아서 모호하고, 팀에 대한 소개를 의미한다는 점이 명확히 드러나지 않아요. teamIntroduction과 같이 의미를 직관적으로 알 수 있는 이름이 더 적합하다고 생각해요.

• description이라는 이름은 모집 공고 전반에 대한 설명을 포함할 수 있어 다소 포괄적인 느낌을 줄 수 있어요. HR 도메인에서는 일반적으로 Job Description이라는 용어를 사용하는데, 이는 채용하고자 하는 직무에 대한 기본적인 설명, 업무 범위, 해당 직무를 효과적으로 수행하기 위한 역량 등을 포괄적으로 가리켜요. 이러한 이유로 jobDescription이라는 이름을 추천드려요.

startDate와 endDate로 모집 기간을 나타내고,
recruitmentSchedule은 말씀해주신대로 채용 과정별 전반적인 일정을 문자열로 받게 되어 Schedule이라는 표현이 전반적인 일정이라는 느낌과 가장 잘 어울린다고 생각해서 이렇게 이름을 지어봤는데, 조금 더 생각해보겠습니다.

• 채용 과정 전반의 일정을 나타내는 표현으로 processTimeline은 어떨까요? schedule이라는 표현보다 채용의 흐름을 강조하면서, 더 명확한 의미를 전달할 수 있을 것으로 보여요.

---

제가 제안하는 이름은 단순히 의견일 뿐이고, 반드시 반영하지 않아도 괜찮아요. 중요한 건 삽입될 데이터의 의미를 명확히 표현할 수 있는 이름을 사용하는 거에요. 팀원들과 적극적으로 의견을 공유하고, 이에 대해 논의하면서 적절한 이름을 결정했으면 좋겠어요.

[SongJaeHoonn]

@limehee

• detail이라는 이름은 주체가 명시되어 있지 않아서 모호하고, 팀에 대한 소개를 의미한다는 점이 명확히 드러나지 않아요. teamIntroduction과 같이 의미를 직관적으로 알 수 있는 이름이 더 적합하다고 생각해요.

• detail을 명명할 때 사실 teamIntroduction도 생각을 했었습니다.
  하지만 저희 모집 공고가 전부 팀을 뽑는게 맞나? 라는 생각이 들어 고민을 많이 했었는데, 운영진 모집도 운영진 팀, 동아리원 모집도 동아리(팀), 코어팀 모집도 팀이므로 괜찮을 것 같다는 생각이 들어 teamIntroduction으로 수정 완료했습니다!

• 채용 과정 전반의 일정을 나타내는 표현으로 processTimeline은 어떨까요? schedule이라는 표현보다 채용의 흐름을 강조하면서, 더 명확한 의미를 전달할 수 있을 것으로 보여요.

• processTimeline 좋은 것 같아요. 모집 기간과 구분되어 전반적인 일정을 나타냄을 직관적으로 이해할 수 있을 것 같습니다! 이것도 수정 완료했습니다.

• 이러한 이유로 jobDescription이라는 이름을 추천드려요.

• jobDescription의 경우는 팀에 합류했을 때의 이점도 적을 수 있기도 하고, 팀에 대한 다른 설명도 적을 수 있게 되어 좋네요.
  HR에서 직무 기술서라는 이름으로 실제로 사용된다는 것도 처음 알았네요! 팀원들의 피드백과 의견을 받은 후 이것도 적용 완료했습니다. 정말 감사합니다!

[limehee]

• PR에 모집 공고 항목별 컬럼명과 스크린샷이 기재되어 있는데, 최종 결정된 컬럼명으로 수정하는게 더 좋을 것 같아요.
• 번거로우시겠지만, 메시지 파일 수정(twoFactorAuthentication)과 PR 작업 내용만 수정해주시면, 그 외에 추가적으로 손볼 부분은 없을 것 같아요. 감사합니다 😊

[mingmingmon]

Recuritment 테이블의 칼럼이 추가되는 변경사항을 확인했어요.
이 변경사항에 대한 SQL문을 PR에 추가해주시면 좋을 것 같아요!

[SongJaeHoonn]

프로젝트에서 hibernate의 ddl-auto 옵션이 update로 되어있어 칼럼 추가시에는 자동으로 감지되어 쿼리문을 적용해주는 것으로 알고 있습니다.
칼럼의 타입이나 이름, 제약 조건이 변경된 것이 아닌 단순 추가이므로 쿼리를 따로 날리지 않아도 괜찮지 않을까요?

[mingmingmon]

확인했습니다! DB가 컨테이너 상으로 관리되고 있어서 SQL 작성이 필요하다고 생각했었네요!

[limehee]

나중에 작업 내용을 추적하기 위해 PR을 살펴봤을 때, 구조적인 변화를 쉽게 확인할 수 있도록 하기 위함이지 않을까 싶어요.

---

아래 내용은 해당 작업과는 무관하지만, 생각이 나서 제안드려요.

현재 ddl-auto 설정이 update로 되어 있는데, 일반적으로 프로덕션 환경에서는 none으로 설정하여 사용하는 경우가 많아요. 이는 데이터베이스 변경으로 인한 안정성 문제를 예방하기 위함이에요.

다만, ddl-auto를 none으로 설정하면 애플리케이션 실행 시 데이터베이스 스키마가 자동으로 변경되지 않기 때문에 변경 사항을 수동으로 관리해야 해요. 그럼에도 이러한 방식은 아래와 같은 장점을 제공해요.

1. 안정성 강화: 스키마 자동 변경은 실수나 버그로 인해 데이터 손실을 초래할 수 있어요. 프로덕션 환경에서는 이러한 위험을 줄이기 위해 스키마를 명시적으로 관리하는 것이 일반적이에요.
2. 표준 관리 방식: 많은 프로덕션 환경에서는 Flyway나 Liquibase와 같은 마이그레이션 도구를 사용하여 스키마 변경을 관리하고, 애플리케이션과 데이터베이스의 상태를 명확히 일치시켜요.
3. 변경 이력 추적: 수동 관리 방식은 변경 사항의 이력을 명확히 기록하고, 추적할 수 있도록 해요. 이는 문제 발생 시 빠르게 원인을 파악하고 수정하는 데 도움이 될 수 있어요.

저희도 애플리케이션에서 자동 업데이트 대신 수동으로 데이터베이스 스키마를 관리하는 방식을 도입하면 어떨까 싶어요. 이를 통해 변경 사항을 더 명확히 관리하고, 예기치 않은 데이터 손실이나 장애를 예방할 수 있을 것 같아요.

[SongJaeHoonn]

새로 생긴 칼럼이 NOT NULL이라 기존 데이터를 옮기는걸 생각 못했었는데, SQL문 추가해뒀습니다!

[SongJaeHoonn]

저희도 애플리케이션에서 자동 업데이트 대신 수동으로 데이터베이스 스키마를 관리하는 방식을 도입하면 어떨까 싶어요. 이를 통해 변경 사항을 더 명확히 관리하고, 예기치 않은 데이터 손실이나 장애를 예방할 수 있을 것 같아요.

사실 운영 환경에서 update 사용의 위험성은 알고 있었고, 제가 합류했을 때에도 운영 환경에서 update를 사용함에 의문을 가지고 있었긴 했는데, 로컬 환경에서 update를 계속 사용하다보니 칼럼 추가에 대한 변경은 자동으로 해주는 것이 정말 편했어서 운영 환경에서도 똑같이 적용하면 되어 "편함" 때문에 계속 사용하고 있다고 생각했습니다.

그러나 MAU가 큰 환경에서는 쿼리문 실수 한번으로 피해가 클 수 있기에, none을 사용하는 것이 맞다고 봅니다.
함께 의논 후 적용했으면 합니다!