우테코: Level5 & 우아한테크코스 수료 회고

지난 11월 29일 금요일, 나는 10개월의 길고도 짧은 우아한테크코스라는 교육을 수료하게 되었다. 수료식을 마치고 한달이 지나서야 회고를 작성하지만, 늦던 빠르던 속도에 집중하지 않고 작성했다는 것에 의의를 두기로 했다.

아쉬웠던 Level5 한달

level5는 자유의 시간이었다. 필수적으로 캠퍼스에 등교해야 하는 3-4일 정도를 제외하고는 10시부터 18시까지의 시간과 장소를 자유롭게 선택할 수 있었다. 이는 이번 6기에서 처음 도입된 방식이었다.

개인적으로 level5의 이런 방식은 장단점이 확실했다고 본다. 캠퍼스와의 거리가 멀었던 나에게는 등하교 시간 3시간을 아낄 수 있다는 장점이 존재했다. 이는 9개월간 부족했던 수면시간을 보충하고 본래의 컨디션을 되찾는 것에 굉장히 많은 도움이 되었다. 그러나 이것은 단점도 존재했다. 아무래도 너무 자유성이 보장되다 보니 캠퍼스에 있을 때와는 달리 시간을 효율적으로 사용하는 것이 많이 줄어들었다. 물론 하루를 의미없이 보내지 않기 위해서 ‘난 꾸준해’ 스터디를 운영하였다. 준과 왼손에게 스터디 운영 방식에 대한 의견을 듣고 스터디원과 공유하고 논의를 통해 안정적인 스터디 운영 방식이 자리잡혔다. 덕분에 나를 포함한 총 8명의 스터디원들이 조금은 시간을 허투로 사용하지만은 않았을 것이라고 생각한다.

그렇지만, 캠퍼스에 등하교를 했을 때 보다는 공부 시간이 많이 줄어들었다고 나는 느꼈다. 오전에 최소 한 시간은 의미있는 시간을 보내긴 했지만, 오후를 제대로 보내지 못한 하루도 많았다. 이런 하루가 존재했던 이유는 level4에 들어서며 몸과 마음이 많이 지쳐, 이를 회복하기 위한 시간을 가졌기 때문도 있다.

회복의 시간

11월은 내 짧고도 긴 인생에서 가장 힘들었던 순간 Top2에 들어갈 한달이었다. 내 자신에 대한 실망과 무기력함, 모든 일들에 대한 의욕 저하, 나의 능력에 대한 의구심과 자책 등.. 부정적인 감정이란 감정들을 정말 많이 느끼며 힘들어 했던 것 같다.
지금와서 왜 그런 감정이 들었을까 생각을 해보자면.. 취업을 위해 이력서를 작성하면서 그간 해왔던 것들에 대해 난 뭘 했던 걸까? 하는 자괴감이 들어서도 있고.. 열심히 했었던 일임에도 결국은 사라지고 남는게 없어져 버렸다는 상실의 감정도 있고. 무의식적으로 계속해서 남들과 비교를 통해 자신감을 많이 잃어버렸기 때문도 있는 것 같다.

Level4가 끝나갈 즈음 현재 나의 감정 상태를 어느정도 파악했고, level5에 개인 시간을 많이 가지며 이런 감정들이 빵!하고 터졌다. 그래서 이런 감정을 회복하고자 하루 하루를 천천히. 잔잔하게 보내고자 노력했다. 나는 나 자신이 자가 회복력이 좀 있다고 평가하고, 믿기 때문에..! 그리고 주변에서 이런 나의 상태를 알고 계속해서 용기를 주었기 때문에 9개월간 쌓았던 것들을 한달이라는 시간동안 꽤 많이 회복할 수 있었다.

회복을 위해 어떤 하루는 의미없이 누워서 시간을 보내기도 했고, 어떤 하루는 나가서 새하얀 눈을 밟으며 힐링하기도 했다. 또, 어떤 하루는 책을 읽으며 많은 위안과 도움을 받았다. 그렇게 하루 하루를 천천히 보내며 나의 페이스를 점차 찾으며 보냈다. 그렇게 11월을 보낸 것 같다.

이렇게 11월을 보낸 것에 대해서 많이 아쉬움이 남고 아깝다는 생각도 들었다. 누군가는 내가 이렇게 시간을 보내는 동안 열심히 하며 한발짝 더 나아가고 있을 텐데.. 라는 생각이 들었다. 그러나, 지금의 이런 회복 기간을 갖지 않고 또 뛰려고 한다면 금세 넘어질 것이라는 확신이 들었다. 그래서 11월에는 캠퍼스에 거의 등교하지도 않았고, 사람들도 잘 만나려고 하지 않았던 것 같다. 같은 업계의 사람들을 만나고 개발 이야기를 하는 것 자체가 당시의 나에게는 정신적으로 힘든 일이었기 때문이다. (사실 지금도 조금은 남아있긴 하지만, 정말 많이 극복한 상태이다.)

level5때 캠퍼스를 거의 나가지 않아, 크루들과의 마지막을 즐겁게 보내지 못한 것 같아 굉장히 아쉽다. 그 전까지는 아쉬움이 남지 않았는데, 수료식을 진행하고 구왼조 사람들과 뒷풀이를 마치고 집 오는 길에 너무나도 아쉬운 감정이 많이 들더라.. 하지만 지나간 시간을 어찌하겠는가.. 내가 선택한 일이니 감수해야지 뭐.

그렇게 level5인 11월을 회복 기간으로 잡으며 천천히 재활을 해 나갔다. 그 덕분에 12월에는 조금씩 조금씩.. 해야 할 일들을 11월보다는 진행할 수 있었다.

수료식

수료식은 사실 크게 진행된 일은 없었다.
오랜만에 사람들을 만나 이야기하고.. 놀고.. 점심 먹고, 회고하고.. 수료증 받고 사진찍고 사진찍고 단체사진 찍고 또 사진 찍고의 반복이었다. 그래서 사실 수료식을 진행하면서는 우테코가 끝났다는 실감은 나지 않았다. 그냥 평소처럼 캠퍼스 나온 느낌?

수료증 내가_준비한_꽃

아, 그리고 수료식이 난 졸업식 같다고 생각이 들어서, 그래도 졸업식 같은 건데 다들 꽃 하나 정도는 받으면 기분 좋지 않을까~? 싶어서 구왼조 사람들과 행동대장 프론트엔드 팀원들에게 비누꽃 한송이를 나눠줬다. (백엔드도 같이 수료식하는 줄 모르고.. 행동대장 프론트엔드만 꽃 챙겨줬는데.. 미안합니다 백엔드 팀원들…🥲) 꽃 주는데 웨디가 울어줘서 기분 좋았다(?) ㅎ.. 약간 뭐라 해야 할까.. 내가 준비한 것으로 인해 감동받아서 훌찌럭 해줘서 뿌듯했달까. (웨디 미안.)

구왼조_단체_사진 구왼조_수료축하_케이크

수료식 끝나고 구왼조와 월하 집에서 수료 파티를 했다. level2 종료하고 이번에 2번째로 오는데 기분이 참 묘~ 했다. 여길 이제 끝나고 오다니.. 라는 감정도 들고.. 그럼에도 그때랑 똑같이 철없이 노는게 행복하기도 했다.

우테코를 수료했다는 실감은 혼자 집가는 버스에서 많이 들었던 것 같다. 노래 들으면서 창 밖을 보며 집을 가는데, 더이상 이 사람들과 다같이 모여서 보기 힘들겠구나..라는 생각도 들고. 이렇게 학생처럼 지내는 날도 이게 마지막이겠지 싶은 생각도 들었다. 그래서 조금 쿨찌럭 하면서ㅋㅎ 집에 갔다.

우테코를 수료하며

2024년 한 해를 표현하자면 우아한테크코스이다. 그만큼, 우테코는 내 그간의 삶에서 짧지만 가장 행복하고 즐겁고 힘들고 아프고 기뻤던. 긍정과 부정의 양가 감정을 모두 극단적으로 느끼게 해주었으며, 개발적인 성장 뿐만 아니라 내면적인 성장을 정말 많이 하게 해준 교육이다. 대학교 5년의 시간보다 우테코 10개월동안의 성장이 더 많았던 것 같다.

우테코가 10개월이라는 타 교육보다는 길지만, 교육을 하기에는 짧은 시간이었다고 생각한다. 그렇기에 너무나도 빠른 10개월을 보냈기에 내 페이스를 유지할 수 없어서 굉장히 많이 지쳤었던 것 같다. 그렇지만 중간 중간에 너무나도 좋은 사람들을 한번에 많이 만나서 이 힘들었던 시간을 버티며 마칠 수 있었다.

우테코가 무엇을 위한 것이었는지 이제야 조금 알겠다. (feat. 몰입, 도둑맞은 집중력)

요즘 ‘도둑맞은 집중력’이라는 책을 읽고 있다. 이 책을 읽으며 그간의 삶. 그리고 24년을 너무나도 빠르게 흘러 보냈다는 생각이 든다. 그래서 요즘 다시 독서를 진행하면서 나의 망가진 집중력을 많이 느낀다. 예전에는 안 이랬던 것 같은데, 책을 읽으며 집중력이 다른 곳으로 새는 것을 정말 많이 느낀다. 이런 이유가 지속적으로 집중력을 방해받는 생활과 빠르게 해야 한다는 것에 집착했던 감정들 때문이었구나를 책을 읽으며 알게 되었다.

그러면서 우테코의 10개월의 의미를 다시 되돌아 보게 되었다. 이 10개월이 이전에는 짧은 시간 안에 여러 지식들을 욱여넣어야 하는 시간이라고 생각했다. 그렇지만 지금와서 되돌아보니 그런게 아니었던 것 같다. 10개월동안 다른 것에 방해받지 않으면서 개발에 몰입해보고 집중해보는 시간을 갖기 위한 수련의 시간이었다. 그런데 나는 그걸 이제야 깨달았고 지난 10개월을 그저 빠르게 지식을 욱여넣고 개발을 쳐내기 위한 시간으로만 사용했다. 그래서 위에서 한탄했던.. 수료 할 즈음.. 지쳐버렸던 것이다.

2025년은!

그래서 2025년은 빠르게, 급하게 생각하지 않고! 내가 몰입하고자 하는 것, 단 하나만 집중하고 몰입하며 보내 보고자 한다. 그렇게 보내다보면 내가 몰입할 수 있으면서 수익도 발생하는 환경을 찾을 수 있지 않을까?

그간 급하게만 살아왔던 삶. 앞으로 조금 천천히 몰입하며 집중력을 찾아보자. 그리고 이 시간동안 그때는 하지 못했던 우테코에서 배웠던 학습과 몰입의 방법들을 적용해보고자 한다.

안녕, 우테코

작년 프리코스 기간부터 올해 2월부터 11월, 그리고 수료를 마친 지금 12월까지 나에게 여전히 영향력을 미치고 있는 우테코.
우테코를 다니는 10개월이 나 자신에 대한 벽에 처음 부딪히고 이 벽을 부수며 나아가는 것이 힘든 과정이었다. 그리고 수료한 앞으로도 벽을 부수는 건 힘든 과정이겠지만. 우테코를 다니며 개발만 배운게 아니라, 나 자신을 되돌아보고 알아가는 방법을 배우며 내면을 단단하게 만드는 방법을 터득할 수 있게 해주었기에. 넘어지고 부딪히더라도 주저앉아 포기하지 않도록 성장시켜준 이 우테코를 기회가 된다면 꼭 다른 사람도 경험했으면 좋겠다.

이제는 진짜 보내줄 때가 된 것 같다. 안녕, 우테코!

우테코_6기_단체사진

우아한테크코스 6기 크루 및 코치님 단체 사진

웹 접근성: 스크린 리더

해당 글은 우아한테크코스에서 진행한 테크니컬 라이팅을 위해 작성한 글입니다. 본문의 글에 추가적인 내용들을 추가하여 업로드 합니다.


💡 읽기 전! 이런 분들에게 추천해요.

  • 웹 접근성에 대해 들어본 적이 있으나 잘 모르시는 분
  • 스크린리더에 대해 들어본 적이 있으나 잘 모르시는 분
  • WAI-ARIA에 대해 기초적인 지식이 필요하신 분

본격적으로 글을 시작하기에 앞서 내가 왜 스크린 리더를 주제로 글을 작성하게 되었는지 설명하고 한다.

스크린 리더를 주제로 글을 작성하게 된 이유

우테코에서 테크니컬 라이팅 작성을 위해 주제를 오래 고민하고 있었다. 그러던 중 한 영상을 보게 되었다.

직접 시각 장애인분이 어떻게 스마트폰을 사용하는지 iOS의 voice over를 사용하시는 모습이 담긴 영상이었다. 이 영상을 보면서 나에게는 새로운 시각이 트이게 되었다. 그동안에는 시각 장애를 가졌다면 스마트 기기를 원활하게 사용하지 못할 것이라고 생각하고 있었다. 그러나 오히려 반대였다. 스마트폰에서는 장애를 가졌던 가지지 않았던 모두가 평등했다. 이는 기기가 이런 차별을 없애기 위해 노력해서 만든 결과물이었다.

스마트 기기들은 장애를 차별하지 않기 위해 정말 정교한 부분들을 배려하며 만들어져있었다. 내가 그간 겪은 적이 없기 때문에 몰랐던 것이다. 그런데 기기가 차별하지 않는데 웹 서비스들이 사람을 차별한다면? 결국은 해당 서비스는 사용되지 못할 것이다.

이것은 사용자를 놓친다는 개념보다는 개발자가 서비스를 만들 때, 의도하지 않게 사람을 차별할 수도 있다고 느꼈다. 나도 모르게 시각 장애인들을 차별해왔던 것이다.
그래서 행동대장 서비스를 voice over를 활용하여 사용해봤다. 내가 개발한 목적대로 절대 사용할 수가 없었다. 그래서 나는 내가 만든 서비스라도 모두가 평등할 수 있도록 하고 싶다.

웹 접근성에는 스크린 리더 뿐 만 아니라 정말 다양한 요소를 고려해야 하지만, 차근 차근 일단은 스크린 리더에 관한 것 부터 개선해 보자는 생각이 들었다. 그래서 이번 테크니컬 라이팅의 주제로 웹 접근성 중 스크린 리더를 개선하기 위해 사용되는 WAI-ARIA를 중점으로 내용을 작성했다.


웹 접근성 - 스크린 리더: 모든 사용자를 위한 평등한 디지털 환경

지난 2021년 코로나19의 장기화로 인해 온라인 쇼핑이 트렌드가 되었다. 그러나 시각장애인 A씨는 온라인 쇼핑을 사용할 수 없었다. ‘스크린 리더’ 를 사용하여 온라인 쇼핑을 진행하려 했으나 대체 텍스트가 제대로 입력되어 있지 않았다. 스크린 리더는 그저 ‘이미지’라는 말만 반복했다.

시각장애인 B씨 또한 비슷한 불편함을 겪었다. 국세청 홈택스를 통해 집에서 편하게 납세하고 싶었다. 그러나 ‘스크린 리더’를 사용했을 때, 정확한 명칭이 아닌 엉뚱한 설명이 나왔다. 이로 인해 B씨는 홈택스를 통한 납세가 어려웠다. 이렇게 시각장애인 A와 B씨는 온라인 서비스를 제대로 이용할 수 없었다. 왜 이런 일이 발생한 걸까?

웹 접근성이란

A와 B씨가 서비스를 제대로 이용할 수 없었던 이유는 바로, ‘웹 접근성’ 이 제대로 지켜지지 않았기 때문이다.
‘웹 접근성(Web Accessibility)’ 은 장애를 가진 사람들이 비장애인과 동등한 웹 서비스를 사용할 수 있도록 설계 및 개발된 것이다. 또한 웹 접근성은 「국가정보화기본법」과 「장애인차별금지 및 권리구제 등에 관한 법률(이하 “장애인차별금지법”)」등 법률에 명시된 의무사항이다.

웹 접근성을 지켜야 하는 이유

웹은 하드웨어, 소프트웨어, 언어, 장소, 능력에 제약없이 모든 사람들이 사용할 수 있도록 설계되었다. 웹이 위와 같은 목표를 달성했을 때, 다양한 청력, 움직임, 시력, 인지 능력을 가진 사람들이 웹에 접근할 수 있게 된다.

이처럼 웹은 물리적 세상에서의 한계를 없애주는 역할을 한다. 웹에서는 시간과 물리적 한계가 존재하지 않는다. 또한, 장애인, 비장애인, 성별, 연령 간의 차별도 존재하지 않는다. 우리는 웹 세상에서 모두 동등해진다.
만약 웹 사이트, 애플리케이션, 기술, 도구가 공평하지 않고 불충분하게 설계된다면 그것은 보이지 않은 장벽을 만드는 것이다. 그렇기에 개발자는 제품 및 서비스에서 차별을 만들지 않기 위해 웹 접근성을 지켜야 한다.

웹 접근성의 종류

웹 접근성을 지키기 위해 할 수 있는 것들의 종류는 굉장히 많다. 이는 한국웹접근성인증평가원에서 발표한 ‘한국형 웹 컨텐츠 접근성 지침 2.1’에 자세히 설명되어있다.
한국형 웹 컨텐츠 접근성 지침 2.1은 W3C(World Wide Web Consortium)가 장애인 등이 웹 사이트에 접근하는 것을 보장하기 위해 만든 ‘웹 컨텐츠 접근성 지침 2.0(WCAG 2.0)’을 참고했다. 해당 지침은 WCAG 2.0의 12개 지침과 성공 기준의 중요도 A 항목을 중심으로 국내에 맞게 고려되어 개발되었다.

아래 표는 한국형 웹 컨텐츠 접근성 지침 2.1에서 말하는 웹 접근성 지침이다.

웹 접근성 지침

구분 항목 세부항목 관련 WCAG 2.0 기준
1. 인식의 용이성 1.1. 대체 텍스트 제공 1.1.1 적절한 대체 텍스트 제공 1.1.1 Non-text Content
  1.2. 멀티미디어 대체 수단 제공 1.2.1 자막 제공 1.2.1 Audio-only and Video-only (Prerecorded), 1.2.2 Captions (Prerecorded), 1.2.3 Audio Description or Media Alternative
  1.3. 명료성 1.3.1 색에 무관한 컨텐츠 인식 1.3.1 Info and Relationships, 1.4.1 Use of Color
    1.3.2 명확한 지시 사항 제공 1.3.3 Sensory Characteristics
    1.3.3 텍스트 컨텐츠의 명도 대비 1.4.3 Contrast (중요도 AA 항목)
    1.3.4 자동 재생 금지 1.4.2 Audio Control
    1.3.5 컨텐츠 간의 구분 1.4.8 Visual Presentation (중요도 AAA 항목)
2. 운용의 용이성 2.1. 입력장치 접근성 2.1.1 키보드 사용 보장 2.1.1 Keyboard
    2.1.2 초점 이동 2.1.2 No Keyboard Trap, 2.4.2 Focus Order
    2.1.3 조작 가능 추가 -
  2.2. 충분한 시간 제공 2.2.1 응답시간 조절 2.2.1 Timing Adjustable
    2.2.2 정지 기능 제공 2.2.2 Pause, Stop, Hide
  2.3 깜빡임 및 번쩍임 사용 제한 2.3.1 깜빡임과 번쩍임 사용 제한 2.3.1 Three Flashes or Below
  2.4 쉬운 내비게이션 2.4.1 반복 영역 건너뛰기 2.4.1 Bypass Blocks
    2.4.2 제목 제공 2.4.2 Page Titled
    2.4.3 적절한 링크 텍스트 2.4.4 Link Purpose
3. 이해의 용이성 3.1 가독성 3.1.1 기본 언어 표시 3.1.1 Language of Page
  3.2 예측 가능성 3.2.1 사용자 요구에 따른 실행 3.2.1 On Focus, 3.2.2 On Input
  3.3 컨텐츠의 논리성 3.3.1 컨텐츠의 선형 구조 1.3.2 Meaningful Sequence
    3.3.2 표의 구성 1.3.1 Info and Relationships
  3.4 입력의 도움 3.4.1 레이블 제공 3.3.2 Labels or Instructions
    3.4.2 오류 정정 3.3.1 Error Identification
4. 견고성 4.1 문법 준수 4.1.1 마크업 오류 방지 4.1.1 Parsing
  4.2 웹 애플리케이션 접근성 4.2.1 웹 애플리케이션 접근성 준수 4.1.2 Name, Role, Value

위 표에서의 웹 접근성은 크게 인식의 용이성, 운용의 용이성, 이해의 용이성, 견고성 4가지로 나눌 수 있다. 다만, 해당 글에서는 모두 다루기는 양이 방대하다. 그래서 스크린 리더와 밀접한 관계가 있는 항목만을 다루려고 한다.

스크린 리더

스크린 리더(Screen Reader) 는 디스플레이 화면에 표시된 내용과 사용자가 입력한 키보드 정보, 마우스 좌표 등을 비시각적인 방식으로 전달해주는 소프트웨어 애플리케이션이다. 이때, 비시각적인 방식으로는 텍스트 음성 변환, 점자 또는 사운드 아이콘 등이 있다. 따라서 스크린 리더는 시각 장애, 문맹, 학습 장애가 있는 사람들에게 필수적이다.

스크린 리더는 비시각적인 방식으로 정보를 전달하여, 시각 장애인이나 다른 접근성 요구가 있는 사용자들이 웹 콘텐츠를 원활하게 이용할 수 있도록 돕는다. 이러한 접근성을 더욱 향상시키기 위해 WAI-ARIA 가 도입되었다.

WAI-ARIA?

먼저 WAI-ARIA에 대해 살펴 보기 전에 RIA에 대해 알아보자.
웹의 빠른 발전으로 인해, 웹은 더이상 문서의 개념이 아닌 애플리케이션처럼 사용되면서 사용자 경험(User eXperience, UX)을 중시하게 되었다. 이런 요구를 해결하기 위해 등장한 것이 리치 인터넷 애플리케이션(Rich Internet Applications)이다. RIA는 정적인 HTML과 단순한 자바스크립트를 넘어 보다 동적인 자바스크립트와 Ajax(Asyncronous Javascript and XML) 등의 기술을 활용한다. 이로 인해 향상된 UX를 사용자에게 제공할 수 있다.

그러나, 모든 사용자가 동등하게 접근할 수 없다는 문제가 존재했다. 스크린 리더 등의 보조기술을 사용하는 사용자는 RIA 기술를 활용한 웹 애플리케이션을 제대로 사용할 수 없었다. 이로 인해 등장한 것이 바로 WAI-ARIA(Web Accessibility Initiative - Web Accessible Rich Internet Applications) 이다. WAI-ARIA는 W3C에서 웹 컨텐츠 및 웹 애플리케이션의 접근성과 상호 운용성을 개선하기 위해 발표한 기술 명세이다. 역할(Role), 속성(Property), 상태(State) 정보를 추가하여 스크린 리더 및 보조기기 등에서 접근성 및 상호 운용성을 향상시킨다.

WAI-ARIA의 3가지 기능

  • 역할(Role)

    유저 인터페이스(User Interface, UI)에 포함된 특정 컴포넌트의 역할을 정의한다.
    페이지의 검색 영역인지, 네비게이션 요소인지, 제목 인지 등의 명확한 기능을 부여한다.

  • 속성(Property)

    컴포넌트의 특징이나 상황을 정의한다.
    폼의 입력 필드가 필수 항목인지, 팝업이 뜨는지, 업데이트 된 정보가 있는지 등의 상황을 사용자가 인지할 수 있도록 한다. 속성명으로 aria-\*라는 접두사를 사용한다.

  • 상태(State)

    컴포넌트의 상태 정보를 정의한다.
    메뉴가 펼쳐진 상태인지, 적절한 값이 입력되었는지, 컨텐츠가 숨김 상태인지 등을 나타낸다.

WAI-ARIA 작성 방법

다음은 어떻게 WAI-ARIA를 작성하면 좋을지 알아보자.

랜드마크

랜드마크(Landmark Role)는 웹 페이지의 특정 컨텐츠가 어떤 역할을 하는지 쉽게 식별할 수 있도록 도와주는 역할을 한다. 이는 웹 접근성을 높이기 위한 기능으로, 기존의 건너뛰기 링크(스크린 리더 사용자를 위해 페이지의 특정 부분으로 바로 이동할 수 있는 링크)보다 발전된 형태이다. 랜드마크는 HTML 요소에 role 속성을 사용하여 컨텐츠 역할을 지정하면 사용할 수 있다.

랜드마크를 사용하면 컨텐츠 블록의 제목을 제공하는 것보다 더 명확하게 영역을 구분할 수 있다. 예를 들어, 네비게이션 바, 주 컨텐츠 영역, 푸터 등을 쉽게 구분할 수 있다.

<!-- 컨텐츠 블록의 제목을 제공하는 형태 -->
<section>
	<h2>소개</h2>
	<p>해당 글에 대한 소개입니다.</p>
</section>

<!-- 랜드마크를 사용한 형태 -->
<main role="main">
	<h1>주요 콘텐츠</h1>
	<p>여기에 주요 콘텐츠가 들어갑니다.</p>
</main>

랜드마크 종류

랜드마크는 다음 표와 같이 8가지의 기능을 제공한다.

역할(Role) 설명 HTML5 요소
application 웹 애플리케이션 영역을 선언. 스크린 리더가 웹 브라우저 탐색 키를 애플리케이션에게 돌려줌. N/A
banner 사이트의 로고나 제목 등을 포함하는 헤더 정보 영역. 사이트 아이덴티티 정보를 포함. <header>
navigation 웹 사이트의 내비게이션 영역. 링크 모음을 포함. <nav>
main 메인 콘텐츠 영역. 웹 페이지 내에서 한 번만 선언 가능. <main>
complementary 메인 콘텐츠를 보충하는 부가적인 내용의 영역. 메인 콘텐츠에서 분리되어도 의미가 있음. <aside>
form 사용자가 입력 가능한 폼 영역. 검색 폼은 제외. <form>
search 검색을 위한 입력 폼 영역. N/A
contentinfo 문서의 메타데이터 영역. 저작권 정보, 주소, 연락처, 개인정보 정책 등을 포함. <footer>

HTML5의 섹션 관련 요소와 WAI-ARIA를 같이 사용할 경우 해당 기능이 무효화 되거나 충돌이 발생할 수 있다. 따라서, 중복해서 사용하지 않도록 해야 한다.

HTML요소의 역할 변경 제한

ARIA를 이용하여 요소의 역할을 변경하는 것을 제한한다.
아래 코드를 예시로 들어보자.

<h1 role="“button”">버튼</h1>

위 코드는 h1 요소에 button 역할을 부여했다. h1은 heading의 역할을 가지는데 ARIA를 사용하여 heading의 역할이 아닌 button의 역할을 하도록 강제했다. 이렇게 ARIA를 사용하여 본질적인 역할을 변경하는 것은 좋지 않다. h1 요소에 button 역할을 주고 싶다면 다음과 같이 사용한다.

<!--  h1 하위 요소로 button 사용 -->
<h1><button>버튼</button></h1>

<!-- h1 하위 요소로 span을 사용하여 role="button" 부여 -->
<h1><span role="button" tabindex="“0”">>버튼</span></h1>

위와 같은 방법으로 h1의 본질적인 역할은 해치지 않으면서 button을 사용할 수 있게 되었다.

키보드 사용 보장

탭, 드래그 앤 드롭, 슬라이드, 스크롤 등과 같이 사용자와 상호작용이 필요한 대화형 UI의 경우 키보드로도 접근과 사용이 가능해야 한다. 키보드 포커스를 받지 못하는 요소의 경우 tabindex 속성을 사용하여 키보드 포커스를 받을 수 있도록 한다.

이때 tabindex 속성에 0을 지정하면 화면에 표시된 순서대로 키보드 포커스가 된다. 만약, 0보다 작은 값을 지정할 경우 키보드 포커스를 받을 수 없게 된다.

<!--  키보드 포커스 X -->
<span role="“button”" tabindex="“-1”">버튼</span>

<!--  키보드 포커스 O -->
<span role="“button”" tabindex="“0”">버튼</span>

그렇다면, tabindex에 0보다 큰 양수의 값이 들어오면 어떻게 동작할까?
해당 요소는 지정한 순서대로 키보드 포커스를 받게 된다. 즉, tabindex 값이 낮을수록 먼저 포커스를 받게 된다. 이 방법을 통해 특정 요소들이 키보드 포커스를 받을 순서를 지정할 수 있다. 아래 0보다 큰 양수 값이 들어 왔을 경우에 대한 예시 코드를 살펴보자.

<!-- tabindex 순서를 지정 -->
<div tabindex="3">세 번째로 포커스</div>
<div tabindex="0">화면 표시 순서(네 번째)대로 포커스</div>
<div tabindex="1">첫 번째로 포커스</div>
<div tabindex="2">두 번째로 포커스</div>
<div tabindex="0">화면 표시 순서(다섯 번째)대로 포커스</div>

tabindex="1"을 가진 요소가 가장 먼저 포커스를 받고, tabindex="2"를 가진 요소가 그 다음, 그리고 tabindex="3"을 가진 요소가 그 다음으로 포커스를 받는다. 이러한 방식은 화면에 표시된 순서와는 무관하게 포커스 순서를 지정할 수 있다.

다만, 이런 방식은 너무 많은 요소에 tabindex를 설정하거나 높은 값을 사용하면 관리가 어려워질 수 있으므로 주의해서 사용해야 한다.

숨김 요소

스크린 리더 사용자를 위한 정보를 제공하지만, 단순히 화면에 보이지 않게만 하려는 경우에는 aria-hidden="true"를 사용하면 안된다. aria-hidden="true"로 지정된 요소는 스크린 리더에서 완전히 무시되기 때문에 스크린 리더는 이 요소가 아예 없다고 생각하게 된다.

<!-- 잘못된 aria-hidden 사용 예시: 중요한 버튼이 스크린 리더에서 무시됨 -->
<button aria-hidden="true">제출하기</button>

만약, aria-hidden=“true"를 사용하여 숨김 요소에 대해 접근을 차단하고 싶다면, CSS를 활용한다. CSS의 display 속성에 none 값을 지정하여 스크린 리더에서 접근할 수 없도록 하고 aria-hidden="true"를 명시한다.

<style>
	button {
		display: none;
	}
</style>

<button aria-hidden="“true”">버튼</button>

중요한 정보를 전달하거나 버튼, 링크 같은 역할을 하는 요소에 role="presentation" 속성을 부여해서는 안 된다. 이 속성은 스크린 리더에게 해당 요소가 단순히 화면에 보이기 위한 것일 뿐이라고 인식하게 해서, 역할이 제대로 전달되지 않는다.

<!-- 잘못된 role="presentation" 사용 예시: 스크린 리더가 버튼 역할을 인식하지 못함 -->
<button role="presentation">다음 페이지로 이동</button>

레이블 제공

모든 대화형 UI 요소에는 반드시 레이블을 제공해야 한다. 레이블은 사용자가 해당 요소의 용도를 이해하는 데 도움을 준다. HTML의 <label> 요소를 사용하여 레이블을 제공하는 것이 가장 좋지만, aria-label이나 aria-labelledby와 같은 WAI-ARIA 속성을 사용해서도 레이블을 제공할 수 있다.

<!-- HTML <label> 요소를 사용한 예시 -->
<div class="container">
	<label for="user-name">이름</label>
	<input type="text" id="user-name" />
</div>

<!-- aria-label 속성을 사용한 예시 -->
<button aria-label="닫기" onclick="myDialog.close()">X</button>

<!-- aria-labelledby 속성을 사용한 예시 -->
<div>
	<div id="name-label">이름</div>
	<input type="text" aria-labelledby="name-label" />
</div>

그렇다면, HTML의 <label>aria-label, aria-labelledby는 무슨 차이점이 있을까?
<label> 요소는 주로 입력 필드(input)와 함께 사용되며, 화면에 텍스트로 레이블이 표시되어 시각적으로 명확하게 한다.
aria-label 속성은 화면에 텍스트 레이블을 표시할 필요가 없는 경우에 유용하며, 보조 기술을 위해 텍스트 레이블을 제공한다.
aria-labelledby 속성은 다른 요소의 텍스트를 사용하여 레이블을 제공하며, 복잡한 레이블을 만들 때 유용하다.

Live Region

Live Region은 웹 문서나 위젯, 웹 애플리케이션의 일부가 동적으로 변경될 때, 사용자가 조작하지 않아도 변경된 내용과 진행 상태를 알릴 수 있도록 도와주는 속성이다. 이 속성은 모든 HTML 요소에 적용할 수 있다.

  • aria-live

    aria-live은 Live Region의 업데이트 내용을 사용자에게 알리는 방법을 설정한다. 기본값은 “off”이며, “polite”로 설정하면 사용자의 입력이 끝난 후 업데이트 내용을 알리고, “assertive”로 설정하면 즉시 알린다.

    <div aria-live="polite">사용자 입력 후 이 내용이 업데이트됩니다.</div>
    
  • aria-atomic

    aria-atomic은 Live Region의 내용이 업데이트될 때, 업데이트된 부분만 알릴 것인지 전체 내용을 알릴 것인지 설정한다. 기본값은 “false”이며, “true”로 설정하면 업데이트된 내용만 전달한다.

    <div aria-live="polite" aria-atomic="true">이 내용이 업데이트되면 전체를 알리지 않고 변경된 부분만 알립니다.</div>
    
  • aria-busy

    aria-busy은 Live Region이 업데이트 중인지 여부를 나타낸다. 기본값은 “false”이며, “true”로 설정하면 업데이트 중임을 알리고 이후 내용은 안내하지 않는다.

    <div aria-busy="true">업데이트 중입니다. 잠시만 기다려 주십시오.</div>
    
  • aria-relevant

    aria-relevant은 Live Region의 업데이트 시 어떤 종류의 변화에 대해 알릴지 설정한다. 기본값은 “additions text”이며, “additions”, “removals”, “text” 및 “all” 값으로 설정할 수 있다.

    <div aria-live="polite" aria-relevant="all">모든 변화가 이곳에 알림됩니다.</div>
    

마무리 말

웹 접근성은 단순히 법적 의무를 넘어, 모든 사람이 정보와 서비스를 동등하게 누릴 수 있도록 하는 기본적인 인권의 문제이다. 장애인뿐만 아니라 비장애인도 다양한 상황에서 웹 접근성의 혜택을 받을 수 있다. 웹의 창시자 팀 버너스리가 말한 것처럼, 웹의 힘은 보편성에 있다. 모든 사람이 장애에 상관없이 웹에 접근할 수 있는 환경을 만드는 것이야말로 우리 개발자가 추구해야 할 목표이다.

웹 접근성을 고려한 웹사이트는 더 많은 사용자에게 다가갈 수 있고, 이는 결국 더 나은 사용자 경험을 제공한다. 개발자는 이러한 접근성을 통해 정보의 격차를 줄이고, 모두가 평등하게 웹을 사용할 수 있는 환경을 만들어야 한다. 이를 통해 더 포용적이고 공정한 디지털 세상을 만들어 나가는 것이 우리의 책임이다.

참고자료

카카오톡 수정한 OGTag 미반영 문제 해결 방법

오랜만에 블로그를 조금 손 보기로 했다.
검정색이던 블로그 색상을 파랑으로 바꾸고, favicon이랑 OGTag도 수정해줬다.
수정하는 것은 매우 수월했다. 그리 어려운 작업도 아니었으니까. 그러나, 문제는 수정한 내용을 확인하는 과정에서 발생했다.

글을 읽기 전 OG가 뭔지 모르겠다면? 간단하게 여기를 읽고 오자.

문제

블로그 색상과 favicon은 정상적으로 반영되었고 OGTag 또한 잘 반영됐다. 근데, 카카오톡에 해당 url을 공유하면 수정 전의 OG로 나타나는 것이다! 다른 곳에서는 모두 정상적으로 새롭게 반영한 OG로 나타났지만 오직 카카오톡에서만 이전 값으로 나타났다.

원인

그래서 나는 카카오톡에 원인이 있다고 판단했다. 아마도 캐시가 남아서 그런거지 않을까?하고 PC 카톡과 모바일 카톡의 캐시를 지워보고자 했다. 지운것 같은데도 여전히 이전 OG로 나타났다!ㅜㅜ

카카오톡_og태그_문제2

여러 서칭을 통해 카카오톡(카카오스토리)의 캐시는 kakao developer 페이지에 접속해서 지울 수 있다는 것을 알게 되었다. 서버 효율을 높이기 위해서 일정기간 OG를 캐싱하여 OGTag를 수정해도 이전 데이터 값으로 나왔던 것이었다.

카카오 Dev Talk 캐싱 삭제 방법 설명

🔗 이미지 내용 원본 링크

해결

해당 링크에 접속하여 URL란에 캐시 초기화를 하고 싶은 url을 입력하면 끝이다!

카카오톡_og태그_문제해결2

단, 해당 서비스를 이용하려면 카카오 로그인이 필수이다.

결과

https://soi-ha.github.io/ url과 그 하위 url까지 모두 정상적으로 변경한 OG가 잘 반영된 것을 확인할 수 있다!

카카오톡_og태그_문제해결 카카오톡_og태그_문제해결2

틈새 학습: OG (Open Graph)란?

Open Graph란, SNS로 웹 페이지를 공유할 때 해당 페이지를 미리 볼 수 있도록 해주는 것이다.
Open Graph 설정을 통해 페이지의 이미지, 내용, 제목이 미리보기 형식으로 확인할 수 있다.

OG 왜 사용함?

Open Graph 사용을 통해 사용자의 클릭률을 높일 수 있기 때문이다. 미리보기를 통해 웹 페이지의 내용을 추측하여 사용자가 원하는 글에 접근할 확률을 높여준다. 만약 OG가 없는 상황에서 사용자가 url을 클릭했는데 원했던 내용이 아니라면? 사용자는 더이상 공유된 url을 클릭할 확률이 줄어든다. 그렇기에 OG로 사용자의 클릭률을 높일 수 있다.

또한, 미리보기를 통해 url만 존재할 때 보다 사용자의 눈길을 끌기 쉽다. 미리보기 이미지가 같이 제공되기 때문에 사용자의 눈길을 잡기 수월할 것이다.

참고

행동대장: 각 행사 url로 QR코드 생성하기 (qrcode.react, react-qr-code, qr.js 비교하기)

행동대장 서비스에 QR코드를 도입한 이유

행동대장 서비스는 sns 친구가 아니어도 정산을 할 수 있도록 하는 것이 목적이다. 그러나 기존에는 최초의 목적에 부합하지 않았다. 카톡이 아니더라도 최소 하나의 SNS의 친구가 되어있어야 했다. 따라서, 각 행사의 고유 QR코드를 생성하여 SNS가 없어도 사용할 수 있고 대면에서 바로 행사 페이지에 접속할 수 있도록 했다.

어떻게 QR코드를 생성할까?

QR코드를 만드는 방법은 다양하게 있을 것이다. 직접 구현하거나, 라이브러리를 활용하거나.

  1. 직접 만들기
    가능한 일이지만 시간 제약이 존재하며 리소스가 넘쳐나는 세상에서는 너무 비효율적인 일이라고 생각한다.
    QR코드를 생성하기 위한 알고리즘을 직접 구현하는 것은 매우 복잡하고 수학적인 연산이 필요할 것이다. 따라서, 해당 방법은 바로 목록에서 지워버렸다.

  2. 라이브러리 활용하기
    우리는 시간과 인적 자원을 아끼기 위해 손쉽게 QR코드를 생성해주는 라이브러리를 활용할 것이다.
    다음 이미지는 NPM에 등록된 QR코드를 생성해주는 라이브러리를 다운로드 순으로 정렬한 것이다.

    NPM QR코드 생성 패키지 다운로드 순위로 정렬

    가장 많이 사용된 3가지는 qrcode.react, qr.js, react-qr-code이다. 이 3가지 라이브러리 중 어떤 것을 사용할지 비교를 통해 선택해보자.

qrcode.react, react-qr-code, qr.js 비교하기

qrcode.react

  • 성능

    React 환경에 최적화되어 있어 QR 코드 생성 속도가 빠르고 효율적이다. 이 라이브러리는 React의 렌더링 방식에 맞게 설계되었기 때문에 대규모 애플리케이션에서도 안정적인 성능을 제공한다. 이는 React의 Virtual DOM을 효과적으로 활용하여 불필요한 재렌더링을 최소화하기 때문이다.

  • 커스터마이징

    색상, 크기, 배경색 등 기본적인 커스터마이징이 가능하지만, 로고 삽입이나 복잡한 디자인 커스터마이징은 지원하지 않는다.

  • 사용성

    React 개발자라면 쉽게 사용할 수 있으며, 설치 및 사용법이 직관적이다. 별도의 복잡한 설정 없이도 간단히 QR 코드를 생성할 수 있다.

  • 문서화

    문서화가 잘 되어 있어 이해하기 쉽고, 예제 코드가 풍부하여 다양한 사용 사례를 참고할 수 있다. 지속적인 업데이트로 최신 기능을 반영한다.

  • 안정성

    널리 사용되는 라이브러리로 안정적이며, 다양한 프로젝트에서 검증되었다. 활발한 커뮤니티 지원으로 문제 발생 시 빠른 해결이 가능하다.

  • qrcode.react NPM 문서

react-qr-code

  • 성능

    성능이 뛰어나 React 애플리케이션에서 빠르게 QR 코드를 생성할 수 있다. 특히 동적 데이터와 연동하여 실시간으로 QR 코드를 생성할 때 유리하다. 이는 이 라이브러리가 React의 상태 관리와 연동이 잘 되어 있어, 상태 변화에 따라 QR 코드가 즉시 업데이트되기 때문이다.

  • 커스터마이징

    기본적인 커스터마이징 옵션을 제공하며, 색상, 크기, 스타일 등을 쉽게 변경할 수 있다. 다만, 고급 커스터마이징 옵션은 제한적이다.

  • 사용성

    React 개발 환경에서 쉽게 사용할 수 있도록 설계되어 있으며, 직관적인 사용법을 제공한다. 사용법이 간단해 초보자도 쉽게 사용할 수 있다.

  • 문서화

    잘 정리된 문서화로 쉽게 시작할 수 있으며, 예제 코드와 함께 제공되어 실습하며 배울 수 있다. 지속적인 업데이트를 통해 최신 기능을 지원한다.

  • 유연성

    다양한 QR 코드 생성 요구사항을 충족시킬 수 있는 유연성을 제공하며, 다양한 크기와 스타일의 QR 코드를 생성할 수 있다.

  • react-qr-code NPM 문서

qr.js

  • 성능

    경량 라이브러리로 QR 코드 생성 속도가 매우 빠르다. 성능이 중요한 경우에 적합하며, 서버 사이드 렌더링(SSR)에도 유리하다. 이는 이 라이브러리가 독립적인 JavaScript로 동작하여 Node.js 환경에서도 쉽게 통합될 수 있기 때문이다.

  • 커스터마이징

    기본적인 QR 코드 생성 기능만 제공하며, 고급 커스터마이징 기능은 부족하다. 색상, 크기 등 제한적인 커스터마이징만 가능하다.

  • 사용성

    경량 라이브러리로 간단한 API를 제공하여 사용이 쉽다. 설치 및 사용법이 매우 직관적이며, 작은 프로젝트에 적합하다.

  • 문서화

    간단한 문서화가 되어 있어 기본적인 사용법을 이해하기 쉽다. 다만, 업데이트가 자주 이루어지지 않으며, 최신 기능 지원이 제한적이다.

  • 크기 라이브러리 크기가 작아 애플리케이션의 전체 크기에 부담을 주지 않으며, 빠른 로딩 속도를 유지할 수 있다.
  • qr.js NPM 문서

어떤 라이브러리를 선택?

라이브러리를 선택하기에 앞서, 행동대장 서비스에서 QR코드를 생성할 때 필요한 조건들을 나열해보자.

  1. QR 코드의 색상 변경이 가능할 것
  2. QR 코드의 사이즈 변경이 가능할 것
  3. 하나의 행사. 즉, 하나의 url에 하나의 QR코드가 생성될 것

위 조건 말고는 다른 것은 크게 중요하지 않았다. 하나의 행사에 url이 동적으로 계속 변경되는 것이 아니었기 때문이다. 위 조건에 맞춰 3가지 라이브러리 중 하나를 선택해보자.
일단, qr.js 제외. 업데이트가 12년 전이고.. 아직도 버전이 0.0.0이기 때문이다. 12년전보다 웹 생태계는 많이 바뀌었다고 들었기에 오래된 라이브러리 사용은 좋지 않다고 판단했다. 그리고 남은 두 라이브러리.. react-qr-codeqrcode.react는 모든 측면에서 우수하고 비슷한 스펙을 가지고 있다. 그래서 뭘 선택해야 하나 고민이 많이 들었는데.. 둘 중 하나를 제외하자면 react-qr-code였다. url의 상태가 지속적으로 변하는 서비스가 아니였기 때문에 동적 데이터에 장점을 둔 해당 라이브러리의 사용은 굳이였다.

따라서, QR코드 생성도 빠르면서 간단한 커스터마이징이 가능하고 지속적으로 배포가 이뤄지고 있는 qrcode.react를 선택했다. 그리고 무엇보다 qrcode.react는 가장 많이 사용되고 있기 때문에 자료를 찾기가 수월했다. 문서화도 매우 친절하게 잘 되어있고! ← 이게 가장 크다.

qrcode.react를 사용하여 행동대장 서비스에 QR코드 기능 추가하기

import { QRCodeSVG } from 'qrcode.react';
import getEventPageUrlByEnvironment from '@utils/getEventPageUrlByEnvironment';
import getEventIdByUrl from '@utils/getEventIdByUrl';

// ...

const QRCodePage = () => {
	const eventId = getEventIdByUrl();

	return (
		// ...
		<div css={QRCodeStyle()}>
			<QRCodeSVG value={getEventPageUrlByEnvironment(eventId, 'home')} size={240} fgColor={`${theme.colors.black}`} />
		</div>
		// ...
	);
};

export default QRCodePage;
  • qrcode.react의 QRCodeSVG 컴포넌트를 사용한다.
  • QRCodeSVG 컴포넌트의 value로 QR 코드를 생성할 url를 넣어준다. 그러면 QR코드가 생성된다.(초간단!) 해당 QR코드는 동일한 url이라면 변하지 않는다.

데스크탑 QR 코드로 초대하기

현재 데스크탑에서 header의 정산 초대하기 버튼을 클릭하면 내용 및 url 복사만 가능하다. 데스크탑에서도 QR code 기능을 추가하는 것이 좋을 것이라고 판단했다. 따라서, 데스크탑에 정산 초대하기 버튼을 클릭하면 DropDown을 통해 링크 복사하기QR코드로 초대하기를 선택할 수 있도록 했습니다.

import { useNavigate } from 'react-router-dom';
import { Dropdown, DropdownButton } from '@components/Design';
import getEventIdByUrl from '@utils/getEventIdByUrl';

// ...

const DesktopShareEventButton = ({ onCopy }: DesktopShareEventButtonProps) => {
	// ...

	const navigate = useNavigate();
	const eventId = getEventIdByUrl();

	const navigateQRPage = () => {
		navigate(`/event/${eventId}/qrcode`);
	};

	return (
		<div style=>
			<Dropdown base="button" baseButtonText="정산 초대하기">
				<DropdownButton text="링크 복사하기" onClick={copyAndToast} />
				<DropdownButton text="QR코드로 초대하기" onClick={navigateQRPage} />
			</Dropdown>
		</div>
	);
};

export default DesktopShareEventButton;

구현 결과

  • 변경된 행동대장 모바일 버전: 정산 초대하기

    모바일 버전 QR코드 초대하기1 모바일 버전 QR코드 초대하기2

  • 변경된 행동대장 데스크탑 버전: 정산 초대하기

    데스크탑 버전 QR코드 초대하기1 데스크탑 버전 QR코드 초대하기2

참고자료

우테코: Level4를 마치며 회고

9월에 Level4를 시작하여 어느덧 10월 마지막 주. Level4 종료까지 이틀을 앞두고 글을 쓴다.
참.. 언제 끝나나 간절히 바라기만 했던 Level3-4가 드디어 끝난다니.. 좋기도 하면서 한편으로는 아쉽기도 하다. 하지만 나는 여전히 Level4의 마지막 날인 금요일을 기다리고 있긴 하다.ㅎㅎ

Level3-4를 진행하면서 나는.

이미지

Level3-4 동안 나는 내가 이루고자 하던 것들을 이뤘을까? 그 당시에 나의 생각을 적어둔 것이 없어서 이뤘는지는 잘 모르겠다. 그래도 뭐 하나 이룬 것이 있었을 거라고 생각한다. 행동대장, 코드 읽기 실력 증가, 디버깅 실력, 협업 경험 등. 지금 생각나는 건 이정도?

그렇다면 나는 Level3-4를 진행하면서 어떤 감정이 가장 기억에 남는가 생각해봤다. 역시 아무래도 고통?인 것 같다. 반복적이면서 변하지 않고 휴식이 부족한 시간들이었다. 그렇기에 주말에 더더욱 쉬려고 혈안이 되어 있었던 것 같다. 나만의 건강한 패턴을 찾았어야 했는데, 그러지 못한 것이 참 아쉽다. 하지만 조금 덜 건강한 패턴이 자리잡은 이유는 “행동대장”이라는 팀에 대한 애정이 넘쳐서 그랬다고 생각한다. 더 좋은 서비스를 만들고 싶고, 더 유저가 편하게 사용할 수 있도록 생각하고 또 생각했었다. 그래서 일도 많고 탈도 있었지만, 모두가 놓지 않고 나아가려고 했기 때문에 지금의 행동대장이 있을 수 있었다.

가장 기억에 남는 감정은 고통이지만 그 사이 사이에 즐겁고 행복한 기억들도 많았다. 행동대장 프론트들이 일정에 치여서 다 같이 노래 흥얼거리며 정신줄 놓고 코딩하던 순간, 데모데이 전날에 항상 밤 새서 개발하던 순간, 코치님들에게 서비스에 대해 칭찬 받았던 날, 맛있는 점심 먹으러 가기, 석촌호수 산책, 최종 데모데이 방탈출 진행, 준의 알맹이 워크숍 수업, 데일리 스크럼 시간에 소알맹을 즐겨준 행동대장 팀원들 등등.. 이런 순간들이 있었기 때문에 힘들었지만 견뎌낼 수 있었다. 물론 막바지에 건강을 조금 잃긴 했지만…

나는 Level3-4를 지내면서 무엇을 얻었을 까? 메인 감정 키워드가 ‘고통’이었던 만큼 얻은 것은 ‘인내’ 라고 생각한다. 이 심란하고도 답답한 순간들을 그저 견디면서 인내할 수 밖에 없었다. 우테코를 그만 둘 수는 없으니까.
그렇다고 가만히 있던 것은 아니다. 이 순간들을 조금이나마 개선하기 위해서 계속해서 걸어나갔다. 멈추지 않았기에 성장할 수 있었다.

요즘 드는 생각들

여전히 나는 걱정이 많다. 주변사람들이 많이 쓰는 토스나 우아한 형제들, DH에 나는 지원하지 않거나 열을 다하지 않았다. 현재의 내가 부족한 것들을 너무나 잘 알기 때문이다. 그래서 지원한다고 좋은 결과가 오지 않을 것이라는 걸 확신했다. 이게 어쩌면 회피일 수 있다. 우형 채용 신청에 대해 고민하면서 나는 지금 이 압박의 순간을 회피하기 위해 이유를 찾아냈던 건 아닐까? 생각을 많이 했다.
누군가는 회피라고 할 수 있다. 그렇다면 난 부정하지 않겠다. 하지만, 나는 지금의 내 선택이 틀렸다고는 생각하지 않는다. 자신감 없는 상태에서 이력서와 포트폴리오를 쓰고 코테 준비를 한다면 좋은 성과가 나지 않을 것을 알기 때문이다. 물론 좋은 성과만을 좇는 건 아니다. 하지만, 내가 가진 이 기회를 잘 적절한 시기에 사용하고 싶다. 사용하지 못 할 수도 있지만 이 기회를 그냥 일반 쓰레기로 처리하지 않고 최소한 분리수거라도 하고 싶다.

앞으로의 취업 준비가 참 막막하다. 다들 뛰어가는 것 같은데, 나 혼자만 걸어가는 느낌이다. 하지만, 언제나 나 자신에게 누누히 하는 말이 있다. 남들과 비교하지 말자. 각자만의 속도가 존재하는 것이다. 무엇이든 비교하기 시작하면 행복해질 수도 있지만 그만큼 불행해질 수도 있다. 그러니 조급해하지 말고 나의 패턴을 찾아서 조금씩.. 조금씩… 나아가자.

Level4의 행복한 순간들

우테코 복지

이미지1 이미지2

이걸 참 복지라고 말하기에는 교육기관이라 애매하지만? 우테코 후드집업과 런던 베이글!!을 복지로 받았당.

코치님들(포비, 준)과의 회식

이미지

무려 고기를 먹으러 갔다. 여기서 코치님들께 좋은 이야기도 많이 들었고 앞으로의 취업에 도움이 될만한 것들도 많이 들었다. 그리고 포비, 준이랑 같이 사진도 찍었다. 고기가 참 맛있었고.. 행동대장 영상도 찍고.. 유익하고 재밌는 시간이었다.

소알맹 : 소하의 알맹이를 찾아서

이미지1 이미지2 이미지2

준의 알맹이 찾기 워크숍을 들으면서 깨달은 것들이 너무 많았다. 나의 알맹이를 찾아야 지치지 않고 살아갈 수 있다고 받아들였다. 그래서 나는 나의 알맹이를 찾고자 했다. 첫 시도는 행동대장 데일리 스크럼 시간에 한 팀원을 인터뷰한 내용으로 퀴즈를 내는 것이었다. 퀴즈를 만들기 위해 한명씩 따로 인터뷰를 진행하는데 이게 또 미묘하고 재밌다. 사실 아직도 어색한 팀원들이 존재한다. 이는 어쩔 수 없는 것 같다. 그런데 이 인터뷰를 하면서 해당 팀원에게 들었던 궁금증을 해결할 수 있었다. 또한, 이전에는 몰랐던 이 사람의 진면목을 알아갈 수 있었다. 내가 기획했지만 여러모로 나에게 많은 도움을 준 활동이었다.
그리고 팀원들이 퀴즈를 적극적으로 재밌게 참여해줘서 너무 고마웠다. 누구 하나라도 좋아하지 않았더라면 중간에 포기했을 텐데.. 즐겁게 임해줘서 너무 행복했다.

여전한 사람들

이미지

우테코를 다니면서 가장 잘 한 일은 Level1때 10명이 같은 조가 되었던 것이다. 내가 의도해서 만들어진 사람들은 아니지만 이는 다시 없을 행운이었고 기쁨이었다. 앞으로 남은 생일자 11월과 1-2월에 꼭 잊지 않고 모였으면 좋겠다.

최종 데모데이 : 행동대장

이미지

위는 내가 만든 행동대장 메인 포스터이다. 사실 메인으로 만든 생각은 아니었다.. 토다리가 만들던 카드뉴스 컨셉에 맞게 방탈출 소품을 위해 만들었는데.. 어쩌다 보니 메인 포스터가 되었다. 그리고 은근 찰떡이다(?) 내가 만들었지만 잘 만들었군. 흠

이미지1 이미지2

우리의 귀여운 행댕이 스티커… 우리 팀에 금손 웨디가 있어서 정말 다행이다. 이 스티커는 진짜 너무 귀여워서 행복했다. 그리고 타 팀원들에게도 우리 스티커가 가장 반응이 좋지 않았을까.. 흠흠^^ 귀여워서 이뻤던 행댕이가 이번 스티커를 통해 더 너무너무 좋아졌다!

이미지1 이미지2 이미지2 이미지2 이미지2

나름 매우 열심히 준비한 최종 데모데이!
우리 팀은 준비한 이벤트가 무려 “방탈출”이다..! 다 같이 아이디어 회의를 한 후, 내가 방탈출 시나리오를 작성했다. 그리고 방탈출을 위한 소품들도 웨디와 함께 직접 만들었다. 웨디가 그려주면 내가 잘라서 입체적으로 소품을 만들었다.
방탈출을 다들 너무 즐겁게 참여해줘서 행복했다! 또한, 방탈출 난이도도 별 3개중 2.5 정도라 어느정도 밸런스를 잘 잡게 짠 것 같아서 마음에 들었다 ^>^ 역시 다년간 크라임씬과 대탈출, 여고 추리반을 섭렵한 나. 헛으로 본게 아니었다. 후후.

이미지

행동대장 Level4까지 종료!
앞으로 Level5부터는 어떻게 될지 확정된 것은 없다. 이번주에 DH와 우형 서류 제출 마감이라 다들 엄청 바쁘다. 그래서 다음주로 미뤄뒀다. 나는 아직 행동대장 서비스를 조금 더 개선해서 우테코 7기들이 유용하게 쓸 수 있도록 하고 싶은 욕심이 있다. 그러나 그 방향은 각자 다르게 생각하고 있을 것이다.
우리 행동대장이 어떻게 되던간에 나에게는 협업이 뭔지, 팀 프로젝트를 하는 이유에 대해 알려준 팀이다. 프로젝트를 진행하며 협업 방식도 정말 많이 변경했고 그 과정에서 FE와 BE간의 의견 차이도 존재했다. 또, FE 끼리도 의견차이가 존재하기도 했다. 이런 것들을 어떻게 해결해 나갈지 알려줬다. 서로가 생각하는 것을 이야기하고 하나씩 수용과 포기를 하며 8가지를 1가지로 만드는 것. 내 욕심을 모두 충족할 수는 없기에 포기하는 법도 배웠고, 나의 주장을 적극적으로 어필하는 방법도 배웠다.

Level4가 끝나간다니.. 참 행복하면서도 믿기지 않는다. 그래도 다음주부터 하루 수면시간 8시간을 보장할 수 있다는 것에서 너무 행복하다.. 이제 지옥같은 출근길과 야간 운전을 하지 않아도 된다.. 밤 늦게 운동하러 가지 않아도 되고.. 내가 하고 싶은 공부들을 할 시간도 생긴다..
한 편으로는 내가 게을러지지 않기 위해 어떻게 해야 할까 고민도 많이 든다. 이건 이번주에 계속 고민해봐야 겠지!

이제 진짜 남은 한달! 우테코 생활 알차게 잘 마무리 해보자! 아쟈쟛!