비전공에서 백엔드 준비하시는 거라면 지금 하시는 고민 순서가 딱 맞습니다. 다만 결론부터 말씀드리면 게시판이라서 안 되는 게 아니라, 게시판을 만들어놓고 거기서 멈추기 때문에 눈에 안 띄는 겁니다. 보는 쪽에서 확인하고 싶은 건 화려한 기술 목록이 아니라 이 사람이 왜 이 구조를 골랐는지 스스로 설명할 수 있느냐거든요.
주제는 남들이 안 하는 걸 찾기보다 본인이 실제로 겪은 불편이나 이전에 일하던 분야에서 고르시길 권합니다. 비전공자의 가장 큰 무기가 도메인 경험입니다. 왜 이 서비스를 만들었냐는 질문에 실제 경험으로 답이 나오는 사람과 강의에서 시키는 대로 따라 만든 사람은 면접 대화의 깊이가 확 갈립니다.
기능 개수를 늘리는 대신 부하가 걸리는 지점을 일부러 한두 개만 만들어 보세요. 선착순 예약이나 쿠폰 발급처럼 요청이 동시에 몰리는 상황, 데이터 수십만 건에서의 목록 조회와 검색, 결제나 알림 같은 외부 API 연동, 이미지 업로드 정도가 신입 수준에서 다루기 좋습니다. 이 중 하나만 깊게 파도 중복 발급이 나서 락을 걸었고 대신 이런 손해를 감수했다는 식의 이야깃거리가 생깁니다.
스택은 신입 공고에 가장 많이 걸려 있는 조합이 제일 무난합니다. 자바와 스프링 부트, JPA, MySQL이 기본이고 캐시나 분산 락 용도로 레디스 정도면 충분합니다. 여기에 AWS에 직접 배포하고 깃허브 액션으로 자동 배포까지 붙이면 체감상 가산점이 큽니다. 반대로 카프카나 MSA, 쿠버네티스는 규모에 안 맞게 넣으면 왜 썼냐는 질문 한 번에 무너지니 지금 단계에서는 굳이 권하지 않습니다.
마지막으로 실제 접속되는 배포 주소와 리드미가 완성도를 좌우합니다. 리드미에 구조도와 왜 그렇게 설계했는지, 겪은 문제와 해결 과정을 적고 가능하면 개선 전후 수치를 남기세요. 응답 시간이 800ms에서 120ms로 줄었다는 한 줄이 기능 열 개보다 힘이 셉니다. 프로젝트는 두 개면 충분하고 그중 하나는 깊게 가는 쪽이 낫습니다. 준비 잘 되시길 바랍니다.