카트 세이버(Cart Savior) - 농축수산물 가격 정보 웹 서비스- 개발 후기

프로젝트 소개

농수축산물 시세 보기 서비스 | 카트 세이버

카트 세이버는 농축수산물의 최근 평균 가격을 확인하는 반응형 웹 페이지입니다. 정부에서 제공하는 농수축산물 가격 정보 공공데이터를 가져와 작업을 했고 약 80개의 품목에 대해 평균가를 제공하고 있습니다. 이 포스팅은 2020년 4월부터 6월말까지 약 2개월에 걸쳐 진행된 개발 과정에 대한 후기입니다.

 

깃헙 링크

pje1740/cart_savior

개발에 사용된 모든 소스와 코드는 프로젝트 레포에서 바로 확인할 수 있습니다. 해당 레포의 위키에 들어가면 서비스와 관련한 상세 내용도 포함되어 있습니다.

 

아이디어

개발을 배우면서 얻는 희열 중 하나는 내가 쓰고 싶은 걸 내가 만든다는 점이 아닌가 싶습니다. 4월부터 두 달 가량 작업했던 카트 세이버 (Cart Savior - 정확히는 카트 세이비어지만 Cart Saver 와 비슷하게 보이는 것을 이용한 말 장난입니다 ;) 돈을 아껴주는 카트 구세주! 이런 느낌으로 이해해주시면 좋을 거 같습니다) 또한 개인적인 필요에서부터 출발한 프로젝트입니다. 장을 볼 때 식재료는 대체 얼마에 사야 적당히 잘 사는 걸까? 이걸 알려주는 서비스를 만들면 내가 쓰지 않을까?

이 아이디어는 제가 참가했던 2018년 오픈데이터포럼이라는 소규모 행사에서 2등을 수상했던 '소확장 - 소소하고 확실한 장보기' 기획안을 발전시킨 사례입니다. 그 때 당시도 2등을 수상했지만, 개발을 공부하던 때가 아니라서 만들어보지 못하고 기획서만 얌전히 드라이브에 간직하고 있었습니다. 다시 꺼내보니 이제는 도전해볼만할 거 같아 팀원들과 힘을 모아보기로 했습니다.

 

기술 요약

카트세이버는 반응형 웹 서비스로 웹, 모바일 모두에서 사용하기 용이하도록 제작하였습니다. 아무래도 장을 볼 때 사용할 서비스라면 모바일 편의가 가장 중요하다고 판단하여 모바일 디자인이 중심이었습니다. 아쉽게도 앱 개발자는 팀원 중 없어서 웹으로만 제작하였습니다. 역시나 가장 많이 받은 조언도 앱으로 제작해보는 것이었는데, 향후 앱 개발을 공부하게 되거나 앱 개발자를 알게 된다면 도전해볼 영역이 될 것 같습니다.

카트 세이버를 처음 시작하면서 협업 방식에 있어 도전해본 한 가지는 철저한 분업이었습니다. 프론트와 백을 확실하게 나눠서 각자의 작업 내용을 상세하게 모르더라도 머지를 했을 때 깔끔하게 동작하는 웹 서비스를 만들고 싶었습니다. 저는 이 프로젝트에서 백엔드 개발자로서 웹 프레임워크를 이용한 동작 구현, DB, 배포를 담당하였습니다.

사용한 기술 & 서비스

프론트: html, css, JavaScript, D3.js

백엔드: python3, pandas, flask, sqlite3, aws Elastic Beanstalk, Route 53

기타: Tableau, BeatuifulSoup, Freenom

버전 정보

파이썬으로 작업했기 때문에 가상환경 안에서 작업했고 아래는 프로젝트 가상환경에 설치했던 라이브러리 목록으로 pip freeze 한 내용입니다.

APScheduler==3.6.3
astroid==2.4.2
beautifulsoup4==4.9.0
bs4==0.0.1
certifi==2020.4.5.1
chardet==3.0.4
click==7.1.1
Flask==1.1.2
idna==2.9
isort==4.3.21
itsdangerous==1.1.0
Jinja2==2.11.2
lazy-object-proxy==1.4.3
MarkupSafe==1.1.1
mccabe==0.6.1
numpy==1.18.3
pandas==1.0.3
pylint==2.5.3
python-dateutil==2.8.1
pytz==2019.3
regex==2020.4.4
requests==2.23.0
six==1.14.0
soupsieve==2.0
toml==0.10.1
typed-ast==1.4.1
tzlocal==2.1
urllib3==1.25.9
Werkzeug==1.0.1
wrapt==1.12.1

 

데이터 선정

농축수산물 가격 데이터, 어떻게 구하지?

프로젝트를 시작할 때부터, 신선식품의 오프라인 판매가는 단기간 안에 우리가 수집할 방법이 없다고 판단하고 공공데이터를 사용하기로 했습니다. 이전에 오픈데이터포럼에서도 공공데이터를 활용한 서비스 방안에 대한 아이디어가 주제여서, 공공데이터 중 농축수산물 가격 데이터가 있는 걸 보고 소확장 서비스를 고안해냈습니다.

하지만 슬프게도, 그 때는 필요한 것이 다 있다고 생각한 데이터에 한계점이 많아 다른 데이터를 선정할 필요가 생겼습니다. 생각보다 가격을 조사한 데이터의 종류가 꽤 많아, 시장 위주의 데이터부터 경매가격까지 있어 나름대로의 조건을 정하고 탐색을 시작했습니다 (해양수산부 제공 데이터에는 오늘 아침 개복치의 경매가까지 나와있습니다 ^^;; 이건 또 너무 과하달까요...).

1. 농산물만이 아닌 농축수산물 모두가 골고루 들어있는 데이터
2. 품목 수가 너무 적지 않을 것 (20개 정도의 큰 틀로 수집한 데이터도 있었기 때문)
3. 최근까지 업데이트 되고 있는 데이터
4. API 로 제공되는 데이터

이런 기준으로 몇가지 선정해서 살펴보았고, 고르게 된 건 aT한국농수산식품유통공사의 일별 품목별 도·소매가격정보였습니다. 약 80개 정도의 품목이 있고, 그 수는 적지만 축산물, 수산물도 흔히 사는 품목이 추가되어 있어서 유의미한 결과는 나올 수 있겠다고 판단이 되었습니다.

백엔드 개발로 넘어가기 전에, 위 API를 실제 개발에 활용할 수 있는 형태인지 테스트 하는 과정에서 겪었던 몇 가지 어려움을 얘기해보고자 합니다.

일일 품목별 데이터와 HTTP 500 에러

한국농수산식품 유통공사에서 제공하는 API는 같은 데이터를 가지고 여러 형태로 제공되는데, 원래는 품목별 데이터를 가져올 생각이었습니다. 아무래도 검색어는 하나의 상품에 대해 들어올 테니, 그 상품만 딱 호출해서 출력해주면 완벽할 테니까요. 그러나 이상하게도 축산물 카테고리나 수산물 카테고리 데이터는 API를 호출할 때마다 심심찮게 http 에러가 발생하여 정확한 가격을 불러올 수가 없었습니다. 혹시나 해당 일자 데이터가 없는 것이 문제일까 싶어 부류별 데이터를 호출해보면 멀쩡히 있고, 입력 필드를 덜 적었나 싶어서 다 적어보아도 변화가 없었습니다. 결국 여러 API의 호출 결과를 테스트해본 결과, 일별 부류별 품목 데이터가 가장 명확하여 해당 데이터를 선정했습니다.

매일 나오는 상품이 다르네...?

신선식품은 계절성을 가집니다. 그렇다보니, 일별로 호출했을 때 오늘은 나오지만 한 달 전에나 어제는 나오지 않을 수도 있습니다. 하지만 API를 호출해서 쓰기만 하는 우리 입장에서는 그런 데이터가 무엇이 있는지 알 수 없다는 점입니다. 당일 데이터가 없는 상품이라면 최신일자를 기준으로만 보여주면 되니 날짜를 하나씩 과거로 거슬러 올라가며 API를 호출하는 방식을 생각했습니다. 여기서 문제는 분명 어제는 있지만 오늘은 해당 품목이 노출되지 않는다면, 이 데이터의 자료는 없다고 노출되는 것이었습니다. 초창기에는 이를 해결할 방법이 없어 넘어갔지만, 이는 이후 db를 붙이면서 해결을 했습니다.

웹 프레임워크 선정

왜 파이썬과 플래스크인가?

한 달 동안 라 피씬에서 C와 동고동락했지만 데잇걸즈 2기를 해서인지 마음의 고향은 언제나 파이썬... 이라기보단 입문의 과정이 가장 빠른 웹 프레임워크를 찾아다니던 중 파이썬 장고와 플래스크를 발견했습니다. 마침 파이썬을 복습하고 있기도 했고, pandas를 활용할 일이 있지 않을까 해서 언어는 파이썬을 고정하고 장고와 플래스크 사이에서 갈등했던 것 같습니다. 결론적으로 flask를 선택한 건 해당 프레임워크가 light-weight이고 입문의 벽이 낮았기 때문이었습니다. 저는 Treehouse 라는 구독형 개발 강의 사이트를 애용하는데, 이곳에서 flask 입문 강의를 제공한 것도 큰 이유였습니다.

Start Learning to Code with Treehouse | Plans & Subscriptions

혹시 Treehouse에 관심이 있으신 분들이 있을까봐 초대 링크도 함께 첨부합니다^^ 할인받고 싶어요...

그리고 정말 명성대로 flask는 입문이 쉽고 이해하기 어려운 부분이 크지 않았습니다. 강의는 각 잡고 딱 3일 동안 쉬지 않고 달려서 API 생성을 제외한 부분까지는 모두 완료했고, 그 정도만 알아도 지정한 루트(주소)에 따른 로직을 구현하여 사이트를 동작시킬 수 있었습니다. HTML과 연결하는 방식도 Jinja를 활용하기 때문에 직관적이고 검색을 통해 답을 찾기가 쉬웠습니다.

<form action="{{url_for('search_functions.search')}}">
    <input class="inp_search" type="text" name="search_text" id="" placeholder="오늘의 무 값은?" required aria-required="true"/>
    <button class="btn_search" type="submit"><span class="ir">검색하기</span></button>
</form>

검색창 구현 예시. 중괄호 두 개로 둘러싸인 부분이 Jinja template이고 이를 통해 flask의 함수에게 매개변수를 전달하거나 받아온 변수를 출력하거나 할 수 있다

@search_functions.route('/search', methods=['GET'])
def search(item_name="오류", item_price=0, date=None):
    """입력된 키워드를 기반으로 상품 리스트를 만들고 정보를 모아 리스트로 만드는 함수.
    이 함수는 검색창을 통해 키워드가 들어올 경우 실행된다."""
    search_key =request.args.get("search_text")
    search_key = key_replace(search_key)
    # search_key는 리스트 형태로 바뀐다. 검색어 전환 때문에.
    items_searched = []
    for key in search_key:
        items_searched.extend(get_all_items(key))
    # 검색 결과가 없으면
    if len(items_searched) == 0:
        random_keys = get_random_keywords()
        context = {'random_keys': random_keys}
        return render_template("search_no_result.html", **context)
    # item_price 테이블에서 items_searched 코드가 있는 최근일자 행을 조회
    items = get_items_from_price_table(items_searched)
    infos = get_info(items)
    session['list'] = infos
    # 금일자 dataframe에 해당 상품이 없으면
    if len(session['list']) == 0:
        random_keys = get_random_keywords()
        context = {'random_keys': random_keys}
        return render_template("search_no_result.html", **context)
    return render_template("search_list.html", list=infos)

검색을 눌렀을 때 실행되는 함수

세션

웹 프레임워크로 사이트 구동 로직을 처음 작성해보면서, 한 가지 골머리를 썩은 부분은 이전 페이지에서 보고 있던 정보를 다음 페이지에서도, 즉 하나의 뷰함수에서 사용한 변수를 다른 뷰 함수로 넘기는 방법을 몰라 한참 헤맸습니다. 기본 강의에서도 쿠키에 저장해두고 사용하는 방식만 소개해주었는데, 뭔가 사용법이 와닿지 않아 한참을 찾다보니 세션의 개념을 발견했습니다. 어떤 것이 더 효율적이고 권장되는 방법인지까지는 알아보지 못하고, 세션이 조금 더 직관적이어서 사용했던 것 같습니다. 나중에 되어서 알아보니 세션은 서버 단에, 쿠키는 클라이언트 단에 정보를 저장하는 차이가 있다고 합니다.

가상환경 virtualenv

파이썬을 처음 배울 때 virtualenv 의 존재에 대해서만 알고 있고 제대로 사용해본 적은 없었는데, 이번 프로젝트를 하면서 처음으로 필요성을 맛본 계기가 되었습니다. flask 강의를 살펴보면 가상환경을 만드는 것이 디폴트처럼 소개되고 있는데, 나중에 배포나 코드 공유 때 없었으면 머리가 아플 뻔 했습니다. 내 로컬 컴퓨터와 이 프로젝트의 라이브러리나 작업 환경을 완전히 분리해놓을 수 있고, 사용법도 비교적 직관적이라 requirements.txt를 만들 때 유용했습니다.

배포

정적 사이트는 깃헙을 통해 종종 배포해봤지만, 백엔드가 있는 사이트의 배포는 사실상 처음이었습니다. 웹인 만큼 로컬에서만 만들어놓고 만족하기는 싫어서 반드시 배포를 하고 싶었는데, 크게 잡은 목표는 두 가지였습니다.

1. 무료 도메인을 구매해서 사용하기 (도메인 이름에 wix, github, heroku가 있는 건 참을 수 없다...!)
2. 소스코드 업로드만으로 배포 완료

카트 세이버의 경우 플래스크를 붙여서 웹 프레임워크만 있었고, 웹 서버를 제가 직접 붙이진 않았기 때문에 이 부분을 알아서 해결해주는 호스팅 서비스가 필요했습니다.

Python Anywhere

Host, run, and code Python in the cloud: PythonAnywhere

처음에 알아본 것은 Python Anywhere 였습니다. 아무래도 소규모 파이썬 프로젝트에 가장 대표적으로 언급되는 무료 티어가 있는 서비스라 알아보게 되었는데, 치명적인 문제는 프리티어에서는 허가되지 않은 url은 urlib를 통해 접근을 막아둔 점이었습니다. 아무래도 국내 사이트는 대부분 화이트리스트에 포함되지 않기 때문에, 유료 티어로 업그레이드 하지 않는 이상 좋은 선택지는 아니었습니다.

Heroku

Cloud Application Platform | Heroku

Heroku의 경우 배포가 커맨드라인 몇 줄이면 끝날 만큼 간편합니다. 다만 초반 개발 단계에서 API 호출이 잦아서 애초에 속도가 느린데, AWS와 비교했을 때 속도가 많이 느려져서 아쉽게도 선택하지 못했습니다. 아마 향후 프로젝트에선 애용하게 될 것 같기는 합니다.

AWS Elastic Beanstalk & Route53

PaaS | 응용 프로그램 관리 | Amazon Web Services

AWS라는 이름은 개발에 입문하기 전부터도 워낙 들어왔기 때문에 언젠가는 꼭 사용해봐야겠다고 결심하고 있던 찰나, 1년 동안 무료로 사용이 가능하다고 하여 어떻게든 AWS로 배포를 해야겠다고 최종적으로 결정이 났습니다.

AWS Elastic Beanstalk 으로 flask app 배포하기(+무료 도메인 route53, freenom)

AWS Elastic Beanstalk, Route53과 Freenom을 이용해 Flask app을 deploy 하는 과정을 기록한 포스팅입니다. 세부적인 과정과 기술의 사용은 이 포스팅을 참고해주시면 감사하겠습니다.

One step further!

여기까지 작업한 것이 나름대로의 version 01 입니다. 총 한 달 간의 작업이었고, 42서울에서 진행한 program 42라는 대회에서 1등을 받게 되었습니다. 덕분에 저희가 사용한 데이터를 수집하고 API를 개발하신 AT 센터에 가서 실무진과 사장님도 뵙고 이야기도 나누는 좋은 기회도 얻었습니다.

이후에 어떻게 하면 더 개선할 수 있을까 고민을 하던 도중, 시간의 제약에 걸려서 해보지 못 했던 DB 부착에 도전해보기로 결심했습니다. version 02라고 할 수 있는데요, 여기서 저희가 추가한 것들은 다음과 같습니다.

• 일일 데이터를 저장할 수 있는 DB를 부착하여 속도 개선
• 한 줄 위키(구매 팁) 추가

겉으로 보기엔 바뀐 것이 많지 않지만, 내부 코드는 아예 싹 갈아엎는 개발이었습니다. 기존의 방식이 검색어가 들어오면 그 때 그 때 API를 호출하여 일일이 체크했다면, 버전2는 검색어만 받으면 모두 미리 저장된 db에서 추출해오는 방식입니다. API 호출을 미리해서 다 저장을 해두었기 때문에, 검색의 속도가 비약적으로 개선됩니다.

데이터베이스

원래는 MySQL을 공부하고 싶어 DB를 붙인다면 MySQL을 생각하고 있었습니다. 그러나 시간이 조금 제한되어 있어서 갑자기 클라이언트-서버 형태의 DB를 붙이기엔 익혀야 할 부분이 많았고, 무엇보다 로컬에서 작업하던 db를 AWS서 사용하려면 RDS 등을 통해야 해서 부가적인 툴이 많이 붙는다는 느낌을 받아 대안을 찾아보기로 했습니다. 그렇게 리서치를 하던 중 과거에 잠시 접한 적 있었던 SQLite를 발견하게 되었고 빠르게 방향을 돌렸습니다.

SQLite는 MySQL 이나 Oracle 과는 다르게 파일 형태로 db를 관리하게 되기 때문에, 이 db 파일을 소스 코드에만 포함하면 Elastic Beanstalk에서도 큰 문제 없이 동작합니다. 어떤 경우에 SQLite를 사용하는지에 대해서는 공식 사이트에서 자세하게 소개를 하고 있는데, 관련하여 블로그에 남긴 다른 글이 있으니 궁금하신 분들은 참고하시면 좋을 것 같습니다.

SQLite은 언제 사용하면 좋을까?

간단한 SQL 쿼리문은 작성할 줄 알기도 했고, ORM을 익히는 데 시간이 더 들 것 같아 코드에 바로바로 SQLite 쿼리문을 작성하여 넣는 방식으로 수정을 진행했습니다. 파이썬을 이용하여 db 파일을 연동시키고, 필요한 테이블과 데이터를 미리 세팅해두고, 라이브 서버에서 매일매일 가격 정보를 업데이트 하는 방식으로 동작시켰습니다.

db 파일로 작업을 할 때, 터미널로는 한계가 있어서 TablePlus 라는 서비스를 이용했습니다. 시각적으로 바로바로 표를 볼 수 있고, 쿼리문도 적용시킬 수 있어서 꽤 유용했습니다.

TablePlus | Modern, Native Tool for Database Management.

스케쥴러

최종 난제는 스케쥴러의 구현이었습니다. AWS 서버에서 특정 시간대나 특정 시간 간격마다 어떠한 동작을 실행하게 하고 싶을 때 어떻게 해야하는가. 제 경우는 당연히 db에 저장할 데이터를 불러와 db에 누적하는 것이었습니다. 업로드하는 시점에선 6월말까지만 데이터가 쌓여있는데, 가격 정보는 매일매일 업데이트가 되기 때문에 제가 관리하지 않더라도 알아서 누적이 되어야 했습니다.

AWS를 사용한다는 전제 하에 방법은 몇 가지가 있는데 대표적으로 발견한 것은 다음 세 가지였습니다.

1. cron.yaml 파일을 활용한다.
2. .ebextensions 폴더에 구성 파일 정보 중 cron을 포함한다.
3. apscheduler 라이브러리를 활용한다.

처음에 발견한 건 3번이었고, 최종적으로 적용한 것도 결국 3번입니다만, 왜 처음에 그냥 보고 넘겼는지는 저도 이해가 잘 가지 않습니다 (^^;;). 아마 AWS에 올려서 테스트를 해봐야 하는데, 안 되면 시간 낭비가 되니 AWS에서 공식적으로 제공하는 cron으로 알아보자! 가 됐던 거 같습니다. 1&2번은 AWS 서버로 하여금 cron job을 하게 하는 것이고, 3번은 flask app 안에다가 스케쥴러를 심는 거기 때문에 조금 다르긴 합니다.

1번은 기각된 것이, 업데이트 할 때마다 cron이 중복되는 문제도 있고, 제가 deploy한 인스턴스에선 불가능하다고 하여 넘기게 되었습니다. 2번은 공식 문서를 읽어보아도 빠르게 이해가 가지 않고, 크론탭 작성 방식에 대해서 확실하게 알고 있어야 작업이 가능하여 무산되었습니다. 시간이 부족했기 때문이죠. 아마도 시간적 여유가 있었다면 2번을 확실히 알아보고 진행했을 거 같습니다. 향후 EC2로 배포하는 프로젝트는 이 방법을 선택하려고 합니다.

3번은 AWS 서버 내에서도 잘 동작하는 건 확인했지만, 한 가지 치명적인 문제는 AWS 서버의 시간을 제가 알 수 없다는 사실이었습니다. 원래는 매일 오후 2시에 db를 업데이트하려고 했는데, 아마도 한국의 시간과 다른지, 지정해둔 시간이 되어도 업데이트가 발생하지 않았습니다. AWS 서버의 시간은 어디서 확인하는지 검색을 해보아도 명확한 답은 나오지 않아 interval 방식으로 빠르게 전환하였습니다. 결국 배포한 시점으로부터 12시간마다 최근 10일치 데이터를 업데이트하고 있습니다. 당연히 중복되는 (이미 넣은) 데이터는 무시합니다.

@app.before_first_request
def initialize():
    cron = BackgroundScheduler()
    # cron.add_job(fill_db.fill_price_data, trigger="cron", hour='14', minute='00')
    cron.add_job(fill_db.fill_price_data, trigger="interval", hours=12)
    cron.start()

우여곡절 끝에 성공시키면서 느낀 점 하나라면, 너무 많은 부분을 외부 서비스에 의존하기 시작하면 섬세한 작업이 힘들어진다는 것입니다. 직접 세팅을 하고 정말 빈 os 하나만 딱 빌린다는 느낌으로 서버를 빌린다면 어렵긴 하겠지만 자유도가 높아지겠구나, 하는 깨달음이 있었습니다. 내부 사정(?)을 모르니 답답함을 많이 느꼈던 작업이었습니다.

구글 애널리틱스

농수축산물 가격 정보는 저희만이 아니라 다른 사람들도 함께 보면 좋은 데이터라고 생각하여 완성한 이후 42서울 내에서 몇번 공유를 했습니다. 다만, 그 전에 작업한 것은 구글 애널리틱스를 붙이는 것이었습니다. 데잇걸즈 활동 당시, 선생님께서 만드신 사이트에 붙이는 과정은 본 적이 있지만 직접 만든 사이트에 적용해본 것은 이번이 처음입니다.

모인 데이터를 상세하게 읽는 방법은 모르지만, 단순하게는 DAU부터 이탈율이나 어떤 걸 검색해보는지 url을 통해 확인해볼 수 있어 흥미로웠습니다. 무료 툴이고, 제 기억으로는 main 페이지의 html 코드의 헤더에 구글 애널리틱스에서 제공하는 코드를 붙여넣으면 바로 연동이 되는 것으로 알고 있습니다.

회고

백엔드를 하나도 모르던 입장에서 1부터 10까지 모두 직접 찾아가며 한 프로젝트고, 직접 기획한 아이디어에서 출발하여 구현까지 완료했던 첫 프로젝였습니다. Program 42에서 1등을 하기도 하고, 이 프로젝트를 통해 좋은 분들도 많이 뵙게 돼서 과정도 결과도 의미 있었습니다.

무엇이든 만들고 나면 늘 아쉬운 점이 많습니다. 그래도 평소에 자기 칭찬에 인색한 저이기에, 아쉬운 점은 깃헙 위키의 회고에 잔뜩 적어두었으니 잘 된 점만 뽑아서 적어보면 이렇습니다.

• 초기 목표한 형태의 서비스를 어떻게든 시간 안에 구현한 점
• 철저하게 분업하여 효율적으로 작업한 점 (이건 같이 해주신 팀원분들 개개인이 너무 알아서 잘 해주신 게 컸습니다)
• Look, 즉 디자인을 소홀히 하지 않은 점 (디자이너이자 프론트엔드 개발자를 해주신 지영님 감사합니다 ^3^)
• 로컬 작업에서 그치지 않고 배포까지 마친 점
• 시간이 부족하면 빠르게 대안을 찾은 점

협업 방식은 다양하기 때문에 위의 내용이 또 어떤 경우 프로젝트의 완성도에 독이 될 수도 있다고는 생각합니다. 같이 작업하는 팀원들의 성향에 따라서도 극명하게 갈릴 것 같습니다. 그래도 이번 작업을 통해 데드라인과 분업을 대하는 제 자신의 태도와 성향을 많이 깨닫게 되었으니, 다음에 다른 사람들과 작업할 때는 더 성숙하게 타협을 할 수 있지 않을까 싶습니다.

 

written by 한땀코딩(sohpark@student.42seoul.kr)