작년에도 연말에 휘몰아치는 업무를 해내느라 겨우 1월에 정신을 되찾고 회고록을 썼었는데, 올해는 무려 2월이 되어서야 작년 회고록을 쓴다. 작년 회고록에서 내 개발자 생활은 "눈코 뜰새 없다."라는 표현이 참 어울린다고 했었는데, 올 해 역시 그 표현은 유효하다. (이번에도 글에서는 읽기 편하게 올해라고 표현하려고 한다.)
워낙 정리하면서 일하는 걸 좋아하는 성격이라 진작에 연간 업무에 대한 정리는 노션에 차곡차곡 쌓아왔었는데, 회고글은 미루고 미루다 이제야 쓰는 걸 보니 정리와 글은 또 다른 영역인가 보다. 앞으론 나를 돌아보는 글에도 부지런해야겠다.
시작하며
오늘 서점에서 ‘창피하지만, 일단 해봅니다.’라는 책을 샀다. 그 책의 일부에 이런 말이 나온다.
능력이 아니라 태도로 싸워라. 능력은 비교하기 쉽다.
능력이 아니라 업무에 임하는 ‘태도’를 소중히 할 것을 권한다.
태도는 다른 사람과 비교해서 우열을 가리는 것도, 시간이 흐르면서 쓸모가 없어지는 것도 아니다.
올해를 돌아보면 매 순간 모든 프로젝트에 최선을 다해 고민하고 연구하고 결과를 냈고 그만큼 성장했다. 그렇게 생각했을 때 나는 스스로 부족한 지식과 실수에 부끄러워한 적은 있어도 업무에 임하는 태도에서 스스로 부끄러웠던 적은 없다는 생각이 들었다.
우연히 본 이 책의 몇마디가 나의 2년 차 개발자 생활을 대변해 주는 것 같아 인용해 보았다.
회사 업무
| 개발 프로젝트 | 구분 | 날짜 |
| 상하위 업무 묶어보기 기능개발 | Task | 1월 ~ 2월 |
| 데스크탑 자동 릴리즈 채널 분리 | Electron | 1월 |
| 업무 그룹 기능개발 | Task | 3월 |
| 업무 그리드 (직접수정 및 편집, 리스트에서 바로 등록 등) 개발 | Task | 4월 ~ 6월 |
| 간트차트 리뉴얼 | Chart | 7월 ~ 9월 |
| 일렉트론 고도화 및 리팩토링 | Electron | 9월 ~ 10월 |
| mac m1용 pc앱 추가 및 공증 | Electron | 10월 |
| 업무 및 간트 리팩토링 - 상태관리 도입 | Task | 11월~ |
우리 회사는 프론트/백 같이 업무의 영역별로 일이 구분되지 않고, 기능과 프로젝트 단위로 일이 진행된다. 올해 진행되었던 프로젝트 중 가벼운 개선건은 제외하고 큼직한 업무들만 리스트업 해보았다.
이전 회고록을 작성했던 작년에는 회사 서비스 전체가 리뉴얼을 하는 대격변의 시기기도 했고 워낙 신입이기도 했어서, 누군가가 진행하던 프로젝트에 지원을 해주고 일부 기능만 맡아 진행한 업무들이 많았다. 하지만 올해는 스스로 생각했을 때 더 나은 서비스와 사용경험을 위해 필요하다고 생각되어 직접 추진했던 개선건도 많고, 기획적인 리뉴얼 건을 통째로 메인으로 맡아 이끌어가는 경우가 많았던 것 같다.
맡겨지고 추진하는 개발건이 중요해진 만큼 개발자로서도, 직장인으로서도, 누군가의 동료로서도 스스로 정말 많이 성장했다고 생각되는 한 해다.
모든 업무를 다 쓸 수는 없기때문에, 현재 맡고 있는 기능 중 올해 공들여 작업했던 몇 건에 대한 회고를 위주로 작성하려고 한다. 1년을 거쳐 현재 내가 맡고 있는 기능을 추리면 Task, Gantt, Chat, Electron이다.
채팅의 경우 자잘한 QA를 제외하면 크게 개선이나 신규 기능이 추진되지 않았고, 우리 협업툴 서비스의 핵심이라고 할 수 있는 Task와 Gantt를 기능적으로 갈고닦는 데에 공을 많이 들였다. 그리고 그 서비스를 배포하기 위한 PC앱용 프레임워크인 Electron의 메인 담당자로서 업무의 프로세스나 코드의 품질을 위한 개선에 시간을 많이 썼다.
1. Task
- 1차 개선: 상하위 구조의 탄생
우리 서비스는 프로젝트/업무관리가 핵심기능인데도 불구하고, 업무를 모아보는 기능을 사용하는 사용자가 많지 않다는 아이러니한 상황이 이어졌었다. 그 상황을 개선하기 위해 진행되었던 첫 프로젝트는 '상/하위 업무'를 묶어보는 기능이었다.
왼쪽이 지금 보면 정말 허전한 개선 전의 '업무' 기능의 모습이다. 기존에는 각 프로젝트에 속해있는 업무들은 정렬 기준에 맞게 리스트형으로만 뿌려지고 있었는데, 여기에 상/하위라는 구조가 생기면서 필터, 정렬, 상하위 세 가지를 모두 고려한 오른쪽의 리스트 구조가 필요하게 되었다. 프론트, 백 작업보다는 db 쿼리의 성능에 초점을 맞춘 개선이 필요했다. 이때의 정렬은 서로의 상하위 관계 매핑만 신경 써서 해주고, 성능체크만 하면 되었기에 (3차 개선에서의 작업에 비하면) 그렇게 어렵지 않았다.
- 업무 조회속도 성능
- 관계테이블 인덱스 추가
- NOT EXIST / EXIST / IN / NOT IN 등 중복처리 효율성 체크
- 필터와 업무트리구조와 정렬의 우선순위 고려
- 상위업무와 하위업무의 정렬 따로 적용 (PARTITION, RANK 활용)
- 추가 묶음기준 확장성 고려
1차 개선 배포 이후, 감사하게도 업무기능의 사용자가 늘어났고, 그만큼 엔터프라이즈 기업들의 추가 커스텀 요청도 늘어났다. 내가 개발한 기능을 많은 사용자들이 잘 쓰고 있다는 것에서 오는 뿌듯함은 이루 말할 수 없다. 계속해서 추가 요청이 들어와도 계속 지치지 않고 열심히 개발할 수 있는 원동력은 나에겐 그 뿌듯함인 것 같다!
- 2차 개선: 그리드의 탄생
많은 커스텀 요청 중 묶어보기 다음으로 추진되었던 것은 '엑셀'과 같은 그리드형으로 리스트를 개선하는 것이었다.
각 업무가 가진 업무명, 업무 상태, 진척도, 마감일, 담당자 등의 항목을 바로바로 리스트에서 수정할 수 있고 (왼쪽사진), 하위 업무를 추가할 수도 있게 개발을 하게 되었다(오른쪽). 조회만 가능했던 리스트에 수정 기능을 붙이는 건 새로운 기능을 만드는 것이나 다름없었다. 이때 주어진 기간은 2개월뿐이라서 정말 급하게 api를 찍어내고 프론트 처리를 했다. 지금 생각해 보면 아무리 급했어도... 그렇게 찍어냈으면 안 되었다..
배포 이후 사용자들은 잘 사용하는 것 같았고 기획이나 CX팀에서도 만족하는 듯하였으나, 나에게는 이 작업 시기가 스스로 불러온 재앙(리팩토링)의 시작이 되었다.
- 3차 개선: 드래그의 탄생
또 다른 커스텀, 드래그의 개념이 탄생했다.
정말 엑셀과 비슷하게 각 칼럼을 자유롭게 옮기고, 너비를 조정하고, 업무들 간의 순서를 조정할 수 있게 되었다. 시간관계상 jQuery UI 라이브러리의 draggable로 구현했는데, 그 라이브러리를 통해 구현 할 수 있는 기능의 끝판왕이 이번 프로젝트가 아니었나 싶다..!
하지만 이 당시 프론트보다 더 중점적으로 고민하고 고려해야 했던 부분은 '필터'와 '컬럼정렬'이었다.
우리 서비스의 리스트는 각 '컬럼'을 기준으로 오름/내림차순을 이미 설정할 수 있었기 때문에, 두 기능 간 충돌이 나지 않도록 작업해야 했고 '필터'에 의해 리스트에서는 조회되지 않는 업무들도 드래그로 인한 순서변경에 영향을 받아야만 했다.
그렇게 리스트 DB 순서 처리 방식에 대해 엄청나게 연구하게 되었고, 데이터 처리에 대해 정말 깊이 있게 고민하게 되었다. (이후 사내 db스터디를 만들고 싶어진 이유이기도 했다.)
이 부분은 나중에 제대로 정리해서 포스팅을 하는 게 나을 것 같다. 시도해 봤던 방법은 간략히 아래와 같다.
- 리스트 순서처리를 저장하는 다양한 방법 (필터로 인해 모든 업무가 나오지 않는다는 전제)
- 소수를 이용한 방법
- bigint를 사용해서 적절하게 간격을 두는 방법
- next_id를 이용해서 다음 컬럼의 순서를 저장하는 방법
- 기본적인 int를 사용하는 방법
- 4차 개선: 그룹의 탄생
이제는 그룹도 탄생했다! 프로젝트 안에서도 그룹을 만들어서 업무를 넣어놓을 수 있게 되었다.
개발자의 입장에서 위 기능을 보면 묶음의 기준이 '프로젝트 - 그룹 - 상위업무 - 하위업무'로 4 뎁스가 되고,
이 중에 필터링과 정렬에 해당하는 리스팅을 해야 하는 굉장한 구조가 된 것이다.
게다가 접었다 펼치는 토글이 있어서, 한 리스트에서도 각 그룹별 페이징이 따로 적용되어야 했고 모바일까지 들어가는 기능이라 여러 가지를 고려하여 개선이 필요했다. 페이징... 웹 개발을 배우는 사람이라면 정말 당연하고 숨 쉬듯이 기본적으로 배웠을 것이다. 나도 그렇게 생각했다가 큰코다치는 경험을 했다. 역시 세상에 쉬운 개발은 없다.
- 배포완료, 리팩토링 시작!
사실 업무 고도화 프로젝트가 시작되고 초반에는 '이젠 정말 쓰는 데에 크게 불편함이 없겠다!'라고 느꼈었는데 한번 건드리고 나니 더 부족한 부분이 나도 보이고, 기획자도 보이고, 디자이너도 보이고, 제일 중요한 건 고객들도 보이고!
그렇게 모두의 바람이 들어간 끝도 없는 개선이 시작된 것 같다.
결과적으로 배포는 완료되었으나 4차에 걸친 개선을 진행하다 보니, 1차에서 고려하지 못한 점이 2차에서 보이고, 2차에서 고려하지 못한 점이 3차에서 보이는 신기한 경험도 했다. 2차 개선때 까지만 해도 사용자들의 개선/추가 기능 요청은 많은 사용량으로부터 나오는 것이라 생각하고, 그 뿌듯함을 원동력으로 삼아 개발했지만 4차 개선까지 이르렀을 땐 '과연 사용자들의 니즈만 충족시키는 개발을 하고 있는 게 맞을까?'라는 생각이 들기도 했다.
상황상 기능적인 개선을 위주로 생각하고 빠르게 개발하여 배포할 수밖에 없는 상황이기도 했지만, 그만큼 자연스럽게 디테일적인 구조나 구현방법을 세워놓고 시작하지 못한 데에서 오는 아쉬움도 있었다. 우리 개발조직엔 아직 프론트엔드 프레임워크가 없이 개발되고 있기 때문에, 잘 짜인 코드가 아니라면 추후 유지보수를 함께 하게 될 개발자들의 시간을 낭비시키는 일이 될 수도 있기 때문이다 (아무리 이번 작업을 혼자했더라도).
그래서 11월부터는 제일 심각하다고 생각되는 프론트 소스 리팩토링을 시작했다.
여러 곳에서 하나의 데이터를 바라보고 있는 만큼, 현재의 jquery로 attr로 상태를 관리하고 직접 dom 요소를 변경해 주는 방식보다는, 별도의 스토어에서 데이터를 잘 관리하여 화면은 데이터를 잘 따라다니게 하는 요즘의 프레임워크 상태관리방식이 효율적일 것 같아 상태관리 방식 변경을 첫 번째 목적으로 했다. 그리고 누구나 보더라도 이해하기 쉽고 수정하기 쉬운 구조화된 코드를 위해 모듈화를 두 번째 목적으로 시도했다.
다른 개발건들과 병행하느라 아직 80% 정도에서 멈추고 마무리를 못하고 있으나, 성공적으로 마무리되면 포스팅해 보자!
2. Gantt Chart 리뉴얼
위에서 업무 고도화 프로젝트에 대해 너무 구구절절 회고한 것 같아 간트차트 리뉴얼은 짧게 쓰려고 한다....!
업무 리스트를 개선한 김에, 해당 리스트가 왼쪽에 노출되고 오른쪽에는 wbs기능을 하는 간트차트를 추가하여
기존의 간트차트를 대체하는 것이 해당 프로젝트의 목적이었다.
개선 전 간트차트에 오류는 많았지만, 워낙 내부에 유틸성 함수가 잘 구조화되어 있어 리뉴얼이 수월했다. 그리고 앞선 업무 개선 작업들로부터 이벤트 처리를 수도 없이 경험한 덕에, 차트 기능을 만들 때 도움이 많이 되었다.
간트차트 고도화에서 개발적으로 주안점을 두었던 부분은 아래와 같다.
- 모듈화
- 기존 소스에 추가하는 방식이 아닌, 필요할 때만 모듈 형태로 붙일 수 있도록 구조화.
- 드래그 시 날짜 이동 단위 처리 개선
- 마우스의 이동과 DOM의 변화, update 기준값이 따로 관리되지 않고 한 번에 작동하도록 구현.
- 그룹/상하위/필터/정렬 등의 기준을 '전체업무'와 동일한 수준으로 변경
- 동일한 수준으로 동작하지만, DB에서는 따로 관리되도록 분리.
- 가로스크롤과 세로스크롤의 동작 개선
- "좌측스크롤/우측스크롤/하단스크롤 + 오름차순/내림차순 + 이동 전 기간 내 다음 페이지 존재 여부"
세 가지 기준에서의 각 조합별 상황에 대한 케이스를 명확하게 하여 개발
- "좌측스크롤/우측스크롤/하단스크롤 + 오름차순/내림차순 + 이동 전 기간 내 다음 페이지 존재 여부"
3. Electron 고도화
입사초기부터 지금까지 가장 꾸준히 맡겨져 유지하고 있는 업무는 서비스를 Electron이라는 프레임워크를 통해 빌드하고 배포하는 일이다. 그때부터 약 1년이 넘는 시간 동안 보안적으로도, 생산성의 측면에서도, 성능적인 측면에서도 모든 게 리팩토링이 필요하여 꼭 고도화해야겠다고 매번 다짐해 왔지만, 혼자 다른 개발건을 병행하며 진행하기엔 무리였다.
그러다가 혼자 하던 일을 둘이서 하게 된 시기가 생겨, 그 시기를 이용해 바로 리팩토링을 추진하겠다고 계획을 세워 팀장님께 말씀드렸고, 계획대로 진행하게 되었다.
고도화는 의도했던 대로 보안적으로도, 생산성의 측면에서도, 성능적인 측면에서도 성공적으로 진행되었다.
업무의 4차 개선의 늪에 치이는 시기 직후라 그런지, 이런 R&D 업무를 하게 되면 오히려 힐링이 되고 묵은 때를 벗기는 기분이라 좋았다. 하지만 내가 개선을 하고자 하는 일에 누군가가 처음으로 같이 도와주는 만큼, 밤이나 낮이나 어떻게 잘 해낼 수 있을지에 대한 고민으로 가득 차있었다.
체력적으로는 무리가 있기도 했지만, 결과적으로는 이때 추진하기 정말 잘했다는 생각이 든다.
무엇보다 가장 보람 있던 순간은 올해 리뉴얼 이후 새로 입사하여 일렉트론을 함께 하고 있는 파트원 두 분께서, 리뉴얼 이전 소스를 보면 경악하고 후 소스를 보고 안정감을 취하실 때!!!!이다. 나의 시간투자로 다수의 생산성을 높일 수 있다는 건 꽤 근사한 일이라는 걸 느낀다. 그리고 내가 입사했을 때 겪었던 당혹스러움을 지금 입사하시는 분들이 겪지 않아도 된다는 사실이 개발자의 생산성 측면에서 뿌듯해해도 되는 성과라고 생각했다.
앞으로 더 개선해야겠다고 느낀 걸 리스트업 해놨는데, 파트원 두 분과 성공적으로 마무리해서 내년 회고록에 꼭 성공 후기가 나오길 바란다!
업무 외 활동
작년엔 너무 일에 치여서 자기 계발이나 개발 공부, 혹은 기타 활동에 소홀했던 것 같아서 올해는 일이 아닌 주위와 나를 더 신경 쓰는 게 목표 중에 하나였다.
1. 개발자 매거진 readIT 기고
예전에 개발에 뛰어들기 전, 인재개발팀에서 근무하던 당시 내가 기획했던 교육을 주제로 인사관리협회 잡지에 기고를 했던 적이 있다. 그때 잡지 기고를 통해 우물 안 개구리에서, 우물밖을 나가지는 않아도 뛰어서 볼 수 있는 개구리(?)가 된 기분을 받았었다.
그래서 이번에는 교보문고에서 출판하는 개발자 매거진에 도전했는데 감사하게도 바로 기회가 찾아왔다. 회사에서 대외적으로 글을 쓰는 사람이 처음인데 괜찮을까 걱정도 있었지만, 주위 분들도 긍정적으로 생각해 주시고 응원해 주셔서 다행이라는 생각, 그리고 참 감사한 동료들과 일하고 있다는 생각이 들었다. 그리고 우리 회사에 입사하기 전 공부를 위해 교보문고에서 개발서적을 샀다가 이 글을 읽었다는 신입 개발자 분들을 봤을 땐, 더 긍정적인 글을 자주 써야겠다는 생각도 들었다.
다음에 또 기회가 있다면 기고해서 꾸준히 주기적으로 연재를 해봐야겠다.
2. 사내 SQL 튜닝 스터디 모집&운영
사실 개발을 처음 배울 때부터 DB에 관심이 워낙 많았고, 설계에도 흥미를 느꼈었다. 주위에서 DB를 취미로 설계하고 튜닝하는 동아리가 있다고 해서 가입을 고민하기도 했었다.
하지만 막상 취업을 하고 나니 내가 하는 일과 큰 관련이 없으면 공부를 깊게 못하게 되는 것 같아 급한 불부터 끄고자 SQL에는 손을 놓고 있다가, 위에서 언급한 업무개선을 위해 SQL 튜닝이 필요해졌다. 취미로 하는 것과는 달리 업무에 바로 적용해야 했기에 이왕이면 함께 고민을 하고 성장을 하기 위해 사내 스터디를 모집하기로 했다.
매일매일 개인 공부 후 발표 자료를 작성해서 발표하는 방식이라 꽤 빡빡한 일정으로 진행이 되었는데도,
같이 참여해 주신 팀원들이 너무나 적극적이어서 (나보다 더...!) 존경심을 느꼈고 서로 성장하는 기회가 된 것 같다.
다음에도 공통의 관심사로 스터디를 모집해 봐야겠다.
3. 일렉트론 정보공유 페이지 개설
입사 초부터 혼자 하던 업무를 팀원이 늘어나며 업무를 분배하게 되었다.
누군가 이 일을 함께하게 된다면 도움이 되었으면 해서 과거부터 모아 왔던 설치 방법에서부터 업무에 참고해야 할 것들, 그간의 히스토리 등을 모아 페이지를 만들어 공유했다.
결과적으론 총 3명이 파트로 함께하게 되었는데, 업무에 유용하게 참고를 하고 계신지는 물어보지 않아 모르겠지만 함께 정보를 공유해 나갈 수 있는 공간이 마련된 것 같아 그 자체로 의미가 있다고 생각한다.
4. 플로우 테크 세미나 참여
팀장님께서 사내 테크 세미나 문화를 만드셨다. 입사할 때만 해도 개발팀이 15명 내외였는데 2년 만에 36명이나 되어 서로 공유할 기회가 적어졌는데, 정보 공유할 기회를 만들기 위해 시도하신 것 같다.
나도 아직 모르는 게 많지만, 새로 들어오신 20명의 개발자 분들이 있으시기 때문에 내가 아는 도움이 될 수 있는 정보는 공유하면 좋겠다 싶어 'Electron 구조 파악하기 (격리와 통신)'이라는 주제로 발표를 진행했다.
발표를 위해 더 꼼꼼하게 알아보게 되는 점도 있어서, 앞으로도 도움이 되는 정보나 경험은 꾸준히 공유해야겠다.
끝내며
1.
난 2년 차가 막 지난 주니어인데, 벌써 리더의 역할로 연말부터 두 명의 파트원분들과 함께하게 되었다.
사실 회사에 적응을 먼저 했다의 차이지 개발연차로는 실력차이가 크게 느껴지지 않는 1~2년 차이로 선임 후임을 나눈다는 게, 처음엔 역할놀이(?) 같은 다소 창피한 일이 아닌가라고 생각한 적도 있었다. (서두에 나온 ‘창피하지만, 일단 해봅니다.’라는 책을 빨리 읽어야겠다)
하지만 개발자와 과거의 경력을 모두 통틀어 사회생활 6년의 과거를 되돌아보면, 하루라도 먼저 들어온 사람의 바짓가랑이라도 붙잡고 이것저것 물어봐서 업무를 해내고 싶었던 기억이 분명히 있다. 그리고 상황상 누구에게도 도움을 요청할 수 없는 시기도 있었는데, 그때 굉장한 슬럼프를 겪기도 했다. 반대로 좋은 선배들을 만나 갑자기 도움을 받고 성장해 본 경험도 있다.
그래서 누군가에게 업무적으로 손 내밀고 싶을 때 적어도 누군가 옆에 있고, 업무와 사회생활에 작은 방향성이라도 제시해 주는 것, 내가 하는 일에 대한 가치를 알아주는 사람이 있다는 것, 말로 조언해주지 않아도 본보기가 되는 사람이 옆에 있다는 것 등등이 얼마나 회사생활에서 큰 영향을 미치는지를 알고 있다.
내가 지금 실력적으로 부족하다는 건 어찌 보면 개발자로서는 평생 느껴야 하는 것일 수도 있다.
하지만 그것과는 별개로, 누군가에게 영향을 미칠 수 있는 위치가 맡겨진 이상 그들의 성장에 좋은 영향을 줄 수 있는 리더이자 동료로 더 노력해야겠다는 생각이 많이 드는 연말이다.
2.
작년 이맘때쯤 1년 차 개발자 회고록을 작성했었다.
첫 개발자로서의 시작이 꽤나 불안하고 어려웠었지만 치열했던 1년이었고, 나와 비슷한 길을 걸어가려는 사람에게 좋은 이정표가 될 수도 있겠다는 생각으로 작성했던 첫 개발자로서의 회고록이었다. 그때는 지금보다 개발에 대한 철학(?)이나 가치관이 생기기 이전이었기 때문에, 좀 더 날 것의 감정과 상황이 담겨있던 것 같다.
그러한 감정이 전해졌는지 이런 댓글이 남겨졌다.
이 댓글이 오히려 나에게 동기부여 그 잡채가 되었다,,!
사실 회고록을 쓰고 끄적끄적 글을 쓰는 게 벌써 익숙해졌는지 '그저 지금을 기록을 하는 것이다'라는 생각으로 글을 쓰곤 한다. 하지만 2년 전, 잘 다니던 회사를 퇴사하고 1년의 개발 공부 끝에 취업준비를 하던 시절의 나를 생각해 보면 정말 불안했고, 다른 개발자들의 글을 읽으며 용기를 얻었고, 나도 누군가에게 좋은 영향을 주고 싶다는 생각을 했다. 그랬던 내가 누군가에게 글로써 용기를 줄 수 있는 사람이 되었고, 기록할 수 있는 무언가가 있고, 함께하는 사람들과 응원해 주시는 분들이 있다는 게 정말 감사하다. 그런 의미에서 이 글을 보는 당신도!! 글을 쓰는 건 정말 추천 추천 대추천이다!!
앞으로도 계속 많은 사람에게 좋은 영향을 주는 사람이 되고 싶다 :)
'Moment' 카테고리의 다른 글
| 3년차 개발자 회고록 (+ 2023년 하반기 회고) (2) | 2024.01.07 |
|---|---|
| 3년차 개발자 회고록 (상반기) (0) | 2023.07.16 |
| (기고문) 함께 일하기 위한 도구, 협업툴 개발자의 질문 (2) | 2023.01.27 |
| 1년차 개발자 회고록 (2) | 2022.01.12 |
| 퇴사 후 회고록 (1) | 2021.01.02 |
