창천향로
4k
2018-04-26 13:02:49 작성 2018-07-11 12:43:08 수정됨
11
6776

3번째 직장에 오기까지 - 4. 두 번째 직장 #1


생애 처음으로 서비스 기업에서 개발을 시작하게 됐습니다.



(오예!)


서비스 기업에선 어떻게 개발하고 교육할까 두근두근한 마음을 안고 첫 출근을 했습니다.


이번 공채로 입사한 개발자 동기는 저 포함해서 3명이였습니다.

서로 어색한 인사를 나누면서 대기하다가, 각 팀의 팀장님들이 오셔서 각자 데려가셨습니다.


1~2주의 개발 교육이 있을 거라 예상했는데, 개발 교육 없이 바로 팀에 합류하게 됐습니다.


회사의 규모에 따라 서비스 기업이라도 신입 사원 개발 교육이 있을 수도 / 없을 수도 있다는 것을 알게 됐습니다.


제 자리에는 모니터 3대와 데스크탑 2대가 포장이 된 채로 있었습니다.

PC설치부터 OS설치까지 모두 직접 해야한다는 것입니다. 

'음..?' 라는 생각이 잠깐 스쳤습니다. 

개발자라면서 혼자서 윈도우, 리눅스도 설치 못한다는 말은 부끄러워서 할 수 없었습니다. 

(리눅스 설치를 생애 처음 시작해봤습니다.)


마음을 가다듬고 포장을 뜯기 시작했습니다.

인터넷망과 내부망 랜선을 각각 PC에 꽂고 2대중 1대는 윈도우를, 1대는 우분투를 설치했습니다.

각각의 드라이버를 다 잡은 뒤 개발 환경을 세팅했습니다.

개발 환경도 특별히 가이드가 없었지만, Java & Spring으로 개발한다고 하셔서 이전 회사에서 했던 것처럼 Java, STS, Maven을 설치했습니다.

일은 언제부터 시작하는 거지? 라는 생각과 함께 첫 날이 마무리됩니다.



4-1. 파일럿 프로젝트


출근 이틀째에 팀장님과 과제에 대해 이야기를 했습니다.


팀장님: 회사에서 책만 보니 심심하지 않나요?
저: 네
팀장님: 책보는 것 보다, 개발하시는게 더 편하시죠?
저: 네 ㅎㅎ 개발하는 게 훨씬 좋죠 ㅎㅎ

라는 대화가 끝나고 바로 과제를 받게 되었습니다.


스프링 부트를 이용해서 게시판을 2주 안에 만드는 것이었습니다.

본격적인 과제 스펙을 전달 받았습니다.

과제는 계층형 게시판이였고, 상세 스펙은 다음과 같습니다.



구현 기능

  • 계층형 댓글 게시판
    • 99 Depth까지 가능하도록
    • 댓글이 많아도 속도 저하를 최소화 할 수 있는 방법 적용
  • 기본적인 스크립트 공격 방어
  • 이미지 등록
  • 로그인/회원가입 등 기본적인 회원 기능


필수 기술

  • Java 8
  • SpringBoot
  • Git & Gitlab
  • Gradle
  • MySQL
  • Javascript


선택 기술

  • Hibernate
  • Grunt/Gulp 등 JS 빌드툴
  • Spring의 다양한 어노테이션 / 모듈
  • Freemarker 등 템플릿 엔진

(자세히 다 기억이 안나서 확실히 기억나는 부분만 작성했습니다.)


여기서 필수 기술은 무조건 사용해야 하는 기술이며, 선택은 사용하면 좋고 아니면 어쩔 수 없는 기술이란 설명을 들었습니다.


그리고 프로젝트 발표 때는 기능과 코드를 다 같이 리뷰하는 시간이란 이야기도 함께 들었습니다.

여러분도 한번 해보세요.
진짜 도움 많이 됩니다.
오라클에선 계층형 쿼리(start with 조건 connect by)를 이용하면 되지만, MySQL은 지원이 안되서 직접 구현해야 하는데 이걸 고민하는 게 생각보다 도움이 많이 됩니다.
(참고: managing-hierarchical-data-in-mysql)


처음 스펙을 들었을 때 "헉?" 이란 생각이 먼저 들었습니다.

게시판이 다 거기서 거기지 라는 생각으로 쉽게 생각했는데, 막상 과제 스펙을 보고 나니 "조금만 더 공부하고 할 걸" 이란 생각이 많이 들었습니다.

Git, SpringBoot, Gradle, Hibernate 등 대부분의 기술이 처음인 상황이라 "이들을 공부하고 적용하는데 기간을 지킬 수 있나?" 라는 생각이 들었기 때문입니다.

팀장님이나 다른 팀원분들은 제가 이미 Java & Spring을 1년간 경험해봤기 때문에 금방 할 거라고 생각하던 상황이라 좀 더 공부하겠다는 이야기를 할 수가 없었습니다.


급하다는 생각으로 부랴부랴 개발을 시작했습니다.

안 그래도 시간이 부족했는데, 사고가 한 번 났었습니다.


팀장님: 어??? 하이버네이트 안 쓰세요?
저: 네? MyBatis 썼는데요…?
팀장님: 헉.. MyBatis 쓰시는 분 처음봤어요;; 여태 신입분들이 다 하이버네이트 쓰셔서 당연히 쓰실 줄 알고 말씀 안드렸는데, 저희 회사 프로젝트 중에 Mybatis 쓰는 프로젝트 없어요;;; 하이버네이트로 진행하셔야 해요 ㅠㅠ
저: ……(그런 말 없으셨잖아요…)


이 대화가 끝나고 미치겠다란 생각을 하면서 부랴부랴 Mybatis로 구현된 부분을 다 걷어 내고, 하이버네이트로 전환을 진행했습니다.

안 그래도 허덕대고 있었는데, 이것까지 겹치니 발등에 불이 떨어졌습니다.

2주 안에 꼭 만들어야 한다는 이야기를 들어서, 매일 11시까지 진행하고 주말에도 출근해서 개발을 진행했습니다.


기능 리뷰 이외에 코드 리뷰도 함께 하기 때문에 마감 3일 전부터는 자체 코드 리뷰와 발표 자료를 만들기 시작했습니다.

첫 회사에서의 경험으로 어찌 됐든 이런 첫 평가가 앞으로의 회사생활에 큰 영향을 끼친다는 걸 알기 때문에 발표 자료도 잘 준비하려고 했습니다.


대망의 발표날이 다가왔습니다.

나름 준비가 된 상태라서 혹시 칭찬 받지나 않을까 하는 기대감으로 회의실로 입장했습니다.

각 팀의 개발자분들이 다 오셨기 때문에 긴장이 조금 됐지만, 그래도 자신감을 안고 발표를 시작했습니다.


그리고 말로 맞는다라는게 어떤 의미인지 알게 됐습니다.



저도 그렇고, 주변을 보면 신입 사원 프로젝트 발표 때는 기능 발표가 대부분이였습니다.

마치 학교의 졸업 작품 전시회 같달까요?

그러다보니 UI가 화려하고, 기획이 잘 되어 있고, 기본 기능이 잘 작동하면 칭찬을 아끼지 않는 걸 자주 목격하는데요.


여기에서는 철저하게 진짜 서비스 할 수 있을 수준으로 리뷰가 진행됐습니다.

  • 기본적인 스크립트 공격
  • SQL 인잭션
  • 로그인 및 권한 처리

등등을 모두 검토한 뒤 바로 프로젝트 코드 리뷰가 진행됐습니다.

JS부터 Java, Table 구조까지 전부 리뷰 되었습니다.


특히 제일 민망했던 기억이 하나 있습니다.

리뷰어: 이건 왜 쓰신거에요?
저: ~~~하려고 썼습니다.
리뷰어: 음.. 그기능은 이거 없어도 작동해요. 복붙하는 건 상관없는데, 알고 복붙하셔야죠
저: 넵..

이렇게 코드 한 줄 한 줄을 모두 검토하는 시간이었습니다. 

2시간 내도록 부족한 점을 듣는데, 등에서 땀이 계속 났습니다. 

"나 그래도 개발은 좀 하는 편 아닐까?" 라고 잠깐 착각했었던 제 자신감이 산산조각 났습니다.


1차 리뷰가 끝나고 나서, 2차, 3차는 팀장님에게만 리뷰를 받았습니다.


코드 레벨에서의 리뷰가 끝나고, 마지막 과제는 제가 만든 프로젝트를 리눅스에 배포하는 것이었습니다.

별도의 리눅스 서버를 받지 않고, VM Ware에 Centos를 설치해서 그 안에서 코드를 gradlew로 빌드하고 부트를 실행해봤습니다.


이때 nohup &을 처음으로 알게 됐습니다.

스프링 부트는 별도로 톰캣을 설치하지 않고, Jar를 실행만 하면 배포가 끝나는구나 라고 혼자서 감탄하기도 했습니다.


그렇게 파일럿 프로젝트가 끝나고, 동기들도 다 과제가 끝난걸 알게 되서 3명이서 같이 신림 백순대를 먹으러 갔습니다.

이런 저런 이야기하다가 파일럿 프로젝트 이야기가 나왔습니다.


이야기를 듣다가 깜짝 놀랬습니다.

동기들은 Spring은 커녕 Eclipse를 처음 쓰는데도 2주만에 만들어 냈던 것이였습니다.
(국비 교육도 안받고, 학교에서 C / C++ / PHP만 하다가 바로 입사한 케이스였습니다.)


저는 국비교육을 받았고, 약 1년간 SI 회사에서 Java & Spring을 했었지만 정말 빡빡했습니다.

헌데 이 친구들은 정말 모든게 다 처음인 상황에서 어떻게 2주 만에 만든건지, 코드의 퀄리티를 떠나서 정말 놀랬습니다.

제가 저 상황이였으면 도저히 그 시간 안에 못했을거란 생각에 기분이 좀 다운 됐습니다.


그래도 이제 하나의 허들을 넘었다는 생각에 동기들과 소주 한 잔하면서 재밌게 이야기하고 그날을 마무리 했습니다.


그리고, 드디어 본격적인 업무에 투입됩니다.



4-2. 다시 강의형 스터디로


본격적인 업무에 투입되면서 제가 속한 개발 팀의 규칙을 듣게 됩니다.

모든 develop 브랜치로의 merge는 MR(Merge Request)을 통한 코드 리뷰로만 진행된다는 것이었습니다.

Github에선 PR (Pull Request)이라고 하는데, Gitlab에선 MR (Merge Request) 라고 합니다.


정말 철저하게 코드 리뷰 기반으로 모든 기능 개발과 배포가 진행됐습니다.

진짜 코드 리뷰가 최고입니다. 여러분.
이게 없으면 주니어가 단기간에 실력 키우는 게 너무나 힘듭니다.
코드리뷰를 안 받게 되면 정말 자기 멋대로 코드 짜고, 혼자서 자화자찬하는 걸 자주 경험합니다.
자기 혼자 착각하는 걸 깨주는 건 코드 리뷰 밖에 없습니다.
주니어 분들은 무슨 수를 쓰더라도 코드 리뷰 하는 회사로 가세요 꼭!


첫 Feature 개발이 끝나고 MR을 통해 리뷰를 받았습니다.

저 보다도, 제 코드를 본 팀원 분이 더 당황하셨습니다.


그리고 "어? 이거 모르세요?" 라는 말을 계속 하셨습니다.

이때부터 저는 "어? 이거 모르세요?" 라는 말에 트라우마가 생겼습니다.


팀원 분들의 문제가 아니라, 제가 이미 경력이 1년이 있기에 어느 정도 할 줄 안다고 기대를 하셨기 때문입니다.

저와 이 회사에서 1년 근무하신 분들은 비교할 수 없을 만큼 많은 격차가 있었던 것이었습니다.

"똑같이 1년의 개발 경험을 갖고 있음에도 이렇게 차이가 날 수가 있구나" 라는 깨달음과 부끄러움이 함께 왔습니다.


1:1 리뷰든, 단체 리뷰를 하든 리뷰만 했다 하면 얼마나 아는 게 없는지 공개되는 상황이 연출 되니 너무 참기 힘들었습니다.

그래서 방안을 모색하기 시작했습니다.


Java, SpringBoot, ORM(Hibernate), Git, Linux, JS 등 모르는 게 너무 많았기 때문에 이것들을 한 번에 배울 수는 없다고 생각해서 가장 급한 불부터 끄자고 생각했습니다.


  • 당시 회사에선 개발자가 JS까지 담당하고 있었고
  • 모든 사용자 서비스는 Backbons.js 기반으로 IE7까지 지원하고 있었고
  • 관리자 서비스는 Angular 1, Bower, Grunt, Underscore등 다양한 JS 프레임워크/라이브러리들이 적용된 상태였습니다.


실제로 제가 주로 하는 개발도 JS가 많았는데, 아는 거라곤 jQuery 밖에 없었기 때문에 JS 공부를 먼저 하기로 결정했습니다.


몇 주간 혼자서 책 보고 예제 따라 치다가 이래서는 결국 남는 게 없다는 걸 깨닫고, 다시 강의형 스터디를 시작하게 됩니다.


네이버 카페에서 다음과 같은 강의형 스터디를 주최했습니다.



당시엔 MEAN(MongoDB, Express, Angular, NodeJS) 스택이 한창 유행할 때라 스터디원을 모집하는건 쉬웠습니다.


본격적으로 강의 준비를 시작하게 됩니다.

토요일 오전 9시에 진행 되기 때문에 최대한 평일에 발표 내용, 예제 코드, 상세 설명, 숙제 등을 준비해야만 했습니다.


회사에서의 야근이 잦아 평일 저녁엔 할 시간이 없어서 항상 출근 전 시간을 많이 활용했습니다.

출근시간이 오전 10시라서 아침 7시에 회사에 도착해서 10시까지 강의 준비를 했습니다.


그럼에도 시간이 굉장히 부족했습니다.

이미 다 알던 내용을 강의하는 게 아니라, 공부하면서 준비하는 거라 10~15시간으로는 제대로 마무리가 안 됐습니다.

그래서 금요일 저녁에는 항상 밤을 새고 토요일 강의를 하러 갔었습니다.


여자친구와 데이트가 끝난 후 저녁 11시부터 아침 8시까지 계속 준비하고, 9시부터 12시까지는 강의를 진행하고 나면 졸음이 쏟아졌습니다.

그래서 여자친구에게는 정말 미안한 일이지만, 토요일 오후 데이트 때는 항상 영화 보는척 하면서 잠을 잤습니다.


그렇게 7개월간 JS와 Java 강의형 스터디를 진행하면서 하나 하나 회사 기술을 이해하기 시작했습니다.



4-3. 유일한 사수의 팀 이동


조직 개편으로 4명이었던 개발팀 인원은 2:2로 나눠지게 되었습니다.

저는 팀장님과 한팀에서 근무를 계속 하게 되었습니다.

팀장님이 정말 실력이 출중하셔서 팀장님만 믿고 계속 열심히 하면 되겠다는 생각을 하던 차에 충격적인 소식을 듣게 됩니다.


팀장님이 팀 이동을 한다는 것이었습니다.

처음에 이 이야기를 듣고 이게 무슨 소린가 했습니다.

입사한 지 7개월 된 저 혼자 남겨진다니요.

팀장님과 함께 퇴근하던 길에 팀 이동을 할 수 밖에 없던 상황을 듣게 되니 납득은 할 수 있었습니다. 

하지만 그렇다고 해서 현재 제 상황이 나아지진 않았습니다.


정말 좌절했습니다.

당장 팀이 맡고 있는 서비스는 메인 / 회원 / 고객센터 / Mail / SMS / 이벤트 / 광고 등등 엄청 많이 있는데 이걸 어떻게 혼자 하라는 건지.


첫 번째 회사에서도 대리님과 둘이서 프로젝트 하던 중, 대리님이 이직하셔서 혼자서 프로젝트 완성과 운영을 진행 했었는데, 여기와서도 또! 혼자 사수 없이 일하게 되는 상황이 너무 황당했습니다.


이걸 나 혼자 어떻게 다 하지?
리눅스에서 log grep조차 제대로 못하는 상황에서 장애나면 어떻게 해결해야 하지?
Nginx도, 리눅스도, 쉘 / 파이썬으로 작성된 스크립트도, 비지니스 도메인도 어느 것 하나 제대로 못하는데 어떡하라는 거지

등등 별별 생각이 다 들었습니다.


앞이 깜깜했습니다.

이때부터 저녁에 잠이 잘 안 왔습니다.

매일 자정에 동네 거리를 돌아다녔습니다.


아니 왜 진작에 시니어 개발자 분들을 안 뽑았던 거지?
이 서비스들을 진짜 나 혼자 해야 하는 거라고???
퇴사해야 하나?
입사한 지 1년도 안됐는데 또 퇴사하는 게 말이 되나??


중간중간 지원할 만한 회사를 찾아보기도 했습니다.

그렇지만 지원을 못했습니다.


이미 첫 회사에서 10개월 만에 퇴사했는데, 두번째 회사에서도 7개월 만에 퇴사하는 건 말도 안된다고 생각했습니다.

커리어가 너무 망가질 것 같다고 생각했기 때문에 어떻게든 더 다녀야 된다고 생각했습니다.


회사 입장에서 못된 생각이지만, 제가 계속 다니기 위해 생각을 바꿨습니다.

못해도 2년은 버티자.
서비스 장애 나도 내 탓이 아니다.
이렇게 몰아 세운 회사 탓이다.

이렇게 생각하니 그래도 마음이 좀 편안해졌습니다.

"에라 모르겠다" 란 마음으로 앞으로의 일을 맞이하게 됐습니다.


그렇게 사수가 떠나고, 팀이 담당하던 서비스를 혼자서 개발하는 생활이 시작됩니다.

예상대로 본격적인 힘듦이 기다리고 있었는데요.

다음 편에선 팀 내 최고참 개발자가 된 이야기를 전해드리겠습니다.


긴 글 끝까지 읽어주셔서 감사합니다^^

아래는 제가 서비스 기업에 입사 전에 알았다면, 입사 후에라도 알았다면 좋았을 팁들입니다.



4-4. 서비스 기업 입사 후 팁


짧지만, SI에서의 개발을 경험하고 서비스 기업으로 이직 후에 가장 힘들었고, 아쉬웠던 점 2가지를 공유드리고 싶었습니다.

서비스 기업을 갔다고 해서, 차근차근 알려주는 환경이 아니라면 본인이 혼자서 다 배워야만 합니다.

그런 상황이 누구든 올 수 있기 때문에 아래 팁들을 참고하시면 좋을것 같습니다.



서비스 운영을 위한 전반적인 지식


자체 서비스를 운영하는 회사에선 어플리케이션 코드 작성만으로는 문제 해결을 할 수가 없었습니다.

웹 서비스의 전반적인 지식이 필요합니다.

SI에서 Java/Spring 코드만 작성했었던 제 입장에서 가장 부족했던 지식이었습니다.


저 뿐만 아니라, 주변의 많은 SI 개발자 친구들, 동생들, 형들을 볼 때마다 느끼고 있습니다.
Java & JS만 하는 경우를 정말 많이 봅니다.


이런 내용들은 오프라인 스터디에서도 다루는 주제가 아니기 때문에 좋은 사수를 만나지 않는 이상은 얻을 수가 없습니다.


그래서 이 지식들을 채워줄 좋은 책들을 소개 드립니다.


3권 모두 한 영역에 특화된 분들을 위한 책들이 아니라, 웹 서비스 개발을 하는 개발자를 대상으로 했기 때문에 읽으시는 데 크게 부담되지 않습니다.


서비스 기업을 노리시거나, 입사를 앞둔 입장이시라면 위 3권은 꼭 읽어보시길 추천드립니다.

다른 것보다 최소한 시니어 개발자분들의 대화가 어떤 의미인지 이해라도 할 수 있어야 하는데, 이 책들은 그런 면에서 큰 도움을 줍니다.


물론 이 책을 읽었다고 해서 갑자기 서버 영역의 전문가가 되지 않습니다.
(연애를 책으로 배운 것처럼)
장애 맞아가면서 본인이 운영 서버에 직접 삽질을 해봐야 늘기 때문에 이 책 읽었다고 아는 척 하시면 큰일납니다.


그래도 대규모 트래픽, 대용량 데이터 상황에서의 해결 전략에 대한 전반적인 지식을 알 수 있는 가장 쉬운 방법입니다.



디버깅 방법


위에서 이야기한 분들이 빠지는 또 하나의 함정인데요.

만드는 방법에만 집중하시고 디버깅 하는 방법을 놓치시는 걸 자주 봅니다.

서비스 기업에서 일의 절반 이상이 디버깅입니다.


여기서 이야기하는 디버깅은 단순히 IDE의 디버깅만 이야기하는 게 아닙니다.
개발 / 운영하는 환경에서의 전반적인 문제 해결 방법을 이야기합니다.

SI에서 개발할 때는 백지에서 제품을 만드는 일을 반복했었는데, 서비스 기업에서는 운영 환경에서 발생한 문제를 해결하는 게 반복된다는 걸 배웠습니다.


(이클립스 디버깅만 알아선 안됩니다)







by 창천향로 : http://jojoldu.tistory.com/ 


평소 공부한 내용을 정리하고, 세미나 후기를 기록하는 블로그입니다.





♣ 에디터 : 다음 편은 저자 연재 일정에 따라 이어집니다! :)

27
25
  • 댓글 11

  • 전재형
    4k
    2018-04-26 17:37:36

    굳굳. 정말 열심히 하셨군요

    0
  • Gibson USA
    708
    2018-04-26 22:21:20 작성 2018-04-26 22:33:17 수정됨

    저도 SI에서 서비스 업체로 재취업을 추진하고 있는데

    많은 참고가 될 거 같습니다.


    혹시 마지막에 추천해주신 웹 사이트 최적화 기법 이란 책을 대체 할 만한 책은 따로 없을까요?


    아무쪼록 이 좋은 내용을 남기기 까지 고생하신 점과 그 투지에 박수를 보냅니다.

    0
  • 꾸아앙
    1k
    2018-04-27 11:07:10

    와... 정말 실력도 좋아보이시지만...

    글작성하시는 능력이 정말 좋은것 같습니다

    저도 회사에서 잘한다소리 듣다가 깃헙 몇달 돌아다니다보니 깨닳음을 얻어서 퇴사하게 됐는데요

    코드리뷰가 정말 하고싶네요ㅜㅜ

    0
  • linja1
    178
    2018-04-27 12:39:48

    잘 봤습니다

    그리고 이거 모르세요???요거 물어본거 그냥 무시하셔도 되요 회사내에서 사용하는 코드와 방법론 등이 전부 달라서 경력 10년차도 입사하면 물어봅니다 신입에게 처음에 구조라든지 방법이라든지 툴 사용법 프로그래밍 규칙이나 방법 등이요 물론 대기업은 메뉴얼 있어서 던져주면 그거 보고 하면 되고요

    서비스 기업이시니 스킬보다 업무 익히시는데 중점을 두시면 됩니다 어차피 시간없고 바빠 죽겠는데 빨리 대응하려면 복붙해야죠

    어차피 생산성 높이기 위해서 다 그런거니까 너무 그런거에 신경 안 쓰셔도 되고요 업무, 디비 구조, 툴 사용법만 잘 익히면 됩니다

    0
  • 헬로우
    2018-04-27 14:53:39
    • 99 Depth까지 가능하도록

    혹시  이 부분 자세하게 알 수 있나요?

    100개가 넘어갈 수 도 있는데요.

    무슨 얘기가 있었는지 궁금하네요.

    0
  • 욥욥욥
    892
    2018-04-30 11:02:34

    정성스런 글에 추천 드립니다.

    좋은 내용 많지만 애초에 좋은 사수나 팀이 없으면 쉽지 않다는게 씁쓸한 부분이네요.

    0
  • Majestic
    1k
    2018-04-30 16:33:39

    감탄했네요..

    1년차면 사실 복붙해서 만들어는것도 잘 한다고 느껴집니다.

    그런데 그 시간에 리눅스와 배포와.. 다들 정말 잘하시네요.. 동기분들도 미칠정도로

    제가 봤을때 이 정도 실력이면 만3년 이상이라고 해도 될 충분해 보입니다...


    0
  • beling
    680
    2018-05-03 10:51:35

    오 개발자 이야기를 드라마화 한다면 이분 글을 바탕으로

    0
  • 라이라
    1k
    2018-05-03 21:13:01

    어서 다음편 보고싶어요 

    0
  • 소록
    655
    2018-06-06 10:31:55

    글 너무 잘보고있습니다 처음부터 다보았습니다 이렇게 경험담을 풀어주셔서 너무 감사드립니다 정말 많은 힘이되고있습니다 다음편 또 기대하고있습니다! 


    0
  • 사케마시따
    280
    2018-06-29 11:38:16

    안녕하세요 혹시 회사이름을 따로 알려 주실수는 있으신가요 좋은 회사인거같아서요 


    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.