글로랑 인턴 후기: 스타트업 협업, 애자일, 그리고 개발자로서 배운 것들

8개월 글로랑 인턴을 마무리하면서, 이번 경험에서 내가 무엇을 배웠는지 한 번 정리해보고 싶었다. 단순히 “재밌었다”, “힘들었다” 정도의 감상보다, 실제로 스타트업에서 어떻게 일하는지, 협업은 어떤 식으로 이루어지는지, 그리고 개발자로서 어떤 관점이 생겼는지를 남겨두고 싶었다. 나중에 다시 봐도 의미가 있을 것 같고, 비슷한 고민을 하는 사람들에게도 조금은 도움이 될 수 있지 않을까 싶다.

이전글

https://bbakgosu.tistory.com/31

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

 

 

배움 1

가장 먼저 배운 것은 일하는 방식이다. 글로랑 인턴을 하면서 가장 인상 깊었던 건 스타트업의 애자일한 업무 방식이었다. 특히 데일리 싱크가 기억에 남는다. 매일 한 번씩 회의를 하면서 어제 무엇을 했는지, 오늘은 무엇을 할 것인지 공유하는 구조였는데, 처음에는 솔직히 조금 낯설었다. “이걸 왜 매일 하지?”라는 생각이 들 때도 있었다. 그런데 시간이 지나고 나니 이 방식이 왜 필요한지 확실히 느껴졌다.

하루에 한 번이라도 서로의 업무를 공유하면, 팀 전체가 지금 어디를 향해 가고 있는지 훨씬 선명해진다. PM은 각자가 어떤 일을 하고 있는지 파악할 수 있고, 팀원들끼리도 자연스럽게 업무 동기화가 된다. 무엇보다도 내 입장에서는 오늘 해야 할 일을 머릿속에서 한 번 더 정리하게 되는 효과가 컸다. 지금 다니는 회사에는 이런 구조가 없다 보니, 서로 무슨 일을 하는지 가늠이 잘 안 되고 싱크가 어긋나는 일이 꽤 자주 생긴다. 그래서 더더욱, 데일리 싱크 같은 기본적인 커뮤니케이션 구조가 생산성을 꽤 많이 끌어올린다는 걸 체감했다.

배움 2

두 번째로 크게 배운 것은 협업 방식이다. 제품 하나가 만들어지는 과정을 가까이서 본 경험이 정말 컸다. 보통은 PM이 디자이너와 먼저 논의하면서 앞으로 어떤 기능을 만들지, 제품의 방향성을 어느 정도 잡아준다. 그리고 디자이너는 PM과 계속 대화를 주고받으면서 “우리가 이야기한 제품이 이런 모습이 맞을까요?”를 확인해가며 디자인을 만들어간다. 그렇게 나온 결과물을 개발자들 앞에서 공유하면, 프론트엔드는 UI/UX 관점에서 피드백을 주고, 백엔드는 사용자 관점에서 이 기능이 어떻게 느껴질지와 동시에 실제 구현을 위해 필요한 데이터 구조나 서버 처리 방식을 가늠한다. 예를 들어, 화면상에서는 간단해 보이는 기능도 실제로는 DB 구조가 그렇게 되어 있지 않을 수 있기 때문에, 구현 가능성과 리소스를 함께 봐야 한다.

 

그다음에는 스프린트 플래닝이 이어진다. 이번 스프린트에서 어떤 범위까지 가져갈지 정하고, 각 작업에 어느 정도 시간이 걸릴지 개발 리드가 정리해서 전체적인 진행 방향을 잡는다. 이건 팀 단위의 협업 방식에 가깝고, 개발자들끼리의 소통 방식은 또 조금 달랐다. 노션을 통해 필요한 API를 정리하고, 누가 어떤 부분을 맡을지 나누는 방식이 주로 사용됐다. 이 부분은 회사 안에서도 여러 번 방식이 바뀌었다. 필요한 API를 쭉 리스트업한 뒤, 한 사람이 하나씩 맡고 다음 작업을 가져가는 방식도 있었고, 피그마 디자인을 보면서 필요한 API를 화면 단위로 적어두고 특정 도메인이나 기능 단위를 한 사람이 맡아 개발하는 방식도 있었다.

 

내가 인턴 후반부에 경험한 가장 마지막 방식은 꽤 인상적이었다. 피그마를 기준으로 어떤 데이터가 필요하고, 어떤 데이터를 출력해야 하는지를 먼저 정리한 다음, 한 사람이 한 영역을 비교적 책임감 있게 맡아서 진행했다. 그리고 의존성이 큰 부분은 뒤로 미루거나 순서를 조정하면서 풀어나갔다. 단순히 “기능 하나씩 쳐내는” 느낌이 아니라, 제품 구조를 보면서 역할을 나눠가는 방식이어서 훨씬 실무적이라고 느꼈다.

 

또 하나 느낀 점은, 생각보다 디테일에 집착하다가 지나가는 시간이 많다는 것이다. 인턴의 시각에서 봤을 때, 제품에는 코어 기능과 디테일한 요소가 있다고 생각한다. 내 기준으로는 성과를 만드는 비중이 코어 7, 디테일 3 정도다. 예를 들어 넷플릭스를 떠올려보면, 결국 핵심은 콘텐츠와 추천 알고리즘 같은 부분이다. 반면 오프닝 건너뛰기 기능이나 리스트형으로 보여줄지, 더 크게 보여줄지 같은 건 디테일에 가깝다. 물론 이런 요소들도 중요하지만, 제품이 진짜 해결해야 하는 문제를 압도할 정도는 아니라고 생각한다.

 

그런데 실제로는 비교적 바꾸기 쉬운 디테일을 잡는 회의에 생각보다 많은 시간이 쓰이기도 했다. 이게 꼭 틀렸다는 뜻은 아니다. 오히려 실제 제품을 만들다 보면 디테일이 쌓여서 완성도가 올라가는 것도 맞다. 다만 나는 이번 경험을 통해, 앞으로 내가 PM이 되든 개발 방향성을 더 주도하는 역할을 맡게 되든, 제품의 코어와 페인포인트를 먼저 명확하게 잡는 데 더 많은 시간을 써야겠다고 느꼈다. 무엇을 예쁘게 만들 것인가보다, 결국 무엇을 해결할 것인가가 먼저여야 한다는 생각이 더 강해졌다.

배움 3

 

개발 실력에 대한 관점도 많이 바뀌었다. 처음에는 Kotlin으로 백엔드를 시작했고, 이후에는 Python이나 Nest.js 같은 다양한 스택도 사용해봤다. 그런데 흥미로웠던 건, 현업에서의 코딩은 학교에서 생각했던 것과 많이 다르다는 점이다. 학생 때는 “정답에 가까운 코드”, “깔끔하게 잘 동작하는 코드”가 중요했다면, 실무에서는 코드는 어디까지나 수단이라는 걸 더 절실히 느꼈다. 결국 가장 중요한 건 사용자가 제품에 더 오래 머무르게 하는 것, 그리고 사용자의 행동이 기업의 성과로 이어지게 만드는 것이다.

 

냉정하게 말하면, 코드가 조금 지저분하더라도 돈이 되는 제품이면 회사 입장에서는 그게 더 큰 가치일 수 있다. 물론 그렇다고 해서 막 짜도 된다는 뜻은 아니다. 오히려 업데이트를 계속해야 하고, 기능이 확장되어야 하기 때문에 한 번 짤 때 구조를 잘 잡아두는 것이 중요하다. 그래서 더더욱 아키텍처와 설계가 필요하다는 생각이 들었다. 단순히 코드 몇 줄 잘 쓰는 문제가 아니라, 프로그램 구조를 어떻게 가져갈 것인지가 장기적으로 훨씬 중요했다.

 

실제로 일하면서는 헥사고날 아키텍처, 도메인별 컨트롤러와 유스케이스 구조, ORM을 통한 DB 핸들링 같은 방식들을 접했다. 어떤 프로젝트에서는 컨트롤러와 유스케이스 안에 도메인 흐름이 꽤 명확하게 나뉘어 있기도 했다. 이런 경험들이 나한테는 일종의 업계 표준처럼 자리 잡았다. 모듈화, 재사용성, N+1 문제 같은 것도 실제로 맞닥뜨리게 됐다. 물론 개발 속도가 매우 중요할 때는 어느 정도 타협하고 넘어가는 순간도 있었지만, 그 안에서도 가능하면 더 효율적인 구조를 지향하려는 태도는 분명히 느껴졌다.

 

조직문화에 대해서도 생각이 많아졌다. 내가 경험한 글로랑의 조직은 전환이 꽤 빠르게 일어나는 조직이었다고 생각한다. 영어 이름을 쓰고, 의사소통은 수평적으로 하는 편이었지만, 동시에 보고 체계나 의사결정 구조에서는 수직적인 요소도 분명히 존재했다. 나는 개발 조직 쪽에서 주로 경험했기 때문에 회사 전체를 다 봤다고 할 수는 없지만, 적어도 AX의 시작점 같은 시기에 그 변화를 가까이서 본 건 꽤 흥미로웠다. 그래서 더 아쉽기도 하다. 회사가 변해가는 흐름 속에서 더 오래 있었으면 배울 게 많았을 텐데, 그 시점에서 나오게 된 게 조금 아쉽다.

특히 인상 깊었던 건 AI를 조직에 녹여내는 방식이었다. 정직원들에게는 원하면 개인별로 Claude 100달러를 지원해줬고, 실제로 AI를 업무에 잘 활용한 사람들의 유즈케이스를 발표하는 자리도 있었다. 이런 식으로 문화를 만들어주니까, 사람들이 억지로가 아니라 자연스럽게 업무에 AI를 사용하게 됐다. “조직이 이런 식으로 변하는구나”를 꽤 가까이서 본 느낌이었다. 물론 이것만으로 충분하다고 생각하지는 않는다. AI를 잘 쓰는 것과, 데이터를 더 잘 뽑아내는 것, 그리고 의사결정에 AI를 정확하게 연결하는 것은 또 다른 문제다. 그래도 적어도 시작은 꽤 순조로워 보였다.

---

 

마지막으로 남는 감상은 이렇다. 이런 조직문화에서 첫 직장생활에 가까운 경험을 하다 보니, 내 기준이 조금 높아진 것 같다. 사람들은 전반적으로 좋았고, 야근을 하더라도 적어도 “무언가를 함께 만들어가고 있다”는 느낌은 있었던 것 같다. 물론 그 뒤에는 PM분들이 프로젝트 전체 방향성을 잡고, 위쪽 의사결정 라인과의 마찰 같은 것들을 대부분 흡수해주고 있었기 때문이라고 생각한다. 그런 기반이 있었기 때문에 개발자들이 조금 더 개발에 집중할 수 있었던 것 같다.

 

체계적인 조직문화와 협업 방식을 배울 수 있었다는 점에서 정말 감사한 경험이었다. 더 일하고 싶었는데 내 잘못으로 계속 함께하지 못하게 된 건 분명 아쉽다. 그래도 이번 경험을 통해 한 가지는 확실히 느꼈다. 생각보다 정말 열심히 하는 사람과 그렇지 않은 사람은 금방 구분된다는 것이다. 몇 번만 대화를 나눠봐도, 일을 대하는 태도는 꽤 선명하게 드러난다.

 

예전에 정승재 선생님이 했던 말이 떠오른다. 사회에 나가서 조금만 더 성실하게, 조금만 더 최선을 다하면 생각보다 훨씬 앞서갈 수 있다는 이야기였다. 예전에는 그냥 흔한 조언처럼 들렸는데, 이번에는 그 말이 조금 다르게 와닿았다. 결국 꾸준히 책임감 있게 일하는 태도 자체가 경쟁력이 될 수 있겠다는 생각이 들었다.

 

앞으로 다른 곳에서 일하게 되더라도, 글로랑에서 배운 것들은 꽤 오래 남을 것 같다. 스타트업의 애자일한 일하는 방식, PM-디자인-개발 간 협업 구조, 제품의 코어와 디테일을 바라보는 시선, 그리고 기술보다 더 중요한 것이 결국 사용자와 비즈니스라는 감각까지. 이런 경험들을 바탕으로 앞으로는 더 나은 협업 방식을 배우고, 더 좋은 판단을 할 수 있는 개발자가 되어가고 싶다.

---

글로랑 홈페이지: https://www.glorang.com/

Glorang

글로랑 기업정보: https://www.jobkorea.co.kr/recruit/co_read/c/saranginc

㈜글로랑 기업정보 - 직원수, 근무환경, 복리후생 등 | 잡코리아

감사합니다!