해외 인턴십 1주차 회고

명확한 기획과 요구사항을 바탕으로 시스템을 설계한다.

명확한 기획과 요구사항의 중요성

기존에 했던 팀프로젝트는 기획부터 내가 참여를 했다. 문제 상황을 보고, 페인포인트를 포착하고, 그것을 분석해 솔루션을 구상하는 것까지. 그리고 그 기획에 맞추어 개발을 했다.
회사는 달랐다. 우선 원하는 기획과 요구사항이 명확하다.

1. System Requirements
   User Types, Authentication, Employee Interface, Admin Interface

2. Technical Requirements
   Architecture, Deployment, Code Management, Security, Performance, Streaming

이 요구사항과 기획 문서를 분석했다. 그리고 어떤 기능이 필요한지 뽑아내기 위해 Use Case를 고려하며 Use Diagram을 그렸다.

---

교과목 '소프트웨어 설계'

(잠깐 여담)

나는 인턴을 오기 직전학기에 '소프트웨어 설계' 과목을 수강했다. 앞으로 커리어를 이쪽으로 키워가고 싶다고 생각할 정도로 너무 재밌게 들었다. 프로젝트 짬빠 덕분에 이론은 정말 이해가 잘되고 조금은 쉽게 느껴졌지만, 실습 과제는 달랐다.

한가지의 소프트웨어를 선택해 이를 설계하는 것이 기말 대체 과제였는데, 정말 어려웠다. 하지만 나는 진짜 교수님을 5번 넘게 찾아가서 궁금한 점을 모조리 여쭤볼 만큼 정말 정말 미친듯이 열심히 공부했다. 그리고 발표도 실습도 1등! 당연히 A+을 받았다. 이 과제에서 Use Case를 작성하고 Use Diagram, Class Diagram, Sequence Diagram을 그렸다. 처음에는 이게 맞나 싶을 정도로 많이 어려웠는데, 교수님께서 '결국에 니가 해내는 구나'라는 말을 하셨을 정도로 나름 잘 했다.

과제를 하는데에서 가장 혼란스러웠던 것은 명확한 요구사항이 없다는 것이었다. 내가 기획한 소프트웨어 시스템에 맞추어 설계를 하는 거라, 그 기준이 오로지 나 자신에게 있었다. 그래서 처음에는 분명 '신체 리듬에 맞춘 게임'으로 시작을 했는데 끝에 가서는 '맥박과 혈압 기반 게임'이 되었다.

즉, 명확하지 않은 요구사항과 기획은 시스템을 설계하는데에 있어서 굉장히 혼동이 된다는 것을 깨달았다.

---

User Validation

회사에서 준 아주 명확한 요구사항과 기획을 보고 Use Case를 뽑아내고, Use Diagram을 작성하면서 어떤 기능이 필요할지 리스트업을 하였다.
개인적으로 프로젝트를 할 때에 비하면 너무나도 좋았다.

그리고 회사의 멘토 분들과 회의를 통해 우리가 만들 기능에 대해 한번 더 확인을 받았다. 이게 소프트웨어 설계에서 배운 User Validation 과정인가! 상당히 두근거렸던 순간이다. 배운걸 내가 써먹는다니 무려 현업에서 흐흐.

내가 만든 Use Diagram 이 잘 작성되었다고 평가 받아서 기분이 좋았다. 그리고 기능을 설계할 때도 계속해서 요구사항을 확인하면서 조금이라도 기획의도와 요구사항에 맞지 않는다면 방향성을 제고하였다.

---

팀 회의에서 회의 목적을 상기하다.

이 미팅이 끝나고 우리팀을 팀 미팅을 바로 또 진행했다. 생성한 Wire Frame을 함께 확인하기 위함이었다.

여기서 의견 차이가 발생하였다.

나는 Wire Frame과 User Flow를 보면서 우리의 시스템 동작이 어떻게 흘러가고, 이 기능이 여기서 쓰이고 어떠한 데이터가 언제 필요한지 그러한 것을 확인하고 싶었다.

그런데 갑자기 한 팀원이 UI를 설계하고 싶다고, 갑 화이트보드에 UI를 그리더니 버튼의 모양은 Square이 좋을지 Round가 좋을지, 색상은 Red가 좋을지 White가 좋을지, 너무나도 세부적인 것까지 의논을 시작하는 것이다.

많이 당황스러웠다. 나는 개발팀 소속이라서 이런 의논에 내가 참여하는 것이 좀 아니다라고 생각 되었다. 그래서 우선 PO에게 이런 내 입장을 간략히 말을 하였다.
그리고 UI를 그리고 있는 팀원에게 조심스럽게 우리 지금 회의의 목적에 대해서 이야기 해보고 싶다고 말했다.

• 나는 개발팀
• 팀원의 마음을 알고 있다.
• 하지만 지금 진행하는 회의는 이전에 진행한 User Validation에 맞추어 확정된 기능과 와이어 프레임을 확인하는 회의라고 생각
• 세부적인 디자인은 추후에 함께 의논하는 것이 필요하다면 너무 좋지만, 지금은 우리가 기존에 모인 목적에 대해 한번 더 생각해줬으면 좋겠다.

이런 식으로 말을 했더니, 그 팀원도 그게 맞는거 같다고 생각한다고 했다.

자칫하면 분위기가 어두워질 수도 있는 순간이었다. 하지만 우선 상대방의 입장을 충분히 알고, 공감한다고 이야기를 꺼냈다. 그리고 나의 입장과 내 생각을 전달하였다. 말투는 기분 나쁘지 않게 신경써서.

상대방이 기분 나쁘지 않게 내 의견을 잘 전달하기 위해서는 상대방의 상황을 충분히 생각하고, 고려했음을 상대방이 알게 해야 한다.
그리고 내 의견을 말하면 된다.

---

스크럼 단위의 프로젝트 진행

스크럼: 팀 단위로 개발의 효율성을 높이는 애자일 개발 방법

• Product Owner
• Scrum Master
• Development Team: 내가 속함

프로젝트 관리의 중요성

WBS, Gantt Chart

인턴을 하면서 가장 좋았던 것을 뽑으라고 하면 바로 전문적인 '프로젝트 관리'이다.
PO는 우리가 뽑아낸 기능과 요구사항 명세서, 기획서를 참고해여 WBS와 Gantt Chart를 만들었다.

WBS는 모듈별로 Use Case가 명세화 되어 있어서 한 눈에 보기 너무 편했다.
Gantt Chart는 모듈에 어떤 것을 해야 하는지 Task가 정리되어 있고, 누가 pic을 했고 얼마나 걸릴 것이고 실제로는 얼마나 걸렸고, 언제 진행했는지 등 진행 상태를 한 눈에 볼 수 있어서 좋았다.

Teams, Trello

그리고 우리는 소통을 위해 Teams, Trello를 썼다.
내가 무엇을 Done 했고, 지금은 무엇을 Doing 하고 있고, 앞으로 ToDo 해야 할 것들이 Trello에 보드 형식으로 되어 있어서 좋았다. 가끔 내가 뭘 했는지 그리고 앞으로 뭘 해야 하는지 그런것들이 정리가 안될 때가 있다. 머리속으로는 개발 이것도 해야 하고 저것도 해야 하고 이거 하다가 저거 하고 그럴 때도 있는데, 혼동이 올 때마다 간트 차트와 Trello를 보면서 개발을 진행했다.

전 직장에서 Jira를 써본 적이 있는데, 솔직히 많이 어려웠다. 백로그, 칸반 보드, 스크럼, 이슈 등등 낯선 용어도 많았다. 하지만 이렇게 Jira나 Trello 같은 협업 툴을 쓰면 내가 지금 무엇을 했고 하고 할 것인지 한눈에 볼 수 있어서 헷갈릴 일이 없다. 그리고 다른 팀원들의 진행상황도 볼 수 있으니 만약에 내가 이슈가 생기면 조금 여유가 있는 팀원에게 도움을 요청하기 편했다.

나는 개발팀에 속해서 Trello를 직접적으로 관리하지는 않았다. PO가 세팅을 하고 전체적인 업무 진행상황을 관리했는데, 정말 힘들어보였다. 그리고 업무 진행상황을 파악하기 위해 정말 적극적으로 소통을 해야 했다.

PO도 같이 온 인턴 중 한명이 담당해서 했는데, 매번 진행상황을 파악하기 위해 팀원들 자리로 와서 묻곤했다. 그리고 우리 팀 중에 다른 팀원은 본인이 무엇을 했고 하고 할 것인지 명확하게 말을 하지 않는 팀원이 있었다. 나는 프로젝트를 할 때 커뮤니케이션을 정말 중요하게 생각한다. 그래서 내가 어떤 Task를 수행할 때마다 Teams에 지속적으로 업데이트를 하면서 PO가 굳이 내 자리까지 오지 않더라도 진행상황을 빠르고 명확하게 파악하도록 노력했다.

Daily meeting

우리는 매일 11시 데일리 미팅을 했다. 자신이 무엇을 했고, 지금은 무엇을 하고, 오늘은 무엇을 할 것인지 등을 이야기하는 자리이다.
멘토님들도 참여하셔서 우리의 진행상황을 지속적으로 확인하고, 피드백을 주셨다.
생각보다 구체적이고 날카로운 질의응답을 하면서 스스로도 많이 성장하게 되었다. '왜?'라는 질문은 정말 중요한거 같다.

---

Architecture

우리가 만들고자 하는 시스템과 우리의 리소스를 파악해서 최고의 아키텍쳐를 짜는 것이 개발 팀의 이번주 업무 중 하나였다.
'회사의 챗봇'을 만드는게 우리 인턴 팀의 업무였는데, 우선 ver 1로 local로 개발을 하라고 하였다. 나는 자동화 배포나 클라우드에 관심이 많아서 이쪽을 해보고 싶었는데 아쉬웠다. 멘토님께도 혹시라도 배포나 클라우드를 사용하게 된다면 내가 꼭 해보고 싶다고 말씀드렸는데, 아직은 그럴 가능성이 없다고 하였다. 기술적으로 보완이 되고 완성적으로 프로젝트가 된다면 나중에 배포를 하면 좋겠다고 하셨다.

AI를 사용해야 했다. 처음에는 경량화 된 모델을 가져와 RAG를 활용해 리트리벌을 하고 응답을 생성하려 했다. 그런데 우리에게 주어진 리소스가 없다고 했다. 그래서 어쩔 수 없이 외부 API인 Gemini를 활용하기로 했다.

나는 Java Spring Boot 개발자이기 때문에 내가 평소에 쓰던 스택으로 개발을 하고 싶었지만, 주어진 4주 (거의 3주)에 빠르게 개발을 하기에는 부적합하다는 피드백을 받았다. 나를 제외한 나머지 팀원들은 개발 경험이 많지 않았고, 그나마 개발 경험이 있는 팀원들은 이전에 Flask를 사용했다고 했다. 그래서 Flask를 활용해 서버를 구축하기로 했다.

DB는 2개를 쓰기로 하였다.

• Meta Data
• Vector Data

나는 Vector DB에 대한 개념을 이번 프로젝트의 아키텍처를 설계하면서 처음 알게 되었다. Vector DB는 문서, 이미지, 텍스트와 같은 비정형 데이터를 고차원 벡터 형태로 저장하고, 이를 효율적으로 검색하기 위해 사용되는 데이터베이스이다. 특히 AI와의 연계가 중요한 프로젝트에서, 대규모의 데이터에서 빠르게 유사성을 기반으로 검색하는 데 강력한 성능을 제공한다.

최적화된 아키텍쳐를 설계하기 위해 많이 고민을 했다. 제공해야 하는 정보와 그에 맞는 구조도 많이 생각을 했다.

우리에게 할당된 자원이 없기 때문에 모든 것을 free local로 개발하라는 요구사항을 맞추느라 상당히 속상했다. 그래도 이런 재정적인 요소를 고려해서 가장 최적화된 설계를 했다.