[TIL] AWS Amplify 빌드 실패 오류 해결하기

1. 발단

최대한 빨리 기능 구현을 완료한 다음에 내가 할 수 있는 한은 열심히 리팩토링을 해보겠다는 생각으로 기업협업 2주 만에, 아니 설연휴 빼면 5일 만에 기능 구현을 빠르게 완료하고 백엔드 통신까지 완료했다. 백엔드 통신을 하면서 난 에러를 해결하는 것까지 해서 5일 만에 빠르게 완료를 하고 나니 이제 test서버와 stage서버에서 확인해보는 일만 남았으므로 내 브랜치를 먼저 test브랜치에 merge해서 test 서버에 업로드를 하고, test 브랜치를 stage 브랜치에 merge해서 stage서버에도 업로드를 해보았다.

아마 빌드하는 데 시간이 좀 걸릴 테니까 조금 있다가 확인해봐야지!

그러나 잠시 후에 test서버와 stage 서버를 각각 들어가보았는데 전혀 업데이트가 되어 있지 않았따. 이럴수가...?

AWS 계정은 내가 직접 볼 수가 없기 때문에 관리를 하고 계신 대표님께 말씀드려서 확인을 해보았더니 빌드에서 무언가 에러가 나서 빌드부터 실패가 떠 있었다. 로컬에서도 잘 돌아갔는데 어디에 문제가 있는지 잘은 모르겠지만 일단 dependencies쪽에 문제가 있는 것 같았다. 일전에 Styled-Components를 설치할 때에도 자꾸 디펜던시 에러가 나서 설치가 잘 안 되는 바람에 강제 옵션을 주어서 설치를 한 적이 있는데 그때 만난 디펜던시 에러가 AWS 빌드에도 영향을 주나 싶은 생각에 어떻게 해야 할지 대표님이랑 둘이서 머리를 잠깐 맞대봤지만 뾰족한 수가 없었다.

그래서 일단 최대한 문제 원인과 해결책을 알아보려고 에러 메시지를 전달받아서 찾아보기 시작했다.

2. 에러 메시지

409 verbose stack Error: exited with error code: 128
409 verbose stack at ChildProcess.<anonymous> (/root/.nvm/versions/node/v14.18.1/lib/node_modules/npm/node_modules/pacote/lib/util/finished.js:12:19)
409 verbose stack at ChildProcess.emit (events.js:400:28)
409 verbose stack at maybeClose (internal/child_process.js:1058:16)
409 verbose stack at Socket.<anonymous> (internal/child_process.js:443:11)
409 verbose stack at Socket.emit (events.js:400:28)
409 verbose stack at Pipe.<anonymous> (net.js:686:12)
410 verbose cwd /codebuild/output/src504828881/src/amongArts
411 verbose Linux 4.14.252-195.483.amzn2.x86_64
412 verbose argv "/root/.nvm/versions/node/v14.18.1/bin/node" "/root/.nvm/versions/node/v14.18.1/bin/npm" "install"
413 verbose node v14.18.1
414 verbose npm v6.14.15
415 error Error while executing:
415 error /usr/bin/git ls-remote -h -t ssh://git@github.com/ngokevin/debug.git
415 error
415 error Warning: Permanently added the ECDSA host key for IP address '15.164.81.167' to the list of known hosts.
415 error Permission denied (publickey).
415 error fatal: Could not read from remote repository.
415 error
415 error Please make sure you have the correct access rights
415 error and the repository exists.
415 error
415 error exited with error code: 128
416 verbose exit [ 1, true ]

위의 에러 메시지는 도커 상에서 표시해주던 길고 긴 에러 메시지 중에서 주목해야 할 부분만 가져온 것으로, 특히나 더 주목해야 할 부분은 여기이다.

415 error /usr/bin/git ls-remote -h -t ssh://git@github.com/ngokevin/debug.git
...
415 error Permission denied (publickey).
415 error fatal: Could not read from remote repository.

이걸 보면 ssh 관련 권한 문제라는 것을 알 수 있다. 하지만 처음엔 어떻게 해야 할지도 몰랐고 저게 무슨 문제인지도 몰라서 삽질을 여러 번 했다...

3. 삽질

첫 번째 삽질. 로컬 컴퓨터의 node 버전 다운그레이드

내 컴퓨터의 node 버전을 한 번 확인해보고 AWS 서버상의 node 버전과 맞추어 보는 게 어떻겠냐는 제안이 나와서 내 컴퓨터의 node 버전을 확인해보았다.

이전의 node 버전

$ node -v
v16.14.0

내 컴퓨터의 node 버전은 최신 LTS 버전이어서 AWS 서버상의 node 버전인 14보다 훨씬 높았다. 그래서 문제가 생긴 것 같지는 않았지만 일단 기존에 설치된 node.js를 삭제하고 AWS 서버상 node 버전과 정확히 맞추어서 다운그레이드를 했다.

현재의 node 버전

$ node -v
v14.18.1

하지만 이렇게 한다고 아무것도 되지 않을 거란 것은 처음부터 자명했던 사실이라 다시 빌드를 시도했다가 장렬하게 실패!

두 번째 삽질. 문제가 되는 라이브러리를 사용한 코드 수정

문제가 된 라이브러리는 VR쪽 라이브러리인데 해당 라이브러리를 사용하여 구현된 코드에 문제가 있을 수도 있다는 말에 잘 작동될 때의 구현 코드로 다시 덮어주기로 했다. 그래서 곧장 코드를 덮어씌우고 해보았지만 결과는 여전히 실패!

세 번째 삽질. package-lock.json에서 문제가 되는 라이브러리의 engines 수정

두 번의 삽질이 실패로 돌아가자마자 계속해서 구글링을 해보고 있었는데 마침 문제가 된 레포지토리의 issue 탭에 있는 글 하나가 눈에 띄었다. issue를 오픈한 사람도 나와 비슷한 문제를 겪은 것 같아서 답글에 달린 내용들을 쭉 읽어보니 아래의 내용을 발견했다.

package.json에서 해당 라이브러리의 engines 부분에 있는 npm 버전이 지원되지 않는 버전이라서 그럴 수 있다는 내용이었다. 해당 내용은 우리 프로젝트에서는 package.json이 아니라 package-lock.json에 있었고, 어떻게 해야 할까 고민하다가 그냥 단순하게 지원되는 버전 부분을 ">= 2.15.9"로 수정해버렸다. 그러고는 요행으로라도 제발 되길 바라면서 다시 서버에 올려보았는데 결과는 역시나 실패!

네 번째 삽질. 명령어 입력해보기

어쨌든 ssh와 관련이 있는 문제인 것 같은데 정확히 어떻게 해결하면 좋을지 모르겠어서 계속 구글링만 해보고 있는 와중에 대표님께서 한번 아래와 같은 명령어를 쳐보라고 하셨다.

git ls-remote -h -t ssh://git@github.com/ngokevin/debug.git

원격 레포지토리의 ssh를 연결하는 명령어인 듯한데, 해당 명령어를 입력해봤자 아무런 반응이 없었다. 사실 그럴 줄 알았다.

4. 해결

컴퓨터가 말을 안 들을 때는 때리는 게 아니라 프로그램 종료하고 껐다 켜보고, 그래도 잘 안 될 때의 극단적 방법은 하드를 모두 밀어버리는 것이다. 마침 새로운 마음가짐을 갖고 새로운 시각으로 구글링을 해보았더니 나에게 한 번 밀어볼 용기를 준 버그 이슈에 대한 깃헙 이슈 쓰레드가 있었다.

1. 이슈1
   이 이슈의 질문 내용이 내가 겪고 있는 ssh 관련 npm install 오류였는데, 답변 중 하나가 이슈2의 내용과 동일한 것 같으니 이슈2를 참고하라는 것이었다.
2. 이슈2
   이슈2의 질문 내용은 이슈1과 동일한 것이었고, 이미 이에 대한 답변도 나와 있었다. 나도 똑같은 문제를 겪고 있는 상황이기 때문에 이슈2의 답변을 하나씩 보고 있었는데 드디어 도움이 되는 답변을 찾았다.
   

즉, npm 버전에 따라 git+ssh가 아니라 git+https와 같은 형태로 레포지토리 주소 연결이 되어 있어야 한다는 것이었다. 그래서 우선 AWS 상의 npm 버전은 6인데 다행히 내 컴퓨터의 npm 버전도 6이었기 때문에 package-lock.json과 node-modules 폴더를 모두 삭제하고 다시 npm install을 해보았다. 그랬더니 새로 생긴 package-lock.json에서는 이전에 git+ssh로 되어 있던 형식이 전부 github:로 변경되었다. npm 버전에 맞게 변경된 것을 확인하자 이대로 다시 서버에 올려보면 될 것 같다는 확신이 들어서 우선 test 브랜치에 병합해서 test 서버에 올렸더니 됐다!

하지만 stage 서버에서는 다시 빌드가 안 되는 일이 발생해서 무엇 때문인지 보려고 package-lock.json 파일부터 살펴보았다. 그랬더니 브랜치가 병합될 때 분명 Accept incoming change로 했는데 제대로 안 된 것 같았다. 그래서 다시 병합해봤는데, 또 제대로 안 되서 다시 하고, 다시 하는 삽질을 또 거치면서 드디어 빌드 성공!

이래서 버전을 맞추는 것이 중요하며, AWS가 꽤나 까다롭구나 하는 것을 느꼈다.