😀 자신과 팀소개를 부탁드립니다.

저희 팀은 2023년 6월에 결성이 되었고, 공모전 수상을 목표로 만들어진 팀이었습니다.

수상 이후 더 디벨롭해보자는 의견이 합쳐져서 현재까지 운영하고 있습니다.

팀원은 공모전 인원 제한으로 인해 4명으로 구성했고, 디자이너, 기획자, 프론트엔드 개발자, 서버 개발자로 구성되어 있습니다.

기획과 디자인, 개발까지 전 과정을 경험하고 싶어서 다양한 직무를 가 진 팀원들이 모였습니다.

서비스명은 CO-DISABLED의 약자인 ‘CODI’로 지었어요.

장애인들이 함께 경험을 공유하 고 새로운 공동체를 만들어갈 수 있는 곳이라는 의미를 가지고 있죠.

팀명은 ‘CODI’의 모든 과정에 함께 한다는 의미로 ‘Codinator’로 지었습니다.

오현재

프론트엔드 개발을 담당하고 있습니다. 유저가 장애로 인해 겪을 수 있는 불편 함을 최소화 하기 위한 UI/UX를 어떻게 코드로 옮겨 실제로 구현할지 고민하고 있습니다.

현재는 유저의 피드백을 프로덕트에 반영하는 작업에 힘쓰고 있습니다.

변찬중

서버 개발을 맡고 있습니다. 사이트 이용에 필요한 다양한 기능의 개발을 하고 있고, 서버 인프라도 관리 중입니다.

현재는 팀원과 추가적으로 개발이 필요한 부분이나 코드 및 성능 개선을 위한 작업을 하고 있습니다.

윤지숙

CODI 에서 프로덕트 디자인을 담당하고 있어요.

리서치를 통해 사용자 경험을 조사하고, 이를 토대로 제품과 서비스를 구성하고 디자인하는 역할을 하고 있습니다.

장보민

기획을 맡고 있습니다. 인터뷰 등을 통한 사용자 의견을 서비스에 기획적으로 반영하는 역할을 하고 있으며,

공모전 출품, 서비스 배포, 협업과 관련한 제안서 등의 기획 문서 전반을 담당하고 있습니다.

🤗 프로덕트 소개좀 해주세요~

CODI는 장애인 멘토와 장애인 멘티를 1:1로 매칭하여, 멘토링을 진행할 수 있도록 도와주는 서비스입니다.

장애유무와 희망직무에 따라 추천멘토를 제공하며, 멘티들은 멘토들의 프로 필과 멘토링분야, 자기소개를 확인한 뒤 멘토링을 신청할 수 있습니다.

기존의 온라인 멘토 링의 장점은 가져가면서, 타깃유저가 장애인이라는 점에서 웹접근성을 극대화하기 위해 다양한 장애유형을 고려하고자 했습니다.

다양한 장애 유형을 가진 사용자들이 이용하는 서비스인만큼

초기 개발 단계부터 여러 분류의 장애를 가진 사용자들과의 깊이 있는 인터뷰를 통해 직접적인 피드백을 수집하고,

실제 사용자들의 목소리를 최대한 반영하고자 하였습니다.

특히 웹접근성이 낮은 장애유형인 지적장애, 저시력자, 전맹인 사용자들의 사용성을 향상하고자 웹접근성 기능에 초점을 두고 서비스 전반을 기획, 개발하였습니다.

현재는 서비스를 1차로 배포하였으며, 이 과정에서

1) 장애인 사용자들의 피드백과

2) 비장애인이지만 웹접근성 프로덕트에 관심이 많은 ux디자이너와 개발자, 기획자들의 피드백을

토대로 서비스를 지속적으로 개선하는 과정 중에 있습니다.

이 과정을 통해 프로덕트를 고도화한 뒤, 2차 배포에서는 비즈니스 모델까지 고려하여 최대한 많은 사용자를 확보하는 것을 목표 로 하고 있습니다.

⁉ 프로덕트를 만들게 된 계기는 무엇인가요?

팀 CODI는 고용노동부 공공데이터 활용 공모전에 참여하기 위해 모였어요.

공모전을 위한 공공데이터를 찾던 중 장애인 취업과 관련된 데이터를 발견했는데,

당시 팀원들이 모두 취준생이었던 만큼 취업이 얼마나 힘든지 피부로 느끼고 있었던 시기라 취업 데이터가 단연 눈에 들어왔죠.

처음에는 '장애인들의 취업 시장은 비장애인보다 더 쉽지 않을 거야'라는 생각에서 시작되었어요.

취업 준비 과정이 얼마나 정보에 의존하는지는 우리도 잘 알고 있었어요. 그런데 사전 리서 치를 해보니,

장애인들은 비장애인 취업 준비생들보다도 취업이나 직무 정보를 얻기가 훨씬 더 힘들더라고요.

그리고 장애유형에 따라서 선호직종이나 취업경험이 달라질 수 있는데, 비 장애인 멘토 또는 장애유형이 너무 다른 멘토들에게 간헐적으로 정보를 받고 있다는 걸 알 수 있었어요.

그래서 '최근 취준생들 사이에서 인기 있는 커피챗처럼, 이미 취업에 성공한 장 애인 멘토와 취업을 준비하고 있는 장애인 멘티를 연결시켜주면 어떨까?'하는 생각이 들었죠.

이 아이디어를 가지고 온라인 리서치 및 장애인을 대상으로 한 설문조사를 진행했고,

조사 결과 평균 80% 이상이 '유사한 장애를 가진 멘토를 만난다면 직무 정보를 얻는 데 도움이 될 것'이라는 의견을 가지고 있었음을 확인할 수 있었습니다.

조사 결과를 보고 저희가 생각 하고 있는 서비스가 장애인들의 직무 및 취업 정보 접근성 향상에 도움을 줄 수 있겠다는 확신이 생겼고,

그렇게 장애인 멘토와 멘티를 잇는 ‘CODI’라는 서비스를 만들기 시작했습니다.

‘CODI’는 장애인들이 취업 시장에서 더 많은 정보 접근성을 가지고, 더 쉽게 도움을 받을 수 있는 환경을 만드는 것을 목표로 하고 있습니다.

앞으로도 많은 장애인 분들이 자신에게 맞 는 직무 정보를 얻을 수 있도록 돕는 서비스로 발전하겠습니다.

🤝 팀원분들은 어떻게 만나셨나요?

CODI 는 현재 프론트엔드 개발자 1명, 백엔드 개발자 1명, 프로덕트 디자이너 1명, 기획자 1 명으로 구성되어 있습니다.

초기에 팀빌딩에 있어 공모전 출품을 목표로 하고 있었기에, “짧은 기간 내에 핵심 기능을 완성도 있게 구현한다”는 방향을 가지고 있었습니다.

따라서 팀원들이 모두 팀의 방향을 우선 순위로 두고, 얼라인되는 것이 팀 운영에 있어 가장 중요하다고 판단했습니다.

프로젝트 팀원을 모집하는 커뮤니티 등을 사용해 모집 공고를 게시했고, 지원자들에게는 팀 의 목표와 우선순위를 먼저 알렸습니다.

커피챗 인터뷰를 통해서도 해당 부분에 대한 인식을 확인하는 것에 초점을 두었습니다.

하지만 이러한 과정을 거쳤음에도 불구하고, 프로젝트 도중에 팀원이 이탈하는 이슈가 있었습니다.

프로젝트의 목표와 방향성에 대한 공감 부족이 이유였는데요.

팀원 모집 과정과 인터뷰에서의 얼라인도 중요한 과정이지만, 팀원을 모집한 이후에도 지속적으로 목표에 대해 소통하는 시간이 필요함을 깨달을 수 있었습니다.

이후 재모집 과정을 통해 열정적인 기획자 한분을 모실 수 있었고, 현재는 부족했던 부분을 채워서 약 10개월 동안 꾸준히 팀을 유지해나가고 있습니다.

😱 개발은 어떻게 진행이 됬나요?

프론트엔드는 Next 13, React를 사용했습니다. 개발 기간이 길지 않았다보니, 가장 익숙한 프레임워크를 선택했습니다.

서버의 경우는 초기 세팅이 용이하고, 도메인 위주의 객체지향 적인 설계와 잘 맞는 Java 기반의 Spring Boot를 사용했습니다.

해당 의사결정에는 국내 사용량이 많아 참고할 자료가 많다는 점도 선택에 영향을 주었습니다.

CODI의 타겟 유저를 ‘구직을 원하는 장애인’으로 명확하게 설정했고,

나아가 모든 장애인들 이 멘토링에서 직무 이외의 다양한 정보를 얻어갈 수 있도록 서비스를 확장하는 것을 다음 목표로 하고 있습니다.

저희 팀이 어떻게 CODI 를 만들었는지 개발 단계별로 자세한 설명을 드릴게요.

1. 스프린트

오현재

'짧은 시간 내에 핵심 기능 완성’이라는 목표 달성을 위해, 작업을 스프린트 단위로 진행했습니다.

하지만 모든 팀원들이 스프린트에 익숙하지는 않았기에, 프로젝트에 맞 춘 용어와 규칙에 대한 가이드를 작성해 참고할 수 있도록 했습니다.

툴은 노션의 스프린 트 템플릿을 사용했습니다.

스프린트 계획은 매주 일요일마다 진행했습니다.

이때 백로그를 함께 작성했는데, 구체 적인 작업 내용을 To-do 리스트 형태로 등록하고, 각 작업에 대한 우선 순위를 매겼습 니다.

스프린트 검토도 매주 일요일에 진행했는데요. 이 과정에서 스프린트 동안 새로운 기능 제안, 작업한 기능에 대한 피드백을 주고받았습니다.

실질적으로 기능의 완성도를 높히고, 개선할 수 있었던 시간이었습니다.

하지만 아쉽게도 스프린트를 프로젝트 끝까지 잘 유지하지는 못했습니다.

아래 두가지 이유가 가장 컸던 것 같은데요.

1) 스프린트 기간 대비 많은 양의 작업 할당

2.)완성하지 못한 스프린트에 대한 피드백 부족 만약 다음 프로젝트에도 스프린트를 사용한다면 ‘이월되는 작업을 어떠한 방식으로 처리할 것인가’,

‘한 스프린트에 할당할 적당량의 작업 양’, ‘실패한 스프린트에 대한 피드백 방식’에 대해서는 반드시 고민해 볼 것 같습니다.

2. 도메인 나누기

오현재, 변찬중

기획 단계에서 어피니티 다이어그램을 작성하는 과정이 큰 도움이 되었 습니다.

오프라인 회의에서 화이트 보드와 포스트잇을 활용해 프로덕트에서 사용할 기능들을 모두 나열하고, 공통된 카테고리로 그룹화하는 작업을 가졌는데요.

도메인을 나누는 과정과 유사하여 많은 도움을 받았습니다.

3. 데이터 설계하기

변찬중

데이터 설계는 도메인을 나누고, 도메인 간의 관계를 잡아 놓은 것이 DB 구조에도 대부분 반영되었습니다.

도메인에 구현할 기능을 생각하며 데이터 필드를 추가하고, 연관 관계를 설정해주었습니다.

하지만 지금 생각해보면 개발을 할 때마다 생긴 골치 아픈 상황들이 너무 도메인에 꽂혀 있어서 정규화에 대한 깊은 고민 없 이 적용을 했기 때문인 것 같습니다.

1차 배포 이후 들어온 유저의 피드백을 반영하여 구조 변경을 할 예정인데요.

개발하기 더 편한 방향으로 구조를 바꿔보고 싶습니 다.

4. REST API 구현

변찬중

CODI 프로젝트 이전까지는 개발 경험이 많이 부족했습니다.

특정 도메인 위주로 개발을 하다보니 다양한 기능을 구현해 본 경험이 없었고, 스스로 고민해서 개발한 API가 많이 없었습니다.

그러다보니 회의에서 결정된 많은 API를 혼자서 만들 수 있을지에 대한 부담도 있었습니다.

하지만 AI 툴이나 공식문서, 여러 회사의 테크 블로그 및 책들을 참고해 서비스의 기본 기능부터 공모전 핵심 기능인 추천 API까지 개발할 수 있었습니다.

그 과정에서 크고 작은 실패를 경험하며 조금씩 성장하고 있다는 생각이 들었습니다.

하나의 예로 JPA에 QueryDSL을 적용하기 전까지 우아한 형제들의 테크 블로그 글을 읽어보며,

JPQL이나 Specification 같은 방법보다 QueryDSL이 개발과 유지보수에 더 용이하다는 점도 몸소 느낄 수 있었습니다.

오현재

“자원의 상태를 표현” 한다는 개념에 최대한 적합하게 설계하려고 했습니다.

좋았던 점은, 도메인 나누기, 데이터 설계하기 두 단계에서 많은 시간을 투자하여 설계가 수월했던 것입니다.

REST API 는 Swagger 로 문서화 하여 공유했습니다.

5. 기능 구현

변찬중

유저에게 추천 멘토를 보여주는 과정이 꽤 복잡했습니다. 추천 멘토 기능은 다양한 데이터들을 다뤄야하고,

유저에게 도움이 될 만한 정보를 제공해야 한다는 점 때문이었습니다.

그래서 간단한 기능부터 구현을 하고, 점진적으로 복잡한 기능을 추가하는 방식으로 구현하고자 했습니다.

멘토를 추천하기 전까지의 과정은 다음과 같습니다.

1) 회원가입 후 개인 프로필을 작성한다.

2) 취업한 장애인들의 직무 데이터를 기반으로 직무를 추천한다.

3) 추천한 직무 데이터의 결과값을 기반으로 개인 프로필의 데이터를 합쳐서 점수 를 매긴다.

4) 점수 별로 상위 4명의 멘토를 유저에게 추천한다.

그 결과 유저가 개인 프로필에 기입한 장애 유형이나 중증도, 연령 등의 데이터 와 취업한 장애인들의 직무 데이터를 기반으로 점수를 매겨

최대한 유사한 환경 을 가진 멘토를 추천할 수 있었습니다.

실무에 계신 분들에게는 크게 어려운 로직이 아닐 수 있겠지만 개인적으로는 추천 을 위해 점수를 낸다는 발상을 하는 것 자체가 쉽지 않았습니다.

ㅎㅎ;; 만들고 나서 테스트용 데이터를 만들고, 테스트를 진행한 다음 원하는 결과값을 얻었을 때는 뿌 듯했습니다.

(물론 아직 해결하지 못한 문제들도 많습니다. ㅠㅠ)

오현재

우선 짧은 시간 동안 빈번하게 변경되는 기능을 작업해야 하는 부분이 어려웠 던 기억이 납니다.

변경 이후에도 팀원 모두가 같은 맥락을 공유하기 위해, 변경점을 각각의 문서[DB(노션), REST API (Swagger), 디자인(Figma)]에 누락되는 부분없이 기록하는 점이 중요했습니다.

또한, 최대한 커밋을 잘게 쪼개려고 노력했습니다.

1) 아토믹 디자인

아토믹 디자인을 활용한 고유한 디자인 시스템 구축 디자인을 프로덕트로 구현하는 과정에서는,

디자인 라이브러리를 사용하지 않 아토믹 디자인을 활용하여 고유한 디자인 시스템을 구축하였습니다.

유저의 장애유형에 따라 UI를 수정하는 기능으로 인해, 생산성보다 높은 자유도를 우선 순위로 두었기 때문입니다.

투자되는 리소스가 많아 짧은 기간 내에 프로덕트를 완성하고자 했던 팀의 목표 와는 반대되는 작업이었지만,

결과적으로는 변경과 확장에 대응하기 더 용이하 였기에 좋은 판단이었다고 생각합니다.

가장 작은 단위인 atoms와 상위 단위 인 molecules를 구분하는 기준을 고민하는 점이 어려웠는데,

정답이 없는 문 제라고 생각하여, 최대한 유연하게 생각하고자 했습니다.

2) 캐싱

프로덕트 전반에 적극적으로 사용한 react-query의 캐싱 기능 데이터의 변경 빈도에 따라 staleTime을 다르게 상수화하여 query 전반에 사 용했습니다.

예를 들어, 코디에는 멘티/멘토 모두 캘린더로 자신의 일정을 관리 하는 기능이 있는데요.

각 날짜를 클릭하면 호출되는 query의 staleTime을 길 게 하여, 여러 번 클릭해도 staleTime 내에서는 캐싱된 데이터를 가져오도록 했습니다.

3) 폼 입력, 검증

다양한 폼 입력 요소에 대응하기 위해 직접 구현한 폼 입력, 유효성 검증 기능 CODI에서 사용되는 폼들은 버튼, 드롭다운과 같이

다양한 형태와 데이터를 가 진 입력요소로 구성되어있습니다.

디자인 요건을 충족시키며 해당 입력요소의 데이터의 유효성을 검증하기 위해서는 formik과 같은 폼 상태 관리 라이브러리 로 한계점이 있었습니다.

따라서, 하나의 폼에서 폼 데이터/유효성 검증 조건/에 러 3가지 상태를 나누어 관리하는 custom hook을 직접 구현했습니다.

6. QA

변찬중

개발이 많이 진행되고 꽤 문제 없이 돌아갈 것 같다는 생각을 할 때 즈음 QA 로 겸손을 배우게 됐습니다.

기본적인 부분도 지키지 못한 부분이 많았다는 것이 스 스로에게 큰 충격이었습니다.

이 때 2가지의 후회를 하게 되는데, ‘나는 왜 테스트 코드를 작성하지 않았는가’, ‘확장성을 왜 고려하지 않았을까’하는 후회였습니다.

QA 이후 하나씩 고쳐나갔지만 아직 갈 길이 머네요.

장애인 1:1 온라인 멘토링 플랫폼, 회고 8 현재 : 팀에서 자체적으로 진행한 테스트와 더불어,

소수의 유저에게서 심층 인터뷰 를 해 얻은 피드백을 반영하는 작업을 함께 진행했습니다.

정말 많은 시간이 소요되 었던 과정인데요. QA의 범위를 적절하게 설정하지 못한 점,

테스트 코드를 구현하 지 못한 점 아쉬웠습니다.

하지만 팀원끼리 생각한 가설이 유저의 피드백에서 나타 나거나, 예상치 못한 인사이트를 얻었을 때 정말 즐거웠던 기억이 납니다.

7. 개선하기

현재 커뮤니티 홍보, 채널톡, Google Analytics 등 다양한 경로로 피드백을 수집하고 있습니다.

피드백을 프로덕트를 개선시킬 방향으로 고민하고, 작업으로 옮기는 과정 에 CODI 팀원들은 모두 즐겁게 힘쓰는 중입니다!

👍 재미있었던 것은 무엇이었나요?

오현재

아이디어를 검증하고, 프로덕트로 실현시키는 과정에서 많은 즐거움과 배움을 얻었습니다.

“이것이 좋은 아이디어 인가?” 에 대한 기준을 찾는 것은 정말 어려웠고 많 은 토론을 거쳐야 했습니다.

저는 “초기단계의 프로덕트에서는 소수의 유저보다는 만드 는 사람이 기준이 되는 게 더 합리적이지 않을까?”라는 생각을 가지고 있었는데요.

실제로 소수의 유저의 피드백만을 바탕으로 고민하는 기업도 있다는 점을 팀원으로부터 알 게 되고,

이후 직접 소수 유저에게서 피드백을 수집하고 프로덕트에 적용해 개선하는 과 정을 거치며, 생각이 바뀌었던 것 같습니다.

프론트엔드 개발자로써 혼자 개발을 진행하며, 디자인 시스템을 구축해보고, 프론트엔 드 서버를 배포하고

DNS를 설정하여 Domain과 연결하는 작업, Next js, reactquery, Typescript 등 평소 얕게 알고 있었던 프레임워크/라이브러리,

언어에 대해 더 깊게 공부할 수 있었던 시간이었습니다.

변찬중

사실 CODI를 시작할 때, 스스로 생각한 목표가 하나 있었습니다.

개발을 진행하 는 모든 과정에 제 스스로의 생각을 많이 반영해보는 것이었는데요.

구현을 한다거나 구 조를 만들어 보았을 때 스스로 한 판단을 믿고 진행하는 과정이 즐거웠습니다.

물론 이 과정을 거치면서 제가 생각한 것보다 더 나은 구조나 구현 방법을 찾아보는 재미도 있었 습니다.

왜 안쓰는지 알게된 것들도 많구요…

윤지숙

저에게는 CODI가 첫 팀프로젝트였는데요, 처음으로 개발자, 기획자분들과 함 께 일하며 협업하는 방식에 대해 배울 수 있었어요.

또 장애인 유저를 대상으로 하는 만 큼 웹 접근성에서 고려해야 할 부분들이 정말 많았는데,

장애 유형에 따른 사용자 경험을 생각해서 디자인으로 구현해내는 과정이 어려우면서도 재미있었던 것 같습니다.

초반에 진행했던 부분들이 지금와서 보면 많이 미흡하고, 또 사용자 테스트를 해보면 부족한 부 분들이 많아서 계속 수정해나가고 있는데

이런 부분들도 개인적인 성장에 많은 도움이 되고 있어요.

장보민

그동안은 서비스 이용을 플로우적으로 보았을 때 논리적인가를 위주로 봤었다 면, codi를 만들면서 웹접근성이 높은 서비스에 대한 관심이 높아졌어요.

서비스 내에서 사용자가 원하는 목표를 이룰 수 있도록 다양한 피쳐들을 넣어왔다면,

codi를 만들면서 는 핵심 기능들을 쉽게 직관적으로 잘 사용할 수 있는가에 더 초점을 두었어요.

하지만 배포 후 유저들의 피드백을 통해서 개발 과정에서는 합리적이라고 생각하고 내렸던 의 사결정들이 미흡했다는 걸 조금씩 느끼고 있고,

이런 사용자의 피드백들이 팀 전체의 성 장에 큰 깨달음을 주고 있는 것 같아요.

👎 아쉽거나 어려웠던 점은 무엇이었나요?

오현재

어려웠던 점은 유저의 사용성에 대해 고려하는 점이었습니다.

장애를 가진 특수 한 환경을 가진 유저를 고려해야 했던 서비스인 만큼, 서비스를 어떤 방식으로 사용할 지 에 대한 경우의 수가 다른 서비스에 비해 많았습니다.

그러한 특수성을 고려해 기능과 UI/UX를 기획하는 과정은 도전적이고 즐거웠지만, 동시에 고통의 순간이기도 했습니 다.

😭 아쉬웠던 점은 더 빨리 릴리즈해서 유저의 피드백을 받아보지 못했다는 것입니다.

릴리즈가 늦어진 큰 이유는 QA 및 개선의 범위를 적절하게 설정하지 못한 점, 완성된 프로덕 트의 기준을 명확하게 하지 못한 점이 아니었나 싶습니다.

작업에는 스프린트 방식을 채 택했지만, 실질적으론 애자일보다는 워터폴 방법론을 따랐던 것 같습니다.

긴 시간의 QA 과정이 힘들었지만, 모두 열정적으로 임해준 팀원들에게 감사의 인사를 전하고 싶습 니다.

변찬중

한정된 시간으로 인해 기획을 더 탄탄하게 하지 못한 것이 아쉬웠습니다.

기획 단계에서 논의되었어야 하는 부분을 개발할 때 알게 되어 임시방편으로 넘어간 적이 꽤 많았거든요.

공모전이 끝난 이후 회의를 통해 조금씩 해결하고 있습니다.

또 한가지는 테 스트 코드를 작성하지 못한 것입니다.

테스트를 진행하며 많은 구멍들이 발생하다보니 초반에 시간이 없었어도 테스트 코드를 작성해보는 것이 필요하지 않았나 하는 생각이 듭니다.

늦었지만 이제부터라도 테스트 코드를 작성하는 습관을 들여보겠습니다.

윤지숙

각각 다른 장애 유형에 따라 웹 접근성을 모두 고려해야 한다는 점도 어렵긴 했 지만,

가장 어려웠던건 아무래도 유저 테스트를 할 사용자를 모집하는 일이었던 것 같아 요.

장애 유형에 따라 사용자를 모집해서 테스트를 해보고 싶었는데 인터뷰이를 구하거 나 직접 만나뵙기가 쉽지 않았습니다.

기획자이신 보민님은 오픈 채팅방에 들어갔다 쫒 겨나기도 하시고,

저는 사용성 테스트를 위해 서울에서 울산까지 다녀오기도 했어요 그 래도 많은분들이 서비스에 대한 설명을 듣고 응원해주시고,

관심을 보여주셔서 정말 감 사하게 생각하고 있습니다.

장보민

비장애인 유저들은 커뮤니티에서 쉽게 만날 수 있었는데, 장애인 유저들을 찾아 서 목소리를 듣기가 쉽지 않았어요.

장애인 유저들 사이에서 온라인멘토링 서비스에 대 한 인식도 높지 않았고, 오픈채팅방과 같은 커뮤니티는 폐쇄성이 높다보니 접근조차 쉽 지 않았죠.

많이 쫓겨나기도 했고, 좋지 못한 소리를 들은 날들도 있었어요.

이런 과정이 있었다보니, 다양한 유저의 목소리를 최대한 많이 모아서 서비스 기획과 운영에 있어

인사이트를 얻고 싶었는데, 이 부분이 가장 어려웠고 현재도 codi의 가장 큰 숙제가 아닐 까 싶어요.

💯 앞으로의 계획을 알려주세요

오현재

우선 다양한 업데이트를 계획하고 진행하고 있습니다! 앞서 말씀 드린 것처럼, 커뮤니티 홍보, 채널톡, Google Analytics를 통해 피드백을 수집하고 있습니다.

피드 백을 바탕으로 구체적인 개선 사항도 정리하여 작업을 진행 중입니다.

예를 들어, 현재는 접근성 기능을 조금 더 다양한 환경에 처해있을 유저를 고려하는 방향으로 개선하는 중 입니다.

점점 다양한 기능이 추가되는 CODI를 앞으로도 관심있게 지켜봐주시면 더할나 위 없이 감사하겠습니다!😃

변찬중

지금까지 문제로 정의한 내용이 굉장히 많은데, 그 부분들을 개선하는 작업들을 빨리 진행하고 싶습니다.

1차 배포를 하게 되면서 미뤄놓은 작업들이 꽤 많았거든요.

동 시에 2차 배포도 앞두고 있어서 1차 배포때 얻은 유저 피드백을 서비스에 반영하기 위해 노력해보겠습니다.

장보민

현재는 서비스를 1차로 배포 후에 인입된 장애인 사용자들과 웹접근성 서비스에 관심도가 높은 프로덕트 메이커들의 피드백을 받고 있어요.

모은 피드백들을 바탕으로 서비스 고도화 작업을 진행중이고요.

고도화 작업이 완료되면 2차 배포를 통해 더 많은 유저를 서비스로 인입시키는 것을 목표로 하고 있습니다.

더불어 서비스에 인입된 사용 자들이 멘토링 외에 사이트 내에서 얻을 수 있는 경험과 인사이트가 무엇이 있을지,

그리고 서비스 운영과 유지 측면에서 비즈니스 모델을 어떻게 확립할지 등에 대해 고민하는 시간을 보내고 있습니다.

🧑‍💻 팀 구성원분들과 찍은 사진이나 추억할 것들이나 기타 공유하고싶으신 내용 말씀해주세요

공모전에서 수상한 사진을 공유하고 싶습니다.😀😀