개발은 실패를 통해 성장한다: 누구나 리포터 LAB 개발팀의 애자일 문화

생각보다 어려운 굴러가는 바퀴 만들기

모두의 연구소에서 회의를 진행하는 모습

여러 인원이 모여서 사이드 프로젝트를 진행해 보신 경험들이 있으신가요? 처음에 시작할 때에는 여러 사람들이 모여 협업하기 때문에 내가 혼자 진행하는 속도보다 몇 배는 빨라질 것이라 생각하지만 실제 체감해보면 생각보다 느린 프로젝트 속도를 체감해 보셨을 것입니다. 그래서 이를 해결하기 위해 여러 규칙들을 만들고 프로세스를 정의하다가 결국 프로젝트 진행이 늘어져 프로젝트 인원들이 나가게 되는 경험들도 해보셨을 거라 생각됩니다.

 

저희 누구나리포터 LAB도  다른 사이드 프로젝트와 마찬가지로 무려 13명이라는 인원들이 모여 프로젝트를 진행하는 과정 속에서 여러 시행착오들과 잘못된 선택들을 한 순간들이 다수 존재했습니다. 그런 순간들을 어떻게 이겨내고 문제들을 해결해 나갔는지 소개하면서 누구나 리포터 랩이 가지고 있는 이야기들을 소개하고자 합니다.

흰 종이에 스케치 하기

그림을 그리기 전 스케치하는 모습

 

화가가 흰 종이에 그림을 그리기 위해서 스케치가 필요하듯이 소프트웨어를 개발 함에 있어도 기초적인 스케치가 필요합니다. 저희 누구나 리포터 LAB의 개발 팀도 마찬가지로 프로젝트의 밑그림을 그리기 위해 프로그래밍 언어부터 코드 컨벤션, 프레임워크, 인프라, 브랜치 전략 등 다양한 주제들로 이야기를 나누면서 시작하게 되었습니다.

 

초기에는 프로젝트의 방향성이 정해지지 않았고 서로가 어떤 경험들을 보유하고 있는지 잘 모르는 상황이었기 때문에 명확하게 기술들을 선정하기 어려웠습니다. 그래서 결국 LAB연구를 요청한 누구나 데이터에서 사용하고 있는 기술을 중심으로 활용하자는 것을 중심으로 의견을 좁히게 되었고 그렇게 첫 번째 잘못된 선택을 하게 되었습니다.

누구나 리포터 LAB 개발팀의 초기 기술 스택

프로젝트 환경: Node.js
데이터베이스: Document DB
프레임워크: AWS SAM

코드 컨벤션: Eslint&Prettier

배포 파이프라인: AWS Code Build

 

 

퍼스트 커밋으로 시작된  스타트 총소리

종민님이 올려주신 초기 템플릿 커밋

 

킥오프가 끝나고 난 뒤 저희 개발팀은 초기 프로젝트 세팅을 위해 각자 역할을 나눠 진행하기로 했고 프로젝트 세팅을 담당하신 종민님이 AWS SAM을 기반으로 만드신 템플릿 코드들을 빠르게 올려주신 덕분에 저도 제가 담당한 Lint(일관된 코드를 작성할 수 있도록 도와주는 도구)를 빠르게 시작할 수 있었습니다.

왜 Lint를 적용했나요?
사실 린트를 사용한다는 것은 초기 프로젝트를 개발하는 것에 있어서 오히려 속도를 저하시킬 가능성이 있습니다. 설정하는 방법과 코드 컨벤션 툴에 대한 학습이 필요하기 때문이에요. 하지만 저희 팀은 저를 포함해서 Node.js를 주 기술스택으로 삼고 있는 분이 적었고 서버리스라는 생소한 환경에서 자율성이 높은 Node.js로 개발했을 때 서로 각자의 개성을 가진 코드를 작성할 가능성이 높았기 때문에 린트를 적용하기로 했습니다. 

글또 커뮤니티를 활용한 기술 리서치 :)

 

Prettier&Eslint를 활용해 보신 분은 아시겠지만 린트를 적용하는 것은 상당히 복잡하고 까다로운 작업 중 하나입니다. 린트를 적용하기 위해 수십 개의 설정들을 통해 코드 컨벤션을 설정하는 것들이 매우 복잡하고 IDE(VS Code, 인텔리제이 등과 같은 도구)와 통합하는 과정도 번거롭기 때문에  최대한 설정이 간단하고 러닝커브가 낮은 기술들을 찾아 여러 커뮤니티(레딧, 슬랙)에 수소문을 해보기 시작했습니다.

검색이 아니라 커뮤니티를 찾은 이유?
구글이나 GPT를 통해 얻을 수 있었던 것은 공개적으로 열려있는 기술의 장단점과 기술의 특성이기 때문에 실제 개발자분들이 해당 기술을 사용하면서 충돌 났던 경험, 또는 컨벤션을 구성하면서 느꼈던 체감했던 경험들이 필요했기 때문에 커뮤니티를 통해 정보들을 찾았습니다. AI와 검색 기술이 많이 발전했지만 아직 이런 주관적으로 느꼈던 경험에 대해서는 따라올 수 없다고 생각합니다.

 

글로 커뮤니티에 계시는 귀인 분들이 Biome라는 기술을 강력 추천해 주셔서 해당 기술에 대해 조사하게 되었고 Biome가 장점으로 내세우는 Simple, Fast, Scalable 등의 장점들이 린트를 빠르게 적용함에 있어서 적합하다는 생각이 들었습니다. 하지만 직접 체감하지 않는 이상 신뢰할 수 없기 때문에 로컬 환경에서 실제로 얼마나 간편한지 테스트해봤고 단순히 터미널 명령어 몇 개로 세팅이 간결하게 완료되는 것을 보고 바로 활용하게 되었습니다.

 

자동화를 통해 주기적으로 의식하게 만들기

 

린트와 같은 도구를 적용하는 데에 있어서 고민되는 포인트 중 하나는 "얼마나 강제성을 가지게 할 것인가?"입니다. 너무 강제성이 높을 경우 개발자들의 피로도를 높이고 개발 생산성을 저해할 수 있고 반대로 강제성이 낮은 경우는 린트의 의미가 옅어져 각자의 개성이 담긴 스파게티의 코드들을 보게 될 가능성이 높았습니다.

 

그래서 저희는 PR에 강제성은 부여하지 않지만 개인에게 주기적으로 의식할 수 있도록 PR에 자동으로 리뷰를 남기도록 설정을 해놓았고 이는 실제로 최소한의 코드 품질을 유지할 수 있게 되면서도 적정 수준의 생산성도 보장할 수 있게 되었습니다.

 

누구나 리포터 LAB 개발팀의 2차 기술 스택

프로젝트 환경: Node.js
데이터베이스: Document DB
프레임워크: AWS SAM

코드 컨벤션: Eslint&Prettier Biome

배포 파이프라인: AWS Code Build

 

Type은 행복 개발의 시작입니다

개발 함에 있어서 강제성을 주는 Type에 대한 논란은 개발 커뮤니티에 항상 뜨거운 주제입니다. Type은 개발하는 것에 안전관리자 같은 역할을 하게 되는데 코드를 작성하면서 잘못된 코드가 있다면 빠르게 알려주고 안정적인 코드를 작성할 수 있도록 도와줍니다. 단점은 모든 코드에 타입을 추가해야 되기 때문에 작성해야 되는 코드 양이 많아지고 자율성을 억제하기 때문에 코드의 유연성이 떨어진다는 단점들이 있습니다.

종민님의 의견 제시

 

저희도 처음에는 Type이 주는 안정성을 좋아하시는 분이 많아 Typescript 활용을 고민하긴 했지만 유지보수하는 개발자 분을 고려해서 처음에는 Node.js를 선택했었습니다. 그러다가 종민님이 나중에 인수인계할 때 Node.js 보다는 Typescript를 기반으로 전달드리는 것이 필요한 코드를 빠르게 찾고 이해하는 데에 더 도움이 될 것 같다는 의견을 주셨고 이 내용을 기반으로 누구나 데이터 분들을 설득하여 타입스크립트로 전환하게 되었습니다.

 

누구나 리포터 LAB 개발팀의 3차 기술 스택

프로젝트 환경: Node.js TypeScript
데이터베이스: Document DB
프레임워크: AWS SAM

코드 컨벤션: Eslint&Prettier Biome

배포 파이프라인: AWS Code Build

 

개발과 권한 사이에 갈등과 고민들

 

누구나 데이터에서는 AWS의 서버리스 서비스인 Lambda를 기반으로 서비스를 운영하면서 AWS 서비스를 이미 활용하고 있었고 비영리 기업을 위한 AWS 크레디트도 지원받고 있었기 때문에 인프라에서의 AWS의 사용은 필수적이었습니다.

 

그래서 AWS를 기반으로 개발 환경을 구축하기 위해 누구나 데이터 회사 측에 사용하고 있는 계정에서 IAM 계정을 전달받아 개발을 진행하기로 했습니다. 하지만 초기에는 아무런 권한이 주어지지 않은 상태였기 때문에 필요한 권한이 있을 때마다 담당자 님에게 권한을 요청하는 형태로 업무를 진행했었고 그때마다 해당 서비스에 사용 목적, 비용, 필요 권한 등의 정보를 같이 전달드리는 형태로 진행했었습니다.

 

하지만 이런 형태의 프로세스는 서로의 피로도를 높이고 지속해서 병목이 발생할 수밖에 없는 형태였습니다. 그렇다고 누구나데이터에서 자유롭게 권한을 풀어주기에는 실제 운영하고 있는 프로덕트에 잠재적으로 문제가 생길 수 있다는 점과 예상치 못한 비용을 지출될 수 있기 때문에 회사 입장에서는 제한된 권한을 줄 수 밖에 없는 상황이었습니다.

 

그래서 처음에는 해당 문제를 해결할 수 있는 어떤 기술들을 찾아 살펴보았고 https://engineering.ab180.co/stories/iam-management-consoleme라는 기술을 알게 되었습니다. 엔지니어가 필요한 인프라 권한을 요청하면 관리자가 빠르게 검토하고 부여할 수 있는 오픈소스로써 누구나 데이터에서 걱정하는 보안, 비용적인 문제들을 해결할 수 있는 설루션 중 하나였지만 해당 기술을 도입하기에는 어려운 부분들이 많았습니다.

 

저희에게는 시간이라는 자원이 매우 부족했고 해당 기술을 적용하기에는 프로젝트 규모도 크지 않기 때문에 적절하지 않다는 생각이 들었습니다. 그래서 문제에 좀 더 집중하여 쉽게 해결할 수 있는 방법을 고민해 보았고 그렇게 고민해 본 결과 새로운 계정을 만들고 비용을 모니터링하는 시스템을 만드는 방법을 생각해 내어 최소한의 시간을 활용하여 문제를 해결할 수 있었고 보안, 비용, 생산성 등의 문제들을 손쉽게 해결할 수 있었습니다.

보안 문제: 현재 운영하고 있는 프로덕션 계정과 다른 AWS 계정을 생성하여 해결
비용 문제: 비용 모니터링 시스템을 도입하여 특정 시간 동안 이상 비용 발생 시 슬랙 알림을 보내도록 하여 문제 해결

 

프로그래밍 언어도 바꿨는데, 프레임워크까지?

SAM vs Serverless Framework

 

RPG 게임을 하면서 초보자로 재밌게 게임을 하다가 나와 안 맞는 직업을 선택해 보신 경험들이 있으신가요? 예를 들어 저는 손이 느려 묵직하게 탱킹 하며 한방이 센 직업을 좋아하는데 스타일리시한 캐릭터를 고르고 사냥하다가 몇 대 안 맞았는데 바로 죽는 캐릭터를 보고 '아 이 직업 뭔가 나랑 안 맞다.... 새로 키울까?'라는 생각으로 새로 키워본 경험들이 있습니다.

이처럼 누구나 데이터 개발팀도 AWS SAM을 활용하면서 위와 같은 경험들을 체감했었습니다. SAM은 AWS내에 복잡하게 얽혀있는 시스템을 코드를 기반으로 설정할 수 있는 것에 특화되어 있었고 외부 시스템과의 통합 같은 부분에 약한 모습들을 보였습니다.

• Open API Specitification을 사용하여 자동화된 API문서를 만들기 위해서는 API Gateway와 통합이 필요
• CI/CD 파이프 라인을 구축할 때 모범 사례의 래퍼런스를 찾기 어려움
• 기술문서들에서 필요한 정보들을 찾기 쉽지 않고 필요한 설정들이 매우 복잡함.
• 프레임워크 자체에서 타입스크립트를 적용하려면 여러 수작업들이 필요함.

그래서 저희는 지금까지 개발해 왔던 SAM 프레임워크를 내려두고 서버리스 프레임워크로 전환하는 건 어떨 지에 대해 진지하게 논의하게 되었습니다. 논의하는 과정 속에 민지 님이 "바꿀 것이라면 하루라도 빠르게 전환하는 것이 좋을 것 같다."라는 의견을 주셨고 모든 분들이 공감하여 일단 로컬서버리스 프레임워크를 활용하여 직접 구축해 보고 AWS SAM과 비교해 큰 차이가 없다면 그대로 가기로 결론을 지었습니다.

 

저로 인해 의견이 번복된 만큼 팀원들에게 부담을 주지 않기 위해 프레임워크 전환 작업을 바로 진행하였습니다. 그렇게 다음날 바로 서버리스 프레임워크로 프로젝트를 세팅하고 구축해 본 결과, 확실히 AWS SAM에 비해 설정이 간편하고 참고할 수 있는 자료(레퍼런스)들이 잘 정리되어 있어 학습 곡선이 훨씬 낮다는 점을 확인할 수 있었고 서버리스 프레임워크에서 제공하는 강력한 플러그인들이 외부 환경과 통합됨에 있어서 손쉬운 개발이 될 것 같다는 판단이 들어 서버리스 프레임워크로 전환을 하기로 결정했습니다.

 

AWS SAM으로 프로젝트를 세팅하느라 고생하셨음에도 불구하고 종민님이 감사하다고 말씀해 주셔서 위안이 많이 되었고 민지 님이 빠르게 판단할 수 있도록 피드백을 주셔서 잘 마무리할 수 있었던 것 같습니다.

 

이처럼 직접 체감해 보니 빠른 피드백을 통해 유연하게 선택할 수 문화가 있어 스타트업들이 공룡 기업과 대등하게 경쟁해 올 수 있었던 것 같다는 생각이 들었습니다. 실패라는 판단이 섰을 때 책임을 묻거나 숨겨주는 것이 아니라 건설적인 피드백 순환을 통해 빠르게 의사결정을 하고 유연하게 방향을 수정하는 것. 이런 문화들이 아마 소규모 팀에서 낼 수 있는 힘이라고 생각이 드는 경험이었습니다.

 

그 뒤에 저는 팀원들이 더 빠르게 적응할 수 있도록 서포트하기 위해 가이드 문서를 작성하고 공유함으로써 팀원 분들이 더 빠르게 팔로우업 할 수 있었고 며칠 뒤 금방 적응하여 활용하는 것을 보고 앞으로도 이처럼 문제 본질에 집중하여 빠르게 의사결정하는 것이 계속된다면 앞으로 하는 프로젝트들도 성공적으로 마무리할 수 있을 거라는 확인을 하게 되었습니다.

 

누구나 리포터 LAB 개발팀의 4차 기술 스택

프로젝트 환경: Node.js TypeScript
데이터베이스: Document DB
프레임워크: AWS SAM Serverless Framework

코드 컨벤션: Eslint&Prettier Biome

배포 파이프라인: AWS Code Build

 

세발 앞서가기 위한 한걸음 후퇴

 

카카오 오픈 빌더를 활용해 본 경험이 없어서 처음에는 금방 연동하여 개발할 수 있을 줄 알았는데 직접 경험해 보니 카카오 챗봇을 개발하기 위해 알아야 하는 개념들과 정보들이 생각보다 많았고 카카오 챗봇의 API의 Payload와 Response 구조 또한 꽤 복잡해서 개발하는 데에 생각보다 많은 시간을 투자해야 할 것 같다는 생각이 들었습니다.

 

그래서 "다른 개발자 분들이 최소한의 정보와 코드만으로도 개발할 수 있도록 SDK를 개발해야겠다."라는 생각을 하게 되었고 개발에 바로 착수하게 되었습니다. 하지만 SDK 개발이 처음이다 보니 어떤 구조로 제공해야 다른 개발자 분들이 편하게 개발할 수 있을지에 대해 고민 중이었습니다. 그렇게 고민하다가 복잡한 Json 구조를 객체로 만들어 쉽게 초기화하고 간단하게 접근하는 것이  중요하다는 생각에 빌더 패턴을 기반으로 객체를 생성하고 활용할 수 있도록 개발하기로 했고 카카오 API의 모든 API 스펙들을 클래스로 만들었습니다.

 

그리고 추가적으로 SDK 개발을 쉽게 이해할 수 있도록 가이드 문서와 주석을 작성하였고 같이 협업하고 있는 개발자 분들에게 덕분에 개발 시간을 단축시키고 체계화된 형태로 개발할 수 있었다고 피드백을 주셔서 뿌듯하게 마무리할 수 있었습니다.

 

 

비즈니스의 목적에 맞춰 변경되는 스토리지 선택

백종원이 짬통을 뒤져 남긴 음식을 맛보는 모습

 

백종원이 흑백요리사에서 손님들이 남긴 음식들을 맛을 보고 어떤 것이 문제인지 파악했던 장면을 보신 적 있으신가요? 이 모습을 본 셰프는 백종원의 모습에서 힌트를 얻어 바로 헤드셰프에게 의견을 전달했고 시합 중간에 바로 레시피를 수정하여 손님들에게 다시 만족스러운 요리를 제공할 수 있었습니다.

 

이처럼 LLM 서비스에서도 중요한 것 중 하나는 유저들이 서비스를 사용했던 정보들을 기반으로 데이터를 수집하고 가공하여 재학습시킴으로써 AI의 성능을 지속적으로 향상하고 서비스의 질을 높이는 것이 매우 중요합니다. 그래서 저희는 유저들이 채팅을 이용한 정보들을 로그로 관리하기 위해 처음에는 ELK를 활용하는 것을 고민했으나 지금까지 변화한 기술 스택만으로도 러닝커브와 인프라의 비용들이 충분히 높아졌다는 의견을 팀원분이 주셔서 통합적으로 데이터를 관리할 수 있는 스토리지에 고민을 하게 되었습니다.

 

PostgreSQL

 

혼자서는 결론이 나오지 않을 것 같아 엔지니어(AI 담당) 팀과 같이 이야기를 나누었고 엔지니어 팀에서는 Vector Embeding기능만 제공된다면 어떤 스토리지여도 상관없다고 이야기를 해주셨습니다. 그래서 PostgreSQL가 Vector Embeding 기능을 제공한다는 것과 누구나 데이터에서 Bigquery를 활용하면서 SQL을 어느 정도 활용할 수 있다는 점을 고려하여 PostgresSQL로 스토리지를 전환하기로 결정하게 되었습니다.

 

누구나 리포터 LAB 개발팀의 5차 기술 스택

프로젝트 환경: Node.js TypeScript
데이터베이스: Document DB PostgreSQL
프레임워크: AWS SAM Serverless Framework

코드 컨벤션: Eslint&Prettier Biome

배포 파이프라인: AWS Code Build

 

 

통합적인 환경을 강제하기 위한 CI/CD 파이프 라인 구축

개발 서버는 구축하고 배포할 수 있는 환경을 만들었지만 자동으로는 배포되지 않아 서로의 환경이 충돌했었고 그래서 서로 다른 환경에서 테스트하고 배포하는 형태들이 지속해서 유지가 되었습니다. 실제로 테스트하기 위해서는 통합된 환경이 필요해 하루라도 빨리 배포 자동화를 구축하는 것이 목표였고 초기부터 지속해서 논의가 되었었습니다.

 

초기에는 AWS SAM 기반으로 CI/CD를 구축하기 위해 래퍼런스를 찾아 위의 그림과 같이 구축해 주셨고 Code Build 기반으로 배포 자동화의 스크립트를 작성해 주셨습니다. 하지만 Serverless Framework로 전환하면서 AWS에서 제공해 주는 Code Build와 ECR을 사용하지 않고 깃헙 액션만 활용하는 방식으로 배포 파이프라인의 복잡성을 낮출 수 있었습니다.

 

그렇게 우리는 점점 개발서버 다운 면모를 갖추기 시작했고 개발팀의 협업 성숙도 또한 점점 성장하기 시작했습니다.

누구나 리포터 LAB 개발팀의 최종 기술 스택

프로젝트 환경: Node.js TypeScript
데이터베이스: Document DB PostgreSQL
프레임워크: AWS SAM Serverless Framework

코드 컨벤션: Eslint&Prettier Biome

배포 파이프라인: AWS Code Build Github Action(Serverless Platform)

 

누구나 리포터 LAB의 프로젝트 관리 변천사

 

LAB 활동의 목표들이 점점 구체화되고 협업 과정들이 점점 발전함에 따라 프로젝트에 대한 관리도 점점 발전하기 시작했습니다. 처음에는 어떻게 협업할지, 그리고 작업을 어떻게 구분할지 명확하게 정해지지 않은 상황이라 단순히 Todo를 관리하기 위한 Task 보드로 시작했었습니다.

 

하지만 점점 목표가 명확해지고 점점 해야 될 일들이 많아지면서 새로운 작업들이 우후죽순 생겨나기 시작했고 이렇게 생성된 작업들이 여기저기 흩어짐에 따라 가시성이 저해되고 프로젝트를 관리하기가 어려워져 체계적으로 관리해야 되는 상황이 필요해지기 시작했었습니다. 그래서 저희는 프로젝트의 목표에 따라 프로젝트 관리 페이지도 발전시키게 되었고 궁극적으로 위와 같이 협업하기 좋은 형태로 진화하게 되었습니다.

초기

 

처음에는 목표와 방향이 아무런 형태로 정해져 있지 않은 상황이기 때문에 할 일을 관리하는 것보다 목표를 정하기 위한 자료들을 조사하는 것이 우선적이었기 때문에 간단한 Todo 형태로 업무를 관리했었습니다. 그래서 Task들이 생성되는 것보다는 Task라는 문서 안에 작성되는 내용들이 많았었고 초기에는 그렇게 Task안에 조사한 자료들을 기반으로 앞으로의 목표와 액션들을 구체화하기 시작했았습니다.

 

프로덕트 로드맵 중심의 프로젝트 관리

 

그 뒤에는 프로덕트의 로드맵을 기준으로 업무를 관리하는 형태로 변화하였습니다. 해당 형태로 진행하게 된 배경은 프로덕트의 로드맵을 진행함에 있어 각 스탭마다 어떤 작업들을 하게 될 것인지 구분 짓고 프로젝트 매니저 분들이 이해하기 쉬운 형태로 그룹화하여 보기 위해 위의 형태처럼 작업들을 관리하게 되었습니다.

 

하지만 작게 나뉜 작업들 속에 누가 어떤 역할을 담당하고 있는지 파악하기 쉽지 않았고 하나의 스탭이 긴 기간 동안 지속해서 진행해야 되는 작업이다 보니 하나의 스탭에 작업들이 몰리게 되는 현상들이 발생하게 되었습니다.

랩 활동을 기준으로 만든 프로젝트 관리

 

그래서 랩 활동 기간을 기준으로 데드라인을 명확하게 정의하고 관리할 수 있도록 프로젝트의 진행 상태를 기준으로 우선순위라는 개념을 추가하게 되었고 이를 통해 각각의 작업들을 짧은 호흡을 가지면서 체계적으로 관리하는 형태로 변화할 수 있었습니다.

 

그다음의 문제는 프로젝트의 역할을 명확하게 표현하는 것이 과제였는데 그건 상위 작업이라는 개념을 추가하고 책임자로 위임함으로써 각각의 역할과 책임이 명확하게 구분 짓고 소통할 수 있게 되었습니다.

 

지금까지의 랩 활동을 진행하면서

처음부터 잘못된 선택을 하고 개발하면서 여러 시행착오들이 있었지만, 저희 팀은 이에 굴하지 않고 이를 극복하며 더 빠르게 나아갈 수 있었습니다. 이렇게 이겨낼 수 있었던 배경에는 문제의 본질을 바라보며 최선의 해결방법을 찾으려는 노력과 서로 간의 빠른 피드백을 바탕으로 유연하게 선택했던 과정들이 있기에 가능했다고 생각합니다.

 

아직 앞으로 넘어야 할 산들은 많지만, 지금의 랩원 분들과 함께라면 지속해서 이겨낼 수 있을 것이라 생각이 드네요 ㅎㅎ. 지금까지 제가 했던 선택들과 의견에 대해 적극적으로 피드백을 주시고, 혼자 해결하기 어려운 문제들 속에서 함께 고민하며 해결해 주신 든든한 랩원 분들이 계셨기에 여기까지 올 수 있었던 것 같습니다.

 

지금 생각해 보면 처음에 리드하면서 부족한 부분들도 많았지만 앞으로도 이러한 협력과 신뢰를 바탕으로 더 나은 방향으로 나아가다 보면, 지금까지의 시행착오와 배움들이 앞으로의 도전 속들이 저에게 큰 자산이 되어 좀 더 좋은 리더가 되는데 많은 도움이 될 것 같습니다.