스타트업 백엔드 개발 인턴 5달차 후기 - 글로랑

벌써 12월

지난 7월 입사를 한지 벌써 5달이 훌쩍 지났다. 많은 일들이 있었던 거 같은데 시간은 그만큼 빠르게 지나간 거 같다.
이전과 같이 이 글을 읽는 독자는 인턴을 앞둔 개발자라고 가정하겠다.

두 달 차에 남겼던 후기가 있다. 참고하면 좋을 거 같다.

 

2025.08.23 - [인턴] - 스타트업 백엔드 개발 인턴 2달차 후기 - 글로랑

스타트업 백엔드 개발 인턴 2달차 후기 - 글로랑

 

 

개발

사실 개발 쪽에서 배운 것은 유지보수, 보안과 관련된 일들이다. 그 밖에는 컨밴션이나, 구조 같은 것은 이전과 크게 달라지지 않았다.
QA와 스프린트 회고, 제품의 방향성 결정 등 개발과 직간접적으로 관련 있는 일들이 더욱 많았던 거 같다.

유지보수

코드는 처음 보는 사람도 술술 읽히고 개발을 따라가기에 어렵지 않은 코드가 클린코드라고 생각한다. 사실 기획 이후 개발을 들어가면 변수명과, 엔티티명에서
고민을 많이 한다.

• 더욱 직관적인 이름은 없을까?
• 이전에 사용하지 않았던 이름이었던가?
• 다른 사람(처음 보는 사람)이 보아도 이해 가능한가?
• 컨벤션에 위배되지 않는 이름인가?

하면서도 1~2주 뒤에 다시 사용할 때 아 이 DB가 어디에 사용되는 거였지? 하고 헷갈린다.
따라서 따로 문서로 정리해 놓는 것도 중요하고 시간이 남으면 머릿속에 남기려고 노력한다. 여기에 관련된 것은 책 Clean Code 가 회사에 있어서
읽어보고 있는 중이다. (찾아보니 이 한 권만 읽고 광신도가 되면 안 된다고 한다...)

보안

우리 서비스 중 하나는 다른 파이썬 서버를 거쳐서 응답을 받는다. AI를 사용하기 때문에 코틀린환경보다 빠르게 제작가능하고, 지원되는 툴들이 많아서 이렇게 개발했는데 이 부분에서 문제가 있었다. 파이썬 서버에 SQL injection이나, key값을 시도하는 등 침투했던 흔적이 남았다.

내가 발견한 것이 아닌 다른 인턴분이 발견해서 사실 조금 아쉬웠다. (아마 파이썬에 있는 프로젝트를 그대로 Kotlin으로 옮기는 것은 내가 하지 않을까?)

다른 서버를 하나 파서 환경설정을 하고 보안문제까지 해야 하니 여간 손이 많이 가는 게 아니다. 다른 회사에서는 어떻게 하는지? 어떻게든 서버를 하나만 두는지 궁금하다.
사실 파이썬 쪽 보안을 조금 더 강화하는 방향이 좋다고 생각한다.

코딩 컨벤션(Coding Convention)

새로 오신 백엔드분이 기존의 컨벤션에서 유지보수등을 조금 더 최적화한 컨벤션을 제시하셨고 개발리더분이 이렇게 가보자 하고 새로운 컨벤션을 적응하는 기간을 가졌다.

 

항목	기존 컨벤션	새로운 컨벤션	변경 이유
Controller 파일 구조	하나의 도메인 파일에 여러 컨트롤러 클래스를 함께 선언함	컨트롤러 파일당 1개 컨트롤러만 선언	단일 책임 원칙(SRP) 강화, 파일 탐색 용이성 증가, 충돌/리뷰 범위 축소
Service 파일 구조	하나의 파일에 여러 서비스 로직 또는 클래스가 섞여 존재	서비스 클래스도 파일당 1개만 선언	서비스의 책임 명확화, 테스트·DI 구조 단순화
DTO 관리 방식	별도의 DTO 패키지에 DTO들을 한꺼번에 모아 관리	컨트롤러·서비스와 같은 위치에 DTO를 함께 배치 (파일 또는 패키지 근접)	흐름(입력→비즈니스→출력)을 한 파일/폴더 내에서 한눈에 파악 가능, 이동 비용 감소
UseCase 적용 방식	서비스 인터페이스 규칙 없음 (각자 형태로 작성)	UseCase<T, R> 인터페이스를 반드시 override하여 서비스 선언	통일된 패턴 확보, 서비스 호출 구조 표준화, 재사용성 및 테스트 용이성 증가
패키지 구조 관점	기능보다 기술적 요소별(Controller/Service/DTO)로 분류	기능·도메인 중심 구조로 통일 (Controller+Service+DTO 위치 근접)	도메인 단위 수정·확장 시 속도 증가 및 실수 방지

 

이렇게 바뀌었는데 일이 있어서 이전구조를 들여다보아도 생각보다 쉽게 다시 이해할 수 있었다. 좋은 컨벤션이 필요한 이유라고 생각한다.

 

QA

따로 QA팀이 있지 않아 직접 QA를 진행한다. 개발, 개발 후 DEV서버에 올라간 뒤 직접 만든 서비스를 테스트 후 QA에 들어가지만 할 때마다 새로운 버그, 특이사항, 사용자 편의를 위한 추가개발이 나온다.

어쩔 수 없는 거 같다. 사용자의 자유도가 높을수록 많은 케이스들이 나오니 많이 해봐야 하지 않을까? 최대한 여러 번의 QA를 통해 사용자들에게 더 나은 서비스를 제공하는 게 좋은 거 같다.

 

개발 방향성

이건 개발자보다는 PM, PO가 조금 더 책임감을 느끼는 부분이다. 사용자들을 특정하고 그들은 Pain Point를 해결하는 기획을 하는 것이 그들의 역할이고 우리는 그것보다는 덜 (기획적인) 책임감을 느끼면서 개발하기 때문이다. 하지만 연대책임 같은 느낌을 받을 수 있다. 따라서 새로운 기능을 기획할 때는 회의의
연속이다. 사용자들이 의도를 알아챌 수 있을까? 잘 팔릴까? 돈을 내고 해결하고 싶은 문제일까? 이런 것들을 항상 그들은 고민한다.

회사 입장에서 실패는 곧 돈을 쓴 거다. 그들이 두 달 동안 개발한 프로그램의 시장성이 확보되지 않았다면 개발에 참여했던 사람의 인건비는 오로지 지출이다. 그렇기 때문에 사업이 어려운 거 같다. 뭐랄까? 소비자들의 마음을 읽는 감각 같은 것이 있어야 한다고 생각한다. 가장 책임감과 어려운 작업이 아닐까?

이것에 대해 고민하는 것은 실제로 우리 팀의 서비스 개발중단이 났기 때문이다. 이유는 다음과 같다.

• 공교육 시장은 매우 보수적인 곳이다. 기존의 것들을 굳이 바꾸고 싶어 하지 않는다. 혁식이 일어나지 않는 이유고, 우리의 상품이 판매되기는 어려울 것이다.
• 또한 매 학기 예산이 정해져 있지만 생각보다 많이 짜게 준다. 한 반에 10~15만 원 정도를 생각했지만 실질적으로 그보다 적게 써야 한다.
• 사이클이 있는 시장이기 때문에 스타트업의 숙명인 빠른 소비자 반응을 이끌어 내기 어렵다. 이는 투자나 성과를 보이는 데에 많은 시간이 들어가야 한다.

기존의 서비스를 폐기하는 것은 아니고 스테이징하고 다른 서비스를 개발할 거 같다.

---

느낀 점

아직 배울 것이 너무 많다.

깔끔한 코드, 취준을 위한 알고리즘과 자료구조, 인프라, CS배경지식, 사이드 프로젝트, 새로운 AI활용, 보안, 개발 방법론, 전체적인 컨벤션 등등

이 모든 것이 익숙해질 때까지 무언가를 항상 해야 한다. 압박감이 조금 오지만 해야만 하지 않을까?

조금 더 내년을 다짐해야 한다. 그리고 이 회사에서 오퍼가 들어오지 않았을 때를 대비해야 한다고 생각한다... (ㅠ_ㅠ)
지각, 자잘한 실수들을 많이 해서 조금 아쉽다는 생각이 든다. 과거는 과거고 앞으로가 중요하다고 생각한다.

 

멈추지만 않으면 뭐라도 되지 않을까?