회고

API 명세서 작성 마무리

어제 완성하지 못했던 API 명세서를 작성 완료했다. 유저와 주문 도메인을 중심으로 팀원들과 회의를 통해 세부 사항을 구체화했다. 함께 논의하며 놓친 부분들도 보완할 수 있었다.

인프라 설계서 작성

제출 기한이 촉박하여 인프라 설계를 맡게 된 나와 다른 팀원 한 명은 인프라 설계서 작성을, 나머지 두 명은 ERD와 API 명세서의 최종 검토를 담당했다. 먼저 레퍼런스 자료를 검토한 후 사용할 플랫폼들을 함께 나열했다. 10분 정도 남은 제출 시간 내에 툴을 익히는 것은 어렵다고 판단해, 경험이 있는 팀장님께 도움을 요청해 자료를 바탕으로 신속하게 설계서를 완성할 수 있었다.

개발 컨벤션 설정

본격적인 개발에 앞서 컨벤션을 설정했다. 팀장님의 예시와 각자의 경험을 공유하며 이번 프로젝트에 적합한 브랜치 전략과 커밋 네이밍 컨벤션을 결정했다. 또한 GitHub의 이슈 기능을 활용하여 기능, 설정, 버그, 리팩토링, 문서와 같은 라벨을 설정하고, 이슈를 참조하여 커밋을 작성하는 방식을 도입했다. 이와 더불어 PR과 병합 시 사용할 커밋 템플릿도 마련했다. 처음 사용해보는 방식이라 걱정이 되기도 했지만, 협업의 효율성을 높일 수 있을 것 같았다.

공통 모듈 논의

공통 모듈 작성을 위해 패키지 구조를 설정했다. 3 Layer와 도메인 중심의 패키지 구성 중 어느 방식이 프로젝트에 적합한지, 공통 기능을 Common 패키지에 둘지 논의했다. 이 과정에서 팀장님이 과거에 사용했던 예제를 보여주셨고, 이 방식을 도입하기로 했다. 예외 처리와 response를 효율적으로 관리할 수 있는 방법은 정말 유용해 보였고 신기했다.

역할 분담 및 인프라 구축

각자 역할을 분담하여 팀장님은 공통 모듈 제작, 팀원 C는 GitHub Organization 및 레포지토리 설정, 팀원 Y와 나는 인프라 구축을 맡았다. 인프라 CICD 플로우를 먼저 작성해본 후, 작업 순서와 역할을 나누었다. AWS 계정이 필요한 작업을 맡게 되었으며, 추가로 SSL 인증서 구현에도 도전해보기로 했다.

예기치 않은 문제

본격적으로 EC2 인스턴스를 생성 하자마자 문제가 발생하여 잠시 작업이 중단되었다.

트러블 슈팅

문제 상황

오류 메시지: Permission denied (publickey)

AWS EC2 인스턴스를 생성하고 발급받은 SSH 키로 접속을 시도했지만, Permission denied (publickey) 오류가 발생했다. 키를 인식할 수 없어 인스턴스에 접근할 수 없는 상황이었다.

원인 추정과 해결 과정

1. 시도해본 해결 방법들

직전 프로젝트에서도 유사한 문제로 접근이 불가능했던 적이 있어, 트러블 슈팅 기록을 참고하여 다음과 같은 방법들을 순차적으로 시도했다.

AWS 인스턴스 상태 확인
포트 설정 확인
Pem 키 권한 문제 확인
Pem 키 위치 문제
SSH 디버그 옵션 사용
사용자 이름 명시

그때는 6번에서 문제가 해결됐었지만, 이번에는 모든 방법이 먹히지 않았다.

2. SSH 설정 파일로 별칭 적용

다른 사람의 해결 사례를 참고하여 ~/.ssh/ 경로로 PEM 파일을 이동하고, ~/.ssh/config 파일을 생성하여 인스턴스 접속 설정을 추가했다.

Host oneeat
    HostName ec2-13-124-66-135.ap-northeast-2.compute.amazonaws.com
    User ubuntu
    IdentityFile ~/.ssh/oneeat-server.pem

그런 다음 ssh oneeat으로 접속을 시도했지만 여전히 같은 오류가 발생했다.

3. 키 파일 에이전트에 추가

ssh-agent를 사용하여 키 파일을 에이전트에 추가하고 다시 SSH 연결을 시도해 보았다.

eval `ssh-agent`
ssh-add ~/.ssh/oneeat-server.pem

그러나 여전히 문제가 해결되지 않았다.

4. 기존 키 파일 삭제 및 새로운 키 발급

기존의 oneeat-server.pem 파일을 삭제한 후, EC2 콘솔에서 새로운 키 페어를 생성하여 다운로드했다. 새로운 PEM 파일에 400 권한을 설정하고 재접속을 시도했으나 Permission denied (publickey) 오류가 계속 발생했다. 이후 키 이름을 바꾸어 재발급해 보았으나, 여전히 오류가 해결되지 않았다.

5. EC2 콘솔에서 키 페어 가져오기 시도

내가 가지고 있는 공개 키를 인식하지 못해 반대로 생각해 키 페어 파일 등록을 하고 가져오기를 시도했다. 하지만 “이미 존재하는 키 페어”라는 오류가 발생하며 실패했다.

6. 인스턴스 재시작

혹시나 하는 마음에 인스턴스를 재시작했지만, 문제는 여전히 해결되지 않았다.

7. 기본 정보 재확인

다시 처음으로 돌아가 키 페어 이름이 정확한지, 퍼블릭 DNS 대신 IP 주소로 접속해 볼 수 있는지, 인스턴스 연결 페이지의 사용자 이름을 다시 확인해 보았다. 하지만 여전히 Permission denied 오류는 그대로였다.

8. 사용자 데이터 추가

자료를 검색하던 중, 이미 생성된 Amazon EC2의 키 페어 변경하기 글을 발견했다. 키 페어 변경을 했었기 때문에, 합리적인 의심이 들어 사용자 데이터에 공개 키를 추가해 보았다.

새로 생성했던 PEM 키의 공개 키를 확인했다.

ssh-keygen -y -f oneeat.pem

인스턴스를 중지하고 사용자 데이터(User Data)에 아래 내용을 추가했다.

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [users-groups, once]
  users:
    - name: {유저 네임}
      ssh-authorized-keys:
        - {공개 키 정보}

인스턴스를 다시 시작한 후 새 PEM 키로 접속을 시도하니 성공했다.

결론

문제의 원인을 정확히 알았으면 더 좋았겠지만, 일단 해결 방법만 찾은 상태다. 추측하자면 인스턴스를 만들 때 발급받은 키가 제대로 등록되지 않은 게 원인인 것 같다. 근데 다른 사용자들은 괜찮은데 나만 이러는 게 좀 이상하다. 그래도 좋게 생각하면 터미널이랑 좀 더 친해졌고, AWS가 제공하는 옵션들도 더 알아볼 수 있었다. 특히, 인스턴스에 사용자 데이터를 설정해서 활용할 수 있다는 것도 이번에 처음 알게 됐다.